Common Vulnerability Scoring System (CVSS)

Back to glossary

What Is the Common Vulnerability Scoring System (CVSS)?

The Common Vulnerability Scoring System is a standardized framework for rating the severity of software vulnerabilities. It produces a numerical score from 0.0 to 10.0 that represents the intrinsic characteristics of a vulnerability, providing a common language for communicating severity across vendors, tools, and organizations.

CVSS scores appear in nearly every vulnerability management workflow. They are published alongside CVE entries in the National Vulnerability Database (NVD), embedded in scanner output, and used to set remediation SLAs. However, a CVSS score reflects theoretical severity based on the vulnerability’s technical characteristics, not the actual risk it poses in a specific environment. 

Understanding how CVSS works, and where it falls short, is essential for teams building risk-based vulnerability prioritization programs.

How CVSS Scores Are Calculated

CVSS uses a set of metrics that describe the properties of a vulnerability. Each metric has defined values, and the combination of all metric values produces the final score through a published formula.

The calculation considers factors like how the vulnerability is accessed (network, adjacent, local, physical), what conditions are required for exploitation (complexity, privileges, user interaction), and what the impact is on confidentiality, integrity, and availability if exploitation succeeds.

The resulting score falls into qualitative severity bands: 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 widely used to set remediation timelines, with many organizations requiring critical findings to be resolved within days and low findings within quarters.

The current version, CVSS v4.0, was released in November 2023 and refines the metric groups, adds supplemental metrics, and addresses some criticisms of earlier versions. CVSS v3.1 remains the most widely used version across scanner vendors and vulnerability databases.

CVSS Base, Temporal, and Environmental Metrics Explained

The CVSS base score is calculated from two metric groups: Exploitability and Impact. These capture the intrinsic, unchanging characteristics of the vulnerability.

Here’s how they work:

  • Exploitability metrics: Attack Vector (how the vulnerability is accessed), Attack Complexity (conditions beyond the attacker’s control), Privileges Required (what access level the attacker needs), and User Interaction (whether a victim must take action). These determine how easy the vulnerability is to exploit.
  • Impact metrics: Confidentiality, Integrity, and Availability impact (each rated None, Low, or High). These determine the consequences of successful exploitation.

Temporal metrics adjust the base score based on factors that change over time: Exploit Code Maturity (whether a working exploit exists), Remediation Level (whether a patch is available), and Report Confidence (how verified the vulnerability is). Temporal scores are rarely published because they require ongoing maintenance.

Environmental metrics allow organizations to customize the score based on their own infrastructure. A vulnerability in a component that handles no sensitive data and is isolated behind multiple network controls will have a lower environmental score than the base score suggests. Environmental scoring is powerful but underused because it requires per-asset configuration that most vulnerability classification workflows do not automate.

Limitations of CVSS as a Prioritization Tool

CVSS was designed to measure severity, not risk. This distinction causes significant problems when organizations use CVSS vulnerability scoring as their primary prioritization mechanism.

Typical limitations include:

  • No context: The base score does not consider whether the vulnerable component is deployed, internet-facing, or processing sensitive data. A Critical-rated CVE in an internal development tool and a Critical-rated CVE in a public-facing payment API receive the same score.
  • No threat intelligence: CVSS does not account for whether a vulnerability is actively exploited in the wild. A theoretically severe vulnerability with no known exploit receives the same base score as one being used in active campaigns.
  • Score clustering: The CVSS formula produces a disproportionate number of High and Critical scores. When everything is critical, nothing is prioritized effectively. Teams face backlogs dominated by findings that all appear equally urgent.
  • Static assessment: Base scores are assigned once and rarely updated. The threat landscape around a vulnerability can change dramatically after scoring, but the base score does not reflect those changes.

These limitations do not make CVSS useless. They make it insufficient as a standalone prioritization mechanism. The base score is a starting point, not a decision.

CVSS vs. EPSS: Complementary Approaches to Vulnerability Scoring

CVSS and the Exploit Prediction Scoring System (EPSS) answer different questions. CVSS asks: “How severe is this vulnerability?” EPSS asks: “How likely is this vulnerability to be exploited in the next 30 days?”

EPSS uses machine learning trained on observed exploitation data, threat intelligence feeds, and vulnerability characteristics to produce a probability score between 0 and 1. A vulnerability with a high CVSS score but a low EPSS score is theoretically severe but unlikely to be exploited soon. A vulnerability with a moderate CVSS score and a high EPSS score may represent a more immediate operational risk.

The most effective prioritization models combine both signals. CVSS provides the severity baseline. EPSS provides the threat urgency signal. Layering these with asset context, runtime exposure, and business impact data from known exploited vulnerabilities catalogs like CISA KEV produces a risk-ranked queue that reflects actual organizational exposure rather than theoretical severity.

Neither CVSS nor EPSS alone is sufficient. Together, they provide two of the key inputs into a risk-based prioritization model.

FAQs

Why does a high CVSS score not always mean a vulnerability is urgent to fix?

A high score reflects theoretical severity. Without context about deployment, exposure, exploit availability, and business impact, severity alone does not determine operational urgency.

What is the difference between CVSS base score and environmental score?

The base score reflects intrinsic vulnerability characteristics. The environmental score adjusts for organizational context: asset importance, existing mitigations, and deployment specifics.

How often does CVSS scoring get updated and why does it change?

The CVSS framework is updated by FIRST.org every several years. Version updates refine metrics and address scoring criticisms. Individual base scores are set once per CVE and rarely revised.

Can two vulnerabilities with identical CVSS scores have very different real-world risk?

Yes. A Critical CVE in an air-gapped internal system poses far less operational risk than the same score in a public-facing API handling payment data. Context determines real risk.

What version of CVSS is most widely used today?

CVSS v3.1 remains the most widely adopted version across vulnerability databases and scanner vendors. CVSS v4.0 was released in late 2023 and adoption is growing.

Back to glossary
See Apiiro in action
Meet with our team of application security experts and learn how Apiiro is transforming the way modern applications and software supply chains are secured. Supporting the world’s brightest application security and development teams: