Supply Chain Cyber Attacks Increased Over 600% This Year and Companies are Falling Behind

Most companies believe they are using no open-source software libraries with known vulnerabilities, but new research finds them in 68% of selected enterprise applications.

In this regulatory and security centric business environment, the number of documented supply chain cyber security attacks involving malicious third-party components has increased over 600% the past year.  Currently, sitting at over 88,000 known instances, according to a new report from software supply chain management company Sonatype.

Companies need to implement vendor due diligence vetting during the onboarding process that can help identify risks that a new vendor/supplier may pose.   Ongoing due diligence vendor risk rating and monitoring provides the detailed information companies need to determine whether to continue a business relationship.  Doing business with a high-risk vendor especially that may provide cybersecurity risks can be extremely detrimental to any companies bottom line, operations, reputation and enforcement actions by international regulators.

Meanwhile, instances of vulnerabilities that software components inherit from their own dependencies have also reached unprecedented levels and affect 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 understanding their origins is critical to vulnerability response. Many organizations 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%.  Additionally, 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 critical issue, highlighting the intrinsic 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 organizations, software repository managers, the Linux Foundation, and government bodies.  Yet, most organizations are far from where they need to be in terms of open-source supply chain management.

Open-Source Utilization Keeps Growing – Increasing Cybersecurity Risks

The average yearly growth in package downloads from the top component repositories – Maven Central (Java), npm (JavaScript), PyPi (Python), and NuGet (.NET) – is 33%.  This is lower than in previous years, such as 2021’s 73% growth, but the number of component downloads has already passed 2021’s numbers across all repositories and collectively sits at over 3 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% 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 behavior of most package management clients configured to search for packages in both public community repositories and internal repositories.

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.

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 analyzed a set of over 12,000 libraries commonly used in enterprise applications and found that only 10% 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%. 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 scrutinize. 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. “Favor 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). Minimizing 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 the 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% of the respondents said they were confident their applications were not using known vulnerable libraries and 84% said they scrutinize 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% 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.

Modevity Contact info:

Thomas J. Canova, Co-Founder, CMO

Office: (610) 251-0700

Leave a Comment

Trusted partner since 2004.

Other Pages

Quick Links

Get the latest news & updates

Copyright © 2022 All rights reserved.