First Impressions of the CVSS 4.0 Preview

CVSS 4.0 (Common Vulnerability Scoring System, version 4.0) is being released with a focus on increasing granularity and improving the usability of the scoring metrics outside of the base score.

Because of this, going from CVSS 2.0 or 3.1 to CVSS 4.0 will reduce the base score of many vulnerabilities allowing for better prioritization. The public comment period closes July 31st 2023, and the official publication is scheduled for Q4 2023.

Release Information

The Forum of Incident Response and Security Teams (FIRST) released a public preview of CVSS 4.0 at the FIRST Conference on June 8th 2023, with the objective of soliciting public comment through the end of July. The actual calculation and coefficients for CVSS 4.0 have not been released yet. To allow time to solicit public feedback, FIRST won't release the finalized standard, including the calculation and coefficients, until Q4 2023. 

Base Score Changes

New in CVSS 4.0 is the Attack Requirements (AT) metric that quantifies severity reduction from the “deployment and execution conditions or variables” of the vulnerable system. Previously, this was either not captured or rolled into the Attack Complexity (AC) metric, which is supposed to be used to quantify severity reduction from features and configurations with the specific goal of increasing security. There are two values for this metric: None (N) and Present (P). 

New in CVSS 4.0 is the Attack Requirements (AT) metric that quantifies severity reduction from the “deployment and execution conditions or variables” of the vulnerable system.

New in CVSS 4.0 is the Attack Requirements (AT) metric that quantifies severity reduction from the “deployment and execution conditions or variables” of the vulnerable system.

The User Interaction (UI) value Required (R) has been split into two new values:

• Active (A) is what is typically thought of when the topic of User Interaction in an exploit comes up, i.e., a user is required to intentionally interact with the payload in order to trigger it, such as enabling macros in a document. Vulnerabilities that require Active User Interaction in order to trigger them can be mitigated through user training and specific warnings during a time of high-threat activity.
• Passive (P) captures situations in which the vulnerability depends on some user activity, but not an activity that could be spotted and avoided by a savvy user. For instance, an exploit that ran when a user logged in would be Passive.

The widely misunderstood CVSS 3.1 metric Scope (S) has been removed in CVSS 4.0. Scope was meant to communicate if a vulnerability crossed security boundaries at a system level, such as a sandbox escape. However, in practice, it was widely disliked and difficult to discern in most cases. In order to capture that information, the Confidentiality, Integrity, and Availability scores have been split into two categories, Vulnerable System (VC, VI, VA) and Subsequent System (SC, SI, SA).  

The impact of more complex vulnerabilities can be communicated better this way. Consider an attack that targets the infotainment system of a vehicle to DOS the CANbus. The vulnerable system may be intact, but the ability to play music is little comfort for the occupants of said vehicle. The availability of the subsequent system is highly impacted!

A large part of the reasoning for these changes was to make CVSS 4.0 more applicable to OT/ICS/IoT equipment.  

A large part of the reasoning for these changes was to make CVSS 4.0 more applicable to OT/ICS/IoT equipment.  

Other Metric Changes

In order to differentiate between different types of CVSS calculations, a new nomenclature has been developed for the different types of scores. The base score most commonly used is now the CVSS-B, while CVSS scores using the Threat (T), Environmental (E), or both are denoted as CVSS-BT, CVSS-BE, and CVSS-BTE respectively.

This will add clarity to what CVSS score is being discussed, although it seems likely that CVSS-B will continue to be the most commonly used and the community will refer to it simply as CVSS as they do now. 

As a significant change, the Temporal metrics group was renamed the Threat metric group to more accurately reflect its contents. Within the new Threat group, there were a few other adjustments:

• Remediation Level (RL) and Report Confidence (RC) - These metrics were removed because they were almost always set to the same values and were, as a result, unremarkable.
  
  
• Exploit Code Maturity - This metric was renamed to Exploit Maturity (E) and its values were also revamped to add clarity:
  
  Not Defined (X) 
  Attacked (A) - This vulnerability was documented as being used in the wild by threat actors.
  Proof of Concept (P) - Exploit code is publicly available, but there are no known cases of it being used.
  Unreported (U) - No instances of the vulnerability being exploited are publicly known, nor is there publicly available exploit code.
  
  
