10th Annual State of the Software Supply Chain®
10th Annual State of the Software Supply Chain Report
10 Year Look Back
As we look back on 10 years of data collection for the State of the Software Supply Chain, it’s a good time to reflect on what has changed — and what hasn’t. This retrospective examines four key dimensions: attackers, publishers, consumers, and regulators.
A decade ago, the cultural landscape was vastly different. Social media was just beginning to show its widespread impact. Instagram had recently been acquired by Facebook, while Snapchat rejected a multibillion-dollar offer from the same giant. Smartphones were everywhere, but apps like TikTok, which would later reshape digital culture, were still far out on the horizon.
In the tech world, cloud computing was maturing, but not yet as integrated into daily life as it is today. Amazon Web Services (AWS) was proliferating, but the full implications of cloud-native development and the shift towards serverless architectures were just beginning to be understood. Kubernetes, which has subsequently revolutionized container orchestration and become a cornerstone of modern infrastructure, was only recently open-sourced by Google.
Many of today’s tech staples were in their infancy. Zoom, now key to remote work, was starting to gain traction, and Slack had just launched, reshaping workplace communication. The Apple Watch and Amazon Echo were just exciting rumors. Smart assistants in every home were still a futuristic idea.
1,466%
463%
704,102
72,065
During this period, cybersecurity concerns, were gaining attention. The Cyber Supply Chain Management and Transparency Act of 2014, commonly known as the Royce Bill, highlighted the growing recognition of these risks. One of its most forward-thinking provisions was the Software Bill of Materials (SBOM) requirement — a comprehensive and confidentially supplied list of each binary component within the software, firmware, or product.
Though the bill never became law, it’s worth considering how aggressive software transparency a decade ago could have led to a more secure ecosystem today. Had the SBOM requirement been implemented back then, we would have a much deeper understanding and control over the components that make up our digital infrastructure today. In fact, we might have mitigated many of the supply chain attacks and vulnerabilities that have plagued the industry in recent years, setting a higher standard for security and trust in software development long before these issues reached the critical point they now occupy.
An SBOM mandate when it was first suggested 10 years ago could have redefined software security and stopped today's supply chain attacks before they began.
This period also preceded the mainstream rise of AI. While AI research was active, and companies like Google and Facebook were investing heavily, public exposure was limited to Netflix recommendations and early virtual assistants like Siri and Alexa.
Figure 1.1 Next Generation Software Supply Chain Attacks (2019-2024)
704,102
Malicious packages discovered
Attackers and the Evolution of Software Supply Chain Exploits
Over the past decade, the software supply chain has become a primary attack vector for malicious actors. What was once a relatively niche method of attack has evolved into one of the most significant cybersecurity threats today, driven by the interconnectedness of modern software ecosystems and the increasing reliance on open source components. As software supply chains have grown in complexity, so too have the strategies employed by attackers, who have shifted their focus from directly targeting organizations to exploiting vulnerabilities within the broader supply chain and all of its downstream consumers.
Early Years (2014-2016)
Struts, Heartbleed, and Shellshock
In the mid-2010s, the software supply chain began attracting more attention from attackers, exemplified by early incidents like CVE-2014-0094, a remote code execution flaw in Apache Struts that allowed attackers to execute arbitrary code on servers running vulnerable framework versions. Although this vulnerability didn’t gain the same notoriety as later software supply chain incidents, it highlighted the risks posed by unpatched open source components that many organizations relied on for critical infrastructure. This issue came to a head in 2017 with the Equifax breach, but the 2014 vulnerability served as an early warning of the dangers of failing to manage the security of widely-used software dependencies.
Around the same time, Heartbleed and Shellshock sent shockwaves through the cybersecurity world. Heartbleed, a flaw in OpenSSL, exposed millions of servers to data breaches, while Shellshock allowed remote code execution on Unix-based systems. Both demonstrated the vast attack surface of widely-used open source components and emphasized the importance of securing the software supply chain.
These early attacks revealed how vulnerabilities in core open source software could ripple across industries, underscoring the need for better patch management, transparency, and proactive security measures.
2017
The Equifax Breach and the Rise of Targeted Supply Chain Attacks
The 2017 Equifax breach, caused by the failure to patch a known Apache Struts vulnerability (not the 2014 vulnerability discussed above), marked a turning point for software supply chain security. It showed how a single unpatched flaw in a widely-used framework could lead to a catastrophic breach, as attackers exploited weaknesses in open source components to access critical systems and exfiltrate confidential information for millions of consumers. The incident was a wake-up call for many organizations, illustrating the devastating effects of not properly managing and securing your software supply chains, and bringing open source supply chain vulnerabilities into nationwide headlines for the first time.
2017 marked another significant turning point as the year when the first targeted attacks on the software supply chain began to emerge using open source malware. Data from the Sonatype State of the Software Supply Chain reports in 2017 and 2018 shows that this was the period when attackers started to intentionally inject malicious code into popular open source libraries, targeting the very foundation of the software supply chain. These early attacks were highly selective and designed to infect specific projects with high adoption rates. For instance, compromised versions of popular npm packages and other open source components were downloaded by developers, inadvertently spreading malware to downstream systems.
This shift from opportunistic to targeted exploitation signaled a new era of supply chain attacks. Attackers recognized the strategic value of compromising software at its source, potentially reaching thousands of users with a single strike. This laid the groundwork for more sophisticated and large-scale exploits in the years to come.
Sadly, seven years later, in 2024, this is still one of the least understood and recognized attack vectors by security teams. The number of attacks detected in the software supply chain doubled again in 2024, indicating that our industry is mainly defenseless against these growing risks.
2020
SolarWinds and the Expansion of Supply Chain Attacks
The SolarWinds attack in late 2020 further demonstrated the growing sophistication of software supply chain threats. In this highly coordinated operation, attackers infiltrated SolarWinds’ build environment and embedded malicious code (Sunburst) into software updates for the company’s Orion platform, distributed to thousands of government agencies and corporations worldwide. SolarWinds represented a new attack level, where adversaries exploited vulnerabilities deep within the development pipeline to compromise trusted software used by highvalue targets. This attack was a technical success and underscored the strategic value of supply chain compromises for espionage and broader cyber warfare — and was the roadmap nation state attackers needed to recognize how effective a software supply chain attack could truly be.
2021–2022
Log4Shell,the Vulnerability that Set the Internet on Fire
The discovery of the Log4Shell vulnerability in late 2021 marked another critical moment in the evolution of supply chain threats. A widely used open source logging utility, Log4j was embedded in thousands of enterprise applications and its critical vulnerability opened a massive attack surface. Attackers quickly capitalized on this flaw, and, within hours of its public disclosure, began launching widespread exploitation campaigns. Log4Shell demonstrated how vulnerabilities in a seemingly obscure open source component could ripple through the entire software ecosystem, impacting organizations across industries.
It was only in the wake of Log4shell did the industry become widely conscious of the impacts of the massive growth of open source dependency consumption combined with lack of mature controls — the very thing this report has been evangelizing since 2014 which could have been markedly impacted had the Royce bill passed back then. This incident finally accelerated the urgency around supply chain security, pushing governments and organizations to adopt more stringent practices like Software Bills of Materials (SBOMs) and continuous monitoring of open source components.
2024
The XZ-Utils Attempted Supply Chain Attack
In 2024, the attempted supply chain attack on XZ-utils, a widely used compression library, marked a dangerous escalation in open source software security. Unlike typical attacks, this sophisticated, likely nation-state-backed operation followed the “benevolent stranger” playbook. The attackers played a long game, leveraging social engineering to gain trust within the project, which had been maintained by a single developer for nearly two decades. In 2022, pressure from suspected bogus accounts paved the way for a new contributor, Jia Tan, who gradually gained the maintainer’s trust.
Over two years, Jia introduced encrypted malicious code into binary test files embedded in the XZ source code. These files, common in compression packages, went unnoticed due to their subtle nature. The attackers were just days away from having this compromised version ingested by major Linux distributions, which would have allowed backdoors to be deployed to countless systems globally.
The attack was thwarted only by chance, averting widespread infiltration of Linux-based devices and enterprises worldwide. This incident highlights the growing trend of highly organized attackers targeting essential open source projects, aiming for maximum disruption within the global software ecosystem.
Consumers of Open Source
Since we published the first State of the Software Supply Chain Report, the profile of open source software consumers has expanded significantly. It has evolved from primarily being for developers and smaller organizations to now being integral to organizations of all sizes, from startups to large enterprises to government agencies around the world.
The growing reliance on open source reflects confidence in its flexibility and innovation, as well as its ability to reduce time-to-market and development costs and increase organizational agility. But it also brings new risks, particularly with poor dependency management and the rise of open source malware.
Nearly three years after the discovery of the Log4Shell vulnerability, 13% of Log4j downloads are still for known vulnerable versions. While this is an improvement, it should be near zero based on the broad public awareness of the vulnerability, signaling persistent issues with dependency management. Additionally, our research in both 2022 and 2023 found that 96% of vulnerable components downloaded had a fixed, non-vulnerable version available. In this year’s report, this figure only improved slightly to 94.9%, highlighting poor consumption practices aren’t really changing and organizations are bringing in exponentially more risk by not paying attention.
Log4Shell by the numbers:
Three year later and...
- 13% of Log4j downloads are still known vulnerable versions.
- 94.9% of vulnerable components downloaded had a fixed, non-vulnerable version available compared to 96% in 2022 and 2023.
Worse, our research clearly shows that poor dependency management often pairs with other poor choices. Failure to regularly update and oversee open source components allows known vulnerabilities to persist, posing serious risks to the software supply chain.
Meanwhile, the threat of open source malware continues to grow as attackers exploit gaps in poor consumption practices. As mentioned above, the XZ Utils project takeover demonstrated how widely used components, often maintained by overworked and underfunded teams, can become entry points for malicious code.
As open source consumption evolves, so must best practices. Organizations must adopt rigorous practices, improve dependency management, and address open source malware risks to ensure the security and reliability of software supply chains. For more details, see The Evolution of Open Source Risk section in this year’s report.
Poor consumption practices aren't really changing and organizations are bringing in exponentially more risk by not paying attention.
Publishers of Open Source
Over the past decade, open source publishers (developers/ projects that are creating and then sharing components via public registries like Maven Central) have shown a remarkable transformation in their behavior, driven by both increased demand and growing expectations for rapid innovation. The data on release frequencies highlights key trends in how projects are maintained and evolved.
Figure 1.2 Release Frequency of Open Source Projects
Projects that released faster, slower or the same as the prior year
From 2010 through 2024, there has been a consistent increase in the number of projects where release frequency grew year-over-year. In particular, 2023 and 2024 saw massive growth, with over 1.8 million projects increasing their release cadence in 2023 alone. This surge reflects the accelerating pace of development as publishers race to release new features, fix bugs, and address security vulnerabilities to meet the growing demands of consumers and regulatory pressures. However, this also introduces challenges related to sustainability and stability, as smaller, independent projects struggle to keep up with the pressure to update and improve continuously.
Mature projects likely prioritize long-term maintenance and reliability over rapid development, catering to industries that require stable, well-tested software.
Despite the overall increase, a significant number of projects saw their release frequency decrease or remain unchanged, particularly after 2020.
By 2024, over 300,000 projects had slowed or halted their release cadence, indicating burnout, resource shortages, or shifting priorities among smaller publishers. This shows that while some thrive in a fast-paced environment, many struggle to maintain activity.
Interestingly, projects with stable release cadences have steadily increased, though remain smaller in comparison. These mature projects likely prioritize long-term maintenance and reliability over rapid development, catering to industries that require stable, well-tested software.
Figure 1.3 Rate of Vulnerability Remediation Over Time
How long a project took to remediate known vulnerabilities in their dependencies.
While projects are generally moving more quickly now than they were a decade ago, the rate of vulnerability remediation is slowing significantly.
The data showing how long it takes projects to update their dependencies in response to disclosed vulnerabilities reveals both progress and ongoing challenges in the open source community. While the need for rapid responses to vulnerabilities is well-understood, the actual time it takes for publishers to update dependencies and release secure versions has varied significantly over the years.
As the interconnectedness of open source projects increase, so do the challenges of maintaining prompt security updates.
In 2017, the mean time to remediate vulnerabilities was relatively short, with some fixes implemented in under 25 days. However, by 2023 and 2024, delays had increased significantly, with some projects taking over 400 days to release secure updates. In 2024, several projects had average fix times exceeding 300 days, with one reaching 470 days.
This trend highlights a growing lag in security response, even as timely updates become more critical.
This pattern reflects a growing complexity in software supply chains, where projects often rely on multiple layers of dependencies. As the interconnectedness of open source projects increases, so do the challenges of maintaining prompt security updates. Publishers, especially smaller or less-resourced teams, may struggle to keep up with the need for constant vigilance and fast releases.
Figure 1.4 Release Frequency by Severity
How long projects took on average to remediate dependency vulnerabilities broken down by severity.
The increasing mean time to remediate vulnerabilities points to the strain on publishers to manage their dependency chains efficiently, despite the growing regulatory and consumer expectations for faster responses. This delay in addressing vulnerabilities has significant implications for the overall security of the open source ecosystem. As projects take longer to implement fixes, the risk of exploitation by malicious actors increases, creating a ripple effect across the software supply chain. The slow pace of updates demonstrates the need for more robust tooling, automation, and support for overwhelmed open source maintainers.
If we break down the mean time to remediate into buckets by vulnerability severity, we see some additional trends.
Over the past decade, the mean time to remediate vulnerabilities has shown a troubling upward trend. While critical vulnerabilities historically received the fastest attention, with average fix times between 200 and 250 days, the data from 2024 shows that even critical issues are now taking significantly longer to address. Some critical vulnerabilities in 2024 took over 500 days to fix, indicating that the response times for the most severe security issues are worsening as complexity in the software supply chain increases.
500+
days to fix some critical vulnerabilities in 2024 indicating response times for severe issues are worsening.
For high-severity vulnerabilities, the pattern is similar. Earlier in the decade, the average fix times ranged between 150 and 300 days, but in recent years, these have extended beyond 400 days. This growing lag poses a substantial risk to organizations that rely on open source components, as longer fix times create larger windows of exposure for potential exploits.
Figure 1.5 Yearly Growth of CVEs, 1999-2023
Vulnerabilities published year over year.
The most alarming aspect of the data is the spike in fix times for medium- and low-severity vulnerabilities, where we see the clearest indication that publisher capacity has been exceeded. Low-severity vulnerabilities, which previously took 300-400 days to fix, are now seeing delays of 500-700 days or more, with some stretching out nearly 800 days in 2024. 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 backlog of unresolved low-severity vulnerabilities could lead to greater security risks as these issues accumulate over time.
When we look at the growth of CVE reports over the last decade, it shines a light on why publishers are struggling to keep up. The massive uptrend beginning in 2016 directly correlates to the increased MTTR seen in the previous analysis.
Overall, the data highlights that the software supply chain has reached a critical point where publisher resources cannot keep pace with the rising volume of vulnerabilities. Without improved automation, tooling, and support for maintainers, the delays in addressing vulnerabilities will continue to increase, leaving organizations exposed to many security risks.
Publishers are overwhelmed, struggling to keep up with both the volume of security issues and the ongoing demands of innovation and feature development.
SBOM Production by Open Source Projects
Following the publication of two new SBOM standards, CycloneDX and SPDX v3, and guided by global government regulations requiring or heavily encouraging SBOMs, we have seen some progress in the number of projects publishing SBOMs alongside their components.
Figure 1.6 Cumulative SBOM Publishing Counts
How many components were published with SBOMs.
Initiatives like the U.S. Executive Order 14028 have driven increased awareness of SBOMs across the industry, and as a result, we’ve seen open source projects begin to create SBOMs. However, we are still seeing essentially linear growth. In the early days of March 2022, we saw about 68 new SBOMs published per day. More than two years later in June of 2024, we are seeing a little over 200 per day (inconsistently).
While this 3x growth is encouraging, if we compare it to the overall growth the new components in the same time period, the view is much darker.
Although the number of published SBOMs is increasing, it is far outpaced by the growth rate of new components. This disparity suggests that while SBOM adoption is growing, it has not yet reached a point where it matches the pace of component releases. This needs to change. As more regulations and security practices mandate transparency and traceability through SBOMs, particularly for open source projects that form the backbone of modern software, ecosystems must keep pace.
We don’t want to ignore the progress, but the software industry has significant work to do to embrace comprehensive software transparency.
Figure 1.7 Cumulative SBOM Publishing Counts vs Cumulative Published Components
Comparing the growth of components with SBOMs vs the overall total shows we are not even beginning to keep up.
The Future of SBOMs
As more organizations embrace software transparency, stronger community standards for SBOMs will be adopted.
Regulators of Open Source
Over the past decade, regulation of open source software has evolved significantly, driven by the increasing recognition of its critical role in the global software supply chain. A hands-off approach in the early 2010s has given way to more proactive regulatory frameworks, aimed at addressing the growing cybersecurity risks associated with software supply chains. Below is a listing of some of the most impactful recent regulations and their effects on the software supply chain:
2014
The Cyber Supply Chain Management and Transparency Act 2014 (Royce bill)
2018
The European Union General Data Protection Regulation (GDPR)
2020
The California Consumer Privacy Act (CCPA)
2020
Cybersecurity Maturity Model Certification (CMMC)
2021
Executive Order 14028
2021
(Germany) BSI Update
2021
The European Union Agency for Cybersecurity (ENISA)
2023
The Network and Information Systems Directive (NIS2 Directive)
2023
The Digital Operational Resilience Act (DORA)
2023
Secure by Design
2023
Self-attestation
2023
Security through Integrated Economic Measures
2023
The CISA Cybersecurity Strategic Plan
2024
The Cyber Resilience Act
2024/2025
Product Liability Directive (PLD)
2025
The Association of Southeast Asian Nations (ASEAN)
Explore Global Regulations and Requirements
Stay up to date on the latest regulatory requirements for software supply chains with resources and guidance outlined in our Regulations and Compliance Resources Center.
Navigating the Future of Open Source
and Software Supply Chain Security
As we reflect on the past decade, the evolution of software supply chain security has been shaped by a growing recognition of the critical role open source software plays in global digital infrastructure. The challenges posed by vulnerabilities in widely used components, like Apache Struts, Heartbleed, and Log4Shell, have illuminated the fragility of our interconnected systems. These incidents underscored the need for increased transparency, accountability, and better security practices across the entire software development lifecycle.
While the early 2010s saw isolated incidents and slow regulatory responses, the emergence of frameworks like the Cyber Supply Chain Management and Transparency Act of 2014 (Royce Bill) introduced forward-thinking concepts like SBOMs. Although it did not become law, the bill’s vision laid the groundwork for today’s regulatory efforts.
A striking 95% of the time, when vulnerable components are consumed, a fixed version already exists.
It took nearly a decade for policy to align with the vision of software transparency proposed in the Royce Bill, as seen in recent regulations like Executive Order 14028, which has accelerated the adoption of SBOMs across industries.
The 2020s witnessed a surge in regulatory action aimed at addressing software supply chain risks. Regulations like the Cyber Resilience Act (CRA) and the Product Liability Directive (PLD) from the European Union signal a new era of accountability, where the security and reliability of open source components are no longer optional but essential. These efforts highlight the growing expectation that organizations adopt robust practices for managing the security of their software supply chains.
However, as highlighted by the data, challenges remain. A striking 95% of the time, when vulnerable components are consumed, a fixed version already exists. This trend has persisted over the last three years, showing little improvement. Despite the availability of patched versions, consumers continue to make poor choices when selecting dependencies. This behavior underscores the need for stronger security awareness, education, and enforcement mechanisms across organizations.
The rise in mean time to remediate vulnerabilities, particularly for low- and medium-severity issues, suggests that publisher capacity is being stretched beyond its limits. Even as the number of SBOMs grows, it has not kept pace with the explosion of new components. This gap signals the need for better automation, tooling, and support for open source maintainers to ensure vulnerabilities are addressed more quickly.
The future of the software supply chain will depend on our ability to meet these challenges head-on. As regulations continue to evolve and attackers grow more sophisticated, organizations must embrace comprehensive security measures and foster collaboration across the industry. Only by building a foundation of transparency, accountability, and proactive security can we ensure that the open source ecosystem remains both vibrant and secure for the decade ahead.
Next: Scale of Open Source
See Next Chapter