CVSS v4 is Almost Here – What You Need to Know

CVSS version 4 request for public comment officially opened on June 8th 2023. This new version of CVSS attempts to address a number of challenges and critiques from CVSS v3.1, released in June of 2019. CVSS v4 official publication is expected in Q4 of 2023.

Brief overview

The Common Vulnerability Scoring System (CVSS) is an open framework for communicating the characteristics and severity of software vulnerabilities. CVSS consists of three metric groups: Base, Temporal, and Environmental.

• The Base group represents the intrinsic qualities of a vulnerability that are constant over time and across user environments
• Temporal group reflects the characteristics of a vulnerability that change over time
• Environmental group represents the characteristics of a vulnerability that are unique to a user’s environment.

The Base metrics produce a score ranging from 0 to 10, which can then be modified by scoring the Temporal and Environmental metrics. A CVSS score is also represented as a vector string, a compressed textual representation of the values used to derive the score.

Pre-2005 – Prehistoric Times

• Vendors used custom, incompatible rating systems to define severity
• NIAC recognized a need to standardize vulnerability measurements across software and platforms

February 2005 – CVSS v1

• CVSS v1 was developed by a handful of “pioneers” with the aim of reaching wide industry adoption.
• Received little peer review before its release, and much criticism after its release
• Ambiguities in the metric definition made scoring and score interpretation hard.
• In April 2005, NIAC selected the Forum of Incident Response and Security Teams (FIRST) to become the custodian of CVSS for future development.

June 2007 – CVSS v2

• Over a dozen members of the CVSS-SIG collaborated extensively through 2006 and 2007 to revise and improve CVSS v1 by testing and re-testing hundreds of real-world vulnerabilities.
• Reduced inconsistencies, provides additional granularity, and more accurately reflected the wide variety of vulnerabilities (at the time).

June 2015 – CVSS v3.0

• Introduced the concept of “Scope” to handle the scoring of vulnerabilities that exist in one software component, but impact a separate software, hardware, or networking component.
• Also updated terms (Access → Attack), added Privilege

June 2019 – CVSS v3.1

• Clarified and improved upon version 3.0 without introducing new metrics or values
• Improved upon clarity of concepts to improve the overall ease of use of the standard
• Added the CVSS Extensions Framework and updated Glossary of Terms
• CVSS is designed to measure the severity of a vulnerability and should not be used alone to assess risk.

June 2022 – CVSS v4.0 – Request for Public Comment (until 7/31/23)

• Importance of using Threat Intelligence and Environmental metrics for accurate scoring 
• Operational Technology/Safety Metrics
• Supplemental Concepts of “Automatable”, “Recovery” and “Vulnerability Response Effort”
• Representation of provider-supplied Urgency within CVSS standard
• Active vs. Passive “User Interaction”
• “Attack Complexity” vs. “Attack Requirements”
• Nomenclature

CVSS v3.1 was no stranger to critiques, the following were the common challenges encountered when leveraging CVSS.

CVSS Base Score being used as primary input to risk analysis

The CVSS Base Score is indeed a key factor in determining the severity of a vulnerability. However, it shouldn’t be the sole determinant as it only considers technical aspects of the vulnerability, not taking into account business context, asset criticality, or threat landscape, which are equally important in a holistic risk analysis.

Not enough real time threat and supplemental impact details represented

This is a fair critique. The CVSS model does not account for real-time changes in the threat landscape, such as whether a particular vulnerability is being actively exploited in the wild. This information, which can greatly influence the risk profile of a vulnerability, is usually available from other sources.

Only applicable to I.T. systems

CVSS was indeed primarily designed for software and hardware IT systems. As such, it may not capture some specific nuances of non-IT systems or operational technologies, which can have different risk profiles and consequences if compromised.

Health, human safety, and industrial control systems not well represented

CVSS does not explicitly factor in the potential impact on human life or safety. In sectors where these factors are critical, like healthcare or industrial control systems, CVSS scores might not fully capture the severity of a vulnerability.

Scores published by vendors are often High or Critical (7.0+)

This can indeed be a problem if vendors overstate the severity of vulnerabilities, leading to alarm fatigue. However, this issue lies more with the vendor’s implementation of CVSS, rather than with the system itself.

