As attacks on the open-source ecosystem continue to grow in various forms, the need to step up security efforts for developers has become paramount. Prominent software supply-chain attacks and breaches have been making headlines [ , ], and attackers have exploited vulnerable open-source components like in the wild. 1 2 Apache and Struts Recently, we have also seen attackers targeting developers and the developer infrastructure in a newer approach to maximize their chances of a successful outcome. Whether it be next-generation supply chain attacks like the or to deliberately introduce vulnerabilities in the Linux kernel code, threats against developers are consistently evolving and come from least expected places. Codecov incident social engineering attempts The introduction of vulnerable code in an upstream repository or a published release - whether intentional or not, can threaten the security of the wider software supply chain, especially for open-source components that are trusted and consumed by thousands. As such, owners of open source ecosystems bear a growing responsibility towards helping developers publish software that is free of common security vulnerabilities. Although commonly known solutions such as “ ” exist, these are meant to be used too late in the process - that is, to verify if an already published dependency or software component being used by a developer contains any known vulnerabilities after the component is already pulled downstream. npm audit This approach also effectively shifts the responsibility of security to the developer without explicitly informing them about this responsibility. Meaning, it’s for you to discover that a tool called “npm audit” exists and then decide whether you’d like to run it. This is a tall ask for mature security practice companies, let alone every developer. Although individual responsibility is key to strengthening security for everyone, traditionally, upstream has aimed to be neutral. But, now, in light of these new issues, it is key that we step up the game. Currently, no open-source software repository provides upfront checks for the package publishers to run something against their code to spot security vulnerabilities before releasing it for consumption by the larger open source community. When, in fact, many supply-chain issues could be avoided by a simple preflight check before hitting publish. Over run Java, and as such, security vulnerabilities in commonly used Java libraries and third-party components can have a wider impact on various applications and devices. 5 billion devices As open-source usage has rapidly increased over the last few years, so has the attack surface-eyed by the adversaries. If vulnerable releases could be controlled right at the source before they make their way into the repository and the distribution pipeline, damage arising from commonly exploited vulnerabilities can be contained. According to , a typical application contains 38 known OSS vulnerabilities, on average. Furthermore, thousands of packages are getting published daily to leading open-source software repositories. Sonatype’s 2020 State of Software Supply Chain report How about scanning at the source before your software gets distributed? Leveraging automated scans before publishing Although educating newer developers to follow secure coding practices is important, with the huge volume of vulnerabilities reported every year, it becomes nearly impossible to keep track of what vulnerabilities lurk in your application manually. Moreover, even if your application had no known vulnerabilities, there remains a chance its dependency or dependency of a dependency used within your application had known vulnerabilities. All of this becomes tedious to monitor without an automation solution in place. As such, Maven Central, the largest Java ecosystem, has introduced a built-in vulnerability scanner, called , for publishers and maintainers of open-source software at no cost for life. Sonatype Lift The distinctive feature of this change is that Java developers publishing their components to Maven Central do not have to take any extra steps - the scans occur during the normal process automatically. “Starting this week, we will be scanning all staged repositories on OSSRH automatically as you’re publishing things to Central,” says Sonatype CTO and co-founder Brian Fox. “You should start seeing reports via email providing details on security issues in your dependencies for things released through OSSRH,” continues Fox in last week’s . posting Therefore, introducing automatic pre-flight security checks before a component enters the distribution stage can help spread awareness among software publishers and highlight insights that might have otherwise been missed. Bringing awareness to security issues lurking in applications in this way safeguards the wider software supply chain from known bugs and vulnerable dependencies. Initially, the offering will primarily focus on detecting security vulnerabilities in Java, Scala, and Android packages published to Central. However, features like detecting licensing issues are expected to be added in the near future, according to Sonatype. As the need to shift security left has become indispensable, more OSS repository maintainers should follow Maven Central’s lead in prioritizing security vulnerability scans before a newly published release gets distributed to a wider audience. What is good for maintainers is good for open source at large - and ultimately is good for the entire industry leveraging this ecosystem. Ecosystems like central have become critical infrastructure, and Maven Central is the first to take a stance to help protect publishers. Helping publishers avoid known issues translates to a more secure and trusted supply chain.
