What Is CVSS? The Vulnerability Scoring System

A CVE lands in your scanner with a 9.8. The ticket says critical, the dashboard turns red, and someone wants it patched by Friday. Then you check the host: it is an internal jump box with no inbound path from the internet, the vulnerable service is disabled, and there is no public exploit. The 9.8 is real. The urgency is not. That gap, between a number that says "severe" and a decision about what to fix first, is where most teams misuse the Common Vulnerability Scoring System.

CVSS is an open framework, maintained by FIRST, for scoring the severity of software vulnerabilities on a 0.0 to 10.0 scale. It is the number behind almost every CVE you triage. This guide covers what the score actually measures, the metric groups that produce it, the Base metrics that do most of the work, the severity bands the number maps to, what changed between the widely deployed v3.1 and the current v4.0, and the one distinction that separates teams who use CVSS well from teams who let it drive the wrong work: severity is not risk. It is written for the people who have to defend a patch order: SOC analysts, vulnerability managers, and DFIR responders who get asked why a 9.8 is still open.

What is CVSS?

The Common Vulnerability Scoring System (CVSS) is an open, vendor-neutral framework for rating the severity of a security vulnerability with a single number from 0.0 to 10.0. It is owned and published by FIRST, the Forum of Incident Response and Security Teams, which runs the special interest group that maintains the specification. The standard is free to use, and anyone can score a vulnerability with the published metrics and produce the same result, which is the entire point: a common, repeatable measure so a vulnerability scored by a vendor, a researcher, and your own team lands on the same number.

That number is what flows into the CVE ecosystem. When the National Vulnerability Database (NVD) attaches a score to a CVE, it is a CVSS score. When a vendor advisory says "critical," it is a CVSS band. When your scanner sorts findings by severity, it is sorting by CVSS. The framework has become the lingua franca of vulnerability severity, which is its strength and the source of its most common abuse.

The score is not a single opaque measurement. It is computed from a defined set of metrics describing how a vulnerability is exploited and what happens when it is. Those metrics are grouped, and understanding the groups is what lets you read a score correctly instead of treating 9.8 as a command.

The CVSS metric groups

CVSS v4.0 is composed of four metric groups: Base, Threat, Environmental, and Supplemental. Each answers a different question, and only one of them is mandatory.

Base captures the intrinsic qualities of a vulnerability that are constant over time and across every environment. How is it reached, how hard is it to exploit, what does exploiting it require, and what is the impact. The Base group is the only one most consumers ever see, because it is the one a vendor or the NVD can compute without knowing anything about your network. When someone says "the CVSS score," they almost always mean the Base score.

Threat reflects the characteristics of a vulnerability that change over time, primarily whether a working exploit exists and how mature it is. In CVSS v4.0 this group was renamed from Temporal, its name in v3.1, because what it really tracks is threat intelligence: a vulnerability with a weaponized, in-the-wild exploit is more dangerous today than the same vulnerability with only a theoretical proof of concept, even though the Base metrics are identical.

Environmental represents the characteristics unique to your environment. It lets you re-weight a score for your own deployment: raise the score for a system holding regulated data, lower it for an asset with compensating controls or no exposure. This is the group that would have fixed the 9.8 jump box in the opening, and it is the group almost nobody fills in.

Supplemental is new in v4.0. It is an optional group that describes additional attributes of a vulnerability, such as Safety, Automatable, Provider Urgency, Recovery, Value Density, and Vulnerability Response Effort. FIRST is explicit that no Supplemental metric changes the calculated score. It carries context for the consumer to act on, not weight for the math.

The practical takeaway is that a bare CVSS score is the Base score and nothing else. FIRST denotes the variants by the metrics used: a Base-only score is CVSS-B, Base plus Threat plus Environmental is CVSS-BTE, and only the full combination, the guide says, gets "much closer to 'Risk.'"

The Base metrics

The Base group is where the score comes from, so it is worth knowing what it actually measures. It splits into exploitability metrics, which describe how the vulnerability is reached and triggered, and impact metrics, which describe the damage.

The exploitability metrics in v4.0 are:

• Attack Vector (AV) describes the context in which exploitation is possible, ranging from Network (reachable across the internet) down through Adjacent, Local, and Physical. A network-reachable flaw scores higher than one needing physical access, because the attack vector determines how many attackers can even attempt it.
• Attack Complexity (AC) measures conditions outside the attacker's control that must hold for exploitation to succeed.
• Attack Requirements (AT) is new in v4.0. It separates out the deployment or execution conditions a target must be in, a concept v3.1 folded loosely into Attack Complexity. Splitting them lets AC describe attacker effort and AT describe target state.
• Privileges Required (PR) captures the level of access an attacker needs before exploiting: none, low, or high. A flaw exploitable by an unauthenticated user scores higher than one needing admin already.
• User Interaction (UI) captures whether a human, such as a victim clicking a link, must participate.

The impact metrics ask what exploitation costs across the classic triad: Confidentiality, Integrity, and Availability. In v4.0 each is measured twice, once for the Vulnerable System (VC, VI, VA) and once for the Subsequent System (SC, SI, SA), which is how v4.0 expresses what v3.1 called Scope.

Severity ratings: from a number to a band

