No deprecated packages in dependencies
Why it matters
Deprecated packages receive no further releases, which means any vulnerability discovered after the deprecation date will never be patched by the original maintainer. OWASP A06 (Vulnerable and Outdated Components) and CWE-1104 (Use of Unmaintained Third Party Components) define this risk precisely. The request library — deprecated in 2020 — is still found in production codebases years later, and every CVE filed against node-fetch or axios since then represents a risk that request users cannot mitigate. SSDF PW.4 requires that known weaknesses in components be identified and addressed; shipping a deprecated dependency means you've accepted permanent vulnerability exposure for whatever the package does.
Severity rationale
High because deprecated packages cannot receive security patches, meaning any CVE discovered after deprecation creates permanent, unresolvable vulnerability exposure in your production stack.
Remediation
Identify deprecated packages and migrate to their recommended successors. Check deprecation status for any suspect package:
npm view package-name deprecated
Common migrations:
request→ nativefetch(Node 18+) oraxiosnode-uuid→uuidglob@<9→glob@latestrimraf@<4→rimraf@latest
Migrate one package at a time and run your test suite after each to surface any API differences.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Dependency & Supply Chain Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- cwe · CWE-1104 — Use of Unmaintained Third Party Components
- owasp:2021 · A06 — Vulnerable and Outdated Components
- ssdf:800-218 · PW.4 — Reuse Existing, Well-Secured Software
Taxons
History
- 2026-04-18·v1.0.0·Initial import from dependency-supply-chain·automated