CVSS, or the Common Vulnerability Scoring System, is an open industry standard for rating how severe a software vulnerability is, expressed as a single number from 0.0 to 10.0. It's maintained by FIRST (Forum of Incident Response and Security Teams) and used in nearly every vulnerability feed you touch: the National Vulnerability Database (NVD), GitHub Security Advisories, Red Hat's CVE database, and the scanners built into tools like Snyk, Wiz, and Safeguard all publish a CVSS score alongside each CVE. A score of 10.0 — the maximum — was assigned to Log4Shell (CVE-2021-44228) in December 2021 and to the 2014 "Heartbleed" bug's more severe cousins. But the number alone tells you less than most security teams assume, and misreading it is one of the most common reasons vulnerability backlogs never shrink. Here's what the score actually measures, how it's built, and where it falls short.
What is a CVSS score?
A CVSS score is a number between 0.0 and 10.0 that represents the technical severity of a vulnerability, derived from a standardized formula rather than assigned by opinion. It's published by FIRST, a nonprofit that also coordinates incident response standards across vendors, and the current versions in active use are CVSS v3.1 (released June 2019) and CVSS v4.0 (released November 1, 2023). Every score is really a composite of several sub-scores: a mandatory Base score (intrinsic severity, set once and rarely changed), an optional Temporal score (how the vulnerability's real-world exploitability changes over time), and an optional Environmental score (how it applies to your specific deployment). When people say "the CVSS score for CVE-2021-44228 is 10.0," they almost always mean the Base score — which is also the number that gets stamped into the NVD feed and inherited by every scanner that ingests it, unmodified, regardless of whether that CVE affects your environment at all.
How is a CVSS score calculated?
A CVSS Base score is calculated by scoring eight metrics on a fixed scale and running them through a published formula, not by human judgment call. In CVSS v3.1, four Exploitability metrics describe how easy the flaw is to trigger — Attack Vector (Network, Adjacent, Local, or Physical), Attack Complexity (Low/High), Privileges Required (None/Low/High), and User Interaction (None/Required) — and three Impact metrics describe what happens if it's triggered: loss of Confidentiality, Integrity, and Availability, each rated None/Low/High. An eighth metric, Scope, captures whether the vulnerability lets an attacker affect components beyond its own security authority. Log4Shell scored 10.0 because it hit the worst case on nearly every axis: Network vector, Low complexity, no privileges or user interaction required, and High impact on all three of confidentiality, integrity, and availability, with a changed Scope. By contrast, a stored XSS bug that requires an authenticated admin to click a crafted link might score in the 5.0–6.0 range because Privileges Required and User Interaction pull it down even though the Impact metrics are high.
What do CVSS score ranges mean?
CVSS scores map to five qualitative severity bands defined in the spec itself: None (0.0), Low (0.1–3.9), Medium (4.0–6.9), High (7.0–8.9), and Critical (9.0–10.0). These bands are why a scan report that says "14 Critical, 62 High, 340 Medium" is legible at a glance, but they compress a lot of nuance into four labels. A 7.1 and an 8.9 are both "High," yet the vulnerabilities behind them can be wildly different in practice — CVE-2017-5638 (the Apache Struts flaw behind the 2017 Equifax breach) scored 10.0 and was remotely exploitable with zero authentication, while plenty of "High" 7.5 scores describe denial-of-service bugs that only matter if the affected service is internet-facing and unauthenticated by design. Treating every Critical the same, or triaging strictly by band, is how teams end up patching a 9.8 in an unused test library before a 7.2 in an internet-facing payment API.
What's the difference between CVSS v3.1 and CVSS v4.0?
CVSS v4.0, ratified in November 2023, replaces the single Scope metric with more granular Vulnerable System and Subsequent System impact metrics, and adds a new Attack Requirements (AT) metric to separate "needs specific preconditions" from Attack Complexity. It also formalizes Threat metrics — most importantly Exploit Maturity, which downgrades or confirms a score based on whether exploitation is unreported, proof-of-concept, or active — and adds a Supplemental metric group covering Automatable and Safety impact, useful for OT and ICS contexts. NVD and most public feeds were still primarily publishing v3.1 scores through mid-2026, three years after v4.0's release, because re-scoring the entire historical CVE backlog under a new rubric is a massive undertaking; FIRST's own numbers show v3.1 metrics still attached to well over 90% of entries in the NVD. In practice, this means most scanners today report v3.1 by default and only surface v4.0 scores for CVEs published after late 2023, so teams comparing scores across a mixed vulnerability set need to check which version each number came from before drawing conclusions.
Why isn't a high CVSS score enough to prioritize a vulnerability?
A high CVSS score isn't enough because the Base score deliberately ignores whether the vulnerable code is reachable, exposed, or even loaded in your specific application. CVSS Base scoring assumes a generic "worst-case" deployment of the affected component — it can't know that the vulnerable function in a library you imported is never called, that the service is only reachable from an internal VPN, or that a WAF rule already blocks the exploit pattern. This is precisely the gap that produced the well-documented finding that only a small fraction of Critical and High CVEs in a typical dependency tree are actually exploitable in the application that ships them — studies from multiple vendors, including Google's own OSS-Fuzz-adjacent research, have put reachable/exploitable Critical vulnerabilities at roughly 5–15% of what static CVSS-based scanning flags. That's why the industry has layered on EPSS (Exploit Prediction Scoring System, also from FIRST) to estimate real-world exploitation likelihood, and why reachability analysis — actually tracing whether your code path calls the vulnerable function — has become table stakes for any tool claiming to help with prioritization rather than just enumeration.
How Safeguard Helps
Safeguard treats CVSS as a starting point, not a verdict. Once a CVE is flagged in your SBOM, our reachability analysis traces the actual call path in your codebase to determine whether the vulnerable function is invoked at all — collapsing the CVSS-plus-EPSS noise into a shortlist of findings that are both severe and reachable. Griffin AI, Safeguard's reasoning engine, layers in exploit context and your deployment specifics to explain why a given 9.8 matters (or doesn't) in your environment, in plain language an engineer can act on without reading the CVSS vector string. Safeguard generates and ingests SBOMs automatically across your build pipeline, so every new dependency is scored and reachability-checked the moment it lands, not weeks later during an audit. And when a fix exists, Safeguard opens an auto-fix pull request with the minimal version bump or patch needed — turning a CVSS number on a dashboard into a merged remediation instead of another line in a backlog.