A raw 0.0 to 10.0 figure is precise but not actionable on its own, so CVSS maps the score to a qualitative severity rating. The bands are fixed and identical across v3.1 and v4.0:

These bands are what your scanner, your SLA policy, and your reporting almost certainly key off. A "patch criticals in 7 days" rule is a rule about the 9.0 to 10.0 band. That is fine as a default, but read the band for what it is: a statement about the worst-case technical severity of the flaw itself, computed without any knowledge of whether the affected asset is exposed, exploited, or even running in your environment.

CVSS versions and currency: v3.1 vs v4.0

Two versions are in active use right now, and a defender needs to read both because scanners, the NVD, and vendor advisories are still mid-transition.

CVSS v3.1 is the version most scoring you see today was produced under. It uses three metric groups, Base, Temporal, and Environmental, and its Base group includes the Scope metric, which captures whether a vulnerability in one component impacts resources beyond its own security scope. v3.1 is not deprecated and remains widely deployed across tooling and historical CVE records.

CVSS v4.0 was officially published by FIRST on November 1, 2023. It is the current standard, and the changes are substantive, not cosmetic:

• The Temporal group was renamed Threat, sharpening its purpose around exploit maturity and threat intelligence rather than a vague "things that change over time."
• Attack Requirements (AT) was added to the Base exploitability metrics, separating target-state conditions from attacker effort.
• Scope was removed and replaced by the split between Vulnerable System and Subsequent System impact metrics, which FIRST describes as capturing the same property more precisely.
• The Supplemental metric group was added, carrying actionable context such as Automatable and Provider Urgency that does not alter the score.

The currency point matters for two reasons. First, when you compare scores, confirm you are comparing the same version: a v3.1 7.5 and a v4.0 7.5 are not computed the same way. Second, the version is usually written into the vector string itself (it begins with CVSS:3.1 or CVSS:4.0), so the source of truth for which version produced a score is the vector, not the dashboard label.

How defenders use, and misuse, CVSS

The single most important thing to understand about CVSS is what the FIRST user guide states plainly: "CVSS Base (CVSS-B) scores are designed to measure the severity of a vulnerability and should not be used alone to assess risk." The Base score "represents only the intrinsic characteristics of a vulnerability and is independent of any factor associated with threat or the computing environment." Severity is not risk. Treating the two as the same is the root of nearly every CVSS mistake.

Three misuses recur:

Patching by Base score alone. A queue sorted strictly by CVSS Base treats a 9.8 on an isolated lab box as more urgent than a 7.5 on an internet-facing authentication server with a known exploit. The Base score cannot see exposure, so a queue built only on it optimizes for the wrong thing. This is the failure that makes a vulnerability management program look busy while leaving the actually-reachable flaws open.

Ignoring the Environmental group. Most teams consume the Base score and never compute Environmental metrics, which is the one part of CVSS designed to fold in their own asset context. The framework already has the mechanism to lower the lab box and raise the regulated-data host. It mostly goes unused.

Confusing a high score with active threat. A Critical Base score says the flaw is severe if exploited. It says nothing about whether anyone is exploiting it. That is what the Threat group, and external feeds, are for.

Used well, CVSS is one input among several. Pair the Base severity with exploitation evidence and asset context:

• EPSS (the Exploit Prediction Scoring System, also maintained by FIRST) estimates the probability, on a 0 to 1 scale, that a CVE will be exploited in the wild in the next 30 days. It answers the question CVSS Base cannot: how likely is this to actually be hit.
• CISA KEV, the Known Exploited Vulnerabilities catalog, lists CVEs with confirmed in-the-wild exploitation. A CVE on the KEV list with a moderate CVSS often deserves attention before a higher-scoring CVE that no one is exploiting.
• Asset context, your own exposure, data sensitivity, and compensating controls, is what CVSS Environmental metrics formalize, and what a continuous threat exposure management (CTEM) program operationalizes across the whole estate.

The pattern is consistent: CVSS tells you how bad a vulnerability is in the abstract. EPSS and KEV tell you how likely it is to be used. Your asset context tells you what it would cost you. Prioritization is the product of all three, and a team that patches on CVSS Base alone is using one third of the picture.

The bottom line

CVSS is an open FIRST standard that scores a vulnerability's severity from 0.0 to 10.0, mapped to five bands from None to Critical. The score comes from the Base metric group (Attack Vector, Attack Complexity, the new Attack Requirements, Privileges Required, User Interaction, and the Confidentiality, Integrity, and Availability impacts), with Threat, Environmental, and the v4.0 Supplemental groups layering context on top. v4.0, published November 2023, renamed Temporal to Threat, added Attack Requirements, and replaced Scope with a vulnerable-versus-subsequent-system impact split, while v3.1 remains widely deployed.

The discipline is reading the score for what it is. A CVSS Base score is technical severity, not risk, and FIRST says so directly. The 9.8 on an unreachable host and the 7.5 on an exploited, internet-facing server are both telling the truth about the flaw and nothing about your exposure. Pair the score with EPSS for exploitation probability, CISA KEV for confirmed active exploitation, and your own asset context, and CVSS becomes what it was built to be: one reliable input into a prioritization decision, not the decision itself.