Abandoned Dependency Risk Monitor — Bus Factor, Not CVEs

The Dependency Vulnerability Advisor (#57) answers "is this package currently vulnerable" — a known-CVE lookup. This actor answers the question that comes before a CVE exists: is this package's maintainer going dark?

The xz-utils backdoor and the event-stream incident both had exactly this shape before anyone found a CVE: a single burned-out maintainer, quietly gone silent, on a package thousands of other projects still trusted blindly.

The risk model

Staleness alone proves nothing — a mature, stable package with five maintainers and no release in three years is probably just finished, not abandoned. The dangerous combination is both axes at once: a single maintainer, gone quiet.

Signal	Meaning
high	Single maintainer + no release in 36+ months — the xz-utils/event-stream shape
elevated	Single maintainer + no release in 18+ months
watch	Single maintainer but still actively publishing, OR multi-maintainer + very stale (probably mature, not abandoned)
deprecated	Explicitly marked deprecated by npm — wins over every other signal
healthy	Multiple maintainers, actively publishing

Input

{ "packages": ["left-pad", "event-stream", "express"] }

Usually your production dependency list, not devDependencies.

Sample output

{
  "package": "left-pad",
  "risk": "deprecated",
  "verdict": "Package is explicitly marked deprecated by its maintainer(s). Plan a replacement.",
  "maintainerCount": 2,
  "monthsSinceLastPublish": 28.6,
  "monthlyDownloads": 6471249,
  "popularity": "critical_infrastructure"
}

Typical uses

• SBOM / supply-chain risk review — flag single-maintainer packages before a security audit asks about them.
• Pre-adoption check — before pulling in a new dependency, check its bus factor.
• Periodic fleet scan — re-run against your package.json quarterly to catch a maintainer going quiet before it becomes an incident.

Pricing

$3.00 / 1,000 results ($0.003 per package checked).

⚠️ Read before you act

• This flags a risk profile, not a confirmed compromise. A "high" risk package may simply be finished and stable — read the verdict, don't auto-block on the label alone.
• Popularity (downloads/month) is a blast-radius signal, not part of the risk score itself — a stale package nobody uses is a shrug; a stale package millions depend on is worth real attention.
• Data comes from npm's own registry — maintainer count and publish dates are what npm reports, not a deeper investigation of actual project activity (GitHub commits, issue responses, etc.).

FAQ

• How is this different from #57? #57 checks known CVEs (a vulnerability that's already been found and reported). This checks maintainer health — a leading indicator, before any CVE exists.
• Why does "deprecated" override everything else? It's the maintainer's own explicit signal — stronger evidence than any inferred staleness metric.
• Can I check devDependencies too? Yes — any npm package name works; this doesn't distinguish dependency type.

Related actors

• Dependency Vulnerability Advisor — known-CVE checking, the complementary half of dependency risk.
• npm Package Info — raw package metadata without the risk scoring.