Will CVSS 4.0 be a vulnerability-scoring breakthrough or is it broken?

Anyone in cybersecurity who has had to deal with vulnerabilities in technology systems has inevitably run into the Common Vulnerability Scoring System (CVSS). Whether or not the name is instantly recognizable, phrases determining vulnerabilities as "critical" or "high" or the like resonate across the industry. CVSS has been used to provide a standardized method to discuss the characteristics of a vulnerability and ultimately produce a numerical score to reflect its severity as well as a qualitative metric (low, medium, or high) to provide a relative gauge for organizations managing vulnerabilities in their systems and environments.

The system has existed since 2005 and achieved widespread adoption and has become the definitive vulnerability scoring system utilized by the NIST National Vulnerability Database (NVD). It has been leveraged by leading vulnerability management tooling and vendors.

CVSS is evolving in the face of criticism

Despite widespread adoption, CVSS has faced several strong critiques: Its scoring approach is complex, it's too subjective, and it's widely misused for vulnerability prioritization. That said, the CVSS Special Interest Group (CVSS SIG) run by the global cybersecurity forum FIRST has continued to innovate upon the CVSS framework and is on the cusp of releasing CVSS 4.0.

Set for official publication on October 1, 2023, CVSS 4.0 has begun a public preview and comment period. Understanding the update's key aspects -- what it looks to address, and some of the remaining gaps or challenges that still leave some practitioners skeptical of its use and value -- is helpful in determining whether it will be a vulnerability-scoring breakthrough or a broken system that may need to be rethought.

Earlier in 2023, industry leaders Dave Dugal and Dale Rich, who co-lead the CVSS SIG, gave a talk that covered key items such as the chronology of CVSS, challenges that emerged in CVSS 3.0, and the goals of CVSS 4.0. Dugal and Rich stressed that CVSS is much more than a base score repository and emphasized that the more metrics used to enrich CVSS scoring, the higher its quality. To help alleviate the challenge of widespread use of only the CVSS base score and the underutilization of additional metrics in vulnerability calculations, CVSS 4.0 will introduce the use of new nomenclatures, such as:

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

Key CVSS changes will include new and revised nomenclature

Other key changes will include the introduction of a new base metric titled Attack Requirements (AT), an update to the User Interaction (UI) metric, and retiring the Scope (S) base metric. Most notably, the longstanding "Temporal" metric has now been renamed to "Threat", retiring the Remediation Level (RL) and Report Confidence (RC) metrics and renaming Exploit Code Maturity to Exploit Maturity, in recognition that not all exploits are code oriented.

A Supplemental metric group will also be added to account for additional extrinsic attributes of the vulnerability and empower downstream consumers and organizations to apply locally significant context (for example, business criticality, data sensitivity, and mitigating controls) in addition to the supplemental metrics to best prioritize for their unique environment and circumstances.

A comprehensive view of the metric groups and their associated metrics and changes from CVSS 3.1 to 4.0 is visualized below, by security researcher Patrick Garrity of Vulnerability Management company Nucleus Security:

Patrick Garrit/Nucleus

The Supplemental group will include new metrics

It is worth noting that only the base metric will be populated in sources such as NVD, as it always has been and it will be up to the CVSS consumer (meaning organizations) to apply additional metrics, such as the Threat Metric, Exploit Maturity, or Environmental and Supplemental metrics to further refine scoring and prioritization.

Given that the Supplemental metric group is entirely new, we should take a few moments to unpack it and the associated metrics. These include: Automatable, Recovery, Safety, Value Density, Vulnerability Response Effort, and Provider Urgency.

The Automatable measure examines whether the exploitation can be automated across several targets, which can aid prioritization and severity considerations since such exploits can allow malicious actors to rapidly expand their attack efforts. Recovery is a recognition that some systems may be able to recover automatically, while others may require user intervention or be entirely unrecoverable. Safety is the acknowledgement that systems are increasingly becoming cyber-physical and have the potential to impact the safety of human life.

Value density is specifically organizationally relevant because it represents the resources the system has access to or possesses, such as Limited or Expansive, with regard to the organization. Not all vulnerability exploitation has the same level of effort with regard to response, and that is where Response Effort comes into play. Lastly, Provider Urgency enables consumers to integrate vendor and provider-specific context on how urgent it is to address a vulnerability in a specific product or service.

Remaining challenges for CVSS 4.0

While CVSS 4.0 brings several improvements and changes to the metric groups and addresses some long-standing issues, challenges remain. One of the largest problems, and the elephant in the room, is that while CVSS may recommend using more than the base metrics for maximum efficacy, those are ultimately what are populated in sources such as the NVD, with the other metric groups left to be parsed by downstream consumers.

We know base metrics alone aren't sufficient to conduct vulnerability prioritization, and additional factors such as environmental or business context and actual exploitation and exploitability of a vulnerability are key as well.

On the exploited front, sources have emerged, such as the US Cybersecurity and Infrastructure Security (CISA) Known Exploited Vulnerabilities catalog, which is directed to federal agencies but useful for commercial organizations as well. Additionally, and ironically, there is also the Exploit Prediction Scoring System (EPSS), which is starting to get industry traction and is also led by FIRST although by a different special interest group. There is overlap between the two groups, with researchers such as Sasha Romanosky contributing to both CVSS and EPSS.

CVSS not broken, but perhaps incomplete

With several of the metric groups left to downstream CVSS consumers and organizations to populate with their own organization-specific context, it leaves a lot of work to be done to come up with accurate vulnerability prioritization scoring and actions. This wouldn't be so bad if it wasn't for the fact that studies are showing many organizations are dealing with vulnerability backlogs into the hundreds of thousands and struggling to keep up with the ever-increasing rate of vulnerabilities being discovered and disclosed.

This is much more of an industry-wide problem than a specific CVSS critique, but it does show how CVSS on its own isn't inherently sufficient for vulnerability prioritization, especially when coupled with previous critiques around the complexity and opacity of its scoring methodology.

The unfortunate reality is that in an industry that is often led by marketing hype and promises of silver bullets, there isn't one. No vulnerability scoring system on its own, without being enriched with organization-specific context coupled with accurate coverage of the existing threat landscape will be a panacea for vulnerability prioritization as part of vulnerability management.

That said, CVSS 4.0 does offer some improvements and promising innovations in cloud-native technologies, APIs, and even AI do offer promise for further automation and efficiency that we haven't been able to achieve historically. However, we aren't there quite yet, and organizations need to do the hard work of applying their specific context and circumstances to properly prioritize vulnerabilities, as well as leverage the evolving landscape of vulnerability databases such as NVD, OSS Index, Global Security Database, and GitHub Security Advisories, just to name a few.