GoKawiilWritten by Isaac Wuest, Principal Product Manager at HeroDevs.
When security teams think about end-of-life (EOL) open source software, the conversation usually starts and ends in the same place: no more patches.
That's true, but it's only half the story, and arguably the less dangerous half. There are two compounding problems most teams are unaware of.
Problem One: The CVE Ecosystem Doesn't Investigate What It Doesn't Support
When a vulnerability is discovered in an open source project, maintainers determine which versions are affected and file a CVE with a defined affected range. Every vulnerability scanner, SBOM tool, and CVE feed in the industry consumes that range.
If your version falls outside it, you get no alert. Not because you're safe, but because no one checked.
EOL versions fall outside that range almost by default. The reason is straightforward: it's a scale problem. In just five years, the global CVE count doubled while the number of unscored CVEs increased 37x, according to Sonatype's 2026 State of the Software Supply Chain report.
Maintainers are already overwhelmed investigating and patching the versions they actively support, and as both CVE volume and the total number of package releases continue to grow, the investigative bandwidth required to cover older release lines simply doesn't exist.
Maintainers must be realistic about how far back in their own release history they can reasonably go.
Sonatype's research explicitly named "EOL versions omitted from advisories" as a driver of false security confidence, contributing to the 167,286 false negatives, exploitable components that went entirely unflagged, they identified in 2025 alone.
... continue reading