CVSS 4.0 Is Here: What Security Leaders Need To Know 

Originally Published September 3rd 2023. Updated April 7th 2024.

The Common Vulnerability Scoring System (CVSS) is used to evaluate and communicate the technical severity of software, hardware and firmware vulnerabilities. While CVSS has been around for nearly 2 decades and now stands as an industry standard tool for scoring the severity of a vulnerability, the framework still has its limitations.  

To mitigate some of these challenges and improve the efficacy of the system, an updated version of CVSS was released in November 2023. This blog post will discuss some of the issues identified in CVSS v3 and outline the changes planned for CVSS 4.0.  

A Brief History Of The Common Vulnerability Scoring System (CVSS) 

The Common Vulnerability Scoring System (CVSS) was developed by the Forum of Incident Response and Security Teams (FIRST), a non-profit organization founded in 1990 that “aspires to bring together incident response and security teams from every country across the world to ensure a safe internet for all.” 

Prior to the CVSS, many different people—software vendors, independent security researchers, cybersecurity professionals at enterprise organizations, etc.—were each using their own homemade scoring systems to define the severity of a vulnerability. These systems were not compatible, which made it difficult for people to collaborate and exchange knowledge about documented CVEs, as they lacked a shared scoring system. The first version of the CVSS was released in February 2005 to overcome these obstacles.  

Over the years, new versions of the CVSS were introduced to improve upon previous versions: 

• June 2007 – CVSS v2 
• June 2015 – CVSS v3 
• June 2019 – CVSS v3.1 

Now, CVSS 4.0 was actively tested by a Special Interest Group (SIG)  and officially published on November 1, 2023, according to the FIRST website.  

A Closer Look At CVSS v3.1  

Before we dive into the details of CVSS 4.0, let’s take a moment to understand exactly how CVSS is designed today.  

A CVSS score is made up of three metric groups: 

• Base Metric Group 
• Temporal Metric Group 
• Environment Metric Group 

There are a few differences between the Base group and the other two metric groups. First of all, the Base Metric Group is required to produce a CVSS score, but the other two metric groups are recommended but not mandatory.  

Second, the Base metrics are typically defined by the person or people who discovered the vulnerability—e.g. the vendor that produces a software product or a team of independent security researchers. The Temporal and Environmental metrics, on the other hand, are defined by the end-user organization.  

As the name suggests, the Temporal metrics change over time and must be updated to reflect the current state of a specific CVE. For this reason, the Temporal inputs must be set by the end-user organization when evaluating the severity of a vulnerability. Environmental metrics must also be entered by the end-user organization, as nobody else can define how critical a particular system or asset is within a given environment. 

Base Metrics 

The Base Metric Group comprises two categories—the Exploitability sub-score and the Impact sub-score—plus a third variable known as Scope. 

The Exploitability sub-score is derived from these four metrics: 

• Attack Vector – a measure of how accessible a vulnerability is (e.g. is physical access needed to exploit the vulnerability or can it be exploited remotely?) 
• Attack Complexity – the conditions that must exist in order for the vulnerability to be exploited   
• Privileges Required – the level of privileges that an actor must have to exploit the vulnerability  
• User Interaction – a binary variable that considers whether or not any action from a human end-user (other than the attacker) is required for exploitation  

The Impact sub-score is a function of the following three metrics: 

• Confidentiality – the extent to which exploitation of the vulnerability reveals sensitive data to the attacker 
• Integrity – the extent to which exploitation of the vulnerability gives attackers the ability to alter or delete data 
• Availability – the extent to which exploitation of the vulnerability enables the attacker to make systems, networks, or data unavailable to the rightful people 

Experienced Information Security professionals will recognize the three components in the Impact sub-score as the CIA triad.  

Lastly, the Base Metric Group considers the scope of a vulnerability. This score reflects the impact of exploitation beyond the scope of the vulnerable software, hardware, or firmware. For example, if successful exploitation of a vulnerability in a web server software gives the attacker access to, say, a database that interacts with a web application running on the web server, then the sScope of the vulnerability is greater than the particular system on which the vulnerability exists. 

Temporal Metrics 

As noted above, Temporal metrics are not required for generating a CVSS score, though they are recommended. Temporal metrics must be entered by the end-user organization when calculating a CVSS score. 

• Exploit code maturity – a discrete variable indicating what type of exploit code is publicly available for the vulnerability (Unproven, Proof of Concept, Functional, High) 
• Remediation level – an score of the type of patch that exists to remediate the vulnerability (Official Fix, Temporary Fix, Workaround, Unavailable) 
• Report confidence – a reflection of the level of confidence in the existence ofthat the vulnerability actually exists and the credibility of the technical details 

