← All guides

CVE, CVSS, and why severity isn't priority

Cross-cutting
On this page

In plain terms

Two acronyms show up in almost every security finding:

CVE

Common Vulnerabilities and Exposures. A unique ID for a specific, publicly disclosed vulnerability, e.g. CVE-2021-44228 (Log4Shell). It's a catalog number, not a judgment.

CVSS

Common Vulnerability Scoring System. A 0–10 rating of how severe that vulnerability is in the abstract, which maps to Low / Medium / High / Critical.

Together they let the whole industry point at the same problem and agree on roughly how bad it is in principle.

Why it matters

CVEs turn "some library has a bug" into a precise, trackable fact. CVSS gives you a first-pass sense of magnitude. Scanners (SCA, image scanning) report findings by CVE and CVSS, so you'll see these everywhere.

The trap: severity is not priority

The number you usually see is the CVSS base score, the vulnerability's severity in isolation. CVSS has other metric groups too: one for whether the flaw is being attacked in the real world (temporal in CVSS 3.1, renamed threat in CVSS 4.0) and one for how it applies to your system (environmental). Both exist to move the number toward your situation, and scanners almost always emit the base score alone. So in practice you're handed a number that ignores both where the vulnerability lives and whether anybody is attacking it.

And context changes everything: a CVSS 9.8 "critical" in a dependency you only use in a local dev script is far less urgent than a CVSS 6.5 "medium" in your internet-facing authentication service. Yet a raw scanner hands you both as a flat list, often hundreds long, sorted by that context-free number.

Priority depends on the context the base score leaves out:

What the base score leaves outThe question it answers
Exposureis the affected component reachable from the internet, or internal only? The environmental attack vector in practical terms
Criticalityhow much would the business feel it if this component were compromised? The environmental security requirements
Compensating controlsis there a WAF, network segmentation, or a non-default configuration already blocking the path? Real risk can be far below the raw score
Exploitabilityis this being exploited in the wild? The threat dimension, and the one the score leaves blank. See EPSS & KEV

Severity is an input. Priority is the decision. Conflating them is why security backlogs balloon into thousands of "criticals" nobody acts on.

Exploit Maturity

CVSS has a metric for whether a vulnerability is actually being attacked. It is called Exploit Maturity, its values run from Unreported through Proof-of-Concept to Attacked, and it is optional. The specification assigns the job of filling it in to whoever consumes a score rather than to whoever publishes one, and the databases scanners read publish base scores.

Two vulnerabilities the score cannot tell apart Two entries with the same base metrics. Working attack code is circulating for the first and nobody has established how to trigger the second. The Exploit Maturity metric, which exists to record exactly that difference, is unset on both, because the specification gives the job of filling it in to whoever consumes a score and the databases scanners read publish base scores. An omitted value is calculated as equivalent to Attacked, so the two come out with the same number and the same band. SAME BASE METRICS, OPPOSITE SITUATIONS Working attack code is circulating for this one. Exploit Maturity: not set 9.8 CRITICAL Nobody has worked out how to trigger this one. Exploit Maturity: not set 9.8 CRITICAL AN OMITTED EXPLOIT MATURITY IS COMPUTED AS ATTACKED Both were scored as though somebody were already exploiting them, because the field that would have said otherwise was left for somebody else to fill in.
No amount of careful sorting separates these two, because the information that distinguishes them was never in the number being sorted.

So the field arrives blank almost every time, and what the specification does with a blank field is the part worth knowing. An omitted Exploit Maturity is calculated as equivalent to Attacked.

Every score you are handed was computed as though somebody were already exploiting the vulnerability, because the field that would have said otherwise was never filled in. A flaw with working attack code in circulation and a flaw nobody has worked out how to trigger come out identical, given the same base metrics.

Filling the field in can only ever lower a score, never raise one: Attacked matches the default and every other value reduces the number. Sorting by severity therefore cannot separate what is being attacked from what is not, however carefully you sort. The information was never in the number.

This is why EPSS & KEV exist as separate feeds. They supply from outside what the score left empty.

SourceWhat it is
CVE ProgramThe authoritative CVE catalog
NVDNIST's database, CVEs enriched with CVSS scores
FIRST CVSSThe CVSS specification
CISA KEVVulnerabilities known to be exploited

Common pitfalls

  • Treating the CVSS number as a work order. It's a starting point, not a ranking.
  • Ignoring "medium" findings on exposed, critical systems while chasing "criticals" on things nobody can reach.
  • No decay for the unreachable. Context should pull unreachable criticals down the list.
  • Reading a blank Exploit Maturity as "not being attacked." A blank field scores as Attacked, so the absence of the metric tells you nothing about the vulnerability and everything about who filled the form in.
How Draugr fits. Draugr fills in what the base score leaves out. KEV and EPSS supply the exploitation the score never carried, and each component's declared exposure and criticality supply the context no scanner can read, so severity becomes one input among several and findings rank into priority bands (P1–P4). The two matrices that produce a band, and what each input does to it, are in how Draugr ranks findings. A flat wall of CVEs becomes a short, ordered list of what to fix first. See vulnerability prioritization.

Keep learning