The open-source development ecosystem has experienced a significant rise in malicious software components, putting enterprises on high alert for software supply chain attacks.
Malware is infiltrating the open-source software development ecosystem at an alarming rate, according to a new report from software supply chain management firm Sonatype. The company has tracked over 500,000 new malicious packages since November 2023 across the popular Java, JavaScript, Python, and .NET packages registries.
New malicious components account for over 70% of around 700,000 malware packages the company has tracked since 2019 when it first started including this statistic to its annual State of the Software Supply chain report.
This wave of malware adds to the existing challenges that organizations face when it comes to the quality of the open-source components they choose to integrate into their applications. According to Sonatype’s data, on average every enterprise application has at least 180 third-party components, a challenging volume to manage.
As a result, the company found that over 80% of vulnerable application dependencies remain unpatched for more than a year even though 95% have safer alternatives available. Even when updates are applied, in 3.6% of cases vulnerable dependencies get updated to other insecure versions.
Take, for example, Log4j. The logging library for Java used in millions of applications had a critical vulnerability dubbed Log4Shell in December 2021. That flaw and a few others that followed shortly after received widespread publicity, but nearly three years later 13% of log4j downloads from the Maven Central Java repository continue to be for vulnerable versions.
“Managing open-source risks requires optimizing security policies and practices to keep up with the fast-paced evolution of new OSS libraries,” Sonatype wrote in its report. “Organizations struggle with the impracticality of slowing down DevOps processes for manual vulnerability reviews, leading to frustration among developers.”
[ Related: “Top 10 open source software security risks — and how to mitigate them.” ]
Malware can lead to supply-chain compromises
Like malware targeting desktop computers, malicious components uploaded to open-source package repositories can serve different purposes and not all have the same impact.
Sonatype catalogs almost half of all malicious components as “potentially unwanted applications” (PUAs) — mostly innocent in practice but with functionality not disclosed to the end user. These include protestware, in which the component’s creator includes protest messages or actions meant to draw attention to a cause they care about.
Another 12% are flagged as “security holding packages,” meaning that the ecosystem maintainers flagged them as malicious at some point and replaced them with a clean placeholder package to draw attention to those using them.
The rest have pretty serious consequences that can result in supply-chain compromises. Around 14% of packages are distributed through phishing techniques, meaning they use dependency confusion to impersonate internal packages used by organizations with the goal of dropping further malware on development systems.
Around 14% of malicious packages are designed to steal sensitive files and data from machines such as environment variables, authentication tokens, password files, and other information that could help the attackers to compromise more systems later. A subset of 3% of packages also target personally identifiable information (PII) and 3% deploy backdoors and trojans on machines.
Other types of malicious actions include dropping cryptocurrency mining programs (1.2%), corrupting file systems, or compromising the IDE tools developers use to write code or continuous integration platforms.
[ Related: “6 most common types of software supply chain attacks explained.” ]
Some recent incidents of undesirable packages include a developer uploading around 14,000 fake packages to NPM to benefit from a cryptocurrency scheme that rewarded contributions to open source, attackers using typosquatting to push a Python package with a name very similar to a popular library that deployed the Lumma Windows stealer, and the ZX Utils backdoor that’s an example of a years-long infiltration attack into a legitimate project by a rogue developer with the intention to poison the code.
“Traditional malware scanning solutions are unable to detect these novel forms of attack, leading developers and DevOps environments to be uniquely at risk,” the Sonatype researchers wrote. “As the volume continues to grow so too will the clear and present danger facing organizations.”
Some vulnerability information is unreliable
Sonatype found that every enterprise application gets on average 13 critical or high-severity vulnerabilities every year that are inherited from dependencies. In addition to needing automated tools that can track all direct and transitive dependencies — dependencies of dependencies — along with the vulnerabilities discovered in them, the sources of vulnerability information are not equal.
For example, the National Vulnerability Database (NVD) has a backlog of over 17,000 vulnerabilities that haven’t been processed yet. And Sonatype found in practice that over two-thirds of vulnerabilities originally rated with a CVSS severity score under 7 (medium) were corrected to above 7 (high or critical) when reviewed in more detail by a security researcher.
As a result, depending on the source of vulnerability information they use, companies might miss vulnerabilities entirely or postpone addressing them, thinking they are less critical to deal with than they actually are. And if a vulnerability’s score is changed after an application was assessed, it’s hard to tell how long it will take until it will be scanned again.
“Reducing persistent risk is possible by focusing on tools that help manage dependencies and apply real-time vulnerability detection,” the researchers wrote. “In fact, we found that projects using a Software Bill of Materials (SBOM) to manage OSS dependencies showed a 264-day reduction in time to fix compared to those that did not.”
The advance of SBOM standards and government regulations that strongly encourage them, have pushed an increasing number of open-source developers to adopt them. Unfortunately, the rate of adoption does not keep up with the rate of newly released components. Almost 7 million new open-source components were published in the past 12 months — of those, only 61,000 had SBOMs.
A troubling trend is the increasing average time to fix vulnerabilities, regardless of severity. Critical vulnerabilities used to have average fix times between 200 and 250 days, but that now exceeds 500 days in some cases. High-severity vulnerabilities have extended their time to fix from between 150 and 300 days to more than 400; low-severity flaws now have a time to fix of 500 to 700 days, with some stretching to 800.
“This sharp increase suggests that publishers are overwhelmed, struggling to keep up with both the volume of security issues and the ongoing demands of innovation and feature development,” the researchers said.
