What Is CVSS? Understanding Vulnerability Severity Scoring

By Cowboy Neil education
cvss vulnerability security scoring
TL;DR

The Common Vulnerability Scoring System (CVSS) assigns severity scores to vulnerabilities on a 0–10 scale. Combining CVSS scores with SBOM data and CISA's KEV catalog helps you prioritize which vulnerabilities to fix first based on both severity and real-world exploitation.

The Common Vulnerability Scoring System (CVSS) is an open framework for communicating the severity of software vulnerabilities. Published and maintained by FIRST.org (the Forum of Incident Response and Security Teams), CVSS produces a numerical score from 0.0 to 10.0 that represents the severity of a vulnerability. The score is accompanied by a vector string that describes the specific characteristics used to calculate it. CVSS is the most widely used vulnerability scoring system in the world — the National Vulnerability Database (NVD) publishes CVSS scores for virtually every CVE entry.

How CVSS Scores Work

A CVSS score is not a single number derived from one input. It is calculated from a set of metrics organized into metric groups. Each metric describes a specific characteristic of the vulnerability, and the combination produces the final score.

CVSS v3.1 Metric Groups

CVSS v3.1 (the most widely deployed version as of early 2026) defines three metric groups:

Base Score (0.0-10.0) — Represents the intrinsic qualities of the vulnerability that are constant over time and across environments. This is the score most commonly reported.

  • Attack Vector (AV): How the vulnerability is exploited — Network (remote), Adjacent (local network), Local (requires local access), or Physical (requires physical access)
  • Attack Complexity (AC): Whether specialized conditions must exist for exploitation — Low or High
  • Privileges Required (PR): What level of privilege an attacker needs — None, Low, or High
  • User Interaction (UI): Whether a user must take action for exploitation — None or Required
  • Scope (S): Whether exploitation impacts resources beyond the vulnerable component — Unchanged or Changed
  • Confidentiality Impact (C): Impact on data confidentiality — None, Low, or High
  • Integrity Impact (I): Impact on data integrity — None, Low, or High
  • Availability Impact (A): Impact on system availability — None, Low, or High

Temporal Score — Adjusts the Base Score based on factors that change over time, such as whether an exploit is available, whether a patch exists, and confidence in the vulnerability report.

Environmental Score — Adjusts the score based on the specific environment where the vulnerability exists, allowing organizations to reflect their own infrastructure context.

Severity Ratings

CVSS scores map to qualitative severity ratings:

Score Range Severity
0.0 None
0.1 - 3.9 Low
4.0 - 6.9 Medium
7.0 - 8.9 High
9.0 - 10.0 Critical

Reading a CVSS Vector String

The CVSS vector string encodes all the metric values in a compact format. For example:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H — Score: 10.0 (Critical)

This describes Log4Shell (CVE-2021-44228): exploitable over the network (AV:N), with low attack complexity (AC:L), requiring no privileges (PR:N) and no user interaction (UI:N), with changed scope (S:C), and high impact on confidentiality, integrity, and availability.

Compare with: CVSS:3.1/AV:L/AC:H/PR:H/UI:R/S:U/C:L/I:N/A:N — Score: 1.8 (Low)

This describes a vulnerability requiring local access, high complexity, high privileges, user interaction, and producing only low confidentiality impact — a much less severe threat.

CVSS v4.0

CVSS v4.0 was released by FIRST.org in November 2023 and represents a significant evolution of the framework. While CVSS v3.1 remains the most widely used version (the NVD still primarily publishes v3.1 scores), v4.0 adoption is increasing.

Key Changes in v4.0

New metric groups. CVSS v4.0 restructures the scoring into four metric groups:

  • Base — Intrinsic vulnerability characteristics (similar to v3.1)
  • Threat — Replaces the Temporal group; focused on exploit maturity
  • Environmental — Organization-specific adjustments
  • Supplemental — Additional context that does not affect the score (e.g., safety impact, automatable, recovery)

Removed Scope metric. The Scope (S) metric from v3.1, which was widely considered confusing and inconsistently applied, has been removed. Its effects are captured through refined impact metrics.

Attack Requirements. A new metric (AT) distinguishes between vulnerabilities that require specific deployment conditions and those that do not, providing more nuance than v3.1’s Attack Complexity.

Multiple score types. CVSS v4.0 defines specific score types:

  • CVSS-B: Base score only
  • CVSS-BT: Base + Threat
  • CVSS-BE: Base + Environmental
  • CVSS-BTE: Base + Threat + Environmental (most complete)

v3.1 vs. v4.0

