CVSS Score

What is a CVSS score?

CVSS (Common Vulnerability Scoring System) assigns a standardized severity score from 0 to 10 to a security vulnerability, based on its characteristics — how exploitable it is and how much impact exploitation would have. It’s the number that rides alongside a CVE identifier: the CVE names the vulnerability, the CVSS score rates how severe it is, mapped to qualitative bands (0.0 None, 0.1–3.9 Low, 4.0–6.9 Medium, 7.0–8.9 High, 9.0–10.0 Critical). Maintained by FIRST, it gives the whole industry a common language for discussing and comparing vulnerability severity, which is genuinely valuable — you can say “a 9.8” and everyone understands roughly what that means.

How the score is built

A CVSS score is computed from several metric groups. The Base metrics (the score you usually see quoted) capture the intrinsic properties: the attack vector (network / adjacent / local / physical — remotely exploitable is worse), attack complexity, privileges required, user interaction needed, and the impact on confidentiality, integrity, and availability. Two often-ignored optional groups sharpen it: Temporal metrics adjust for real-world state (is exploit code available? is there a patch?), and Environmental metrics let you re-score for your context (how critical is the affected asset to you, and are the impact dimensions that matter present in your deployment?). The current standard, CVSS v4.0, refined the model to address long-standing criticisms of v3. The important thing to grasp is that the headline number is almost always the Base score alone — a context-free, theoretical measure — and the Temporal and especially Environmental adjustments that would make it actually relevant to your situation are the parts most organizations never apply.

Why “score” is not “risk” — the central pitfall

The single most important lesson about CVSS is that a high CVSS score does not automatically mean high risk to you, and treating the two as identical is how vulnerability programs waste enormous effort. Severity is an intrinsic property of the flaw; risk depends on your environment: Is the vulnerable software even present? Is the affected system internet-reachable or buried on an internal segment? Is there a compensating control? Is the vulnerability being actively exploited in the wild? A “critical” 9.8 in a component you don’t expose may be irrelevant, while a “medium” 6.5 on an internet-facing authentication service under active attack may be your most urgent fix. This is why prioritizing purely by CVSS score — “patch all the criticals first” — is a flawed strategy that buries teams in high-scored-but-low-real-risk work while missing genuinely dangerous exposures. The mature approach combines signals: the CVSS score (theoretical severity) plus exploitation intelligence (CISA’s KEV catalog of vulnerabilities known to be actively exploited, and EPSS, which estimates the probability a vulnerability will be exploited) plus your own asset context and exposure. Score tells you how bad it could be; KEV/EPSS and environment tell you how likely and how relevant it is. Using CVSS as one input rather than the sole verdict is the difference between a risk-driven and a checkbox-driven security program.

What people get wrong

• Treating CVSS score as risk — severity is intrinsic; real risk depends on exposure, asset criticality, and active exploitation in your environment.
• Patching strictly by score: “fix all criticals first” drowns teams in theoretical severity while missing lower-scored but actively-exploited, internet-facing flaws.
• Ignoring KEV/EPSS and Environmental metrics — exploitation data and your own context are what turn a generic Base score into an actual prioritization decision.

Primary source: FIRST: CVSS