The Ghost in the Dependency Tree: The End-of-Life Risk Your Scanners Miss

The average commercial application now pulls in roughly 1,100 open source dependencies, according to Sonatype's 2026 State of the Software Supply Chain report, which HeroDevs contributed data to. Most teams have no reliable way to tell which of those dependencies are still maintained.

That gap was the subject of a recent episode of the OpenSSF's "What's in the SOSS" podcast, where host CRob talked with Isaac Wuest of HeroDevs. HeroDevs got its start when Google sunset AngularJS and a few people from the Angular team built secure drop-in replacements for the end-of-life versions. The company has since expanded that model across other major frameworks and is now working on the broader end-of-life problem, deeper down the dependency tree. Isaac spends their time working directly with open source maintainers, and the conversation centered on a problem most security tooling still handles poorly.

‍

The blind spot in CVE-based scanning

CVE is, in effect, a dictionary of disclosed vulnerabilities. Someone discovers an issue, a certified reporter files it, and scores like EPSS and known-exploited lists build on top. The entire system rests on one assumption: that the vulnerability has been found and reported.

End-of-life packages break that assumption twice over. When a version stops receiving support, it stops getting security patches, and it usually stops being investigated for new vulnerabilities at all. As Isaac put it, that leaves you closer to "we just don't know" than to a clean bill of health. Maintainers rarely have the time to go back and check whether every newly disclosed CVE applies to their older release lines. The unknown is the risk.

‍

Attested end of life vs. maintainer abandonment

The most useful idea in the conversation was a distinction that's starting to harden into industry language: there are two kinds of end of life.

The first is maintainer-attested end of life. The maintainer formally states that a version is no longer supported, often with a published schedule. The big frameworks do this. For an Angular, a Vue, or a Spring, you can check the project's site or a resource like endoflife.date and see exactly when a line goes to long-term support and when support drops. An auditor can rely on it.

The second is maintainer abandonment, and it's the harder one. There's no formal notice. A maintainer quietly drops a release line, renames a package, or burns out and steps away, and no one fills the gap. Sometimes the only signal is a note in a README, a deprecated flag in the npm registry, or a post on social media. When you actually talk to maintainers, Isaac noted, even they are often unsure, the answer is some version of "I could patch it if I had time." That ambiguity is fine for the open source ethos and brittle for any enterprise trying to depend on it.

‍

Why end of life is a compliance problem, not just a security one

The security implications are clear enough: no patches, no vulnerability reports, a blank spot in your risk picture. But Isaac pointed out that the sharper motivation is usually compliance. A team handling health or payment data under HIPAA, HITRUST, or PCI cannot carry dependencies that will never receive updates. That's not a tolerable level of risk for an auditor, and it has created a real vacuum around open source end of life.

To frame the judgment call, Isaac borrowed an analogy from food regulation: the difference between hazard and risk. A shark in an aquarium tank is a hazard. The risk that it actually hurts you is low. End of life is inherently a hazard. The work for a security team is figuring out how much real risk a given end-of-life package represents, and how much effort to spend on it.

That calculus is about to get more consequential. As CRob noted, the EU Cyber Resilience Act holds manufacturers accountable for every component in their products, open source included. The bar for shipping secure software keeps rising, which is healthy for the industry and genuinely hard to meet.

‍

Why your tools miss it

Standard tooling does not close this gap yet. SBOM formats like CycloneDX and SPDX, along with most scanners, prioritize publicly reported vulnerabilities first and maintainer-attested end of life second. Very few have a complete picture of maintainer abandonment. It's still an open field.

The reason is structural. Scanners need certainty to report a clean result; they want to say supported or not supported. Maintainers live in the gray, where "I could support it if someone asks" is a common answer. The collaborative, anyone-can-pitch-in nature of open source is one of its best features, but it becomes a bug for the enterprise that needs a definitive answer for a compliance report.

‍

What to do about it

Right now the workflow is reactive. A scanner flags a CVE, an engineer searches the package name and version, and stumbles onto the fact that it's end of life with no obvious upgrade. Isaac's practical recommendations:

• Use endoflife.date for the major frameworks, where attested calendars are well maintained.
• For the long tail, use a free tool that detects maintainer abandonment. HeroDevs publishes one at eoldataset.com, where you can load an SBOM or manifest and get back which packages are end of life or likely abandoned, including the deep dependencies that attested calendars never cover.
• Then answer the question that actually matters: is there a supported version to move to, how severe are the breaking changes, and is the package buried deep enough in the graph that its version is constrained.

Knowing a package is end of life is not enough on its own. Engineers need the upgrade path. And for the cases where migrating before the deadline isn't realistic, Never-Ending Support keeps end-of-life versions patched and compliant, so the migration happens on your schedule instead of under pressure.

Isaac's closing advice was simple: find out what your applications are actually exposed to. Most teams don't know how much end-of-life code is sitting in their dependency tree, and that's the first thing worth fixing.

Listen to the full episode: "The Ghost in the Dependency Tree" on What's in the SOSS.