Changes and improvements in CVSS 4.0

• by Samuele Resca

The Common Vulnerability Scoring System (CVSS) is a system for capturing the properties and severity of software vulnerabilities. The Forum of Incident Response and Security Teams (FIRST) and the CVSS Special Interest Group (SIG) recently released the 4.0 version of CVSS[1].

This post outlines the improvements introduced in CVSS 4.0 and what's changed compared with CVSS 3.1. The post originates from the CVSS 4.0 public preview presentations[2][3].

Base score alone is not accurate

The CVSS 3.1 Base score is used as a primary input for assessing CVEs. The Base score definition captures all the vulnerability's characteristics that don't change over time nor across user environments. Most of the CVEs published on the vendor databases comes with the base score already set. Downstream consumers often rely only on the base score for doing vulnerability assessment and prioritization.

CVSS 4.0 emphasize that the Base score is only one part of the CVSS scoring. Introducing the following terms:

  • CVSS-B refers to the CVSS base score alone.
  • CVSS-BT refers to a CVSS score that provides both the CVSS Base and Threat metrics.
  • CVSS-BE refers to a CVSS score that provides both CVSS Base and Environmental metrics.
  • CVSS-BTE refers to a CVSS score that provides CVSS Base, Threat and Environmental metrics.

CVSS 4.0 states that using more metrics makes the vulnerability assessment more accurate. [2:1] Moreover, CVSS-B should not be used alone to set the remediation priority of a vulnerability.

Temporal metrics weren't impacting the final score

In CVSS 3.1, the Temporal Score metrics had a low impact on the overall score. The Temporal Score metrics are Exploit Code Maturity (E), Remediation Level (RL), and Report Confidence (RC). During the assessment, the Remediation Level (RL) is frequently set as Official fix (O) and the Report Confidence (RC) is frequently set as Confirmed (C).

CVSS 4.0 introduces the following changes:

  • Rename the Temporal Score metrics to Threat Metrics.
  • Rename the Exploit Code Maturity to Exploit Maturity.
  • The Exploit Maturity is now enumerated with Attacked (A), POC (P), Unreported (U).
  • Retire the Remediation Level (RL) and Report Confidence (RC) metrics.

On top of the changes above, the Threat Metrics have now a higher impact on the calucation of the final CVSS-BTE score.

User Interaction metric wasn't granular enough

The User Interaction (UI) metric in the CVSS 3.1 specification has two possible values: None(N), Required(R). These values do not tell the difference between voluntary and involuntary interaction.

CVSS 4.0 introduces new metrics values for the User Interaction (UI) metric:

  • None (N) : the vulnerable system can be exploited without intervention.
  • Passive (P) : a user needs to interact with the vulnerable system. These interactions would be involuntary.
  • Active (A): a user must interact with the vulnerable component and the attacker’s payload. Or, the user's actions would subvert protection mechanisms and lead to exploitation.

The changes above provide a better representation of the type of interaction needed for exploiting the system.

Scope (S) metric was ambiguous

CVSS 3.1 defined a Scope (S) metric. The metric captured the idea of a vulnerable system, that when compromised, could also impact resources beyond the security control of the vulnerable system. The metrics was inconsistent across the vendors.

CVSS 4.0 introduces the concept of vulnerable system, which refers to the actual system that is vulnerable. And a subsequent systems, referring to the downstream system that is impacted by the exploitability of the vulnerable system.

The new CVSS 4.0 Impact Metrics are split into two groups. They represent the difference between the vulnarable and the subsequent system. Each group contains the familiar Confidentiality (C), Integrity (I), Availability (A) metrics.

This approach remove the need of the Scope (S) metric.

New supplemental metrics

CVSS 4.0 introduces a set of Supplemental Metrics. They give additional information on a vulnerability. Note that Supplemental metrics do not affect the CVSS score. They store extra information to help organizations assessments. It is up to the organizations ignore or use this group of metrics during the assessment.

Below is a summary of the supplemental metrics added in CVSS 4.0.

Safety (S)

Safety (S) is intended for fitness devices. Exploiting the vulnerability might have a safety impact on an individual or a system.

