2024 State of the Software Supply Chain
A look at Sonatype's 10th annual State of the Software Supply Chain Report
If you’re like me, you love data.
Research, studies, insights, and data-driven information to help understand a problem landscape, trends, and more. The Sonatype State of the Software Supply Chain Report is among some of my favorite vendor reports in this regard and I have cited it in my writing quite a bit, including in my book “Software Transparency: Supply Chain Security in an Era of a Software-driven Society”
They recently published their 10th annual report, and a decade of data is a pretty great trove that warrants a look, so let’s take a look at some of the key findings and takeaways.
Interested in sponsoring an issue of Resilient Cyber?
This includes reaching over 7,000 subscribers, ranging from Developers, Engineers, Architects, CISO’s/Security Leaders and Business Executives
Reach out below!
Scale of Consumption
The report opens pointing out the massive scale of pervasive nature of open source in general. As I have discussed from others such as Synopsys, open source now makes up 90%~ of modern applications and is a key aspect of the modern digital supply chain, powering everything from consumer goods to critical infrastructure and national security. The Sonatype report pulls insights from over 7 million open-source projects and points out that there is a 156% YoY increase in malicious packages in the ecosystem, which is a tremendous concern. That comes up to 512,847 malicious packages, as they show in the image below.
Not only do they point out the pervasive nature of open source and the rise of attacks but they show that leading ecosystems such as JavaScript and Python have exponential consumption.
Software Ages like Milk
As the saying goes, software ages like milk, not wine. This is further amplified due to the complacent behavior of organizations using OSS, as Sonatype shows.
As shown above, nearly 15% of Log4j downloads are of vulnerable versions and this is 3 years after the Log4shell exposure. That might explain why in a recent CISA Publication of 2023 Top Routinely Exploited Vulnerabilities, Log4j was the only open source component that made the list.
Sonatype points out that despite the myriad of best practices, guidance, publications, frameworks, and more, organizations’ behaviors largely remain unchanged, and insecure consumption and governance of OSS still is rampant.
Having a secure OSS ecosystem with well-maintained projects and components won’t mean much if consumers don’t do the maintenance to run updated secure versions of libraries.
This problem of course impacts commercial software, with organizations struggling to keep up with patching and having massive vulnerability backlogs in the hundreds of thousands or millions. The challenge of course is OSS is much more granular and pervasive with hundreds of libraries and components in the average application, making the scale of maintenance a bit more challenging.
Drowning Developers
Sonatypes report points out the massive inefficiency, waste and toil that Developers are dealing with. Vulnerability management is often akin to Security beating Developers over the head with a massive laundry list of vulnerabilities with little to no context in areas such as known exploitation (KEV), exploitability (EPSS), reachability, business criticality and more.
Sonatype shows that factors such as the size of the application doesn’t matter because even “small” applications have nearly 200 components and dependencies. That said, they did mention that data quality does matter, which is a point I have made previously when covering Endor Labs 2024 State of Dependency Management Report, as well as in a recent Data Quality in Vulnerability Management paper from the Cloud Security Alliance (CSA).
The reality is that the current vulnerability database ecosystem is incredibly scattered and the entries in leading databases, such as NIST’s NVD are far from perfect, often needing corrections or additional details.
Ironically, despite a lot of criticisms of CVSS, they did state that nearly 70% of vulnerabilities that were originally scored below a 7.0 severity score, were corrected higher once reviewed, albeit most organizations operate on CVSS base scores and don’t have the bandwidth of expertise to analyze CVE’s and their CVSS scores at-scale and right-size them.
10 Year Look Back
One of the coolest aspects of Sonatype’s report is that they have 10 years of data to reflect back on, something most organizations do not, especially in the software supply chain space, which started to gain most of its traction post SolarWinds, Log4j and the U.S. Cyber EO.
As they point out in the report a lot has changed in a decade, including the explosion of Cloud, microservices, DevSecOps, OSS consumption and more.
Some of the metrics they show above are outright staggering. We see a 1,466% increase in release frequency, no doubt spurred by the adoption of Agile and DevOps and short more frequent release cycles and underpinned by the competitive drive of organizations leveraging software to serve consumers and stakeholders and looking to use feature velocity as a key metric.
Security, of course, has done our best to keep up with this velocity and a myriad of AppSec tools (e.g. SAST, SCA, IaC, Secrets et. al) have proliferated across the open source and commercial ecosystem to try and “shift security left”, but these tools are far from perfect, struggle with data quality, as discussed above and still often leave security being viewed as a blocker that introduces friction rather than a business enabler, despite our delusions otherwise.
They also show that CVE growth has grown 463% in the last decade, a metric corroborated by vulnerability researchers I often cite, such as Jerry Gamblin. Now ask yourself, has your team/organization improved their vulnerability management efficiency by 463%? Please, hold your laughter for now.
This tremendous growth and scale of OSS adoption have made it a ripe target for malicious actors, as demonstrated by the metric of 704,102 malicious packages since 2019 alone, and these are of course just the ones identified and caught so far.
I will add that the Sonatype report puts quite an emphasis on SBOM’s and their value. For example, they claim that projects that using SBOM’s to manage OSS dependencies showed a 264 day reduction in MTTR.
I am of course an advocate for Software Transparency and even published a book by the name, and think SBOM’s have a real opportunity to address information asymmetries between Software Vendors and Consumers, as well as organizations to perform internal dependency management. That said, there is the reality that Sonatype sells a product that uses it as an artifact and key offering, which has to be taken into consideration.
SBOM’s have faced stark criticisms from folks such as Dan Lorenc, who questions their value, and the impact they are having if at all. However, I don’t want to sidetrack this article into a deep dive into SBOM’s, which I’ve already covered in articles such as:
Understanding OWASP’s Bill of Material Maturity Model: Not all SBOMs are created equal
SBOM Management: A look at the NSA's "Recommendations for SBOM Management"
Sonatype’s report provides an amazing recap of the evolution of software supply chain attacks, from early attacks such as Struts, Heartbleed and Shellshock to Equifax, Solarwinds, and Log4Shell and XZ-Utils.
Each of these attacks have some unique nuances and I strongly recommend giving the report a full-read.
Looking at popular sources such as Maven Central, the report shows a steady growth in the number of days (e.g. Meantime to Remediate (MTTR)) for vulnerabilities. Reasons cited include the growing complexity of the modern software supply chain, multiple layers of dependencies, and perhaps a sense of burnout by Developers, which is something cited in reports from others, such as Tidelift.
This increase comes at a time when compliance requirements and consumers expect faster remediation timelines. The report states the average fix times for even critical vulnerabilities is 200-250 days, with some taking over 500 days to fix.
Sonatype states the problem is even more severe for medium and low-severity vulnerabilities, with them seeing timelines of 500-700 days or even 800 days to fix. Given the previous discussion above about how vulnerabilities upon further evaluation required an increase in CVSS score, these timelines could be concerning meaning they are lingering longer, and may actually be more severe than initially suspected.
As the report indicates, open source maintainer and publisher capacity are likely simply being strained beyond realistic expectations, especially given the majority of OSS is maintained and published by uncompensated volunteers and offered as-is with no assurances or expectations.
The overall growth continues to have a trajectory that would make the average investor jealous, climbing rapidly YoY. This of course contributes to MTTR timelines too, as the number of vulnerabilities becomes too much to keep pace with, both for maintainers/publishers and organizations and consumers of OSS alike, showing a similar problem that commercial vulnerabilities suffer across enterprises, as they linger longer and longer.
Open-Source Regulatory Landscape Complexity
The Sonatype report does an excellent job highlighting the growing complexity of the open-source regulatory landscape. From early efforts in 2014 such as the Royce Bill to the explosive growth in the EU in particular with GDPR, BSI, ENISA, NIS2, DORA, Cyber Resilience Act (CRA), and now the Product Liability Directive (PLD), the EU is easily outpacing the U.S. in its aggressiveness when it comes to open source and regulation.
That said, as pointed out in my recent discussion with IAPP Cybersecurity Law Center Director Jim Dempsey, this approach by the EU is, and is likely to continue to have detrimental effects to the EU economy, innovation and its ability to keep pace with the U.S. and others when it comes to technology.
The U.S. of course has had its own activity, with fragmented state-specific efforts such as CA’s CCPA and other broader far reaching efforts such as CMMC for the Defense Industrial Base (DIB). That said, most of the recent U.S. efforts, such as Secure-by-Design are largely recommendations, guidance and voluntary, including the Secure-by-Design Pledge which I discussed in the article “A Digital Scouts Honor: A look at the recently announced Secure-by-Design Pledge led by CISA”.
This is a stark difference from the heavy-handed liability and punitive approach the EU is taking.
Conclusion
While the Sonatype State of Software Supply Chain Report contains MUCH more in terms of insights, metrics and findings, I wanted to keep this article manageable for now.
One thing is clear, we’ve got problems, and big ones.
From the enormous growth of OSS, exponential vulnerability growth, struggles by maintainers and publishers to remediate vulnerabilities and even when they do, organizations either continue to download vulnerable versions, or fail to upgrade to secure versions and components.
Attackers of course are taking advantage of this at a rapid rate, with hundreds of thousands of malicious packages pervading the OSS ecosystem and most organizations just continuing their blind consumption.
As my friend Chinmayi Sharma put in her article, our entire digital infrastructure is built on a house of cards. It is only a matter of time until the house of cards comes crashing down, with incidents impacting critical infrastructure and disrupting every day life, perhaps then finally driving systemic changes.
