CVSS v4.0: What You Need to Know about the Latest Version

Blog

CVSS v4.0: What You Need to Know about the Latest Version

10 min.

March 16, 2025

Introduction

The Common Vulnerability Scoring System (CVSS) has long been a prime method for accurately assessing vulnerability severity, providing a standardized approach to communicating the characteristics and severity of software vulnerabilities. With the release of CVSS version 4.0, significant improvements have been made to enhance the precision and flexibility of vulnerability scoring.

After more than eight years since the last major update, CVSS v4.0 was officially published on November 1st, 2023, and has been gradually adopted by major organizations in the cybersecurity field.

Overview of CVSS v4.0

CVSS is an industry-open framework designed to communicate the characteristics and severity of software vulnerabilities.

Version 4 now consists of four metric groups:

Base Metrics

Represent the intrinsic qualities of a vulnerability that remain constant over time and across user environments.

Environmental Metrics

Represent the characteristics of a vulnerability
unique to a user’s environment and may or may not
change over time.

Threat Metrics

Reflect the vulnerability characteristics that may change over time, focusing on the current state of exploit techniques, exploit code availability, or active “in-the-wild” exploitation.

Supplemental Metrics

A new optional group that provides additional extrinsic context without affecting the base score.

The primary goals of CVSS v4.0 are to improve scoring accuracy and granularity, increase flexibility across different environments, and help enhance vulnerability prioritization capabilities.

Key Changes in the Latest Version

CVSS v4.0 introduces several significant changes in the metrics and values to improve the focus and granularity of the resulting score. Some key modifications include:

Groups Changes

CVSS v3.1 CVSS v4.0
Base Metrics Base Metrics
Temporal Metrics Threat Metrics
Environmental Metrics Environmental Metrics
Supplemental Metrics

New Metrics and Parameters for the Base Group

Attack Requirements (AT) metric: Assesses prerequisites for exploitation by evaluating conditions in the vulnerable component that enable the attack.

Attack Complexity (Clarifications): The Attack Complexity (AC) metric was improved to have a clearer meaning and segregate the ideas that are now described in the Attack Requirements (AT).

User Interaction (UI) metric: Now offers three values (None, Passive, Active) to better describe required user involvement.

Vulnerable System and Subsequent System Impacts: Replaces the previous Scope concept to focus more on the relationship between scope and impact, providing additional Impact information on both Vulnerable System (VC, VI, VA) and Subsequent Systems (SC, SI, SA).

Revamped and Simplified Metrics

Threat Metrics (formerly Temporal Metrics)

Reflects a shift towards incorporating threat intelligence in scoring. The Exploit Maturity (E) metric (formerly Exploit Code Maturity) now can have four values: Not Defined (X), Attacked (A), Proof-of-Concept (P), and Unreported (U).

Environmental Metrics

These metrics allow for the adjustment of the Base Score to reflect the importance of the affected IT asset to a user’s organization. The Environmental metrics group has been updated to include a Safety parameter when there could be an impact on humans. This new parameter allows for the assessment of potential safety impacts in systems where safety is a critical concern, particularly relevant for OT, ICS, and IoT environments.

Supplemental Metrics

This entirely new, optional group provides additional context without affecting the base score, including:

  • Safety (S): Assesses safety impact on human life
  • Automatable (AU): Indicates if vulnerability exploitation can be reliably automated at scale
  • Recovery (R): Measures system recovery capabilities post-exploitation
  • Value Density (V): Assesses the concentration of valuable resources accessible through exploitation
  • Vulnerability Response Effort (RE): Reflects the effort required to successfully respond to the vulnerability
  • Provider Urgency (U): Allows vendors to indicate the urgency of remediation

Importance of Threat Intelligence

The renaming of Temporal Metrics to Threat Metrics emphasizes the increased importance of threat intelligence in CVSS v4.0. This change recognizes that the threat landscape is constantly evolving and that a vulnerability’s risk level can change rapidly based on threat actor behavior. Real-time threat intelligence is crucial for accurate risk assessment.

Improvements in Severity Assessment and Scoring

CVSS v4.0 introduces significant improvements in severity assessment and scoring, aiming to provide more accurate, nuanced, and context-aware vulnerability ratings.

