# What Is CVSS? — Scores, Severity Ratings and Vector Strings Explained

Canonical: https://commareports.com/glossary/cvss
Published: 2026-10-25

> CVSS is the 0–10 score attached to almost every CVE and GitHub advisory. How the score maps to Low, Medium, High and Critical, how to read a vector string, what changed in CVSS 4.0, and why a 9.8 isn't automatically your top priority.

# 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](/glossary/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](/tools/npm-audit-viewer) or a `.sarif` scan
into the [SARIF viewer](/tools/sarif-viewer), publish it as a link, and
comment on the finding itself ([comment on HTML](/comment-on-html)).

## Try it

Comma is free — unlimited reports, unlimited commenters, unlimited
revision history.

**[Open the npm audit viewer →](/tools/npm-audit-viewer)**

### Related

- [npm audit viewer](/tools/npm-audit-viewer) · [SARIF viewer](/tools/sarif-viewer) · [Share an npm audit report](/share-npm-audit-report)
- [SARIF](/glossary/sarif) · [SBOM](/glossary/sbom) · [Security teams](/for/security-teams)
- [Share a security scan report](/share-security-scan-report) · [Glossary](/glossary)