Environmental Metrics 

Just like Temporal metrics, Environmental metrics are recommended but not essential in generating a CVSS score and they must be defined by the end-user organization. 

This dimension of a CVSS score takes into account how severe the impact would be if a particular IT asset is compromised. Some assets may be of comparatively low importance, so the fallout is minimal if an attacker manages to gain full control of the asset. Other assets are business-critical and the organization may incur substantial financial damages if the asset is compromised. 

Generating A CVSS Base Score 

With all of the metrics above defined, the CVSS produces a base score on a scale from 0 to 10. After the quantitative score is given to a CVE, a qualitative label is assigned to make it easy to quickly communicate and understand the severity of a particular vulnerability. 

Challenges With CVSS 3.1 

There are a few major challenges with CVSS as it stands today. First and foremost, CVSS measures the technical severity of a vulnerability, not risk. This may seem like a minor point but, in fact, it is extremely important to make this distinction. In the FIRST organization’s own words, CVSS produces a score that measures “the intrinsic characteristics of a vulnerability which are constant over time and across user environments.”  

Recall that only the Base metrics components of CVSS are required to generate a score. The Base metrics are also the only part of CVSS that can be completed by any qualified professional (rather than the end-user organization that is trying to protect their networks, systems, and data).  

For these reasons, the organizations that maintain a public repository of documented vulnerabilities—e.g. the NIST National Vulnerability Database (NVD) or the MITRE Corporations CVE program—use CVSS to assign Base scores for every new vulnerability. All too often, the CVSS Base metrics score provided in these public databases is mistaken for an objective risk score. 

Moreover, because different people will use the CVSS in different ways and assign different scores or labels, the same vulnerability can be given inconsistent Base scores. Take CVE-2022-23720 for example: 

The vendor, Ping Identity Corporation, assigned the CVE a base score of 7.5 while the NIST team, gave it an 8.2. This may seem like a minor difference but it demonstrates how the subjective nature of CVSS can lead to inconsistencies. 

The FIRST team notes several other Challenges and Critique of CVSS v3.1 in a presentation introducing CVSS v4.0: 

• A lack of real-time threat intelligence data 

• Exclusive to IT systems (overlooking other environments, e.g. OT systems like SCADA and other industrial control systems) 
• Scores published by vendors skew high 
• Insufficient granularity (as there are only 99 discrete scores available) 
• Despite lacking granularity, CVSS can still feel overly complex and difficult to use 

All of these limitations were identified as areas for improvement with the new CVSS v4. 

A Summary Of Changes Coming In CVSS 4.0 

The initial draft of the CVSS 4.0 specification document was released on June 8, 2023 for review and comments from the information security community. The comment period closed on July 31, 2023, with FIRST aiming to address feedback and make revisions by August 31, 2023. The target date for official publication of CVSS v4 is October 1, 2023. 

While it is not yet finalized, the CVSS 4.0 specification document outlines a number of major changes to the framework. Here is an overview of the planned modifications and enhancements. 

New Nomenclature In CVSS v4 

One of the major adjustments coming in CVSS v4 is to the nomenclature of CVSS scores. To reinforce the concept that a Base score is not a complete assessment of a vulnerability’s severity, the following terms will be implemented: 

• CVSS-B = CVSS Base Score 
• CVSS-BT = CVSS Base + Threat Score 
• CVSS-BE = CVSS Base + Environmental Score 
• CVSS-BTE = CVSS Base + Threat + Environmental Score 

In other words, there will no longer be a single name for a CVSS score. Instead, there will be a specific term for the score indicating which metric groups were taken into account in generating that score. 

Applicability To OT, ICS, and IoT 

Another major change coming in CVSS 4.0 is the additional applicability to OT environments, industrial control systems, and IoT devices, such as medical devices. The increased applicability comes primarily from new Safety metrics, which we will discuss more below. 

Updates To Base Metrics 

As it was in CVSS v3.1, the Base Metric Group in CVSS v4 comprises two categories—the Exploitability sub-score and the Impact sub-score. There have been changes to both of these metric subcategories. 

The Exploitability sub-score now has a 5th metric: Attack Requirements. This  

The Impact sub-score now contains three new metrics to indicate the impact to additional IT systems if/when a specific vulnerability is exploited. In sum, the Impact metric group includes: 

• Confidentiality Impact to the Vulnerable System  
• Integrity Impact to the Vulnerable System 
• Availability Impact to the Vulnerable System 
• Confidentiality Impact to Subsequent Systems 
• Integrity Impact to Subsequent Systems 
• Availability Impact to Subsequent Systems 

