Prioritising by real exploitability: CVSS, EPSS and business context

Any organisation with a scanner running accumulates more findings than it can fix. The usual answer — “we fix the criticals first” — sounds reasonable and produces two perverse effects: effort goes into vulnerabilities nobody will ever exploit, while medium-severity ones being exploited this week stay open.

The problem is not a shortage of data. It is that a single metric is being used to answer a question with three distinct dimensions.

What CVSS measures, and what it does not

CVSS describes the intrinsic characteristics of a vulnerability: how reachable the vector is, what privileges it requires, whether user interaction is needed, and what impact it has on confidentiality, integrity and availability. It is a structured, comparable description, and as such it is useful.

What almost nobody uses is the rest of the standard. The base score — the one that ships with the CVE and appears in 95% of reports — is designed to be modulated by the environmental and threat metric groups. In CVSS v4.0, published by FIRST in November 2023, those are the names; in v3.1 they were temporal and environmental. Those groups exist precisely to capture whether exploit code is available and what the affected asset is worth in your estate.

When an organisation says “we prioritise by CVSS”, it almost always means “we prioritise by somebody else’s base score”. That is, by a deliberately decontextualised metric.

What EPSS adds

EPSS, also maintained by FIRST, answers a different question: the probability that a specific vulnerability will be exploited in the wild over the next 30 days. It is a statistical model trained on observed signals — reported exploitation activity, CVE characteristics, presence of public exploits — and it is recomputed daily.

It returns two numbers worth not confusing. The probability is a value between 0 and 1: 0.08 means the model estimates an 8% chance of observed exploitation over the period. The percentile says how many vulnerabilities score lower than this one. A percentile of 0.95 does not mean 95% probability: it means the vulnerability sits in the top 5% of the catalogue, which can still be a modest absolute probability.

The practical value of EPSS is that it inverts the bias. The great majority of published CVEs are never observably exploited, and EPSS is quite good at separating that noise. As a discard criterion it is more efficient than CVSS; as an urgency criterion it only works in combination.

The two together: four quadrants, not a formula

The temptation is to build a formula multiplying CVSS by EPSS and sort by the result. Don’t: you lose the information about which dimension drove the priority, and you can no longer explain the decision.

It is more useful to think in four quadrants:

High severity, high probability. Short tail, immediate action. This is where your emergency process should live.
High severity, low probability. The case that generates the most argument. It belongs in the normal patch cycle, not the emergency one, unless the asset is critical and exposed.
Low severity, high probability. The quadrant CVSS-based prioritisation systematically ignores, and the entry point for a fair number of real incidents. It deserves active watching even when the base score is 5.3.
Low severity, low probability. Long tail. Resolved by scheduled maintenance, not by individual tickets.

And there is one list that beats both metrics: CISA’s Known Exploited Vulnerabilities catalogue. If a CVE is in there, exploitation has been observed. At that point you do not need to estimate probability: it already happened.

The third dimension, which neither metric includes

CVSS and EPSS describe the vulnerability. Neither knows anything about your system. And the question that matters is not “how bad is this CVE” but “what happens if somebody exploits it here”.

Four context factors change priority more than any metric adjustment:

Exposure. Is the asset published on the internet or does it live in an internal segment with restricted access? The difference between the two is usually worth more than two points of CVSS.
Real compensating controls. Is there a WAF with a specific rule deployed, segmentation that prevents reaching the port, mandatory prior authentication? A verified compensating control lowers urgency; an assumed one does not.
Value of the data or the function. A memory corruption bug on a lab box and the same bug on the system supporting a declared critical function under DORA are not the same finding.
Cost and risk of the fix. A patch requiring a downtime window on a real-time system competes with other priorities. That does not lower the risk, but it does determine which route you take.

A scheme that works without becoming bureaucracy

A simple procedure, defensible in front of an auditor, that does not require building your own model:

Discard with EPSS. Anything below a low probability threshold and not in the KEV catalogue moves to the maintenance cycle.
Escalate by exposure. Of what remains, separate what is internet-facing from what is not.
Rank by business impact. Use the asset criticality you have already declared — if you have done ENS categorisation or the DORA function inventory, it exists; do not invent it a second time.
Set deadlines per quadrant, not per finding. “Critical and exposed: 7 days. Critical and internal: 30. Everything else: monthly cycle.” A deadline per quadrant can be measured; a deadline negotiated finding by finding cannot.
Record the decision, especially when you downgrade. The exception is the auditable part of the process: which finding, which compensating control was invoked, who accepted it, until when.

What an auditor usually checks

They rarely argue with your formula. They check three things: that the criterion is written down and predates the decisions, that the declared deadlines are met in practice — by taking a sample — and that exceptions carry a name, a date and an expiry.

A programme that fixes 70% of its criticals on time and documents why the remaining 30% are still open will survive a review. One that claims 100% and cannot show the trail will not.

The real cost of all this is not making the decision, it is keeping the decision attached to the finding when the scanner rediscovers it three weeks later under a different identifier. Solving that continuity — so the exception, the compensating control and the deadline travel with the finding across campaigns — is the work we automate in Violet Security, because by hand it is always lost.