Insufficient granularity – fewer than 99 discrete CVSS scores in practice

While CVSS offers a decimal-based scoring system, the practical usage often results in fewer discrete scores, limiting its granularity. A more granular system might offer better differentiation between vulnerabilities.

Temporal Metrics do not effectively impact the final CVSS score

Temporal metrics in CVSS, which include factors such as the current state of exploit and remediation level, indeed often have less weight in the final score. While their inclusion is important, their impact may not be as significant as desired.

The math seems overly complicated and counterintuitive

The CVSS scoring involves complex mathematical equations to ensure a balanced representation of various factors. For non-technical users, this complexity can be overwhelming and appear counterintuitive. Simplification, while maintaining accuracy, could potentially improve usability and understanding of the system.

Where did you come up with that formula?

This critique emphasizes the complexity and seemingly arbitrary nature of the CVSS scoring algorithm. The CVSS scoring system was developed by a diverse team of experts and is based on extensive research and analysis. While it may seem confusing, it is the product of a deliberate process to balance a variety of different factors in vulnerability scoring. Nevertheless, continuous improvement and simplification should always be sought.

To stress the idea that CVSS is not just a base score, new nomenclature has been adopted.

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

New Base Metric: Attack Requirements

Problem: The “low” and “high” AC values do not reflect the significant differences between conditions currently compressed in the definition of “high” complexity. For example, the evasion of security mitigation techniques such as ASLR or crypto objectively require significantly higher exploit complexity than iterating an attack to win a race condition; yet both conditions currently result in the same “penalty” to the final severity score.

Solution: CVSS v4 current proposal aims at addressing this by splitting the current AC definition in two metrics, called “Attack Complexity” (AC) and “Attack Requirements” (AT) that respectively convey the following:

• Attack Complexity – Reflect the exploit engineering complexity required to evade or circumvent defensive or security-enhancing technologies. (defensive measures)
• Attack Requirements – Reflect the prerequisite conditions of the vulnerable component that make the attack possible.

Updated Base Metric: User Interaction

Allow for additional granularity when considering the interaction of a user with a vulnerable component, and details are as follows:

• None (N): The vulnerable system can be exploited without interaction from any human user, other than the attacker.
• Passive (P): Successful exploitation of this vulnerability requires limited interaction by the targeted user with the vulnerable component and the attacker’s payload. These interactions would be considered involuntary and do not require that the user actively subvert protections built into the vulnerable component.
• Active (A): Successful exploitation of this vulnerability requires a targeted user to perform specific, conscious interactions with the vulnerable component and the attacker’s payload, or the user’s interactions would actively subvert protection mechanisms which would lead to exploitation of the vulnerability

Retired Base Metric: Scope

Problem: Scope may have been the least loved and least understood CVSS metric ever.

• Caused inconsistent scoring between product providers
• Implied “lossy compression” of impacts of vulnerable and impacted systems

Solution: Impact Metrics expanded into two sets:

• Vulnerable System Confidentiality (VC), Integrity (VI), Availability (VA)
• Subsequent System(s) Confidentiality (SC), Integrity (SI), Availability (SA)
• “Modified” Environmental Metrics updated accordingly

Temporal → Threat Metric Group

Problem: Unnecessarily complex threat metrics 

Solution: Remediation Level, Report Confidence, and Exploit Code Maturity simplified to Exploit Maturity.

• Remediation Level (usually O) and Report Confidence (usually C) retired
• Exploit Code Maturity renamed Exploit Maturity
• Enhanced impact for Threat Metric values
• Adjusts “reasonable worst case” Base score by using threat intelligence to reduce the CVSS-BTE score, addressing concerns that many CVSS (Base) scores are too high.

Supplemental Metrics provide the ability to define new metrics that describe and measure additional extrinsic attributes of a vulnerability. The information consumer can then use the values of these Supplemental Metrics to take additional actions if they so choose, applying locally significant importance to the metrics and values. 

No metric will define numerical impact on the final calculated CVSS score (e.g., CVSS-BTE). Organizations may then assign importance and/or effective impact of each metric, or set/combination of metrics, giving them more, less, or absolutely no effect on the final risk analysis. Metrics and values will simply convey additional extrinsic characteristics of the vulnerability itself.

Note: All Supplemental Metrics supplied by the information provider are optional.

