A CVSS score is not a risk

Take an ordinary Monday morning (a fictional example). The scanner has delivered its report: 412 vulnerabilities, 38 of them rated critical. Internal policy requires critical issues to be fixed within seven days, and the team has the capacity to handle about ten. Someone has to choose which ones go first.

Sorting by descending CVSS score is the most common reflex. That sort rests on a misunderstanding, one the authors of the standard took care to clear up themselves.

What CVSS measures, according to its authors

The Common Vulnerability Scoring System is maintained by FIRST. The version 3.1 user guide devotes a section to the question, titled “CVSS Measures Severity, not Risk” (CVSS v3.1 User Guide). CVSS measures the severity of a vulnerability; risk is a different quantity.

Severity describes the intrinsic characteristics of the flaw: how it is reached, what it takes to exploit it, what it allows. It is the same for every organisation. Risk depends on your context: how exposed the asset is, the data it holds, whether the vulnerability is being exploited right now, whether a compensating control exists. It varies from one organisation to the next.

The score published in vulnerability databases is almost always the base score, which knows nothing about your infrastructure.

Reading the vector

A 9.8 on its own says little. Its vector says more:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H   → 9.8 (Critical)

Network attack (AV:N), low complexity (AC:L), no privileges (PR:N) and no user interaction (UI:N) required, high impact on confidentiality, integrity and availability. If the affected component only listens on an internal interface, AV:N remains correct in the sense of the specification, yet poorly describes your real exposure. The CVSS 3.1 calculator breaks a vector down metric by metric and shows what moves the score.

CVSS 3.1 and 4.0: what changed

Version 4.0, published by FIRST in November 2023 (specification), fixes several shortcomings attributed to 3.1.

	CVSS 3.1	CVSS 4.0
Metric groups	Base, Temporal, Environmental	Base, Threat, Environmental, Supplemental
Attack conditions	Attack Complexity only	AC, plus a new Attack Requirements (AT) metric
User interaction	None, Required	None, Passive, Active
Scope	Scope (S) metric	Removed: separate impacts on the vulnerable system (VC, VI, VA) and on subsequent systems (SC, SI, SA)
Threat	Exploit Code Maturity, Remediation Level, Report Confidence	Exploit Maturity only
Nomenclature	“CVSS score”	CVSS-B, CVSS-BT, CVSS-BE or CVSS-BTE depending on the groups used

The same remote code execution, with no prerequisites, reads as follows in 4.0:

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N   → 9.3 (Critical)

For prioritisation, the new nomenclature is the most useful change. Writing “CVSS-B 9.3” states explicitly that this is a base score, computed without any information about the threat or the environment. The reader knows straight away what the calculation leaves out.

EPSS: a probability of exploitation

The Exploit Prediction Scoring System, also run by FIRST, answers a different question: the probability that exploitation activity for the CVE will be observed in the next 30 days. The score, between 0 and 1, comes with a percentile and is recalculated every day from observation data and the characteristics of the vulnerability.

The API is public and needs no authentication:

curl -s "https://api.first.org/data/v1/epss?cve=CVE-2021-44228" | jq '.data[0]'

The response contains epss (the probability), percentile and the date of the calculation. The EPSS FAQ gives two caveats. EPSS estimates a probability of exploitation in the wild and says nothing about impact: a CVE with a low EPSS on your most critical asset can still be a priority. And it is a statistical estimate across all vulnerabilities, which ignores whether your organisation is specifically targeted.

KEV: exploitation observed

The Known Exploited Vulnerabilities catalogue from the US agency CISA lists vulnerabilities for which there is reliable evidence of active exploitation. Three conditions apply for inclusion: a CVE identifier, confirmed exploitation and a clear remediation action. The catalogue is available as JSON:

curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | jq '.vulnerabilities[] | select(.cveID == "CVE-2021-44228")
        | {cveID, dateAdded, knownRansomwareCampaignUse}'

EPSS predicts, KEV records. A CVE listed in the catalogue and present in your estate deserves to be handled before the others, whatever its CVSS score. In France, the CERT-FR advisories and alerts play a complementary role, particularly for products widely deployed in French public bodies and companies.

Prioritising in context

None of these sources is enough on its own. Combined with your inventory, they give you a defensible grid, to be adapted to your organisation.

1. Confirmed exploitation. The CVE is in KEV, or a CERT-FR alert mentions exploitation. If the asset is exposed, it is handled immediately.
2. Exposure. Can the asset be reached from the Internet, from a partner network, or only from an administration segment?
3. Asset criticality. Personal data, production, the payment chain and the authentication directory do not weigh the same as an isolated test machine.
4. Probability of exploitation. A high EPSS, in absolute value or as a percentile depending on the threshold you have calibrated, raises the priority by one level.
5. Technical severity. The CVSS vector, read metric by metric, clarifies the exploitation conditions and the impact.
6. Compensating controls. The vulnerable feature is disabled, traffic is filtered upstream, or the affected module is absent from your installation.

Before ranking a scanner result, verify the installed build, the vulnerable feature and its configuration. A KEV entry for a component absent from an asset creates no urgency on that asset. Conversely, exploitation of a critical internal service can demand immediate action without Internet exposure. EPSS thresholds and response times should follow your capacity and obligations, not a sample formula.

For a more formal approach, the SSVC model (Stakeholder-Specific Vulnerability Categorization), designed by CERT/CC and adapted by CISA, replaces the score with a decision tree. Its criteria include exploitation status, whether the attack can be automated, and impact, and its outputs are actions: Track, Track*, Attend, Act.

The blind spot: vulnerabilities without a CVE

EPSS and KEV index CVEs. CVSS can also score a flaw without a CVE if you supply its vector; it will not discover that flaw for you. A misconfiguration in your own deployment, broken access control in custom code or an exposed administration interface may have no CVE. If none was assigned, those weaknesses will not appear in EPSS or KEV; you must find and prioritise them through your own assessment.

For these flaws, only a demonstration in your real context establishes exploitability; a version number is not enough to infer it. A finding that comes with its proof is much easier to prioritise. Research note RZ-2026-8084, Proof before alert describes this approach in detail. Whatever grid you choose, write it down: a documented prioritisation rule can be discussed, audited and corrected, which is impossible with an implicit sort by score.