The Safety (S) metric can assume the following values:

  • Not Defined (X) indicates that the metric is not defined.
  • Negligible (N) means the vulnerability's consequences are "Negligible" by IEC 61508.
  • Present (P) means that the vulnerability's consequences meet the IEC 61508 consequence definitions. These include "Marginal", "Critical", or "Catastrophic".

Automatable (AU)

Automatable (AU) metric answers the following question "Can the attackers automate the exploitation across multiple targets?". The Automatable (AU) metric can have these self-explanatory values: Not Defined (X), No (N), Yes (Y).

Recovery (R)

The Recovery (R) metric describes how well a system can recover from exploitation. The ability to recover has to be intended from an availability and performance point of view.

The Recovery (R) metric can assume the following values:

  • Not Defined (X): the metric is not defined.
  • Automatic (A): the component recovers automatically after an attack.
  • User (U): The component requires manual intervention by the user to recover after an attack.
  • Irrecoverable (I): the component is irrecoverable by the user, after an attack.

Value Density (V)

The Value Density (V) metric represents the amount of resources an attacker will gain control of with a single exploitation event.

The Value Density(V) metric can assume the following values:

  • Diffuse (D): the system that contains the vulnerable components has limited resources.
  • Concentrated (C): the system that contains the vulnerable component is rich in resources.

Vulnerability Response Effort (RE)

The Vulnerability Response Effort (RE) measures how difficult it is for consumers to provide an initial response to the impact of vulnerabilities for deployed services.

The Vulnerability Response Effort (RE) has the following values:

  • Low (L): the effort required to respond to the vulnerability is low. Some example provided includes configuration workarounds.
  • Medium (M): responding to the vulnerability will need some effort. It could cause minimal service impact. Some examples provided by the CVSS 4.0 specifications include: simple remote updates or a low-touch software upgrade.
  • High (H): the actions required to respond to a vulnerability are significant and/or difficult. Some examples provided by the CVSS 4.0 specifications include: a highly privileged driver update or updates that require careful analysis.

Provider Urgency (U)

The Provider Urgency (U) metric is meant to capture the provider's assessment. It shows how urgent the vulnerability should be fixed. It can assume the following: Not Defined (X), Red, Amber, Green, Clear. Where Red implies the higher urgency while Clear the lower (no urgency).

CVSS 4.0 also specifies that any provider along the supply chain may set a Provider Urgency rating. For example:

Library Maintainer Urgency -> OS/Distro Maintainer Urgency -> Provider 1 .. 
Provider N  Urgency -> Consumer

From a Consumer point of view, the Provider N urgency is the more accurate.

New EPSS scoring system

On top of the CVSS 4.0 release, FIRST recently introduced a new scoring system called EPSS[4]. The system relies on a model trained on list of data sources, see Table 1. Description of data sources used in EPSS[5], for estimating the probability that a vulnerability would be exploited within 30 days following the prediction.

Recap

  • The Common Vulnerability Scoring System (CVSS) is a system for capturing the properties and severity of software vulnerabilities.
  • CVSS 4.0 introduces new terms and emphasizes that the Base score is only one part of the CVSS scoring.
  • The Temporal Score metrics have been renamed to Threat Metrics and have a higher impact on the final score.
  • The User Interaction (UI) metric has been updated to provide a better representation of the type of interaction needed for exploitation.
  • The Scope (S) metric has been removed and replaced with the concept of vulnerable and subsequent systems.
  • CVSS 4.0 introduces a set of Supplemental Metrics that do not affect the CVSS score but provide additional information on a vulnerability.
  • FIRST also introduced a new scoring system called EPSS, which estimates the probability that a vulnerability would be exploited within 30 days following the prediction.

  1. CVSS 4.0 specifications. At the time of writing, most vendors have not adopted CVSS 4.0 yet. However, CVSS 4.0 launched in late 2023. It will take time before it is widely used by vulnerabilities databases and integrated with the vulnerabilities detection tools. ↩︎

  2. CVSS v4.0 NIST presentation ↩︎ ↩︎

  3. Announcing CVSS v4.0 ↩︎

  4. Exploit Prediction Scoring System ↩︎

  5. Jacobs, Jay, Sasha Romanosky, Octavian Suciu, Ben Edwards, and Armin Sarabi. "Enhancing Vulnerability prioritization: Data-driven exploit predictions with community-driven insights. ↩︎