The Overlooked Vulnerability Threat
Your Software Composition Analysis (SCA) tool flags 47 vulnerabilities in your production dependencies. You patch them, and your dashboard shows green. But here's the catch: your tool never informed you that 25% of your npm packages reached end-of-life (EOL) months ago, and the CVE feed you rely on stopped investigating vulnerabilities in those versions.
This isn't just a breach—it's a systematic failure affecting thousands of organizations that mistakenly believe their vulnerability management process is effective.
The Growing Coverage Gap
2018-2023: The global CVE count doubled, while unscored CVEs increased 37 times. The CVE ecosystem couldn't keep up with the surge in open-source packages.
Ongoing: Security researchers and CVE Numbering Authorities (CNAs) focus on new vulnerabilities in supported software versions. They rarely backtest EOL versions, even when the vulnerable code exists in those older releases.
Present day: HeroDevs analysis shows that 80% of CVEs assigned to supported versions also affect their EOL counterparts. Your CVE feed only shows the 20% that are tracked, leaving the majority unflagged by your tools.
Identifying the Control Failures
Vulnerability identification failed at the data source level. Your SCA tool can only alert you about what the CVE database contains. If EOL versions are excluded from CVE investigations, the vulnerabilities remain invisible in your feed, even though they exist in your codebase.
Asset inventory failed to flag EOL status. Most organizations track package names and versions but don't systematically identify which dependencies have reached EOL. The most widely-used EOL tracking source, endoflife.date, covers only a fraction of the actual EOL software landscape.
Risk assessment failed to account for coverage gaps. Compliance frameworks require vulnerability scanning, assuming scan results represent actual risk exposure. When 80% of applicable CVEs never appear in your results, your risk assessment is fundamentally flawed.
Compliance Standards and Your Responsibilities
PCI DSS v4.0.1 Requirement 6.3.2 mandates identifying security vulnerabilities and assessing their risk. If your CVE feed doesn't include EOL vulnerabilities, you're not meeting this requirement.
NIST 800-53 Rev 5 control RA-5 requires vulnerability monitoring and scanning. The control states you must remediate flaws based on risk assessment, but you can't assess risk for unknown vulnerabilities.
ISO/IEC 27001:2022 Annex A.8.8 requires obtaining timely information about vulnerabilities. This becomes meaningless when information never arrives because researchers stopped investigating your software versions.
SOC 2 Type II CC7.1 addresses security vulnerabilities. Your auditor will review your vulnerability management process, but standard audits don't typically test if your CVE feed covers EOL software.
These frameworks assume comprehensive vulnerability data, not accounting for systematic blind spots in the CVE ecosystem.
Actionable Steps for Your Team
1. Build an EOL inventory separate from your vulnerability scanner
Your SCA tool tracks packages. You need a parallel process to track EOL status. Start with:
- Query your package manifests against endoflife.date via API.
- Flag any package version that's EOL or within 6 months of EOL.
- For packages not in endoflife.date, check the project's official support policy.
Document this as part of your asset inventory (NIST 800-53 CM-8). Update it quarterly.
2. Treat EOL software as a vulnerability class
In your risk register, create a category for "EOL software with active CVE coverage gap." Assign it a base risk score, independent of whether CVEs exist. The absence of CVEs doesn't mean absence of risk.
Document this in your risk assessment for PCI DSS compliance (Requirement 12.3.1). For SOC 2, include it in your risk management narrative.
3. Set upgrade triggers before EOL dates
Don't wait until software reaches EOL to plan the upgrade. When a dependency announces an EOL date:
- Schedule the upgrade for 90 days before EOL.
- If you can't upgrade by EOL, document the compensating controls and timeline.
- Add the package to your exception tracking with automatic expiration at EOL.
This aligns with ISO/IEC 27001:2022's requirement to maintain supported software versions.
4. Challenge your audit scope
Next time an auditor reviews your vulnerability management process, ask them to test a sample of EOL packages. Request verification on whether your scanning tool would detect a known CVE in an EOL version.
5. Recalibrate your "clean scan" interpretation
A vulnerability scan with zero findings doesn't mean zero vulnerabilities. It means zero vulnerabilities that your tool's database knows about. Train your team to ask: "What percentage of our dependencies are EOL?" before celebrating a clean scan.
The 80% figure from HeroDevs should change how you interpret scan results. If a quarter of your npm packages are EOL, and 80% of CVEs in supported versions also affect EOL versions, your actual exposure is likely 4-5 times what your dashboard shows.
You can't patch what you can't see. But you can identify what you're missing—and that's where the work begins.
