The number of documented supply chain attacks involving malicious third-party components has increased 633 per cent over the past year, now sitting at over 88,000 known instances, according to a new report from software supply chain management company Sonatype.
Meanwhile, instances of transitive vulnerabilities that software components inherit from their own dependencies have also reached unprecedented levels and plague two-thirds of open source libraries.
“The networked nature of dependencies highlights the importance of having visibility and awareness about these complex supply chains,” Sonatype said in its newly released State of the Software Supply Chain report.
“These dependencies impact our software so having an understanding of their origins is critical to vulnerability response. Many organisations did not have the needed visibility and continued their incident response procedures for Log4Shell well beyond the summer of 2022 as a result.”
Log4Shell is a critical vulnerability discovered in November 2021 in Log4j, a widely popular open source Java library used for logging and bundled in millions of enterprise applications and software products, often as an indirect dependency. According to Sonatype’s monitoring, as of August 2022, the adoption rate for fixed versions of Log4j sits at around 65 per cent.
Moreover, this doesn’t even account for the fact that the Log4Shell vulnerability originated in a Java class called JndiManager that is part of Log4j-core, but which has also been borrowed by 783 other projects and is now found in over 19,000 software components.
Log4Shell served as a watershed moment, highlighting the inherent risks that exist in the open source software ecosystem – which sits at the core of modern software development – and the need to manage them properly. It also led to several initiatives to secure the software supply chain by private organisations, software repository managers, the Linux Foundation, and government bodies.
Yet, most organisations are far from where they need to be in terms of open source supply chain management.
Open source consumption keeps growing
This is lower than in previous years, such as 2021’s 73 per cent growth, but the number of component downloads has already passed 2021’s numbers across all repositories and collectively sits at over three trillion. The npm repository alone will serve more downloads this year than all four repositories did in 2021.
The decline in open source consumption rate is not necessarily due to users implementing stricter open source procurement and management policies, but rather is normal given the size that these ecosystems for different programming languages have reached and their rate of adding new projects and releases.
“Although the pace of growth is slowing down, the absolute scale of growth continues to compound on the previous yearly rates,” Sonatype concluded. “The pace of open source adoption shows no signs of running out of steam anytime soon.”
Types of supply chain attacks have diversified
Sonatype had tracked around 12,000 known instances of malicious supply chain attacks until the end of last year, but that number has now grown to over 88,000, a 633 per cent year-over-year growth. The company has also discovered 97,334 malicious packages distributed in a variety of ways.
One of the top contributors to the growth of malicious packages is an attack technique called dependency confusion that was publicly disclosed by security researchers in February 2021 and has since seen wide adoption.
The technique exploits the behaviour of most package management clients configured to search for packages in both public community repositories and internal repositories.
When a package name exists in both locations, the client will pull in the one with the higher version number. This causes a problem because many organisations use in-house developed packages that only exist in their internal repositories and were never meant to be published publicly.
However, if attackers find the names of those packages from manifest files, they can publish malicious packages with those names in the public repositories, with a higher version number to trick software building clients.
It’s hard to say if all instances of dependency confusion attacks have been malicious in nature because the technique is also popular with penetration testers.
However, organisations can protect themselves by either registering the names of their private packages in the public repositories or use prefixes for all their packages that they then can then be registered as namespaces or scopes on public repositories, meaning attackers should no longer be able to publish packages with those prefixes.
Other types of mass attacks that have been known for a while are typosquatting and brandjacking, Typosquatting involves attackers registering malicious packages with names that are similar to those of some popular and widely used packages. This is a passive attack that relies on developers making mistakes – typos – when typing package names in their build scripts or commands.
Brandjacking is similar but targets other package maintainers in the hope that they will include a hijacked or typosquatted package as a dependency in their own components. This can also happen when the maintainer of a legitimate package passes ownership to someone else, or when they stop developing that package and delete it and the old name becomes available.
Malicious code injection is another technique that is more targeted and involves attackers compromising a developer’s system or code repository and injecting malicious code into their package without their knowledge. This can also happen when a package maintainer gives multiple parties commit access to their code repositories and those parties either have malicious intentions or they become compromised.
Another attack type that is similar to malicious code injection but is perpetrated by legitimate developers is known as protestware. This refers to incidents where a developer adds malicious code to their own previously clean package as a sign of protest.
Choosing components with good security practices
Building and maintaining an inventory of components used across all internal software development efforts and tracking vulnerabilities discovered in them is a key aspect of mitigating security risks. However, having clear policies around component provenance is just as important.
Choosing components or libraries with a low incidence of vulnerabilities in their own code is not a guarantee, because many of them can inherit vulnerabilities from their own dependencies, so the time it takes them to respond to such vulnerabilities and update their own dependencies is critical.
Sonatype analysed a set of over 12,000 libraries commonly used in enterprise applications and found that only 10 per cent of them had a vulnerability directly in their code. However, when including transitive vulnerabilities inherited from dependencies and dependencies of those dependencies, the incidence rose to 62 per cent. On average, each library had 5.7 dependencies.
Also, choosing components based with a lower rate of vulnerabilities does not necessarily translate to better security outcomes in the long run because there is a lot of bias in how researchers choose the projects they want to scrutinise. In other words, a popular project might have a higher number of vulnerabilities discovered just because more eyes are on it.
“Since most vulnerabilities arise from transitive dependencies, the clearest guidance is to carefully consider every library you use,” the Sonatype researchers said. “Favour ones with smaller dependency trees. Look for projects that are quick to update when new versions of their dependencies are released (low MTTU – mean time to update).
"Minimising the total number of dependencies and maintaining low update times for your own project's dependencies are two critical factors for reducing the risk of transitive vulnerabilities.”
Several metrics are available to judge the security practices of open source projects. One of them is the Security Scorecard system developed by the Open Source Security Foundation (OpenSSF).
This system performs a series of automated checks to check if open source projects have unfixed vulnerabilities, if they use tools to help update their dependencies, if they run CI tests, if they run automated code fuzzing, if they use static code analysis tools, if they avoid dangerous coding practices, if they perform code review before merging new code, if they declare and pin their dependencies, and much more.
Sonatype used its own data to assess much impact some of those practices have on lowering the chance of a project having vulnerabilities and found that the highest impact actions were code reviews, not including binary artifacts, avoiding dangerous coding practices (branch protection), pinning dependencies, and reviewing code commits.
“We continue to recommend that developers select components with the highest MTTU, Security Scorecard, OpenSSF Criticality, and SourceRank in that order,” the Sonatype researchers said. “We understand trying to aggregate and weigh the various scores may be difficult. We've made it easier by adding the new Sonatype Safety Rating to our public vulnerability database OSS Index.”
Companies are overconfident in their open source practices
Sonatype ran a survey of 662 enterprise engineering professionals and asked 40 questions about their use of open source components, dependency management, governance, approval processes, and tooling. Most of the responses indicated levels of supply chain management that were lower than what’s required to produce high-quality outcomes in Sonatype’s assessment.
The highest scores were in the remediation and application inventory categories. For example, 68 per cent of the respondents said they were confident their applications were not using known vulnerable libraries and 84 per cent said they scrutinise the security history of the open source components they use.
However, this didn’t match Sonatype’s findings in practice where a scan of 55,000 enterprise applications selected randomly revealed that 68 per cent of them had known vulnerabilities.
“We leveraged the demographic data collected during the survey and broke down the results by job title,” the researchers said.
“The findings were illuminating. There is an ongoing bias towards seeing things in a better light, in which managers report higher stages of maturity compared to what is reported by other roles. Survey-wide, this discrepancy is statistically significant when comparing IT managers and those working in information security roles."