List of Potential Future CVSS Improvements for CVSS v4.0

Last updated: 2019-06-09

A list of potential improvements targeted at CVSS 4.0 has been created based on input and feedback from various sources.

Dates are in ISO 8601 format, i.e., YYYY-MM-DD or YYYY-MM.

Distinguish attacks available only on specific networks (VPN)

Explore adding a metric value to Attack Vector to distinguish attacks that are exploitable only on specific networks, e.g., within a corporate intranet, versus anywhere on the Internet.

Improve measurement of Exploitability and Exploit Code Maturity to reflect the potential of a vulnerability being exploited

Ideas include:

Measure physical outcome of an exploited vulnerability

Measure whether a successful exploit can cause physical damage and/or harm to living beings. Max Heitman uses the term "kinetic impact". People working with medical device vulnerabilities would like to see the addition of a measurement like this.

Measure up-stream and/or down-stream impacts

Explore a new metric to measure the direct up and down stream impact of an impacted component, perhaps restoring some aspects of Collateral Damage Potential from CVSS v2.0 to Environmental Impacts. Alternatively, maybe Asset Value, or "Safety" is better. Target Distribution metrics may take us into "risk assessment" territory, but that is severity on a meaningful scale, the specific severity of one single instance of a vulnerability on one system is academic.

Change the Exploit Code Maturity metric so that the Not Defined value is the same as Unproven, not High

For RC and RL one assumes a valid report and no remediation available and the Temporal score lowers if report confidence drops or a fix becomes available.

For E, current and proposed measurement is for any vulnerability by default (ND) to assume the equivalent of High exploitability and lower the Temporal score if exploitability found to be less than High.

While this is a safe/conservative approach, it seems to me to be inverted. Most vulnerabilities are not exploited, that is to say there is no evidence of exploitation. Those that are exploited (or are likely to be) stand out as much higher priority to address. So I'd suggest that the default (ND) for E to be equivalent to U, and evidence of exploitation should raise the Temporal score.

Replace the Exploitability metric with a new metric named "Likelihood of Attack"

Art Manion sent an email to the CVSS list on 2015-03-16, with a Word document explaining the new "Likelihood of Attack" metric. See LikelihoodOfAttack.docx for details.

Move the Exploitability metric to the Base Metrics and remove the remaining Temporal Metrics

Seth Hanford sent the following email to Max Heitman on 2015-09-17 detailing his previous suggestion:

IMO, exploitability is something that could be measured in base. The other metrics don’t really matter.

If you did that, you could simplify things a lot. Temporal existed because there was a push for “things the vendor can track and update” and “things that other people will track and pay attention to” and in reality, that seems to have not really panned out.

The major downside to this is that exploitability becomes something that vendors have to track / assign. It also would push people to keep scores updated / need to have some source of authoritative scores. I’m not sure that’s bad, but I can see it being a topic of some resistance. Additionally, a move like this would probably be best done with some consideration to whether or not CVSS should really be tracking exploitability. Does it make sense to track something which isn’t about Severity, but is more about Urgency?

People use CVSS to prioritize, but we’ve headed more in the direction of describing vulnerability potential energy or vulnerability capability. Still, with hundreds of vulns out there, some of the most effective measurement is “Is there a metasploit module?” and if so, you can patch. So… that makes a fairly strong argument for tracking some kind of exploitability. That said, should it simply be “is this being exploited in the wild or in an exploit automation / framework?” in which case it could be a binary decision.

Re-introduce the Collateral Damage and Target Distribution metrics

Garret Wassermann added the following on 2015-09-18:

Collateral Damage (CDP) might be good to reintroduce, and could be tweaked/renamed to be a "Safety" (S) metric. I think this will be important as we see more car and medical device vulns in the wild. The vuln itself doesn't directly hurt people (only abuses the software/system), but may result in human injury. It strikes me as something important to include to boost the score to Critical territory whenever human injury/life is involved, even if the vuln is on its own pretty weak. This might be a good modifier in the Environmental metrics, or perhaps it should even be part of the Base metrics.

Target Distribution (TD) ("how widely deployed is this") also seems good to add back. After working some scores internally at the CERT/CC, the CVSSv3.0 Environmental metric in practice does not provide much additional information and seems to degenerate to just copying the same content from the Base metrics. To be more useful, the Environmental metric should include some unique metrics. Having TD for the Internet or within an organization seems useful for modulating a score and helping to prioritize.

Art Manion edited the wiki on 2016-04-18 to add the following comment. It has been moved from the list of topics to here:

