Software supply chain security (SSCS) can be noisy, as more vendors have rushed in to capitalize on a complex ecosystem full of organizational risks and challenges.

That said, one of the firms in the space I really respect is Reversing Labs, who always produce excellent content, insights, research, and more and I’ve had the opportunity to join them at RSA for a book signing, as well as be featured as a guest on their blog several times.

In this article, I will examine their recent SSCS Security Report and its key findings and takeaways. So, let’s check it out!

Get The Full Report!

SSCS Landscape

At a high level, the SSCS was still a massive attack vector for malicious actors. They didn’t discriminate between open source, commercial vendors, SaaS, and everything in between as they continued to capitalize on the complex and opaque nature of the modern software supply chain.

One thing I like about the RL report right off the bat is that it doesn’t hyper-fixate on just one aspect of the supply chain, such as open source software (OSS), which tends to be the case in the broader industry.

I particularly loved the below quote from RL’s Sasa Zdjlear:

Of course, there is a nuance there, given that commercial software is overwhelmingly made up of OSS. Still, at the end of the day, most organizations are primarily using commercial software and not running their entire enterprise on OSS projects that they are maintaining and operating themselves, even if it is indeed mixed in to the enterprises application footprint to some extent.

I’ve discussed this with other industry AppSec leaders, such as Jeff Williams, and covered it in an article titled “False Dichotomies and Overemphasizing Open Source Security.”

2024 saw several serious examples of supply chain attacks targeting OSS and commercial software and how organizations consume them. RL lays out examples in OSS such as XZ Utils, Solana, Utralytics, and Respack, as well as commercial examples such as Justice AV Solutions (JAVS) and more.

As I often say, attackers are equal-opportunity exploiters.

RL’s report pointed out that the top OSS packages across the three leading package managers contained hundreds of millions of downloads while also having many critical severity CVEs with known active exploitation. It also noted a 12% jump in developer secrets and sensitive data being exposed, something that is correlated in other reports, such as this State of Secret Spawl 2025 report.

Underpinning all of the specific vulnerabilities, misconfigurations, exploitation activity, and attacks are broader challenges with the vulnerability database ecosystem, most notably NVD in 2024, which I also covered in an article titled “Death Knell of the NVD?”

Now that we have a broad picture of some of the challenges let’s examine some of RL’s specific findings.

As we dive in and break the report down further if you’re interested in a live webinar discussion of the report and key findings, I’ll join the RL team to do just that, and you can join us here!

It will be on March 27th at 11 AM ET.

Join us live!

Key Trends

RL’s report highlights some key trends that are worth discussing:

Crypto

The first is attackers' focus on crypto, and they point out that this is occurring in part because it is tied to financial benefit, which is a primary motivation for some of the most highly capable cybercriminal groups. RL highlights attackers targeting crypto infrastructure and assets such as crypto wallets and the Developers involved in those projects.

Some of the techniques RL cites include attackers compromising widely used OSS packages such as aoicpa and solana tied to crypto and inserting malicious code and functions into those packages.

Some of these packages receive hundreds of thousands of downloads weekly and have thousands of downstream dependencies as well.

Attackers are taking various approaches to compromise the packages or impact intended downstream consumers, including targeting developers, hosting infrastructure, and typosquatting.

If you’d like a deeper look at potential attack vectors, check out my article, “Software Supply Chain Attack Types: A look at the CNCF catalog of Software Supply Chain Compromises.”

RL identified over 20 campaigns specifically targeting crypto-related projects in 2024 and provided a breakdown below in terms of the two major package managers:

Social Engineering, XZ Utils, and State Actors

2024 also saw an uptick in social engineering targeting developers, with the most notable example being XZ Utils, which dominated the news for a bit, showing the sophistication and patience of malicious actors targeting OSS and those who maintain it.

For those unfamiliar, XZ Utils involved a backdoor in a widely used OSS library being inserted after a years-long campaign by a fake developer who pressured the maintainer to allow others to contribute and maintain the project. How many more of these have occurred or are ongoing is still unknown.

RL points out that in 2024, there was a rise in nation-state threat actors targeting development organizations and the OSS ecosystem they depend on.

Commercial Binaries

