All guides
← All guides

CVE, CVSS, and why severity isn't priority

Cross-cuttingDraugr: available today

In plain terms#

Two acronyms show up in almost every security finding:

  • A CVE (Common Vulnerabilities and Exposures) is a unique ID for a specific, publicly disclosed vulnerability, e.g. CVE-2021-44228 (Log4Shell). It's a catalog number, not a judgment.
  • A CVSS (Common Vulnerability Scoring System) score is 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. It's one of three CVSS metric groups: base (intrinsic), temporal (how it evolves as exploits mature), and environmental (how it applies to your system). That last group exists precisely to tailor the score to your environment, but scanners almost always emit the base score alone, and few teams ever compute the environmental adjustment. So in practice you're handed a number that ignores where the vulnerability lives.

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:

  • Exposure. Is the affected component reachable from the internet, or internal-only? (This is the environmental "attack vector" in practical terms.)
  • Criticality. How much would the business feel it if this component were compromised? (The environmental "security requirements": how much confidentiality/integrity/availability this asset needs.)
  • Compensating controls. Is there a WAF, network segmentation, or a non-default configuration that already blocks the path? Real risk can be far lower than the raw score.
  • Exploitability. Is this vulnerability being exploited in the wild? (the temporal dimension. 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.

Popular & reputable references#

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.
How Draugr fits. Draugr takes severity as one input and combines it with each component's exposure and criticality to rank findings into priority bands (P1–P4), turning a flat wall of CVEs into a short, ordered list of what to fix first. See vulnerability prioritization.

Keep learning#