CVSS

The Common Vulnerability Scoring System translates the properties of a vulnerability into a number between 0.0 and 10.0. It answers the question “how bad is this vulnerability in general?” It does not answer “how dangerous is it for us?”

That distinction is the heart of using CVSS sensibly. Skipping it means prioritising by a number that knows nothing about your deployment.

How the score is built

CVSS consists of several metric groups, of which in practice only the first is usually published:

• Base metrics describe invariant properties of the vulnerability: how it is reached, how complex exploitation is, which privileges are needed, what damage it can do.
• Threat or temporal metrics ask how mature available exploit code is and whether exploitation is already happening.
• Environmental metrics capture how relevant the affected system is in your setting and which safeguards are already in place.

The figure quoted publicly is almost always the base score. It is a starting point, not a result.

The severity bands

Scores are conventionally translated into five bands: 0.0 none, 0.1–3.9 low, 4.0–6.9 medium, 7.0–8.9 high, 9.0–10.0 critical. These bands are a convention of the system, not a legal requirement.

Alongside the long-established version 3.1 there is now version 4.0, which mainly reworked the threat and environmental parts. Databases carry both, sometimes side by side. When comparing two scores it is therefore worth checking the version.

The vector tells you more than the number

Every score comes with a vector, a compact string showing how it was arrived at. A typical example in version 3.1:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

The key abbreviations:

• AV (attack vector): N (network), A (adjacent network), L (local), P (physical access). The difference between N and L often decides actual urgency.
• AC (complexity): L (low) or H (high), meaning whether special conditions must be met.
• PR (privileges required): N (none), L (low), H (high).
• UI (user interaction): N (none needed) or R (required).
• C/I/A: impact on confidentiality, integrity and availability, each H, L or N.

Two vulnerabilities scoring an identical 7.5 can have completely different vectors. One is reachable over the network with no privileges; the other needs local access and user interaction. For prioritisation that is the decisive information. The number does not carry it.

Version 3.1 and version 4.0

Both versions are in circulation, and their values are not comparable. Before placing two scores side by side, check the prefix in the vector.

Version 4.0 changed three things above all. The previously under-used temporal group became the threat group, focused on the maturity of available exploits. The contested scope metric was replaced by separate impact metrics for the vulnerable system and for subsequent systems. And a supplemental group was added, capturing among other things safety relevance, automatability and recoverability.

Practically important is the naming convention: a bare base value is CVSS-B, one enriched with threat data CVSS-BT, a fully contextualised one CVSS-BTE. Where that label is missing, you are almost always looking at the base value alone.

What usefully complements CVSS

Because the base value says nothing about the actual threat situation, two complements have become established:

• EPSS estimates the probability that a vulnerability will be exploited within the next 30 days. It answers the question CVSS leaves open: not “how bad would it be” but “how likely is it to happen”.
• Catalogues of known exploitation, such as the KEV list maintained by the US agency CISA or the exploitation status in the European vulnerability database EUVD, record vulnerabilities for which exploitation is evidenced.

The second category matters particularly under the Cyber Resilience Act (CRA): an entry there is strong evidence that you are dealing with an Actively exploited vulnerability, and therefore a trigger to check whether the reporting clock is running. A high CVSS score alone is expressly not.

What CVSS does not do

It does not measure risk. Risk is impact times likelihood in a specific context. CVSS supplies building blocks for that, not the result.

It does not know your product. Whether the vulnerable function is ever called in your product is something the system cannot know. Documenting exactly that is what VEX is for.

It does not replace a decision. Two vulnerabilities with identical scores can differ completely in urgency. A defensible prioritisation rule is worth more than a fixed threshold.

Relation to the CRA

The regulation does not mention CVSS. It does, however, require the final report on an Actively exploited vulnerability to describe the vulnerability “including its severity and impact”. Using an established, reproducible scoring method is therefore the pragmatic way to meet that requirement defensibly.