Most vulnerability management programmes have a rule that sounds defensible: patch everything scoring 9.0 or above first, then work down. It is auditable, it is easy to explain, and the number it runs on is published for free by the National Vulnerability Database.
The organisation that publishes CVSS says that number should not be used that way, and says it in those words.
What FIRST actually wrote
The clearest statement is in the FAQ for CVSS version 4.0:
"CVSS-B Base scores are not risk, and should not be used alone for patch prioritization."
The point is older than v4.0. The v3.1 User Guide carries a section headed "CVSS Measures Severity, not Risk", which opens by explaining why the section exists at all:
"Concerns have been raised that the CVSS Base Score is being used in situations where a comprehensive assessment of risk is more appropriate."
⚠️ One correction worth making, because it is easy to overstate this. The word "risk" does not appear anywhere in the v3.1 Specification Document — not once. The severity-not-risk statement lives in the User Guide and, for v4.0, in the FAQ and User Guide. "Its own specification says so" is the wrong citation; "its own publisher says so, repeatedly, in the documents written to explain it" is the right one.
Why the base score cannot be risk
The specification is explicit about what the Base score covers:
"The Base Score reflects the severity of a vulnerability according to its intrinsic characteristics which are constant over time and assumes the reasonable worst case impact across different deployed environments."
Constant over time, and worst case across environments. Both halves are doing work. A score that is constant over time cannot account for whether anyone has written an exploit; a score assuming worst case across environments cannot know that the affected service is not installed on your estate.
CVSS has metric groups for both — Threat and Environmental in v4.0, Temporal and Environmental in v3.1 — and they are optional. Version 4.0 sharpened the wording: "Assessment of the Threat and Environmental metrics is not required, but is highly recommended for more meaningful results," where v3.1 had said only "recommended".
The naming rule that makes the gap visible
Version 4.0 introduced labels for which metric groups went into a score: CVSS-B for base alone, CVSS-BT with threat, CVSS-BE with environmental, CVSS-BTE with both. The specification says this "should be used wherever a numerical CVSS value is displayed or communicated", and then notes who supplies what:
"Assessment providers such as product maintainers and other public/private entities such as the National Vulnerability Database (NVD) typically provide only the Base Scores enumerated as CVSS-B."
So the number a "patch everything above 9.0" rule reads off a feed is a CVSS-B, which is precisely the one FIRST names as unsuitable for prioritising patches on its own. The gap is not subtle once the labels are applied; the labels are what most tooling still omits.
How much of the queue is wasted
FIRST publishes the base rates through its Exploit Prediction Scoring System:
"The CISA KEV catalog lists roughly 0.5% of published CVEs. In any 30-day window, through all of our data partners, EPSS is observed roughly 2.5-3% of published CVEs with exploitation activity."
Against a published population they put at around 350,000 CVEs. Their own description of what that does to prediction is worth sitting with: a rule that simply predicts no exploitation for everything "achieves accuracy around 97-98%".
⚠️ FIRST is notably blunt about how well severity predicts exploitation. Their EPSS documentation states that CVSS and EPSS are "empirically uncorrelated" and that "high severity scores are slightly better than random at predicting exploitation activity". It also warns against the obvious-looking fix: "Multiplying EPSS by a CVSS score does not compute probability × severity and is never a good idea," because one is a calibrated probability and the other an ordinal expert ranking.
⚠️ Do not describe EPSS as "complementary" to CVSS on FIRST's authority. That word appears nowhere in their current EPSS FAQ or usage guidance, and the framing there is closer to a critique than a partnership. The defensible statement is that they measure different things.
What the ranges actually are
The qualitative bands are identical in v3.1 and v4.0: None is 0.0, Low is 0.1 to 3.9, Medium 4.0 to 6.9, High 7.0 to 8.9, and Critical 9.0 to 10.0. The specification adds that using them at all "is optional, and there is no requirement to include them when publishing CVSS scores".
What this does not mean
It does not mean CVSS is broken or should be dropped. It is a severity scale, it is transparent, and severity is a genuine input to risk. FIRST's own FAQ says the technical severity assessments "provide inputs to frameworks… to help guide patch prioritization as part of enterprise risk assessment" — as inputs, within a framework.
Nor does it mean a 9.8 is safe to ignore. A vulnerability with no exploit today can have one tomorrow, and the base score is the part that will not change when it does.
What to do with it
Add the two things the base score structurally cannot contain: whether it is being exploited, and whether you are exposed. CISA's Known Exploited Vulnerabilities catalogue answers the first as a matter of record rather than prediction — CISA describes it as "the authoritative source of vulnerabilities that have been exploited in the wild" and says organisations "should use the KEV catalog as an input to their vulnerability management prioritization framework". The second only your asset inventory can answer.
If the programme is governed by a threshold, FIRST publishes a translation for the one most teams already use. They note that a CVSS Critical filter and the 90th EPSS percentile select populations of about the same size, which makes the change a reprioritisation rather than a request for more capacity.
And when a score is quoted in a ticket, write which metric groups produced it. A number with no label is assumed to be a risk rating by everyone downstream who did not read the specification.
Where this comes from
The quotations are from FIRST's CVSS v4.0 FAQ, the CVSS v4.0 Specification Document published in November 2023, the CVSS v3.1 User Guide section 2.1 and the CVSS v3.1 Specification Document, together with FIRST's EPSS FAQ and usage guidance. The catalogue description is CISA's own. All were read on 16 September 2026, when the KEV catalogue reported 1,710 entries at catalogue version 2026.09.14 — a figure that moves weekly and should be re-checked rather than quoted from here.
⚠️ The absence claim above was measured rather than assumed. "Risk" occurs zero times in the v3.1 Specification Document, against "severity" 17 times, "Temporal" 27 and "Scope" 23 in the same file — the document was searched. This mattered: an automated summary of that same page confidently reported a "risk" occurrence in section 1, with a quotation attached, and it was not there.
View author profile → · Editorial policy