• Supplemental Metric: Automatable
• Supplemental Metric: Recovery
• Supplemental Metric: Value Density
• Supplemental Metric: Vulnerability Response Effort
• Supplemental Metric: Provider Urgency

Supplemental Metric: Automatable

The “Automatable” metric captures the answer to the question ”Can an attacker automate exploitation of this vulnerability across multiple targets?” based on steps 1-4 of the kill chain: reconnaissance, weaponization, delivery, and exploitation.

No – Attackers cannot reliably automate all steps of the kill chain for this vulnerability (reconnaissance, weaponization, delivery, and exploitation). 

1. The vulnerable component is not searchable or enumerable 
2. Weaponization requires human direction for each target 
3. Delivery uses channels that network security configurations block 
4. Exploitation is not reliable, due to exploit-prevention techniques enabled by default 

Yes  – Attackers can reliably automate all steps of the kill chain (reconnaissance, weaponization, delivery, and exploitation). 

• As one heuristic for yes, if the vulnerability allows unauthenticated remote code execution or command injection, the expected response is yes. 
• Analysts should provide an argument or demonstration that all four steps are able to be automated rather than solely relying on heuristics.

Supplemental Metric: Recovery

This metric describes the resilience of a Component/System to recover services, in terms of performance and availability, after an attack has been performed.

• Automatic (A): The Component/System recovers automatically after an attack. 
• User (U): The Component/System requires manual intervention by the user to recover services, after an attack. 
• Irrecoverable (I): The Component/System is irrecoverable by the user, after an attack.

Supplemental Metric: Value Density

Value Density describes the resources that the attacker will gain control over with a single exploitation event. It has two possible values, diffuse and concentrated.

• Diffuse: The system that contains the vulnerable component has limited resources. That is, the resources that the attacker will gain control over with a single exploitation event are relatively small. 
• Concentrated: The system that contains the vulnerable component is rich in resources. Heuristically, such systems are often the direct responsibility of “system operators” rather than users

Supplemental Metric: Vulnerability Response Effort

Provides supplemental information on how difficult it is for consumers to provide an initial response to the impact of vulnerabilities for deployed products and services in their infrastructure. 

The consumer can then take this additional information on effort required into consideration when applying mitigations and/or scheduling remediation.

• Low (L) – The effort required to respond to a vulnerability is low/trivial. 
• Moderate (M) – The actions required to respond to a vulnerability require some effort on behalf of the consumer and could cause minimal service impact to implement. 
• High (H) – The actions required to respond to a vulnerability are significant and/or difficult, and may possibly lead to an extended, scheduled service impact. Alternately, response to the vulnerability in the field is not possible remotely. The only resolution to the vulnerability involves physical replacement.

Supplemental Metric: Provider Urgency

To facilitate a standardized method to incorporate additional provider-supplied assessment, an optional “pass-through” Supplemental Metric called Provider Urgency has been defined. 

While any provider along the product supply chain may provide a Supplemental Urgency rating:

Library Maintainer → OS/Distro Maintainer → Provider 1 … Provider n (PPP) → Consumer

The Penultimate Product Provider (PPP) is best positioned to provide a direct assessment of Urgency.

• Red: Provider has assessed the impact of this vulnerability as having the highest urgency 
• Amber: Provider has assessed the impact of this vulnerability as having a moderate urgency 
• Green: Provider has assessed the impact of this vulnerability as having a reduced urgency 
• Clear: Provider has assessed the impact of this vulnerability as having low or no urgency (Informational)

Many vulnerabilities today have impacts outside of the traditional C/I/A triad of logical impacts. Increasingly more common is a concern that, while logical impacts may or may not be recognized on a vulnerable or impacted system, it is possible for tangible harm to occur to humans as a result of a vulnerability exploit. 

IoT, ICS and healthcare sectors in particular care greatly about being able to identify this kind of impact as part of the CVSS specification to help drive prioritization of issues aligned with their growing concerns.

OT: Consumer Supplied Environmental Safety

When a system does not have an intended use or fitness of purpose aligned directly to safety but may have safety implications as a matter of how or where it is deployed, it is possible that exploiting a vulnerability within that system may have safety impact(s) which can be represented in the Environmental Metrics group. 