Improved Granularity

  • More Precise Metric Values: Introduction of new metrics and expanding existing ones allow for more precise vulnerability descriptions.
  • Separation of Vulnerable and Subsequent Systems: This change allows for more precise scoring of the impact for vulnerabilities that affect multiple systems or have cascading effects.
  • Refined Attack Complexity Assessment: The separation of Attack Complexity (AC) and Attack Requirements (AT) metrics allows for a more nuanced evaluation of the difficulty in exploiting a vulnerability.

Improved Scoring System Development

CVSS v4.0 addresses the “score inflation” problem seen in v3.x through more balanced severity distribution and more precise scoring. The refined scoring system prevents too many vulnerabilities from being rated as critical, addressing the perception that “most” vulnerabilities were scored 9.8 in version 3.1.

Understanding CVSS v4.0 Score Changes

To understand how scoring has evolved, let’s look at the key metric changes from v3.1 to v4.0 and examine an example vulnerability.

Example – CVE-2024-6387

CVE-2024-6387 is a vulnerability affecting OpenSSH’s server (sshd), also known as regreSSHion. The vulnerability arises from a default configuration for the signal handler. By exploiting a race condition in this default behavior, an unauthenticated attacker might be able to gain root access to the server and execute commands.

Key characteristics of this vulnerability:

  • Attack Requirements are Present because an attacker needs to win a race condition.
  • Attack Complexity is Low in a general scenario since no mitigative measures are involved.
  • No User Interaction is required.
  • Scope is Unchanged in version 3.1, therefore there is no Subsequent system impact in version 4.0.
  • Confidentiality, Integrity, and Availability are fully impacted since the attacker can execute commands with full privileges.

Resulting scores:

  • CVSS v3.1: 8.1 (High)
  • CVSS v4.0: 9.2 (Critical)

The score change reflects the improved granularity and context-awareness of CVSS v4.0. When evaluating this vulnerability in a specific context with additional parameters (e.g., ASLR measures, threat intelligence), the score can be further refined to better reflect the real-world severity.

Provider vs. Consumer Roles

CVSS v4.0 introduces a clearer distinction between metrics that are expected to be filled by the vulnerability provider (such as software vendors or security researchers) and those that should be assessed by the consumer (individuals or organizations using the affected software):

Provider Role

Providers use their intimate software knowledge to assess Base Metrics, including attack vector, complexity, and potential impact. They provide the foundation for vulnerability assessment based on their expertise with the affected software.

Consumer Role

Consumers play a vital role in contextualizing vulnerabilities within their specific environments. They should provide the Threat metrics by using their own threat intelligence sources, as well as accurately assess the Environmental Metrics, which take into account factors like the importance of affected assets and any security measures in place.

This distinction allows for a more comprehensive and accurate vulnerability assessment, combining the technical expertise of providers with the contextual knowledge of consumer.

Transition to Version 4

The adoption of CVSS v4.0 will be a gradual process requiring updates to tools, processes, and team knowledge. Key steps in the transition include:

  • Updating vulnerability management tools to support CVSS v4.0 metrics and scoring
  • Refreshing vulnerability management processes and prioritization strategies
  • Integrating threat intelligence feeds into vulnerability management processes
  • Investing in training for security professionals to understand new concepts and metrics
  • Integrating asset management data with vulnerability scanning results to leverage Environmental metrics

Conclusion

While the transition to CVSS v4.0 may require effort, the improved accuracy and flexibility it offers should ultimately lead to more effective vulnerability management and a stronger security posture. Organizations that invest in adopting this new version will be better equipped to assess and prioritize vulnerabilities in their increasingly complex IT environments.

CVSS 4.0 and Checkmarx

When it comes to managing your application security posture, having the right tools makes all the difference. Checkmarx SCA solution fully supports CVSS 4.0, helping you to better prioritize and act on the risks that matter most.

CxOne Knowledge Center support of CVSS version 4.0.
Figure 1 – CxOne Knowledge Center support of CVSS version 4
Vulnerability with CVSS version 4.0 in SCA scan result.
Figure 2 – Vulnerability with CVSS 4.0 in SCA scan result