As I mentioned above, I really like how the RL report highlights the overemphasis on OSS and that significant risks still exist from commercial software. If we look back on the major incidents of 2024, many of the most impactful and visible incidents are tied to commercial, not OSS incidents.

The major difference for most organizations is that with OSS, you can get visibility and transparency on the code. What you’re consuming the same can’t often be said for commercial software.

To highlight these risks, RL analyzed 30 widely used commercial software binaries using their Spectra Assure product and found vulnerabilities, exposed developer secrets, and CVEs that are known to be actively exploited.

Many of these were tied to VPN clients, which we saw have highly visible and impactful incidents in 2024, including impacting U.S. Federal agencies and the Department of Defense.

Without conducting binary analysis, many customers would never know their software vendors are passing these risks downstream to them, given customers often lack this level of transparency from their software suppliers.

RL demonstrates how Spectra Assure can account for various risks from malware, tampering, vulnerabilities, and more.

Open Source Risks Still Resonate

In addition to insights into risks associated with commercial software via binaries, RL provides data to support the case that OSS also presents significant risks to organizations.

To put into perspective just how significant those risks are, RL found that instances of malicious code climbed 1,300% between 2020 and 2023. RL identifies several key trends and risks in the OSS space, which we will touch on below.

RL found over 650 million total downloads across just 30 leading npm, PyPI, and RubyGems packages, with a median of 27 security flaws and an average of 68, 2 of which are critical. This means these security flaws are heavily consumed, distributed, and present across the fragile software ecosystem.

Pervasive & Porous

RL points out that while incidents like XZ Utils and Log4j may dominate the headlines, the OSS ecosystem is riddled with problems just as pervasive as open source. This includes exploitable flaws, vulnerabilities, configuration problems, and many unmaintained and rotting projects and libraries.

These findings align with those of other reports I’ve recently covered, such as the “2025 Open Source Security Landscape.” RL reports that the average flaws in popular packages and languages range from tens to hundreds, as seen below:

RL identified widely popular OSS packages with millions and hundreds of millions of downloads containing critical and exploitable flaws. This rapid and expansive use of these packages infers that downstream consumers, in terms of organizations and applications, are littered with known exploitable vulnerabilities (KEV).

The average top OSS package across npm, PyPI, and RubyGems was identified as having nearly 70 vulnerabilities. Python fared even worse, with over 100 vulnerabilities per package, 11 of which were deemed “critical.”

The findings from RL’s research indicate widespread, ongoing download and use of these OSS packages despite known flaws and vulnerabilities, even some of which are known to be actively exploited. This demonstrates a lack of concern or awareness among these packages' maintainers, developers, and downstream consumers.

One significant risk RL highlights is what they call “code rot,” or old and not actively maintained open-source packages. This isn’t just an RL finding or perspective either, as others have pointed out the alarming statistics below:

• 90% of codebases contain OSS components that are more than four years out of date

• 91% of codebases have components that have not seen new development in the past two years

• 79% of codebases contain components with no activity in the last 24 months while still using the latest version of the component

RL’s analysis finds similar concerning trends, such as the npm package sdp-translator not having a version release in the last 8 years but still receiving thousands of weekly downloads. This same package has hundreds of vulnerabilities in its latest version, and several of them date back to over 10 years ago - demonstrating how rotting projects and libraries that are highly vulnerable are still being consumed.

This demonstrates a complete lack of concern or governance by downstream consumers of OSS. sdp-translator isn’t alone, and RL goes on to point out several similar packages across other languages, such as Python, that are several years old but have thousands and even millions of downloads despite hundreds of vulnerabilities, many of which have been known or even exploited for years.

RL demonstrates code rot is pervasive because the industry as a whole prioritizes feature development and speed to market over security, which I also pointed out in my recent article “Secure-by-Design Delusions: The challenges of contrasting cyber with other industries and glaring challenges with Secure-by-Design desires”.

Shifting this onus onto software vendors/suppliers was a key part of the latest U.S. National Cybersecurity Strategy (NCS), but that was under the prior U.S. Presidential administration, so we will have to see if the current administration stays that course or pivots.