• Not Defined (X) 
• Attacked (A) - This vulnerability was documented as being used in the wild by threat actors.
• Proof of Concept (P) - Exploit code is publicly available, but there are no known cases of it being used.
• Unreported (U) - No instances of the vulnerability being exploited are publicly known, nor is there publicly available exploit code.

The new Threat metric group will have a greater impact on the CVSS-BT than in previous CVSS iterations. We are very excited about this change at Finite State, as we’ve observed that the vast majority of CVEs applicable to a given device do not have any kind of proof of concept exploit available nor being exploited by threat actors. We feel that this reconfiguration will offer much more actionable results based on reasonable threat models.

The new Threat metric group will have a greater impact on the CVSS-BT than in previous CVSS iterations.
There is also going to be a new metric group – Supplemental. These metrics do not contribute to the CVSS-BTE score, and the use thereof is intended to be determined by the CVSS 4.0 consumer. 

Safety (S) is part of the new focus on OT/ICS/IoT, and captures IEC 61508 definitions of safety. That is, can this vulnerability lead to someone being hurt or killed? ICS people have it rough.
Automatable (AU) is pretty straightforward; can the attack be automated? This is defined as happening in the first four stages of the kill chain, so we’ll see how this one goes as we suspect the answer in most cases is “yes in theory, but no one’s willing to actually put in the work.”
Provider Urgency (U) is an interesting idea and reflects how important fixing the vulnerability is to the software provider.
Recovery (R) is an important new metric as well, rating how difficult it is to recover from the attack. It has the following values:

Automatable – recovery can be done completely automatically
User – manual intervention is required to recover
Irrecoverable – recovery is flat-out not possible
Value Density (V) is a more complicated concept, and it is meant to capture whether an attacker gains control over a disproportionate amount of resources with the attack


Vulnerability Response Effort (RE) captures the effort required by a consumer to remediate the vulnerability. A vulnerability that can be responded to with a simple firewall rule gets a low. Happy path updating is a medium. Anything that requires more complex updates to a complete rip and replace scores high. 

If you’d like to know more, you can read the specification here!  And, as always, reach out with questions to the Finite State team, and we'll help you navigate these changes.

The new Threat metric group will have a greater impact on the CVSS-BT than in previous CVSS iterations.

There is also going to be a new metric group – Supplemental. These metrics do not contribute to the CVSS-BTE score, and the use thereof is intended to be determined by the CVSS 4.0 consumer. 

• Safety (S) is part of the new focus on OT/ICS/IoT, and captures IEC 61508 definitions of safety. That is, can this vulnerability lead to someone being hurt or killed? ICS people have it rough.
• Automatable (AU) is pretty straightforward; can the attack be automated? This is defined as happening in the first four stages of the kill chain, so we’ll see how this one goes as we suspect the answer in most cases is “yes in theory, but no one’s willing to actually put in the work.”
• Provider Urgency (U) is an interesting idea and reflects how important fixing the vulnerability is to the software provider.
• Recovery (R) is an important new metric as well, rating how difficult it is to recover from the attack. It has the following values:
  
  Automatable – recovery can be done completely automatically
  User – manual intervention is required to recover
  Irrecoverable – recovery is flat-out not possible
  Value Density (V) is a more complicated concept, and it is meant to capture whether an attacker gains control over a disproportionate amount of resources with the attack
  
  
• Vulnerability Response Effort (RE) captures the effort required by a consumer to remediate the vulnerability. A vulnerability that can be responded to with a simple firewall rule gets a low. Happy path updating is a medium. Anything that requires more complex updates to a complete rip and replace scores high. 
  
  If you’d like to know more, you can read the specification here!  And, as always, reach out with questions to the Finite State team, and we'll help you navigate these changes.
  
  
• Automatable – recovery can be done completely automatically
• User – manual intervention is required to recover
  Irrecoverable – recovery is flat-out not possible
• Value Density (V) is a more complicated concept, and it is meant to capture whether an attacker gains control over a disproportionate amount of resources with the attack