CVE and CVSS for Dependency Risk

Run npm audit on any JavaScript project that’s a few years old and you’ll get a wall of red. A raw count like “214 vulnerabilities” doesn’t help anyone: nobody can act on it, and nobody can prioritise it against features. The fix is to turn the count into a short, ranked list of real risks, described in terms the whole team understands.

The vocabulary

• CVE (Common Vulnerabilities and Exposures): a public ID for one known vulnerability, e.g. CVE-2025-58754 (a denial-of-service flaw in Axios). npm audit reads the GitHub Advisory Database (GHSA-… IDs, usually mapped to a CVE).
• CVSS (Common Vulnerability Scoring System, maintained by FIRST): a 0–10 severity score. Bands: Low 0.1–3.9 · Medium 4.0–6.9 · High 7.0–8.9 · Critical 9.0–10.0.
  • Base metrics are what the advisory gives you: attack vector (network → physical), attack complexity, privileges required, user interaction, and impact on confidentiality, integrity and availability.
  • CVSS v4.0 (2023) adds Threat (is it being exploited?) and Environmental (how much do we care?) groups. Most tools still show the Base score only, which is the generic one.
• EPSS: the probability a CVE is exploited in the next 30 days. CISA KEV: the list of CVEs known to be exploited in the wild. A 7.5 on the KEV list beats a 9.8 nobody exploits.

From score to real impact

CVSS says how bad a vulnerability is in general. Six questions say how bad it is for you:

1. Is it in production code? npm audit --omit=dev. A ReDoS in a test runner isn’t a customer risk.
2. Is the vulnerable path reachable? Do we call the affected function with attacker-controlled input?
3. Is it exposed? An internet-facing API, an internal tool, or a browser bundle.
4. What’s behind it? Customer personal data, payments or auth tokens raise the stakes (GDPR, and PCI DSS expects critical patches within a month).
5. Is it being exploited? Check EPSS and KEV.
6. What does the fix cost? A patch bump, or a major upgrade blocked by old tooling? The latter is tech debt with a security price tag, and a good argument for paying it down.

Then say the impact in business terms. “Critical, reachable from the checkout API, could leak customer emails, one-line patch, fix this sprint” is something a product manager can prioritise in a minute.

Minimising exposure

• Version sprawl is attack surface. Every version still running (per client, platform or deployment) is another place a CVE lives and another patch to ship. Old versions often can’t take the fix at all.
• Consolidate. Set a support policy (e.g. latest and one back), give clients an upgrade path, and retire the rest.
• Keep visibility at all times. Keep an inventory of what’s deployed where, with its dependencies (an SBOM per release). The test: when a big CVE lands, “are we affected, and where?” should take minutes, not days.

Automating it, with guardrails

• Bots raise the PRs (Dependabot or Renovate), grouped: one PR per ecosystem or per week, not forty.
• Auto-merge only patch and minor updates, and only when tests, contract checks and the build are green. Majors, and anything touching auth or payments, get a human reviewer.
• Wait before adopting brand-new releases. Renovate’s minimumReleaseAge, Dependabot’s cooldown and pnpm’s minimumReleaseAge all do this. The 2025 npm attacks (the chalk/debug hijack, the Shai-Hulud worm) shipped malicious versions that were pulled in within hours. Security fixes can skip the wait; Dependabot’s cooldown already applies only to version updates.
• Gate CI on new High/Critical issues in production dependencies (npm audit --audit-level=high --omit=dev, or a commercial scanner). Allow a documented ignore with an expiry date and an owner, so accepted risk is a decision, not something forgotten.
• Use lockfiles and npm ci, and never run npm audit fix --force in automation: it installs breaking majors.
• Agree severity targets, e.g. Critical within days · High within 30 days · Medium in the next maintenance window · Low batched. Track time to fix as a metric.
• Give every service an owner who gets the alert, and hold a regular triage slot rather than relying on a hero.

When the scanner itself is down

A SaaS scanner in CI is a dependency too. Its outage or maintenance window shouldn’t stop delivery, and “skip the scan” isn’t acceptable either.

• Self-host or mirror what CI relies on: a cached vulnerability database plus a self-hosted scanner (e.g. OSV-Scanner or Trivy with an offline DB) as a fallback, and a registry proxy (Verdaccio, Artifactory) so registry outages don’t break installs.
• Fail open on pull requests, fail closed on release. PR builds pass with a visible warning and a required re-scan; the production release gate stays strict.
• Catch up with nightly scheduled scans on main and every supported release branch.
• A self-hosted SBOM platform (OWASP Dependency-Track) re-checks every deployed version against new CVEs without a rebuild, which also answers the visibility question above.

In practice

On a trading platform I worked on, the audit came back long and the habit was to patch only what was critical or broken. What changed it:

• regular scanning, with alerts triaged by score and context;
• potential criticals fixed on discovery rather than queued for a sprint;
• a build-tooling proof of concept that unblocked a backlog of upgrades.

High-profile attacks elsewhere in the industry, even ones that didn’t touch us, then made the case for tightening every layer. Those were consolidating versions, keeping visibility of what’s deployed, and keeping the scanning pipeline resilient. Related: AI-Era Supply Chain: What to Trust When Anything Can Be Generated · Staying Current: Awareness vs the Trigger to Act.