A 9.8 "critical" score doesn't automatically mean drop everything, and a 5.3 "medium" isn't automatically safe to ignore. The trick is knowing which number answers which question.

Open any vulnerability write-up and you get hit with an alphabet soup: a CVE identifier, a CVSS score in an alarming shade of red, and if you dig a little, an EPSS percentage and a note about whether it's on the KEV list. Most people read the big red number and either panic or shrug. That's the wrong instinct in both directions, because the big red number is the least decision-useful thing on the page.

Each of those four acronyms answers a genuinely different question. Learn which is which and you can triage a scary-looking advisory in about five minutes.

1. CVE — the name, not the verdict

A CVE identifier — CVE-2024-3094, say — is just a unique name for one specific vulnerability. It's issued under a programme run by MITRE and sponsored by the US cybersecurity agency CISA, and the only job it does is disambiguation: so that when you say "the xz backdoor" and someone else says "the liblzma thing," you can both point at the same ID and know you mean the same flaw.

That's it. A CVE ID carries no severity information on its own. It doesn't tell you how bad the bug is, whether it's exploitable, or whether you're affected. People routinely treat "it has a CVE" as "it's serious" — but a CVE is a library catalogue number, not a review. The severity lives in the numbers attached to it, which is where the other three acronyms come in.

2. CVSS — how bad it could be in theory

The Common Vulnerability Scoring System is the 0-to-10 number everyone quotes. It's maintained by FIRST.org and it rates intrinsic technical severity: given the nature of the flaw, how much damage could it do and how hard is it to trigger? The bands are fixed — 0.1–3.9 low, 4.0–6.9 medium, 7.0–8.9 high, 9.0–10.0 critical.

Two things people miss. First, the headline figure is the base score — a worst-case, context-free rating that assumes the vulnerable component is reachable and deployed in the most exposed way possible. It deliberately knows nothing about your environment. A CVSS 9.8 in a library you compile out, or expose only on localhost, is not a 9.8 to you. That's what the Environmental metrics are for, and almost nobody recalculates them.

Second, CVSS measures potential, not likelihood. It answers "how bad if exploited," never "will it be exploited." A beautifully severe bug that requires physical access, a rare configuration and a coin-flip race condition can still score high. Which is exactly why the severity colour alone is a bad patching queue.

"CVSS is not a measure of risk ... it measures the severity of a vulnerability, not the likelihood of it being exploited or the impact of a successful exploit on a particular organization."

FIRST.org, CVSS v3.1 User Guide

3. EPSS — how likely it is to actually be exploited

This is the number that turns severity into a queue. The Exploit Prediction Scoring System, also from FIRST.org, is a data model that outputs a probability — between 0 and 1 — that a given vulnerability will be exploited in the wild within the next 30 days. An EPSS of 0.92 means "very likely to see real attacks soon." An EPSS of 0.001 means "technically nasty, but nobody's biting."

The combination is what matters. High CVSS and high EPSS is your drop-everything pile: severe and being weaponised. High CVSS but low EPSS can usually wait for the normal patch cycle — dangerous in theory, quiet in practice. Low CVSS but climbing EPSS is the sleeper category worth watching. Triaging by CVSS alone means you spend your Friday night patching a scary 9.1 that no one will ever exploit while a boring 6.5 with a public exploit kit quietly gets popped.

4. KEV — the "this is not a drill" list

The Known Exploited Vulnerabilities catalogue is CISA's list of vulnerabilities confirmed to be exploited in the wild right now. Where EPSS is a prediction, KEV is an observation: someone has seen these being used in real attacks. US federal agencies are required to remediate KEV entries by set deadlines, and for everyone else it's the single best free "patch this first" signal available.

If a CVE is on the KEV list, the debate is over — it's being exploited, ship the fix. It's a small list precisely because it's evidence-based, which makes it a far sharper filter than a wall of critical-rated CVEs, most of which will never be touched by an attacker.

5. Where the scores come from — and why they lag

One practical wrinkle: the CVE is often published before anyone has scored it. Enrichment — the CVSS vector, the affected-version ranges — usually lands later, frequently via the US National Vulnerability Database (NVD), run by NIST. So an advisory can legitimately show a CVE ID with "awaiting analysis" and no score for days. Don't read the absence of a number as "not serious." Cross-check the vendor's own advisory, which is usually faster and more specific than the aggregators.

A five-minute triage, in order

None of this needs a paid platform. CVE IDs, CVSS vectors, EPSS scores and the KEV catalogue are all public and free. The skill is reading them together rather than reacting to whichever one is reddest.

A few small tasks come up constantly while working through advisories, and they're the sort of thing you shouldn't paste into a random website. After patching a binary, verify it against the vendor's published checksum with a hash generator so you know you got the real fix. When an advisory's proof-of-concept hinges on a token, a JWT decoder lets you inspect the claims locally without shipping the token anywhere. And when the honest response to a disclosure is "rotate everything," a password generator and a quick base64 encoder for wrangling the encoded blobs advisories love to include will save you a few tabs — all of it running in your own browser, which is exactly where security-sensitive scratch work belongs.

← All articles