You're maintaining a payment processing service that depends on 247 open source packages. Eighteen of them haven't seen a commit in over two years. Three have known CVEs with no patches coming. Your compliance audit is in six weeks.
This guide walks you through identifying, assessing, and remediating end-of-life (EOL) open source dependencies before they become compliance violations or breach vectors.
Scope - What This Guide Covers
This guide addresses:
- Identifying EOL and unmaintained dependencies in your stack
- Mapping EOL software to specific compliance requirements
- Building a remediation decision tree
- Documenting compensating controls when replacement isn't immediate
It does not cover evaluating commercial software lifecycle policies, managing internally-developed legacy code, or general vulnerability management. For scanning workflows, see OWASP Dependency-Check documentation.
Key Concepts and Definitions
End-of-Life (EOL): A project whose maintainers have announced no further updates. Example: Python 2.7 reached EOL on January 1, 2020.
Unmaintained: No explicit EOL announcement, but no commits, releases, or issue responses in 12+ months. This carries similar risk to EOL.
Transitive dependency: A package your direct dependencies require. You don't import it directly, but it's in your runtime or build environment. These often hide EOL risks.
Compensating control: A security measure you implement when the standard approach isn't feasible. For PCI DSS v4.0.1, these require documentation and annual review per Requirement 12.3.
Requirements Breakdown
PCI DSS v4.0.1
Requirement 6.3.2: Your custom software must be developed according to industry standards. Using EOL dependencies with known vulnerabilities violates this if patches exist in maintained alternatives.
Requirement 6.3.3: You must review code before release to production to identify security vulnerabilities. Your SAST/SCA tools should flag EOL dependencies. If they don't, your review process has a gap.
Requirement 11.3.2: Internal vulnerability scans must run quarterly and after significant changes. EOL dependencies with CVEs will appear here. You need a remediation plan before the next scan cycle.
SOC 2 Type II
CC7.1 (Change Management): Your change management process should include dependency updates. If you're still running EOL packages, auditors will ask why your change process didn't catch them.
CC7.2 (System Monitoring): You must detect security events, including new CVEs announced against dependencies you're running, even if they're EOL.
ISO/IEC 27001:2022
A.8.9 (Configuration Management): Your asset inventory must include software components and versions. EOL dependencies are configuration items that need tracking and review.
A.8.31 (Separation of Development, Test and Production): If you're using EOL dependencies, ensure they're documented in each environment. Different versions across environments create untracked risk.
Implementation Guidance
Phase 1: Discovery (Week 1)
Generate a complete dependency tree:
# Node.js
npm list --all --json > deps.json
# Python
pip-audit --format json
# Java
mvn dependency:tree -DoutputType=json
# Go
go mod graph
Flag packages where:
- Last release date > 18 months ago
- No commits in 12+ months
- Open CVEs with CVSS > 7.0
- Marked "deprecated" in package registry
Phase 2: Risk Assessment (Week 1-2)
For each flagged dependency, document:
- Exposure: Does it handle user input, parse untrusted data, or touch cardholder data?
- Transitivity: Direct dependency (you imported it) or transitive (something else needs it)?
- Alternatives: Is there a maintained fork, official successor, or equivalent library?
- Effort: Can you replace it in one sprint, or does it require architecture changes?
Create a risk matrix. High exposure + no maintained alternative = critical. Low exposure + easy replacement = quick win.
Phase 3: Remediation Decision Tree
If a maintained alternative exists:
- Replace it. Budget 2-4 weeks for testing if it's a direct dependency with significant usage.
- For transitive dependencies, update the parent package first. If the parent is also EOL, you have a bigger problem.
If no alternative exists and exposure is high:
- Fork the project and maintain security patches internally, OR
- Isolate it behind a security boundary (separate service, restricted network access, input validation wrapper), OR
- Replace the entire feature that requires it
If no alternative exists and exposure is low:
- Implement compensating controls:
- Network segmentation (if it's a service)
- Input validation at boundaries
- Runtime application self-protection (RASP) or WAF rules
- Increased monitoring/logging
- Document these controls for compliance evidence
- Set a review date (quarterly minimum)
Phase 4: Documentation for Compliance
Your compensating control documentation must include:
- Specific requirement you're addressing (e.g., "PCI DSS v4.0.1 Requirement 6.3.2")
- Why the standard control isn't feasible ("No maintained alternative to libXYZ exists; replacement requires 6-month rewrite")
- Controls you've implemented instead (list them specifically)
- Evidence the controls are effective (scan results, test reports, monitoring data)
- Review schedule and owner
Store this with your compliance documentation. Your QSA or auditor will ask for it.
Common Pitfalls
Pitfall 1: Ignoring transitive dependencies
You updated your direct dependencies but didn't check what they require. Run npm audit or equivalent after every update.
Pitfall 2: "It's not exploitable in our context"
You're probably right, but your auditor won't accept that without evidence. Document the attack path analysis or implement compensating controls.
Pitfall 3: Forking without a maintenance plan
You fork an EOL project, apply one patch, then forget about it. Now you're maintaining EOL software. If you fork, assign an owner and budget ongoing security review time.
Pitfall 4: Waiting for "the next sprint"
EOL dependencies don't age well. The longer you wait, the harder replacement becomes. If you can't fix it this quarter, document why and set a concrete deadline.
Pitfall 5: No policy for future prevention
You clean up your current EOL dependencies but have no process to prevent new ones. Add a policy: "Dependencies with no release in 12 months require architecture review before adoption."
Quick Reference Table
| Scenario | Compliance Risk | Recommended Action | Timeline |
|---|---|---|---|
| EOL package with CVE > 9.0, handles PCI data | Critical | Emergency patch or isolate | 1 week |
| EOL package, CVE 7.0-8.9, no PCI exposure | High | Replace or compensating controls | 1 sprint |
| Unmaintained (no CVE yet), processes user input | Medium | Monitor, plan replacement | 1 quarter |
| Transitive dependency, EOL, no direct exposure | Low | Update parent package | Next release |
| EOL, no CVE, no external input, internal tool | Low | Document and review quarterly | Next audit |
Next steps: Run your dependency scan today. You likely have more EOL packages than you think. Start with anything that touches payment data or authentication, then work down the risk matrix. Your Q2 audit will thank you.
