Maintenance Risk Detection

A CVE scanner tells you a transitive package is vulnerable. It does not tell you why you cannot fix it. Often the answer is one of your own direct dependencies: it pins the vulnerable package below its fixed version, and the only way out is a major-version upgrade of that direct dependency - a breaking change the scanner never mentions. The finding looks fixable; in practice it is stuck.

This is maintenance risk, and it is invisible to tools that only match versions against advisories. A package can be perfectly up to date on its own line and still hold your whole tree hostage.

cve-lite . --check-maintenance looks for this pattern directly. It flags the direct dependencies that are blocking a CVE fix (constraint drag) and the direct dependencies that are deprecated on npm, so you see the maintenance decisions hiding behind your vulnerability list.

---

Running the check

--check-maintenance runs alongside a regular CVE scan in one pass:

cve-lite . --check-maintenance             # CVE scan + maintenance risk
cve-lite . --check-maintenance --json      # combined JSON output
cve-lite . --check-maintenance --fail-on high   # fail CI on a high finding
cve-lite . --check-maintenance --offline   # drag detection only (no deprecated check)

Maintenance findings render in the terminal, in --verbose, in the JSON output, and in the HTML report (--report), and they count toward --fail-on.

There is no separate subcommand and no --fix for maintenance risk: unlike an override, the remediation is a real, potentially breaking, major-version upgrade of a direct dependency, so it is surfaced for a human to decide rather than applied automatically.

---

The rules

Rule	Name	Severity	What it detects
DM001	Maintenance risk	high / medium	A direct dependency that pins a transitive dependency below its CVE fix and needs a major-version parent upgrade (high), or that is deprecated on npm (medium)

The maintenance-risk family is designed to grow. Release age already ships as context on a finding - a Last release line for packages that have not published in years - which helps you judge abandonment without treating age itself as a risk verdict. Repository-archive detection is a planned opt-in signal.

---

Why CVE scanners miss this

A version-matching scanner sees the vulnerable transitive package and stops. It does not walk back up the tree to identify which direct dependency is holding the fix hostage, and it has no concept of a package being deprecated or abandoned. --check-maintenance adds that upstream view.

---

How this fits alongside CVE and override findings

CVE Lite CLI surfaces three complementary kinds of risk in one scan:

• CVE findings - a package version matches a known vulnerability advisory.
• Override hygiene (--check-overrides) - a manual overrides/resolutions patch is stale, misplaced, or failing to take effect.
• Maintenance risk (--check-maintenance) - a direct dependency is blocking a CVE fix behind a major-version wall, or is deprecated on npm.

The three answer different questions - what is vulnerable, did my patch work, and why can't I fix it - and can be combined:

cve-lite . --check-overrides --check-maintenance --fail-on high

---

How this compares to other tools

Most dependency scanners match installed versions against advisory ranges and report what is vulnerable. They do not model the relationship between a direct dependency's version constraint and a transitive fix, so they never surface the maintenance decision that is actually blocking remediation.

Capability	--check-maintenance	npm audit	OSV-Scanner	Snyk CLI	Socket CLI
Flag the direct dep blocking a transitive CVE fix (DM001)	✅	❌	❌	❌	❌
Distinguish a within-range fix from a major-upgrade wall	✅	❌	❌	❌	❌
Flag a deprecated direct dependency	✅	❌	❌	❌	❌
Count maintenance risk toward a CI gate (--fail-on)	✅	❌	❌	❌	❌

Maintenance risk detection is part of what makes CVE Lite CLI, an OWASP Lab Project, more than a version matcher: it explains not just what is vulnerable, but what is standing between you and the fix.