The ironic point that RL emphasizes is that customers ultimately end up paying for vulnerable code and products as vendors prioritize competing interests over security concerns and pass those vulnerabilities, flaws, outdated components, and their associated risks downstream to customers and consumers.

RL uses the example of Ivanti, who we saw have several highly impactful and visible incidents in 2024, including impacting U.S. Federal agencies through vulnerabilities in their Ivanit Connect Secure VPN and other products. This incident involved a base operating system that was more than a decade old and had already been declared end-of-life (EoL) 4 years prior. Ivanti devices also had versions of OpenSSL that were over 7 years old, with hundreds of vulnerabilities and over a hundred active exploits.

Secret Sprawl

I’ve written and spoken frequently about how secret sprawl is a real challenge, especially in the current world of open source, DevOps, Cloud, and Microservices. RL’s report found that this is still a problem, as they found that leaked developer secrets increased across almost every OSS package manager in 2024.

We know secrets often include forms of access and authentication such as passwords, API tokens, and more, and credential compromise plays a leading part in security incidents per sources such as Verizon’s DBIR. Below are the findings from RL’s report:

The RL team, in particular, was able to identify the following:

• 45,816 exposed secrets, 12% more than the year prior across npm, PyPI, nuGet, and RubyGems

• npm and PyPI accounted for 95% of the identified leaked secrets

• npm alone saw 4,000 more exposed secrets in 2024 than in 2023

What’s interesting is RL was able to show the top vendors associated with leaked secrets on npm’s platform:

They had similar findings from PyPI and stated that 80% of all identified secrets were either private keys, web-service API keys, or web-service access tokens. You can see it broken out below by the type of secrets leaked on npm as an example:

RL demonstrates in the report just how damaging these exposed secrets can be too, with examples such as:

• RedHunt found a leaked GitHub token belonging to a Mercedes employee that granted unrestricted and unmonitored access to the entirety of Mercedes’ GitHub enterprise server

• JFrog identifying a compiled Python file in a Docker container that could have been used to access any package stored on PyPI and the raw code for the Python language itself - whose reach can’t be overstated

Vulnerability Ecosystem Struggles

As I mentioned in the article's landscape section above, supply chain attacks are affecting not just OSS and commercial code but also the underlying vulnerability database and management ecosystem as a whole. In 2024, the latter struggled, showing foundational weaknesses with widespread ramifications.

RL’s report hammers this home, explaining how NIST’s NVD ceased enriching CVEs entirely between February and May 2024 due to funding challenges, a legacy system lacking automation, an exponential growth of discovered and reported vulnerabilities, and other challenges.

This is exceptionally depicted in RL’s diagram below, where we see the paths between new CVEs received vs. analyzed directly diverge:

CISA did/had tried to step in with a project of their own called “Vulnrichment” but even that has had some struggles as well. As the NVD’s backlog of non-enriched CVEs grew, the problem became increasingly discussed across the industry in 2024.

Vulnerability Researcher Jerry Gamblin recently pointed out that, as of last week, 8%, or over 22,000 CVEs, are still awaiting analysis and broke this down across the 10 leading CNAs.

Despite news from NIST that a new contractor was engaged to address the backlog and lack of enrichment, the problem still persists to this day, to the tune of tens of thousands of CVEs. While CISA’s Vulnrichment shows promise, the agency also faces some workforce challenges in the face of Federal workforce overhauls, leaving questions marks to the long-term sustainability and reliability of Vulnrichment as an alternative to the NVD’s gaps.

RL’s report discusses a potential post-CVE future due to challenges such as the one discussed above, missing threats in custom, proprietary software across the supply chain, and overall challenges with data quality and completeness regarding CVEs.

This aligns with my experience as organizations begin to realize the fragility and gaps of CVEs and CVSS and now add additional context such as EPSS, CISA’s KEV, leaning on additional vulnerability databases such as OSV and GitHub Security Advisories, among other mitigating measures to address for the gaps of solely relying on CVEs and CVSS base scores.

Closing Thoughts

The RL Supply Chain Security Report provides a comprehensive look at the evolving software supply chain landscape. From the ever-present open source security concerns, often overlooked commercial software risks, attack trends, and more.

If you’re interested in software supply chain security, this isn’t one to miss!

Get The Full Report!