What the 2026 State of the Software Supply Chain Report Gets Right About End-of-Life Software

When Sonatype reached out to collaborate on the 2026 State of the Software Supply Chain Report, we knew we were walking into a conversation the industry needed to have. What we didn't fully anticipate was how clearly the data would validate something we've been watching up close for years: the part of the vulnerability problem that nobody's tooling was built to solve.

The report is out. HeroDevs contributed original EOL research to it. And if you work in security, engineering leadership, or compliance, this report — specifically the vulnerability management chapter — is worth your time.

Here's what we found, what it confirmed, and what it means for organizations trying to get a handle on open source risk in 2026.

‍

What Is the 2026 State of the Software Supply Chain Report?

The State of the Software Supply Chain (SSCR) is an annual research report published by Sonatype, a software supply chain security company that operates Maven Central — the primary repository for the world's Java open source components. The report draws on data from more than 10 trillion open source downloads across Maven Central, PyPI, npm, and NuGet, combined with analysis from Sonatype's security research team.

This year's report covers six major areas: open source growth, malware, vulnerability management, AI agents, compliance, and methodology. The vulnerability management chapter is where HeroDevs' contribution lives, and it's where the report's most significant findings for the EOL space appear.

‍

What HeroDevs Contributed: Putting Numbers on the EOL Problem

End-of-life software has always been hard to quantify. There's no universal registry of "dead" packages. Maintainers rarely announce their departure — they just stop responding. Projects fade away without a formal end date. That ambiguity has historically let organizations underestimate how much EOL software they're actually running.

For the SSCR, HeroDevs contributed data and analysis on the scale and security implications of EOL dependencies in enterprise software stacks. The numbers that made it into the report:

81,000+ package versions with known CVEs are both end-of-life and unpatchable. These are not theoretical risks — they are disclosed vulnerabilities in software that will never receive a patch because the project is no longer maintained. HeroDevs estimates the actual figure across all registries may be closer to 400,000, because advisory coverage degrades for unsupported versions and many EOL vulnerabilities are never formally disclosed.

5 to 15 percent of components in enterprise dependency graphs are EOL. This matters because it means EOL exposure is present even when teams believe they're only using supported top-level libraries. EOL hides in transitive dependencies — the packages your packages depend on — where it's invisible to most scanning workflows.

619 million downloads of Log4j artifacts affected by Log4Shell came from EOL versions in 2025 alone — four years after the vulnerability was disclosed. 14% of all affected Log4j artifacts are now EOL, meaning no patch path exists even for teams that want to remediate.

These aren't edge cases. They're structural features of how modern enterprise stacks accumulate dependencies over time.

‍

The Three-Layer Framework: Where EOL Fits

The SSCR's vulnerability chapter introduces a framework for understanding why vulnerability management is failing — not because of any single tool or team, but because the system breaks down across three distinct layers simultaneously.

The Data Layer is where vulnerability intelligence originates: CVE, NVD, and the advisory pipelines around them. Last year, 64% of open source CVEs went unscored by the NVD. The median time for NVD to score a CVE was 41 days — during which exploits and patches were both already circulating. When the data layer fails, every downstream decision starts from the wrong premise.

The Consumption Layer is where organizations import open source into their builds. Even when accurate data and patches exist, vulnerable versions continue to be downloaded at scale. The report found 1.8 billion avoidable vulnerable downloads in 2025 from just four prominent Java components — all with fixes readily available.

The Ecosystem Layer is where HeroDevs operates. This is where software reaches end of life, patches stop being issued, and traditional "scan → ticket → patch" workflows become permanent backlog generators. When no patch is coming, you can't fix your way out of the risk. You need a different model entirely.

The report is explicit about this: for the ecosystem layer, the only viable paths are major upgrades, framework replacement, or commercial backports that extend support for unsupported release lines. HeroDevs exists for that third option.

s

What Surprised Us in the Data

We spend every day working on EOL software. We've seen what it looks like inside organizations — the legacy apps that run fine but sit on frameworks nobody supports, the migration roadmaps that keep getting deprioritized, the CVEs that come in with no remediation path. We thought we had a pretty clear picture of the problem.

