The Common Vulnerability Scoring System (CVSS) is an open standard that expresses the severity of a security vulnerability as a number from 0.0 to 10.0, along with a matching label from None to Critical. When you read that a flaw is "CVSS 9.8 Critical," you are seeing the output of a defined formula that scores the vulnerability's technical characteristics — how it is exploited and what damage it can do. CVSS gives the whole industry a common language for "how bad is this?" But the number is frequently misread, so understanding what it does and does not measure is essential to using it well.
Why It Matters
Organizations face far more vulnerabilities than they can fix at once. Tens of thousands of CVEs are published each year, and any real system inherits hundreds through its dependencies. CVSS provides a first, standardized cut at triage: it lets teams sort findings by severity instead of treating every alert as equally urgent. Compliance frameworks and internal policies lean on it heavily, often setting rules like "remediate all Critical findings within seven days."
That reliance is also the danger. CVSS measures the intrinsic severity of a vulnerability in the abstract, not the risk it poses to your specific environment. A 9.8 in a component you do not actually use may matter less than a 6.5 sitting on your internet-facing login path. Reading the score as a complete risk verdict — rather than one input among several — is the most common and costly mistake teams make with it.
The Core Concepts
A CVSS score is built from a vector string, a compact encoding of the metrics that produced it. The most important group is the Base metrics, which describe the fixed, environment-independent traits of the flaw:
- Attack Vector — can it be exploited over the network, or does it need local access?
- Attack Complexity — how much has to line up for exploitation to succeed?
- Privileges Required — does the attacker need an account, and how privileged?
- User Interaction — must a victim click or act for the attack to work?
- Impact on Confidentiality, Integrity, and Availability — what is damaged if it succeeds?
Two optional metric groups refine the picture. Temporal (or Threat, in the newer version) metrics reflect whether exploit code exists and how mature it is. Environmental metrics let you re-weight the score for your own deployment. In practice, most published scores are Base-only, which the standard itself warns is the least complete form.
How It Works: From Metrics to Number
The base metrics feed a scoring formula that produces the 0 to 10 value and its severity band.
| Score range | Severity label |
|---|---|
| 0.0 | None |
| 0.1 to 3.9 | Low |
| 4.0 to 6.9 | Medium |
| 7.0 to 8.9 | High |
| 9.0 to 10.0 | Critical |
A worked example makes the vector readable. Consider a flaw exploitable remotely, with no special conditions, requiring no privileges or user interaction, that fully compromises data and the system:
CVSS 3.1: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H -> 9.8 Critical
Every letter maps to one metric choice. Change one input — say the attacker now needs local access (AV:L) — and the number drops sharply, because a flaw that cannot be reached over the network is far less dangerous in most contexts.
As of 2026 the ecosystem straddles two versions. CVSS 3.1 remains the most widely published. CVSS 4.0, released in late 2023, sharpens several metrics — it replaces the Scope metric with separate impact triads for the vulnerable and any subsequent system, and adds an Attack Requirements metric — but adoption is still partial, so you will routinely see both. When comparing findings, note which version produced each score, because the two do not map one to one.
Best Practices
- Never patch by CVSS alone. Combine it with EPSS (the probability a flaw will be exploited) and with reachability — whether the vulnerable code runs in your app at all.
- Use environmental metrics. Re-score findings for your context; an availability impact matters more for a payment system than for an internal report tool.
- Track the vector, not just the number. The vector tells you why something scored high, which is what actually informs the fix.
- Note the CVSS version. Do not compare a 3.1 score against a 4.0 score as if they are interchangeable.
- Set SLAs on effective risk. Drive remediation deadlines from a blended risk view, not the raw base score in isolation.
How Safeguard Helps
Safeguard treats CVSS as one signal among several rather than the final word. Software Composition Analysis attaches the full CVSS vector — 3.1 and 4.0 where both exist — to every finding, then layers on EPSS and reachability so you see not just how severe a flaw is in theory but how exposed you are in practice. A theoretical 9.8 in an unreachable code path is de-emphasized; a 7.0 on a live, exploitable path rises to the top.
Because that blended prioritization would be tedious to compute by hand across hundreds of findings, Griffin AI does it continuously and explains its reasoning. To understand the neighboring terms — CVE, EPSS, reachability — the concepts library lays them out, and step-by-step lessons on triage live in Safeguard Academy. To see prioritized scores on your own dependencies, create a free account.
Frequently Asked Questions
Does a higher CVSS score always mean I should patch it first?
Not necessarily. CVSS measures a vulnerability's intrinsic severity, not the risk to your particular system. A Critical-rated flaw in a component your application never actually invokes can be lower priority than a Medium-rated one on an internet-facing path that runs constantly. Sound prioritization blends the CVSS score with exploit likelihood and reachability rather than sorting on the number alone.
What is the difference between CVSS and EPSS?
CVSS scores how damaging a vulnerability would be if exploited. EPSS, the Exploit Prediction Scoring System, estimates the probability that it will actually be exploited in the near term. They answer different questions — severity versus likelihood — and are strongest together. A flaw that is both high-severity and high-probability is the clearest candidate for urgent action.
Why do different sources sometimes show different CVSS scores for the same CVE?
Because scoring involves analyst judgment, and different bodies may assess the same metrics differently, or use different CVSS versions. A vendor might score a flaw in the context of their product while a national database scores it more generically. When scores disagree, read the vector strings to see which metric choices differ, rather than assuming one number is simply wrong.
Should I switch entirely to CVSS 4.0?
Adopt it as an additional data point rather than a wholesale replacement in 2026. Coverage is still incomplete, so you will keep encountering 3.1-only findings for the foreseeable future. Store both vectors where available, prefer the more complete one for prioritization, and avoid comparing a 3.1 and a 4.0 score directly, since the versions changed how several metrics are calculated.