In this blog post, we will highlight Snyk’s view on the new vulnerability scoring framework, CVSS 4.0, which was released on November 1, 2023.

Why was it necessary?

The revised framework emerges as an inherent progression in the landscape of cybersecurity vulnerabilities and as a solution to overcome soft spots in the previous methodology. Since its release in 2016, CVSS 3 has proved to be a robust assessment tool used by professionals to depict the potential impact and risk level of various vulnerabilities, thereby helping organizations and individuals to protect themselves against cyber threats better.

Seven years later, CVSS 4.0 is the next iteration, which aims to provide better granularity and further refine the scoring methodology to better suit the evolving dynamics of cybersecurity threats and the digital landscape.

What will change?

Let’s analyze the changes that will be introduced by performing a technical comparison between the 3.1 and 4.0 frameworks.

Note: The score severity levels/ranges (Low, Medium, High, and Critical) for each qualitative severity value will remain the same.

Attack Vector parameter

The new Attack Vector parameter, apart from incorporating a few semantic changes that imply a more inclusive specification (e.g. component vs system, or physical vs proximity), will achieve the same purpose as before.

Therefore, we do not expect any changes in how this parameter will be used when assessing vulnerabilities with CVSS 4.0.

Attack Complexity parameter

CVSS 3.1 Attack Complexity parameter will be split into Attack Complexity and Attack Requirements to allow more granularity.

The newAttack Complexity parameter is designed to be used on highly specialized attacks that involve “evasion or circumvention of security-enhancing techniques”.

Attack Requirements, on the other hand, will cover cases where successful exploitation “depends on the presence of specific deployment and execution conditions of the vulnerable system that enable the attack.”

The main distinctionbetween Attack Complexity and Attack Requirements will derive from the purpose of the specific conditions that enable the attack. According to the specification document, the Attack Requirements will be used only to capture scenarios that are NOT covered by the new Attack Complexity parameter (aka not to be used for scenarios that circumvent exploit mitigation techniques).

Within the open source ecosystem, we do expect lower usage of this parameter since Attack Complexity will only be used for highly specialized attacks. Attack Requirements, however, will probably see higher usage as it will encapsulate conditions that “emerge naturally as a consequence of the deployment and execution of the vulnerable system.”

Privileges Required parameter

The new Privileges Required parameter only incorporates small changes that aim to offer more clarity and provide more concise wording. The parameter’s value also remains unchanged.

We anticipate there will be no changes in the way this parameter is used for assessing vulnerabilities.

User Interaction parameter

Notable changes can be observed in the CVSS 4.0 specification document for the new User Interaction parameter — or, more specifically, its values. This will contribute to a more precise assessment of attack conditions.

User Interaction will have 3 possible values (as opposed to 2 in CVSS 3.1).

None — This value includes an improved definition by emphasizing the human user. Therefore, this value can be engaged whenever “the vulnerable system can be exploited without interaction from any human user, other than the attacker.”
Passive — The intended usage covers attacks that can be carried out through involuntary actions taken by the victim.
Active — Contrary to the previous case, this value will be used whenever the attack depends on the victim “to perform specific, conscious interactions with the vulnerable system and the attacker’s payload.” Alternatively, the victim’s “interactions would actively subvert protection mechanisms, leading to exploitation of the vulnerability.”

These additions will facilitate a better distribution of vulnerability severity by replacing the old User Interaction values. Therefore, the usage of this parameter in the vulnerability assessment process will change.

CIA triad

There are no notable modifications in the CIA triad other than small rephrasings, which aim to maintain consistency across the specification document definitions.

The usage of these parameters will most likely remain unchanged.

Scope parameter

Scope parameter will be replaced by Subsequent System Impact Metrics, which will favor a more even severity distribution while providing more accuracy when assessing the impact of a vulnerability.

This change will not only parameterize the change in scope but also pinpoint the consequences on the subsequent system.

The new approach will change the vulnerability assessment process while providing a more precise way to evaluate the impact.

Threat Metrics

Notable changes are present in the Threat Metrics (previously known as Temporal Score) as well, but we will go over only the Exploit Code Maturity. This parameter will be renamed Exploit Maturity and will contain four possible values (as opposed to five, the Functional value will be removed). The new definitions for the Exploit Maturity values have been improved and now include specific requirements that must be met to justify the usage.

Not Defined — The value should be used when “reliable threat intelligence is not available to determine Exploit Maturity characteristics.”

