CVSS
The Common Vulnerability Scoring System (CVSS) is an open standard for
rating how severe a software vulnerability is, on a scale from 0.0 to
10.0. It is maintained by FIRST, the Forum of Incident Response and
Security Teams, and it is the number next to nearly every CVE, GitHub
security advisory, npm audit finding and Dependabot alert.
Score to severity
CVSS v3.x and v4.0 share one qualitative scale:
| Score | Rating | npm audit says | GitHub code scanning says |
|---|---|---|---|
| 0.0 | None | — | — |
| 0.1–3.9 | Low | low | Low |
| 4.0–6.9 | Medium | moderate | Medium |
| 7.0–8.9 | High | high | High |
| 9.0–10.0 | Critical | critical | Critical |
npm's info level sits below Low and carries no score. In SARIF, a
rule's security-severity property is a CVSS-style score, and GitHub
buckets it with the same bands (SARIF).
Reading the vector string
A score is computed from metrics, and the vector string is those metrics written out. The commonest one in practice:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H → 9.8 Critical
| Metric | Values | Here |
|---|---|---|
| AV — Attack Vector | Network, Adjacent, Local, Physical | Network |
| AC — Attack Complexity | Low, High | Low |
| PR — Privileges Required | None, Low, High | None |
| UI — User Interaction | None, Required | None |
| S — Scope | Unchanged, Changed | Unchanged |
| C / I / A — Impact | High, Low, None (each) | High on all three |
Read it as a sentence: reachable over the network, easy, needs no account
and no victim click, and fully compromises the component. Change UI:N
to UI:R — the victim has to open a link — and the same flaw drops to
8.8.
CVSS 4.0
FIRST published CVSS 4.0 in November 2023. The changes most readers notice:
- Scope is gone. Impact is split into the vulnerable system
(
VC/VI/VA) and subsequent systems (SC/SI/SA) instead. - Attack Requirements (
AT) joins Attack Complexity, for conditions like a race window or a specific configuration. - User Interaction becomes None, Passive or Active.
- Temporal becomes Threat, reduced to one metric: exploit maturity.
- Supplemental metrics such as Automatable and Recovery add context without changing the score.
- Scores are labelled by what went into them: CVSS-B (base only), CVSS-BT, CVSS-BE or CVSS-BTE.
Advisory databases carry both versions during the transition, so the same CVE can show a v3.1 and a v4.0 score that differ.
Severity is not priority
The score you see on an advisory is almost always a Base score: the worst plausible case for the flaw in general. It knows nothing about whether the vulnerable function is reachable in your code, whether the package only runs at build time, or whether the service is internet facing. FIRST says as much — CVSS measures severity, not risk.
That is why audit triage is a conversation, not a sort. The usual inputs alongside CVSS:
- EPSS — FIRST's estimate of the probability a CVE is exploited in the next 30 days.
- CISA KEV — the Known Exploited Vulnerabilities catalogue: proof it is being used in the wild.
- Reachability — whether your code calls the vulnerable path at all.
- Environment — the Environmental metric group exists precisely so you can re-score for your deployment.
Where the decision lives
The outcome of that triage — "accepted, build-time only", "patched by
the override in #2214", "waiting on upstream" — is the part an auditor
or a client asks for later, and it rarely survives in a terminal or a CI
log. Turning the audit into a report and attaching the decision to the
advisory it concerns keeps them together: drop npm audit --json into
the free npm audit viewer or a .sarif scan
into the SARIF viewer, publish it as a link, and
comment on the finding itself (comment on HTML).
Try it
Comma is free — unlimited reports, unlimited commenters, unlimited revision history.