Scope - What This Guide Covers
This guide addresses the risks of end-of-life (EOL) open source dependencies in commercial applications. You'll learn how to identify EOL components, assess compliance impact, and implement monitoring systems before a critical framework becomes unsupported.
This applies if you:
- Maintain applications with numerous dependencies
- Must comply with PCI DSS v4.0.1, HIPAA, or SOC 2 Type II
- Need to defend your dependency strategy to auditors
Key Concepts and Definitions
End-of-Life (EOL): The date after which a project maintainer stops releasing security patches. This is different from deprecation, where support continues but is discouraged.
Unmaintained vs. EOL: An unmaintained project has no active development but no formal EOL announcement. EOL means the maintainer has explicitly ended support.
Transitive Dependency Risk: Your direct dependencies pull in many more. When AngularJS reached EOL, every application using it inherited that risk—whether teams knew they depended on it or not.
Security Debt: The accumulating risk from running EOL software. Unlike technical debt, this risk compounds as new vulnerabilities are discovered without available patches.
Requirements Breakdown
PCI DSS v4.0.1
Requirement 6.3.2: Inventory all software components, including version numbers and EOL status. Auditors will ask how you track when dependencies lose support.
Requirement 6.3.3: Address vulnerabilities based on risk ranking. When a component reaches EOL, you can no longer receive patches for new vulnerabilities, affecting your risk ranking.
SOC 2 Type II
CC7.1 (System Monitoring): You must detect security events. EOL dependencies represent a blind spot—you can't detect patches that will never exist.
CC8.1 (Change Management): Document your process for evaluating and responding to EOL announcements. Auditors expect evidence you're tracking this systematically.
ISO/IEC 27001:2022
Control 8.31 (Separation of Development, Test, and Production): EOL components in production require documented risk acceptance if you can't upgrade. Your ISMS must address how you handle dependencies that can't be patched.
Implementation Guidance
Build Your EOL Tracking System
Start with a dependency inventory. Run npm audit, pip-audit, or your language-specific scanner. Export the full dependency tree—both direct and transitive.
For each dependency, document:
- Current version
- Latest available version
- Announced EOL date (if any)
- Maintainer's communication channel (GitHub releases, mailing list, Twitter)
The variability in EOL communication is a major challenge. Some projects announce 12 months ahead, while others go silent. AngularJS gave clear notice, but smaller libraries may just stop committing.
Set Up Monitoring
Create calendar alerts for known EOL dates. For dependencies without announced EOL:
- Watch the GitHub repository for reduced commit frequency
- Monitor issue response time
- Track maintainer activity across their projects
If commits stop for 6+ months and issues pile up, treat it as pre-EOL and start planning.
Build Your Response Playbook
When an EOL announcement hits:
Week 1: Assess impact
- Which applications use this dependency?
- Is it direct or transitive?
- What's the upgrade path?
Week 2-4: Evaluate options
- Can you upgrade to a supported version?
- Does a fork with active maintenance exist?
- What's the cost of rewriting to eliminate the dependency?
Month 2+: Execute or accept risk
- Document the business justification if you can't upgrade
- Implement compensating controls (WAF rules, runtime monitoring)
- Schedule the work in your next planning cycle
Compliance Documentation
Your auditor will want:
- Dependency inventory with EOL dates
- Risk assessment for each EOL component
- Remediation plan with timelines
- Compensating controls for accepted risks
Build this documentation continuously, not just for audits.
Common Pitfalls
Assuming transitive dependencies are "someone else's problem": You own the risk for every dependency in your tree. When a library three levels deep reaches EOL, it's your vulnerability surface.
Waiting for a CVE before acting: By the time a CVE is published for an EOL component, you have no patch option. You're choosing between emergency rewrites or running known vulnerabilities.
Treating all EOL equally: An EOL logging library is different from an EOL web framework. Prioritize based on attack surface—anything that parses untrusted input or handles authentication gets attention first.
Ignoring the "it still works" trap: EOL software works fine until it doesn't. The risk isn't that it stops functioning—it's that new vulnerabilities emerge with no fix available.
Underestimating upgrade complexity: "Just upgrade" sounds simple. In practice, major version bumps break APIs, require code rewrites, and cascade through your architecture. Budget accordingly.
Quick Reference Table
| Scenario | Compliance Risk | Action Priority | Timeline |
|---|---|---|---|
| Direct dependency, EOL in 6 months | High - auditors will ask about upgrade plan | P1 | Start planning now |
| Transitive dependency, EOL in 6 months | Medium - document why direct dependency hasn't upgraded | P2 | Evaluate alternatives to direct dependency |
| Direct dependency, EOL announced (past) | Critical - active compliance finding | P0 | Upgrade, replace, or document risk acceptance this sprint |
| Transitive dependency, EOL announced (past) | High - shows lack of supply chain visibility | P1 | Force upgrade of direct dependency or fork |
| No EOL date, but unmaintained 12+ months | Medium - potential future finding | P2 | Add to watch list, plan migration |
| Critical security component (auth, crypto) EOL | Critical regardless of timeline | P0 | Emergency response |
What to Do Monday Morning
- Run your dependency scanner and export the full list.
- Cross-reference against Sonatype's supply chain reports or endoflife.date.
- Flag anything EOL or unmaintained for 6+ months.
- Schedule a 30-minute review with your team to assign owners.
- Create a standing agenda item in sprint planning for dependency health.
The work isn't glamorous. But when your auditor asks how you manage EOL risk—or worse, when a zero-day hits an EOL component—you'll have an answer ready.