Attacked (previously High) — The value can be engaged whenever 1) attacks have been reported or 2) the exploit has reached a level of maturity that allows it to be integrated into various solutions, such as exploit kits, which aim to simplify and automate the exploitation.

PoC — Should be used whenever one of the requirements applies:

“Proof-of-concept is publicly available.”
“No knowledge of reported attempts to exploit this vulnerability.”
“No knowledge of publicly available solutions used to simplify attempts to exploit the vulnerability.”

Unreported — neither PoC nor Attacked,but different from Not Defined (use case is for scenarios where threat intel is available).

These changes will modify the usage of the Exploit Maturity parameter.

How will the changes affect users?

In addition to what the previous section highlighted, we will review three vulnerability examples and attempt to provide an assessment with CVSS 4.0 while explaining the process.

Remote Code Execution affecting microsoft.chakracore package, version 1.10.1

CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H — 7.5 High
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:L/SI:L/SA:L — 7.6 High

The attack can be carried out over the network, hence AV:N. According to the spec, AC:H shall be used whenever bypassing protections such as ASLR. Given the available information for this vulnerability, we believe it would fall under this scenario. There is no indication for either Low or High privilege prerequisites, therefore PR:N. Successful exploitation depends on the existence of another human user. However, there is insufficient evidence that the user would need to engage with the attacker’s payload actively, therefore UI:P. Given that “an attacker who successfully exploited the vulnerability could take control of an affected system”, both confidentiality and integrity are affected, therefore VC:H, VI:H and VA:N,.We believe that the impact will also reflect on the subsequent system, which in this case, is the victim’s machine. The impact, however, will depend on the permissions that the attacker will have on the victim’s machine, therefore SC:L, SI:L, SA:L.

Remote Code Execution affecting ipython package, version 8.10.0

CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:L — 4.2 Medium
CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N — 1.0 Low

Due to the purpose of the package, the attack can only be carried out locally, therefore AV:L. Successful exploitation does not require bypassing security mechanisms but is conditioned by the Operating System and specific deployment (ctypes library, which is shipped by default with Python installs, has to be disabled). This scenario qualifies as AC:L and AT:P. The attacker would also need access to the local environment, which implies that PR:L. The victim will need to actively and consciously engage with the attacker’s payload by invoking the vulnerable function on “Windows in a Python environment where ctypes is not available,” which means that UI:A. Based on the available information for this vulnerability, we believe there will be no impact on the CIA triad within the Vulnerable System but only on the Subsequent System. This is because the commands are on the host system, and the Python installation itself isn't impacted directly. The shell commands are also “limited to the scope of the current process,” which translates to SC:L and SI:L. Since there is no evidence for the availability of the Subsequent System to be impacted, SA:N.

Cross-site Scripting affecting org.jenkins-ci.plugins:rundeck package, version 3.6.11

CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N — 5.4 Medium
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N — 5.1 Medium

The attack can be carried out over the network and does not require the bypass of “exploit mitigation techniques” or any special deployment configuration in order to be successful, therefore AV:N, AC:L, and AT:N. The attacker will, however, depend on an active account for achieving the exploit. Since this is a stored XSS, it means that the victim does not need to perform specific actions with the payload, therefore UI:P. The impact will be reflected in the Subsequent System as the attacker can read or modify data in the victim’s browser, resulting in VC:N/VI:N/VA:N/SC:L/SI:L/SA:N.

Official examples have been published by first.org.

General conclusions

We can immediately observe that CVSS 4.0 will offer improvements in the vulnerability assessment process. Users will be able to pinpoint the security impact more precisely, and this contributes to better prioritization of security issues. As for the severity distribution, it's reasonable to expect that CVSS 4.0 will result in a more balanced distribution due to its increased granularity. This balance will prevent an excessive concentration of vulnerabilities in a particular severity range. Also, we anticipate fewer vulnerabilities with an elevated severity score, especially since CVSS 4.0 will be “keeping the score ranges for each qualitative severity value the same” as for CVSS 3.1.

When will we transition?

While we can’t share an exact ETA, we are actively involved and investigating the best approach to flipping the switch. We are in touch with various vendors (such as Red Hat) and looking into how we can make the best use of these changes. Most of the efforts are currently concentrated on understanding how the new framework can fit within various Snyk products and how it will benefit Snyk users. The aim is to strike a balance between being early adopters and overcoming the potential issues that might appear along the release of CVSS 4.0.

If you are interested in learning more about how to use the CVSS framework when rating vulnerability severities, check out our scoring security vulnerabilities 101 blog post.

What’s new in CVSS 4.0