CVSS, and what a score does not tell you

Why this matters

CVSS is the most examinable single topic in Domain 2. You should be able to read a vector string, explain what each metric means, and — more importantly — say why two vulnerabilities with the same score can deserve completely different urgency.

That last point is the one that separates an analyst from a report generator. CVSS measures technical severity in the abstract. Prioritisation requires exploitability and business context, which the base score deliberately excludes. Treating the base score as a priority is the most common mistake in the whole discipline.

The lesson

Base, temporal and environmental metrics

CVSS has three metric groups, and almost everyone uses only the first.

Base metrics describe intrinsic characteristics that do not change over time or between environments. Split into exploitability and impact:

Exploitability

• Attack Vector — Network, Adjacent, Local, Physical. Network is worst.
• Attack Complexity — Low or High. Whether special conditions are needed.
• Privileges Required — None, Low, High.
• User Interaction — None or Required. Whether a victim must do something.
• Scope — Unchanged or Changed. Whether the flaw lets the attacker affect resources beyond the vulnerable component. Scope Changed raises the score sharply and is the metric people most often misread; a container escape or a hypervisor breakout is the classic example.

Impact — Confidentiality, Integrity and Availability, each None, Low or High.

Temporal metrics adjust for the current state of the world: whether exploit code exists, whether a fix is available, how confident the report is. These move over time and are the metrics that most change urgency in practice.

Environmental metrics adjust for your deployment: how much you care about each impact type for this asset, and whether any base metric differs in your configuration — a "network" vulnerability on a host with no network route is genuinely less severe for you.

CVSS v4.0 restructures this — adding threat metrics, supplemental metrics, and finer-grained exploitability — but the conceptual split survives: intrinsic, current-world, and your-environment.

The examinable point: vendors publish base scores. Base scores are deliberately context-free. The temporal and environmental groups exist precisely to add the context, and almost nobody applies them, which is why raw CVSS prioritisation performs so poorly.

Reading a vector string by hand

You should be able to decode one without a calculator.

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

Read it left to right:

• AV:N — Attack Vector: Network. Exploitable remotely.
• AC:L — Attack Complexity: Low. No special conditions.
• PR:N — Privileges Required: None. No account needed.
• UI:N — User Interaction: None. No victim action needed.
• S:U — Scope: Unchanged. Contained to the vulnerable component.
• C:H/I:H/A:H — total loss of confidentiality, integrity and availability.

That combination is the worst realistic case: remote, easy, unauthenticated, no user interaction, total impact. It scores 9.8 and is the profile of a vulnerability that gets exploited at scale within days.

Compare:

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

Local access, high complexity, high privileges already required, and the victim must act — with confidentiality impact only. Same class of impact on one axis, a completely different real-world risk. It scores around 4.2.

The habit worth building: read AV, PR and UI first. Those three answer "how hard is this to actually use?", which drives urgency far more than the impact metrics do.

Why two 9.8s are not equally urgent

The central argument of this lesson.

Two findings, both AV:N/AC:L/PR:N/UI:N with total impact, both 9.8:

• Finding A is in an internet-facing VPN appliance, has public exploit code, and is being actively used by ransomware operators this week.
• Finding B is in a management service on an internal host, reachable only from one administrative subnet, has no public exploit, and requires a configuration your build does not use.

The base scores are identical. The urgency differs by weeks.

What CVSS base does not know:

• Whether an exploit exists, or is being used right now.
• Whether the asset is exposed to the network the attacker is on.
• Whether the vulnerable feature is enabled in your configuration.
• What the asset is worth — a test box and the payroll database score the same.
• What compensating controls sit in front of it.
• How many instances you have.

So the base score answers "how bad would this be if exploited?" and the analyst must answer "how likely is that, here, this week?" Both are needed, and prioritising on the first alone produces a queue sorted by the wrong key — which is the risk-based argument developed in the next lesson.

EPSS and exploit-likelihood scoring

EPSS — the Exploit Prediction Scoring System — addresses exactly this gap. It estimates the probability that a vulnerability will be exploited in the wild in the next 30 days, expressed from 0 to 1, updated daily from observed activity and vulnerability characteristics.

It is a different question from CVSS, and the two are complementary:

• CVSS: if this is exploited, how bad is it?
• EPSS: how likely is it to be exploited at all?

The practical value is in the asymmetry of the distribution. Only a small minority of published vulnerabilities are ever exploited in the wild. A backlog sorted by CVSS treats thousands of 9.8s as equally urgent; adding EPSS identifies the small subset with meaningful exploitation probability, and that subset is where the limited remediation capacity should go first.

The combination used in practice:

• High CVSS and high EPSS — fix immediately.
• High CVSS and low EPSS — schedule normally; revisit if EPSS rises.
• Low CVSS and high EPSS — worth attention, particularly if chainable. People miss these because the severity label looks unalarming.
• Low both — routine patching.

The caveats belong in your reasoning too: EPSS is a prediction, it reflects mass exploitation rather than targeted attacks, and it says nothing about your exposure. A low-EPSS vulnerability in your internet-facing crown jewel is still your problem.

Known-exploited catalogues as a prioritiser

The strongest signal available, because it is not a prediction at all.

Several authorities publish catalogues of vulnerabilities known to have been exploited in the wild — the best known being the US CISA Known Exploited Vulnerabilities catalogue, which carries remediation deadlines that are binding on US federal agencies and widely adopted voluntarily elsewhere.

Why it beats both CVSS and EPSS as a first filter:

• It is observed, not modelled. Someone has used this against real targets.
• It is small — thousands of entries against hundreds of thousands of CVEs — so it is an achievable work list rather than a backlog.
• It carries deadlines, which gives a vulnerability programme something rare and useful: an externally defensible due date.

A defensible prioritisation order, and a good answer to an exam question about where to start:

1. Known exploited, and exposed in your environment. Today.
2. Known exploited, present but not exposed. This week.
3. High EPSS with high CVSS on exposed assets.
4. Everything else, by risk-based prioritisation.

Two cautions to state plainly. Absence from a catalogue is not evidence a vulnerability is safe — it is evidence nobody has reported exploitation yet, and targeted attacks rarely appear in these lists. And a catalogue is a floor, not a ceiling: meeting its deadlines is the minimum, not a complete programme.

Which sets up the next lesson: scores and catalogues narrow the field, and the remaining decision — what to do first, given your assets and your capacity — is a business-context judgement rather than an arithmetic one.

Topics this lesson owns

• [x] Base, temporal and environmental metrics
• [x] Reading a vector string by hand
• [x] Why two 9.8s are not equally urgent
• [x] EPSS and exploit-likelihood scoring
• [x] Known-exploited catalogues as a prioritiser