The Safety metric value measures the impact regarding the Safety of a human actor or participant that can be predictably injured as a result of the vulnerability being exploited. Unlike other impact metric values, Safety can only be associated to the Subsequent System(s) impact set and should be considered in addition to the N/L/H impact values for Availability and Integrity metrics.

OT: Consumer Supplied Environmental Safety

Modified Integrity of Subsequent System: Safety (MSI:S)

Successful exploitation compromises the integrity of the vulnerable system (such as changing the dosage for a medication infusion pump), resulting in an impact to human health and safety (injury).

Modified Availability of Subsequent System: Safety (MSA: S)

Successful exploitation compromises the availability of the vulnerable system (such as a brake system in a car becoming unavailable), resulting in an impact to human health and safety (injury).

OT: Provider Supplied Supplemental Safety

When a system does have an intended use or fitness of purpose aligned to safety, it is possible that exploiting a vulnerability within that system may have Safety impact which can be represented in the Supplemental Metrics group. 

The possible values for the Safety Supplemental Metric are as follows: 

• Present (P): Consequences of the vulnerability meet definition of IEC 61508 consequence categories of “marginal,” “critical,” or “catastrophic.” 
• Negligible (N): Consequences of the vulnerability meet definition of IEC 61508 consequence category “negligible.” 
• Not Defined (X): The value of this metric has not been defined for this vulnerability.

Note: Providers are not required to supply Supplemental Metrics. They can be supplied as needed, based solely on what the provider chooses to convey on a case-by-case basis.

• Use metric groups to gather 15 million CVSS vectors into 271 equivalence sets
• Solicit expert opinion to compare vectors representing each equivalence set
• Calculate the order of vectors from least severe to most severe
• Determine boundaries between Qualitative Severity Ratings compatible with qualitative severity boundaries from CVSS v3.x.
• Compress the vector groups in each qualitative severity bin into the number of available scores in that bin (for example, 9.0 to 10.0 for critical, 7.0 to 8.9 for high, etc.)
• Leverage interpolation to adjust scores within a vector group to ensure changes in any metric value results in a score change.

CVSS Base scores (CVSS-B) represent “Technical Severity”  

• Only takes into consideration the attributes of the vulnerability itself
• It is not recommended to use this alone to determine remediation priority 

“Risk” is often a religious topic, CVSS-BTE scores take into consideration the attributes of the:

• Base Score  
• Threat associated with the vulnerability  
• Environmental controls / Criticality 

If used properly, CVSS-BTE scores represent more comprehensive attributes than many highly respected 3rd party security organizations consider when they generate their proprietary “Risk” ratings.

Additional scoring systems have been recently introduced and adopted to handle complementary aspects of vulnerability assessment and patch priority. These are welcome additions to the vulnerability scoring toolbox, providing innovative exploit prediction and decision support.  

• EPSS: Exploit Prediction Scoring System A data-driven effort for estimating the likelihood (probability) that a software vulnerability will be exploited in the wild within 30 days.  
• SSVC: Stakeholder-Specific Vulnerability Categorization A decision tree system for prioritizing actions during vulnerability management.

Use databases and data feeds to automate the enrichment of your vulnerability data.

• NVD (Base Metric Values)
• Asset Management Database (Environmental Metric Values)
• Threat Intelligence Data (Threat Metric Values)

Find ways to view your vulnerability data based on important attributes

• Support Teams Responsible for Resolution
• Critical Applications
• Internal vs. Externally facing
• Business Units
• Regulatory Requirements

Credit: Dave Dugal

How does VULNERA leverage CVSS? We pick apart the different elements of the CVSS score, and enrich CVSS vulnerability data with with asset management and threat intelligence data, just as recommended by the publishers of CVSS. This turns into the VULNERA VSCORE, a risk score calculated unique to every instance of every vulnerability across every asset of the organization.

Vulnerability prioritization requires multiple risk and scoring metrics to add context, at VULNERA, we leverage our integrated threat and vulnerabilities intelligence to add that context, identifying real-world risk attributes such as the availability of public exploits, difficulty of exploitation, active exploitation, etc. VULNERA enriches vulnerabilities to identify risk, and cross-references with asset criticality levels for the organization, identifying the most critical issues that need to be addressed on the most critical assets.