TD does get in to "risk assessment" territory, but that is severity on a meaningful scale, the specific severity of one single instance of a vulnerability on one system is academic. Another possible new vector, even more down the risk assessment path, would be something like "asset value."

Integrate CWSS metrics into current CVSS metrics (ITU proposal from Iran)

As part of the ITU standards process for CVSS v3.0, Iran submitted contribution T13-SG17-C-0541!!MSW-E.docx. It makes several suggestions, including the incorporation of Common Weakness Scoring System (CWSS) metrics into CVSS.

Add a way to baseline a set of vulnerabilities to the underlying component so their severity can be compared

Chris Betz verbally suggested, during the CVSS SIG meeting held on 2016-03-10, that CVSS provides a way to score vulnerabilities relative to an underlying component. This was the way all vulnerabilities were scored under CVSS v2.0, but the addition of Scope in CVSS v3.0 means we now score relative to vulnerable & impacted components. This makes it hard to compare vulnerabilities with different vulnerable & impacted components. Adding a way to score the impact a set of vulnerabilities on an underlying component they all share, such as an operating system, allows their severities relative to one another to be determined.

Art Manion writes: An example of this, in Microsoft terms, is IE on "workstation" vs. IE on server. The same vulnerability in IE has significantly different severity due to differences in platform (default configurations of IE). Could be thought of as scoring CVSS on a combination of (CVE + CPE) instead of just a CVE.

Distinguish Active versus Passive User Interaction

During the CVSS SIG meeting held 2016-03-30, Chuck Wergin suggested adding an additional metric value to User Interaction to capture whether a victim needs to actively participate in the attack. A couple of examples not discussed at the meeting but included here in an attempt to clarify:

The User Interaction metric could have values None, Passive and Active, with None resulting in the highest Base Score.

Add a concept of "survivability"

Bruce Monroe emailed the list on 2016-01-22 and made the following suggestion:

The only thing remaining that would enable us to replace our internally developed scoring solution we use for products in development would be baking in the concept of "survivability". Namely how hard is it to mitigate issues in the field? (Documentation, Remote Patch - Easy, Remote Patch - Hard, Recall). I'm hoping to see that in the next iteration of CVSS V3.

Add a metric for "Wormability"

During the CVSS SIG meeting held 2016-03-03, it was suggested that we could add a metric to indicate if a vulnerability could be exploited via a worm, the justification being that we are more likely to see attacks for such vulnerabilities, so they present a more severe threat.

Add Threat Intelligence metric to Temporal Metrics

During the CVSS SIG meeting held 2016-04-28, Dale Rich suggested adding a metric allowing threat intelligence information to be included as a Temporal metric, if such information is available.

During the CVSS SIG meeting held 2016-09-08, Dale Rich suggested the metric could allow a scorer who has access to a thread intelligence feed that rates vulnerabilities on a 5-point scale to include this metric in the Temporal metric group. The scale ranges from no attacks taking place to lots of attacks being seen (and/or exploits being included in many exploit and malware kits).

Art Manion: Strongly agree. Would cover "wormability" issue above, mild suggestions for "Threat" vs "Threat Intelligence" and consider an even number of slots if possible (e.g., 4 point scale).

Review how CVSS can better reflect the risk of a vulnerability being exploited

Sasha Romanosky sent the following in an email on 2016-04-28, which was briefly discussed during the CVSS SIG meeting:

First, I’ve been corresponding with a fellow who used to run the Verizon DBIRs. He has since left, but I was asking him about the claim that 85% of the breaches were caused by something like 10 different vulnerabilities. He mentioned that this claim came not from Verizon data, but from another company who was able to analyze network traffic. The fellow who did that analysis is Michael Roytman, and I’ll be talking to him today before our call. I wanted to just [chat] with him to get a better understanding of what they have and don’t have. Now, in addition to doing that work, he also had some harsh words for cvss. Specifically, he suggests that using cvss as strategy to fix vulnerabilities is a bad way to go because those vulns which are actively exploited (and which therefore pose the greatest risk), are not necessarily those scored as a 10. [Fair point, and my reaction to the claim is that, “fine, this isn’t exactly the point of cvss anyhow.”] His short paper is available at . Second, I understand that the most recent DBIR has just come out. And with it, OSVDB’s hating on it. Their comments are here, , and it does identify these most common vulns, which aren’t necessarily the ones we’d expect. Some of these are fair points, but mostly it’s funny to hear different people just wanting to get mad at other people.

