What a CVSS score does and does not tell you about your risk

The CVSS base score describes intrinsic technical characteristics of a vulnerability: how it is accessed, how complex exploitation is, what privileges and user interaction it requires, and its impact on confidentiality, integrity and availability. Scores run 0.0 to 10.0 and band into none, low at 0.1 to 3.9, medium at 4.0 to 6.9, high at 7.0 to 8.9 and critical at 9.0 to 10.0.

It is deliberately context-free. That is not a limitation someone forgot to fix — it is the entire point. A context-free score is comparable between two testers, two reports and two years, which is what lets you say a finding is worse than another finding at all.

The current version is CVSS v4.0, published by FIRST in 2023, which organises metrics into Base, Threat, Environmental and Supplemental groups — the Threat group replacing what v3.1 called Temporal. In practice a great deal of tooling and many reports still use v3.1, so a sensible habit is to check which version a score came from before comparing two of them.

Because the score you are sorting by has explicitly excluded the two things that determine whether you should care: whether the affected thing matters to you, and whether anyone is actually attacking it.

A critical-rated flaw requiring an unusual configuration, local access and a specific version may never be exploited anywhere, and may not even be reachable in your deployment. A medium-rated flaw enabling remote code execution with no prerequisites is the kind that gets weaponised within days and turns up in commodity attack tooling. Sorted by base score, you fix the first one first.

The visible symptom of this is a remediation backlog that never shrinks, because the queue is ordered by a number nobody believes. Engineers work the top of the list, notice the top of the list is not the scary stuff, and quietly start working from their own judgement instead — at which point the process has stopped being a process.

EPSS, the Exploit Prediction Scoring System, is also maintained by FIRST and answers a different question: the probability, from 0 to 1, that a vulnerability will be exploited in the wild within the next 30 days. It is a forecast rather than a severity judgement, and it moves as the world changes.

CISA’s Known Exploited Vulnerabilities catalogue is the confirmed version of the same question — a binary list of vulnerabilities observed being actively exploited. It is authoritative about what is on it and says nothing about what is not, so it is a floor rather than a filter.

Used together the division of labour is clean. CVSS tells you how bad it would be. EPSS and KEV tell you how urgent it is. Neither tells you whether the affected system holds anything you care about, which is the part only you can supply — and which CVSS has an answer for in its environmental metrics that almost nobody fills in.

A report that simply prints CVSS base scores and sorts descending has handed you an input and called it an output. What a useful report does is rank findings for your estate: this system is internet-facing, this one holds customer data, this one is reachable only from a management network nobody can get to.

That is also a reasonable thing to ask for before you buy. Does the report rank findings by risk to us, or by score? Does it say why? Does it note where a low-severity finding chains into something worse — the information disclosure that yields a credential that reaches the database? Chaining is exactly what base scores cannot represent, because each link scores low on its own.

And when you are the one triaging, write your reasoning down. A finding deprioritised with a recorded rationale is a decision your auditor and your successor can both follow. A finding deprioritised silently is indistinguishable from one that was missed.

Most organisations set remediation timeframes by severity band — criticals in so many days, highs in so many more. That is reasonable, auditable and much better than nothing, and it has one predictable failure mode.

Anchoring SLAs purely to base score means a medium that is being actively exploited against systems like yours gets a medium’s timeline. Adding a simple override — anything in KEV, or above an EPSS threshold, escalates regardless of base score — costs very little to define and closes the gap that actually gets organisations breached.

Whatever you choose, be able to show it running. From an audit perspective the policy matters less than evidence that findings were triaged against it consistently and closed within the windows you set yourself.