Aspect CVSS v3.1 CVSS v4.0
Metric groups Base, Temporal, Environmental Base, Threat, Environmental, Supplemental
Scope metric Present (Unchanged/Changed) Removed
Attack granularity Attack Complexity (Low/High) Attack Complexity + Attack Requirements
Score types One composite score Four named score types (B, BT, BE, BTE)
NVD support Fully supported Adoption in progress
Adoption status Industry standard Growing adoption

Both versions produce scores on the same 0.0-10.0 scale with the same severity ratings. A score of 9.8 means roughly the same severity in both versions, though the exact metrics contributing to that score may differ.

CVSS in Vulnerability Prioritization

CVSS scores are essential for vulnerability prioritization, but they should not be the only signal.

CVSS Alone Is Not Enough

A CVSS Base Score measures theoretical severity — how bad the vulnerability could be if exploited. It does not tell you:

  • Whether it is being exploited. The CISA KEV catalog answers this question. A CVSS 7.5 vulnerability that is actively exploited (KEV-listed) is more urgent than a CVSS 9.8 vulnerability with no known exploits.
  • Whether you are affected. A critical vulnerability in a component you do not use, or in a code path your application never reaches, represents zero actual risk to you.
  • Your deployment context. A network-exploitable vulnerability in an internet-facing application is far more urgent than the same vulnerability in a completely internal tool.

A Combined Prioritization Approach

Effective vulnerability prioritization uses CVSS together with other signals:

Signal Source What It Tells You
CVSS NVD, vendor advisories Theoretical severity (how bad it could be)
KEV CISA KEV catalog Whether it is actively exploited
EPSS FIRST.org EPSS Probability of exploitation in the next 30 days
SBOM Your component inventory Whether you use the affected component
Context Your deployment architecture Whether the vulnerability is reachable

For a practical prioritization framework that combines CVSS with KEV status and deployment context, see our KEV guide.

CVSS and SBOMs

SBOMs enable CVSS-based vulnerability management at scale. Without an SBOM, you need to manually determine which components are in your software before you can look up their CVSS scores. With an SBOM, this process is automated.

The Workflow

  1. Generate SBOMs for your applications using tools from our SBOM generation guides
  2. Ingest SBOMs into a monitoring platform like sbomify or OWASP Dependency-Track
  3. Automatic matching — the platform matches your components against vulnerability databases and retrieves CVSS scores
  4. Prioritize using CVSS severity combined with KEV status and your deployment context
  5. Remediate according to your defined SLAs

CVSS in SBOM Formats

CycloneDX includes a vulnerabilities array that can carry CVSS scores directly within the SBOM or an associated VEX document. This allows a single document to contain both the component inventory and its known vulnerabilities with scores.

SPDX 3.0 supports vulnerability information through its Security profile, which can reference CVSS data.

For more on SBOM scanning and vulnerability detection, see our SBOM scanning guide.

Frequently Asked Questions

What is CVSS?

The Common Vulnerability Scoring System (CVSS) is an open framework maintained by FIRST.org for scoring the severity of software vulnerabilities on a scale of 0.0 to 10.0. Scores are calculated from metrics describing the vulnerability’s attack vector, complexity, required privileges, and potential impact. CVSS scores are published by the NVD for virtually every CVE and are the most widely used measure of vulnerability severity.

What is a good CVSS score?

Lower CVSS scores indicate less severe vulnerabilities. A score of 0.0 means no impact. Scores of 0.1-3.9 are Low severity, 4.0-6.9 are Medium, 7.0-8.9 are High, and 9.0-10.0 are Critical. However, “good” depends on context — even a Medium vulnerability is urgent if it is being actively exploited (listed in the CISA KEV catalog) or in an internet-facing system.

What is the difference between CVSS v3.1 and v4.0?

CVSS v4.0 introduces refined metric groups (Base, Threat, Environmental, Supplemental), removes the controversial Scope metric, adds an Attack Requirements metric for more granular exploitability assessment, and defines four named score types (CVSS-B, CVSS-BT, CVSS-BE, CVSS-BTE). Both versions use the same 0.0-10.0 scale and severity ratings. CVSS v3.1 remains more widely deployed; v4.0 adoption is growing.

How should I prioritize vulnerabilities?

Do not rely on CVSS scores alone. Combine CVSS severity with CISA KEV status (is it actively exploited?), EPSS probability (how likely is exploitation?), your SBOM (do you use the affected component?), and deployment context (is the vulnerable component exposed?). A KEV-listed vulnerability at CVSS 7.5 often warrants faster action than a non-exploited vulnerability at CVSS 9.8.

What is EPSS?

The Exploit Prediction Scoring System (EPSS) is a model maintained by FIRST.org that estimates the probability that a CVE will be exploited in the wild in the next 30 days. EPSS scores range from 0 to 1 (0% to 100% probability). Used alongside CVSS and KEV, EPSS provides a forward-looking signal for vulnerability prioritization.

Found an error or typo? File a PR against this file.