Reflecting on 10 years of the State of the Software Supply Chain report is both a milestone and a call to action. Over the past decade, the world of software development has been transformed by open source consumption. We've seen unprecedented innovation, but also a rise in new challenges, particularly in managing the security and integrity of the software supply chain.
At Sonatype, we've been at the forefront, analyzing these trends, and today, the insights from our tenth annual report are more critical than ever.
When we first started tracking open source consumption a decade ago, the landscape looked entirely different. Software development was still catching up to cloud-native architectures, and security concerns were more localized. Fast forward to today, open source software accounts for up to 90% of a modern application's codebase, and global open source consumption has skyrocketed to an estimated 6.7 trillion downloads this year. Ecosystems like npm and PyPI have surged, largely driven by trends like AI, cloud computing, and DevOps - and in some cases, malicious intent.
But, this growth has come with a darker side: a rise in attacks targeting the software supply chain itself. What started with occasional incidents, like Heartbleed or the Equifax breach, has escalated into sophisticated and widespread attacks. In just the last year, over 500,000 malicious open source packages have been introduced into open source repositories — a staggering 156% year-over-year increase. This is no longer an emerging threat. It's the new normal.
One of the key findings in this year's report is the concept of persistent risk. We introduced this term to capture the combined threat posed by unfixed vulnerabilities and the corrosion that occurs over time when security issues linger.
Imagine rust slowly eating away at the structural integrity of a building — this is what's happening in our software supply chains. We see this playing out most clearly in cases like Log4Shell, where, nearly three years after the vulnerability was first exposed, 13% of downloads remain vulnerable despite the availability of a fixed version.
Even more concerning, 80% of application dependencies remain un-upgraded for over a year, with 95% of those vulnerable versions having a safer alternative readily available. This is not just a technical issue — it's a behavioral one. It reflects a widespread complacency in how organizations manage their software dependencies. Developers are stuck in cycles of inertia, often due to fear of breaking changes or the pressures to ship new features faster.
We've also seen, and have been closely tracking, a new breed of attacks rising to prominence: supply chain contamination, also known as malicious open source or open source malware. This year alone, 512,847 malicious packages were discovered (65,000 of which were high-severity malware packages) representing a 156% year-over-year increase, targeting everything from automated build environments to developer workstations.
Open source malware is particularly insidious because it blends seamlessly into legitimate development processes, bypassing traditional defenses. These attacks are not hypothetical — they are actively targeting and exploiting real-world software ecosystems, including major incidents like the XZ Utils backdoor attack, which nearly compromised the world's servers.
The sheer scale of open source today is both its greatest strength and its biggest challenge. In the JavaScript ecosystem (npm) alone, there were 4.5 trillion package requests this year — a 70% year-over-year increase. Python's ecosystem is similarly booming, driven by the AI revolution.
Yet with this scale comes complexity. Developers are overwhelmed by the number of choices and are often picking unsafe or outdated components simply because it's too hard to sift through the noise.
This "choice overload" is a significant contributor to security risks. Out of the 7 million open source projects, only 10.5% are actively used and developers often default to familiar or popular packages without properly vetting them. It's not a matter of "if" but "when" these choices lead to security vulnerabilities.
Security is not just a technical problem, but also a productivity problem. The effort required to manage open source dependencies, patch vulnerabilities, and adhere to licensing terms is eating into development cycles.
On average, applications contain 180 open source components. Managing these dependencies manually is becoming an impossible effort. Worse, 92% of publicly available vulnerability data needed corrections after deeper review by security researchers. This creates what we call "surprise risk," where developers falsely assume they are protected, only to discover the opposite when it's too late. Not to mention the backlog of 17,656 published but unprocessed vulnerability advisories in the National Vulnerability Database (NVD), meaning those trying to do this without a software composition tool are often digging themselves a bigger hole as they have a false sense of security. We also have to take into account other types of "risk," like legal and compliance, which affects overall productivity and technical debt as well.
So, where do we go from here? If the last decade has taught us anything, it's proactivity beats reactivity every time. Organizations must adopt always-on security practices — this means integrating Software Composition Analysis (SCA) tools directly into the CI/CD pipeline and ensuring that every component is vetted, monitored, and updated in real-time. It's not enough to perform a one-off security check or even multiple single-point checks. Continuous monitoring is essential.
Dependency management is another critical area. You must understand what's in your software. We've found that projects using a Software Bill of Materials (SBOMs) to track and manage open source dependencies reduced their time-to-fix vulnerabilities by an average of 264 days compared to those that didn't. But the only way to know what projects you're using, without any question, is SBOMs built for every single one of your applications. This is the kind of tooling and automation that reduces risk, improves efficiency, and ultimately drives better security outcomes.
As we look ahead, it's clear that open source is not going away — nor should it. But as we will continue to say, with great power comes great responsibility. The next decade of software supply chains will depend on our ability to adopt better tools, enforce better practices, and foster a culture of security within development teams. We've also seen that it will greatly depend on the role of regulation - and the reaction to those regulations. We're on the precipice of great change in this area with an exponential rise in new policies and legislation around the world.
This issue is not just an issue for security professionals. It's an issue for boards, executive leadership teams, developers, legal teams, and product owners alike.
Sonatype has been dedicated to solving these problems from day one, and we're not slowing down. Our goal is to help every organization — from startups to enterprises — navigate the complex world of open source safely and efficiently. The data show that automation, intelligent tooling, and proactive risk management are the keys to a more secure future. We've created our platform to help you take control over your software supply chain.
Download the full 10th annual State of the Software Supply Chain report and let's continue working together to build a more secure, efficient, and innovative future.