An abandoned npm package is more dangerous than a vulnerable-but-maintained one. A maintained package with a CVE today is a fixed package next week. An abandoned package with no CVE today is a future critical CVE that nobody will patch. Reviewers know this. Your dependency report should know it too.
Why abandonment matters more than current CVE count
Take two packages, both used at depth 2 in your tree:
express@4.21.0— 0 known CVEs, last commit 3 weeks ago, 8 active maintainers.node-uuid@1.4.8— 0 known CVEs, last commit 8 years ago, deprecated.
Today they look identical to a basic CVE scanner. In practice, the second is a ticking time bomb: any future vulnerability discovered in it will sit unpatched, and you will have to fork, patch, or migrate under emergency pressure.
The signals that mark a package as abandoned
No single signal is conclusive. The combination is.
| Signal | Threshold (warn) | Threshold (red) |
|---|---|---|
| Last commit on main branch | > 12 months | > 24 months |
| Last npm publish | > 12 months | > 24 months |
| Open issues never triaged (oldest) | > 18 months | > 36 months |
| Active maintainers in last 12 months | < 2 | 0 |
| Explicit deprecation notice | — | any |
| Repository archived on GitHub | — | any |
A "no recent commits" alone isn't damning. Some libraries (e.g. small utilities, polyfills) are finished. Cross-check with maintainer count and explicit deprecation before flagging.
Free signals you can pull yourself
- npm registry:
npm view <package> time— last publish date - GitHub API:
/repos/<owner>/<repo>forarchived,pushed_at,open_issues_count - libraries.io: aggregates registry + repo signals into a SourceRank score (free up to a quota)
- OSV.dev: vulnerability data, queryable without auth
What auditors do with this information
For each abandoned package in your tree, an auditor will want:
- Confirmation of the abandonment status (last commit, maintainer count)
- Your replacement plan (fork, swap, remove) with a deadline
- If you cannot replace it before ship: a documented compensating control (sandboxing, input validation, restricted code path)
See every abandoned package in your tree
DepTriage flags last-commit-age and maintainer count for every dependency in your lockfile.
Run a scan →FAQ
No. Some libraries are deliberately stable — small utilities, well-defined polyfills. Combine the signals; do not flag on commit-age alone.
If you only call one or two functions of it, copy those functions into your code and remove the dependency. This is faster than forking and ends the future risk entirely.
npm deprecate remove the package?No — it adds a warning that appears on install. Deprecated packages remain installable. You still need to act on them.