A CVSS score is a number between 0.0 and 10.0 that the Common Vulnerability Scoring System assigns to a vulnerability to estimate its technical severity. The Forum of Incident Response and Security Teams (FIRST) maintains the standard, and the National Vulnerability Database (NVD) publishes a base score for nearly every CVE within days of disclosure. A score of 9.0 or above is labeled Critical, 7.0-8.9 is High, 4.0-6.9 is Medium, and 0.1-3.9 is Low, with 0.0 meaning None. CVSS v3.1, released in June 2019, is still the version most scanners default to, while CVSS v4.0, published on November 1, 2023, adds metrics for exploitation likelihood and safety impact. The catch: CVSS measures how bad a flaw could be in a vacuum, not whether an attacker can actually reach it in your environment, which is why teams that patch by score alone burn cycles on vulnerabilities that were never exploitable to begin with.
What Do CVSS Score Ranges Actually Mean?
CVSS scores map to four severity bands defined by NVD: Low (0.1-3.9), Medium (4.0-6.9), High (7.0-8.9), and Critical (9.0-10.0). These bands come from a base score built out of eight metrics in CVSS v3.1: Attack Vector, Attack Complexity, Privileges Required, User Interaction, and Scope (which together form the "exploitability" sub-score), plus Confidentiality, Integrity, and Availability impact (the "impact" sub-score). A vulnerability that's remotely exploitable over the network with no privileges and no user interaction, and that fully compromises confidentiality, integrity, and availability, lands at 10.0 — that's exactly the profile of CVE-2021-44228 (Log4Shell), disclosed December 9, 2021, which NVD scored 10.0 under CVSS v3.1. A local privilege escalation bug requiring an authenticated attacker with existing shell access, by contrast, typically scores in the 6.5-7.8 range even if the ultimate impact is full system compromise, because the exploitability metrics pull the score down.
How Is a CVSS Base Score Calculated?
A CVSS base score is calculated by plugging eight metric values into a formula published by FIRST that combines an exploitability sub-score (0-3.9) with an impact sub-score (0-6.0), then applies a scope modifier. Each metric has 2-4 possible values: Attack Vector ranges from Physical (0.2) to Network (0.85), Privileges Required from High (0.27, or 0.5 if Scope is unchanged) to None (0.85), and so on for Attack Complexity, User Interaction, and the three impact metrics rated None, Low, or High. Analysts don't do this math by hand — FIRST publishes an official calculator at first.org, and every major scanner (Snyk, Qualys, Tenable, NVD itself) embeds the same formula. Two people who select identical metric values for the same CVE will always get the same base score, which is the entire point of CVSS as a standard: it replaces ad hoc "critical/high/medium" labels with a reproducible, auditable number. The formula itself changed between CVSS v2 (2007), v3.0 (2015), v3.1 (2019), and v4.0 (2023), which is why the same vulnerability can carry different scores depending on which version scored it.
What Changed Between CVSS v3.1 and CVSS v4.0?
CVSS v4.0, published by FIRST on November 1, 2023, removed the Scope metric and replaced it with separate Vulnerable System and Subsequent System impact metrics, giving a clearer picture of blast radius across system boundaries. It also added a Safety metric for vulnerabilities that can cause physical harm (relevant to industrial and medical device CVEs), and it formally split Temporal metrics into a Threat metric group (Exploit Maturity) and a set of optional Supplemental metrics — Automatable, Recovery, Value Density, Vulnerability Response Effort, and Provider Urgency — that vendors can attach but that don't affect the base score. In practice, adoption has lagged: as of mid-2026, NVD still publishes CVSS v3.1 scores as the primary metric for most CVEs, with v4.0 scores appearing for a growing but still minority subset. If your vulnerability management program only reads "the CVSS score" without checking which version, you can end up comparing a v3.1 8.1 against a v4.0 8.1 as if they were computed the same way, when the underlying metrics and weighting differ.
Why Do Different Scanners Report Different CVSS Scores for the Same CVE?
Different scanners report different scores for the same CVE because they pull from different scoring authorities — NVD, the CVE Numbering Authority (CNA, often the software vendor), and the scanner vendor's own research team can each publish a separate CVSS vector for the same CVE ID. NVD re-scores nearly every CVE it processes, and its score frequently diverges from the CNA's own rating: it's common to see a vendor-assigned base score of 7.5 sit alongside an NVD base score of 9.8 for the same finding, because the two teams selected different values for Attack Complexity or Privileges Required based on differing read of the advisory. Log4Shell is again illustrative — Apache's own advisory and NVD both converged on 10.0, but several downstream repackagers of the Log4j library initially published lower scores in their own advisories before aligning with NVD. When your SCA tool and your cloud vendor's dashboard disagree on a score, check which CVSS vector string each one used (the string starting CVSS:3.1/AV:N/AC:L/...) rather than assuming one tool is simply wrong.
Does a 9.8 CVSS Score Mean You Should Patch It Tonight?
Not necessarily — a high CVSS score tells you how severe a vulnerability could be if exploited, not how likely it is to be exploited in your specific environment. Heartbleed (CVE-2014-0160), disclosed in April 2014 and arguably one of the most damaging bugs in internet history, carried a CVSS v2 base score of just 5.0 (Medium) because the v2 impact metrics only supported coarse "partial" ratings for confidentiality loss — the score badly understated real-world risk. The inverse happens constantly today: a library with a 9.8 base score that's imported but never actually invoked in your running code (a common outcome of dependency bloat) poses zero practical risk, while a 6.1-scored flaw in a function that parses untrusted input on your public API is a live threat. This is why FIRST's own CVSS specification explicitly recommends layering Environmental metrics and organization-specific context on top of the base score before making a remediation decision — the base score alone was never meant to be a prioritization queue.
How Should CVSS Be Combined With EPSS and CISA KEV for Prioritization?
CVSS should be combined with EPSS and CISA KEV by using CVSS for technical severity, EPSS for exploitation probability, and KEV for confirmed real-world attacks, then prioritizing the intersection of all three. EPSS (Exploit Prediction Scoring System), also maintained by FIRST, assigns each CVE a percentage estimating the probability it will be exploited within the next 30 days — Log4Shell's EPSS score has sat above 90% since shortly after disclosure, while the majority of published CVEs sit under 1%. CISA's Known Exploited Vulnerabilities (KEV) catalog, launched under Binding Operational Directive 22-01 in November 2021, lists CVEs with confirmed in-the-wild exploitation and has grown to well over a thousand entries; federal civilian agencies are required to remediate KEV entries within deadlines as short as two weeks. A vulnerability with a CVSS of 9.8, an EPSS above 90%, and a KEV listing is an emergency; a 9.8 with sub-1% EPSS and no KEV listing can often wait for the next patch cycle. Treating all "Critical" CVSS labels as equally urgent is the single most common way teams misallocate patching effort.
How Safeguard Helps
Safeguard turns CVSS scores into an actionable queue instead of a flat severity label. Our reachability analysis traces whether a vulnerable function in a flagged dependency is actually called by your application's code paths, so a 9.8-scored CVE in an unreachable code path gets deprioritized against a 6.5-scored CVE sitting in your request-handling logic. Griffin AI layers in exploit context — EPSS trends, KEV status, and public exploit availability — on top of the raw CVSS vector to produce a single risk ranking per finding, explained in plain language. Safeguard's SBOM generation and ingest capabilities give you a live inventory of every component carrying a CVE, so scoring changes (like a CVE's CVSS being revised after disclosure) automatically re-rank affected assets. When a fix is available, Safeguard opens an auto-fix PR with the minimum version bump needed to resolve the CVE, so the gap between "we know the score" and "we shipped the patch" closes in one review cycle instead of a backlog ticket.