Remediation Level: Add a way to track the source of vulnerability information

Add a way to track the source of vulnerability information, especially for Temporal metrics. For example, was threat intelligence information released by the product vendor?

This information would probably not form part of the CVSS score or Vector String.

Bring back Target Distribution

CVSS v2 had an Environmental Metric called Target Distribution used to measure the proportion of vulnerable systems, represented as an environment-specific indicator in order to approximate the percentage of systems that could be affected by the vulnerability. This metric was removed in CVSS v3, and while most/all scoring providers (read: vendors) never published Target Distribution, some scoring consumers and coordination centers used it regularly.

v3 Environment is focused on the specific instance/target (e.g., modified base scores, security requirements, database server A holding cafeteria menu vs. same database server software, different instance (server B), holding credit cards). Entire network environment vs. local single machine/group environment.

Publish a Risk Analysis BCP document

CVSS is exclusively a measurement of the severity of a vulnerability. However, many new incident response teams struggle with how to use the CVSS score as input to an overall risk assessment. Many mature (P)SIRTs have well-worn models for taking CVSS, along with Exposure and Threat, and calculating a Risk score. While outside the scope of CVSS, it may be very helpful for new consumers of CVSS to have a SIG-approved Best Current Practices (BCP) document on some ways organizations use CVSS as an input to risk analysis. Furthermore, this may also address criticism over how CVSS is "insufficient" in scoring the realized impact of vulnerabilities, since many critics are still trying to morph CVSS into a risk calculator without taking into account other attributes of the vulnerability or environment.

Review scoring for vulnerabilities with impacts to Vulnerable Component and Impacted Component

Under the CVSS v3.0 guidance, a vulnerability that has impacts to both the Vulnerable Component and the Impacted Component is scored with Scope = Changed, and the impact metrics are based on the component that will lead to the highest impact. The concern is that, based purely on CVSS information, it is impossible to determine which component the impacts belong to. Adam Maris provided more detail in an email he sent 2018-09-17:

At the beginning, I interpreted CVSS as an attack scenario from which I could reliably to a certain degree figure out the attacker, the means to attack the vulnerable component and the impact it produces. This was one of the stumbling stones where I realized some time ago this doesn't work the way I expected. From this resulting score, I cannot interpret much because it describes non-existent attack scenario, i.e. the impact doesn't correspond to Scope metric. Imagine the exploit vectors would be different as well, that's even more confusing.

I would rather have two CVSS vectors (or more if needed), one with S:C and one with S:U that would describe the actual characteristics of the exploitation without any surprises.

Revisit Vulnerability Chaining guidance

Recommendations and an example for scoring a sequence of vulnerabilities are included in the CVSS v3.0 User Guide, but these could benefit from clearer guidance on how to calculate a score for the chain as a whole. On 2018-10-01, Bruce Monroe mailed the list with a link to an attack on Facebook constructed from three vulnerabilities that could serve as a useful example for discussion:

Alternatively, some of the "Pwn2Own" type hacking contests are typically won with attacks based on chained vulnerabilities, providing another source of potentially useful examples. Several SIG members contributed to the email thread started by Bruce, recorded in VulnChainingThread1.pdf and VulnChainingThread2.pdf.

Exploit Code Maturity formula/constants

ECM has too little impact on the overall score.

Review definitions in User Guide glossary

The following comments were made by Art Manion during voting of v3.1 glossary in an email sent on 2019-04-23, but we did not have time to discuss or incorporate by v3.1 deadline, so they are being carried forward to v4.0:

Impacted, Exploitable, and Affected all run together. If we're going to use all three terms with specific meanings, we also need to clearly define the relationships between all three terms. May need to add "vulnerable/vulnerability" to that list.

"Impacted Component" is important because of Scope, possibly different than "Vulnerable Component."

"Affected" and "Vulnerable" seem to mean the same things.

"Vulnerability" still lists a number of options, we probably shouldn't ship that just yet. And do we also really need "Weakness?"

Backwards compatibility with CVSS v3.x

Dave Dugal made a comment in an email sent 2019-05-02 that CVSS v4.0 could include "some sort of lossy backward compatibility with CVSS v3.x", i.e., a programmatically defined and approved way to map v3.x to v4.0. This would ease the transition between CVSS versions.

He added "There has always been sidebar discussion about how one might score a vulnerability with incomplete information. If this were taken on as a v4.0 work item, we could conceivably consider a pre-v4.0 score as 'incomplete', applying Not Defined (X) multipliers as applicable."