Since the Impact Metric Group now covers the effect on both the vulnerable system itself as well as subsequent systems, there is no longer a need for the Scope metric. Thus, Scope was removed entirely from the CVSS. 

Lastly, the User Interaction metric was changed from a binary Yes or No to a more granular approach, which includes None (no user interaction required), Passive (some indirect user interaction required), and Active (direct user interaction required). 

Updates To Threat Metrics (formerly known as Temporal Metrics) 

The Temporal Metric Group was renamed to the Threat Metric Group. This metric has four options: 

• Not Defined – the metric is not set (e.g. because no data is available) 
• Attacked – the vulnerability is being targeted in the wild (regardless of whether the attack is successful)  
• Proof of Concept – a proof of concept demonstrating exploitation of the vulnerability is publicly available (regardless of who published the POC or what their intentions were) 
• Unreported – there is no threat intelligence knowledge that there is a POC available for the vulnerability or that the vulnerability has ever been targeted by threat actors in the wild 

Two metrics previously included in the Temporal Metric Group of CVSS 3.1 — Remediation Level and Report Confidence—have both been retired. They will not be included in CVSS 4.0. 

Updates To Environmental Metrics 

Just as in CVSS 3.1, the Environmental Metric Group in CVSS 4.0 must be set by the end-user organization.  

The main adjustment to Environmental metrics in CVSS v4 is the addition of a safety metric to indicate the impact on the physical safety of human beings if the vulnerability is exploited. This metric is primarily useful for OT environments.

As before, the Environmental Metric Group in CVSS v4 also allows end-user organizations to override and replace Base metrics set by the person or persons who first detected the vulnerability. 

Addition Of The Supplemental Metric Group 

A new metric group is added in CVSS 4.0: Supplemental metrics. They are as follows: 

• Safety – whether exploitation of the vulnerability will endanger the physical safety of humans  
• Automatable – whether exploitation of the vulnerability can be fully automated at scale  
• Provider Urgency – a score given by the vendor or manufacturer to indicate the urgency of remediating the vulnerability   
• Recovery – a measure of how quickly and to what extent a system will be able to recover if the vulnerability is exploited 
• Value Density – the level of resources the attacker will have access to when they exploit the vulnerability (Diffuse or Concentrated)  

• Vulnerable Response Effort – a score that reflects how much effort is required on the part of the defending organization to respond to and remediate a vulnerability 

The Supplemental metrics are optional and they may not apply to every vulnerability. 

The Importance Of Threat Intelligence In CVSS 4.0 

As the renaming of the Temporal Metric Group to Threat Metric Group would suggest, the new CVSS 4.0 framework places greater emphasis on threat intelligence. This is true for several reasons. 

To begin with, the threat landscape is constantly evolving. A known vulnerability may be relatively low risk one month, then represent a critical risk the next, all due to changes in threat actor behavior. A continuous source of real-time threat intel data is indispensable in evaluating the risk of a vulnerability. 

Furthermore, without threat intelligence, it is impossible to know whether a specific vulnerability has ever been exploited in the wild, whether a public POC exists, or whether exploitation can be automated. These are all essential considerations in determining how to prioritize patch and remediation efforts. 

Cyberint’s CVE Intel module is designed to provide impactful threat intelligence for each documented vulnerability. Using data collected from thousands of sources across the open, deep, and dark web, Cyberint can provide the following insights on each CVE:

• mentions on websites (e.g. independent security researchers, security vendors, etc.)
• mentions in threat actor forums or chat groups
• mentions in code repositories, which may indicate a public PoC of exploitation
• PoC code on vulnerability exploit repositories (e.g. exploit-db)
• confirmed exploitation of the CVE in the wild
• automated exploitation of the CVE at scale

All of these insights factor into the Cyberint score, which reflects the risk a CVE presents to an organization. The score helps organizations to understand the risk they face from outdated software in order to prioritize patch and remediation efforts, ensuring maximum efficiency of the resources dedicated to such efforts.

In the coming weeks, Cyberint will publish a second blog on CVSS 4.0 to discuss the need for threat intelligence in vulnerability scoring and prioritization in much greater detail. Stay tuned! 

The Upcoming CVSS v4 Framework

In the world of cybersecurity, there are no silver bullets. This is especially true when it comes to evaluating and quantifying cyber risk, particularly for the risk of a given vulnerability. These challenges exist for all InfoSec professionals, regardless of the size of their organization, their industry, or the exact configurations of their environment. 

The upcoming CVSS v4 framework will serve as a useful tool for cybersecurity experts around the globe, providing several major enhancements over the current v3.1. While challenges will of course still exist, CVSS 4.0 should be adopted by vulnerability and patch management leaders as soon as its available.