No dependencies with no maintainer activity in 2+ years

Abandoned packages are a latent supply chain risk: they accumulate unpatched CVEs indefinitely, and their maintainers cannot respond to security disclosures. When an abandoned package becomes popular enough to be a valuable attack surface, malicious actors have successfully requested and received maintainer access — precisely to insert backdoors into what appears to be a legitimate, versioned dependency. OWASP A06 (Vulnerable and Outdated Components) explicitly covers this scenario. CWE-1104 (Use of Unmaintained Third Party Components) names the defect class. SSDF PW.4 requires ongoing vulnerability tracking; you cannot track vulnerabilities in a package whose maintainer has gone dark. The longer an abandoned package stays in your dependency graph, the more likely it becomes that you'll be the last project to find out it was compromised.

For each abandoned dependency, evaluate alternatives before your next deploy cycle:

1. Search npm and GitHub for a well-maintained fork or successor package.
2. If the package is small and stable, vendor it — copy the source into src/lib/ and own it directly.
3. If no alternative exists, open an issue on the repository to determine whether the maintainer intends to continue it.

Add a scheduled npm outdated review to your quarterly engineering housekeeping to catch abandonment before it becomes a crisis.

• ID: no-abandoned-deps

• Severity: medium

• What to look for: Examine production dependencies (dependencies in package.json) and look for packages that show signs of abandonment: check the resolved version in the lock file against the npm registry metadata if accessible, or evaluate based on version age. Packages to flag: those whose latest version in the lock file was published more than 2 years ago AND which have no indication of intentional maintenance-freeze (i.e., they are not declared as "stable" or "feature-complete" in their README). Well-known stable-by-design packages (e.g., ms, mime-types, mime-db, qs, inherits) do not count as abandoned. Count all instances found and enumerate each.

• Pass criteria: All production dependencies show evidence of recent maintainer activity (last release within 2 years), or are well-known intentionally-stable utility packages. At least 1 implementation must be confirmed.

• Fail criteria: One or more production dependencies have not received any release in 2+ years and are not known intentionally-stable packages.

• Skip (N/A) when: No package.json detected, or the project has no production dependencies listed.

• Detail on fail: "Package 'some-lib@1.2.0' in dependencies — last published 3 years ago with no recent activity. Evaluate whether the package is abandoned." List up to 3 packages.

• Remediation: Abandoned packages accumulate unpatched vulnerabilities over time, and their maintainers cannot respond to security disclosures. If the package becomes popular enough to be a valuable attack target, it may be taken over by malicious actors.

  For each abandoned dependency:

  1. Check if there is a well-maintained fork or successor (search npm and GitHub).
  2. If the package is simple enough, vendor it — copy the source into your project under src/lib/.
  3. If no alternative exists, open an issue on the repository to understand its maintenance status before relying on it further.

  For a broader view of code quality and maintainability practices, the Code Maintainability Audit covers this in depth.