What the report reinforced was the gap between what organizations think they're running and what they're actually running. The 5-15% EOL figure in enterprise dependency graphs is particularly striking because it shows up even in organizations with mature dependency management practices. Teams govern their direct dependencies carefully and still end up with EOL exposure in the transitive layer.

The other finding that stuck with us: "no CVE" for an EOL package doesn't mean it's safe. It often means nobody's looking at it anymore. Advisory coverage degrades for unsupported versions at the same time that code review activity drops. The absence of disclosed vulnerabilities in abandoned software can be a signal of low scrutiny, not actual security.

‍

What This Means for Security Programs in 2026

If you take one thing from the SSCR this year, it should be this: your vulnerability management program is probably not designed for the ecosystem layer of your risk. Most scanning tools, most CVE workflows, and most remediation processes assume a patch exists or will exist. They are optimized for the data and consumption layers. They have no answer for the 81,000+ package versions — likely 400,000 — where the answer is simply: no patch is coming.

That creates three practical questions worth asking:

Do you know how much of your dependency graph is EOL? Not just your top-level dependencies, but your transitive graph. If you don't have continuous visibility into EOL status across your full application portfolio, you're making security decisions without a complete picture of your risk.

What's your plan for EOL exposure you can't immediately migrate? Migrations take time. Engineering capacity is finite. Compliance requirements don't wait for roadmaps. Organizations need a plan for the gap between "we know this is EOL" and "we've completed the migration."

Are your compliance attestations reflecting your actual EOL exposure? The report notes that compliance artifacts increasingly reflect what tools can see rather than what's actually running. If your scanning tools aren't built to surface EOL status, your audit results may be giving leadership a false sense of coverage.

‍

Read the Full Report

The 2026 State of the Software Supply Chain Report is available here. The vulnerability management chapter is required reading for anyone building or maintaining a security program in 2026. Read it alongside the compliance chapter for the full regulatory picture.

‍

Find Out Where Your EOL Exposure Actually Is

HeroDevs' EOL Detection Suite provides continuous visibility into end-of-life dependencies across your entire application portfolio — not just your top-level packages, but your full transitive graph. When a package reaches EOL or a new CVE is disclosed against an unsupported version, your team knows immediately.

For EOL dependencies you can't migrate on your timeline, Never-Ending Support (NES) provides security patches and CVE remediation for end-of-life frameworks — giving your team the runway to migrate on your schedule, not under duress.

See where your EOL exposure is: eoldataset.com

‍

Frequently Asked Questions

What is the 2026 State of the Software Supply Chain Report? The State of the Software Supply Chain is an annual report published by Sonatype that analyzes open source risk, vulnerability management, malware, compliance, and AI across the global software ecosystem. The 2026 edition draws on data from more than 10 trillion downloads across Maven Central, PyPI, npm, and NuGet.

What did HeroDevs contribute to the 2026 SSCR? HeroDevs contributed original research and data on end-of-life (EOL) software, including estimates of the number of EOL package versions with known CVEs, EOL prevalence in enterprise dependency graphs, and analysis of how EOL status creates permanent vulnerability exposure that traditional remediation workflows cannot address.

What is the ecosystem layer of vulnerability management? The ecosystem layer is the third of three failure layers identified in the 2026 SSCR vulnerability chapter. It describes the risk created when open source software reaches end of life and patches stop being issued. Unlike the data layer (incomplete CVE data) and consumption layer (poor dependency hygiene), the ecosystem layer cannot be fixed by scanning tools or patching workflows — it requires migration, replacement, or extended commercial support.

How many EOL package versions have known CVEs? According to HeroDevs' research cited in the 2026 SSCR, at least 81,000 package versions with known CVEs are both end-of-life and unpatchable. HeroDevs estimates the actual figure across all registries may be closer to 400,000, because advisory coverage degrades for unsupported versions and many EOL vulnerabilities are never formally disclosed.

What is Never-Ending Support (NES)? Never-Ending Support is HeroDevs' commercial extended support offering that provides security patches and CVE remediation for end-of-life open source frameworks. NES allows organizations to maintain security coverage for EOL dependencies while migrations are planned and executed, without requiring emergency rewrites under pressure.