The highly anticipated Common Vulnerability Scoring System (CVSS) version 4 is planned to be released on October 31st by the Forum of Incident Response and Security Teams (FIRST). The first CVSS version was introduced in 2005 and has since undergone several iterations. Version 4 is actually the fifth version of the CVSS score, since there was an additional version 3.1.

We see the release of the new CVSS version as a great opportunity to talk about the new version in comparison to the old one, in addition to describing the gaps that still exist in this system. In this blog, we’ll describe what the outcomes were, and how this will impact organizations going forward. An important point to note though is that it’s our recommendation to never only rely on CVSS scores when prioritizing risk. You can read more about this later in the blog.

But before we begin, we’ll first explain what CVSS is, provide a brief history, and explain what the actual differences are between version 3 and 4.

What is the CVSS Scoring System?

The Common Vulnerability Scoring System (CVSS) is the accepted standard for ranking the severity of vulnerabilities and is an essential part of vulnerability management. The purpose of the CVSS system is to provide a universal framework for scoring different vulnerabilities and enable security teams to prioritize remediation of the most critical vulnerabilities.

A CVSS score is between 0 and 10, where 10 is the most severe vulnerability. Several factors are considered to determine the CVSS score of a vulnerability, including attack vector, complexity, privileges required, user interaction, and business impact. For example, the Log4j vulnerability CVE-2021-44228 was scored 10 out of 10 because it  was accessible through the Internet, needed no privileges, required no user interaction, had low complexity and very high availability. 

The further advantage of the CVSS system is that it’s vendor agnostic, so security professionals can easily understand and compare vulnerabilities, no matter which vendor or application they’re using.

CVSS scores allow you to understand the severity of vulnerabilities

Who Maintains CVSS?

The National Infrastructure Advisory Council (NIAC) was the driver behind the first release of the CVSS system in 2005. NIAC then appointed the Forum of Incident Response and Security Teams (FIRST), a non-profit organization run by incident response teams with global coverage, to maintain the universal CVSS system going forward. Every subsequent CVSS version has been subject to peer review as well as review by other organizations, to make the system as accurate as possible.

The Current CVSS Version 3.1

The current version (3.1) considers the following metrics to calculate the overall score:

  1. Base score: This score reflects the intrinsic characteristics of the vulnerability, such as the required attack vector, what kind of user interaction is needed, etc. When you review a CVSS score on websites such as the National Vulnerability Database (NVD), you will usually only see this part of the score.
  2. Temporal score: This score reflects the current state of exploitation and remediation. However, in theory, this metric was supposed to reflect the current state of the vulnerability and its change over time.
  3. Environmental score: This score reflects the importance of the vulnerable asset or the vulnerable IT resource in the environment. 

Diagram showing the metrics that CVSS V3.1 considers

Why is the New CVSS Version 4 Needed?

For several reasons, version 3 was in need of refinement:

  1. The ‘Attack complexity’ and ‘User interaction’ metrics did not consider the probability of an attack accurately enough.
  2. Too many vulnerabilities were pushed to the higher part of the scale.
  3. The system offered insufficient granularity – the formula did not create 99 different scores, as should be in a range of 0.0 to 10.0.
  4. New attack vectors were not taken into consideration – for instance, Operational Technology (OT) impact, including health, human safety, and industrial control systems, was not included and more.

The New CVSS V4

CVSS V4 was presented in June 2023 and should be made available for GA on October 31st. 

Diagram showing the metrics that CVSS V4 considers

Here’s what’s new in CVSS V4:

  1. User interaction – The options have been expanded from Required/None to Active/Passive/None.
  2. Attack Requirements – A new base metric that gets the value “Present” if there is a pre-attack configuration or deployment needed for successful exploitation.
  3. Scope → vulnerable system and subsequent system – The “Scope” feature from CVSS v3.1 was retired in v4. Instead, new features were added to indicate the possible impact scope of the vulnerability exploitation: Vulnerable System Confidentiality (VC), Integrity (VI), Availability (VA) and Subsequent System(s) Confidentiality (SC), Integrity (SI), Availability (SA)
  4. Temporal Score → Threat Metrics – The temporal score in v3 had the same score in most of the cases (official fix with confirmed confidence). The new Threat Metric in v4 includes only the exploit maturity in the wild, with values of Attacked/POC/Unreported (intelligence is unknown whether there’s in the wild exploitation)/Not Defined (clear intelligence that no exploitation was found in the wild)
  5. Supplemental Metrics – These metrics are new in v4 and provide the ability to define new metrics that describe and measure additional external elements  of a vulnerability. Organizations can use these metrics  to take additional actions if they so choose, if they seem  to be significant in their environment. All Supplemental Metrics are optional.
  6. More granularity in the environmental and modifiable parameters –  This provides organizations with more options to adjust scores to their needs and internal priorities. The safety metric in the Environmental metrics can serve OT/ICS/IoT.
  7. New nomenclature – In view of the new metrics categories, the following abbreviations have been applied:
  • CVSS-B: CVSS Base Score 
  • CVSS-BT: CVSS Base + Threat Score 
  • CVSS-BE: CVSS Base + Environmental Score 
  • CVSS-BTE: CVSS Base + Threat + Environmental Score

One thing to note though is that the National Vulnerability Database has not yet specified whether they are going to support existing CVEs with the new CVSS v4 score. Also, currently there is no automatic way to transform the old CVSS v3 score into the new one.

CVSS v3 Versus v4 Bake Off

FIRST added multiple examples of CVEs and how their score changed when using CVSS version 4. Below, we examine five existing CVEs and compare what score they would get in CVSS v4 using the FIRST calculator. 

#1. CVE-2021-44228 (Log4shell)

VERSIONCVSS BASE VECTORSCORE
CVSS 3.1CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H10
CVSS 4CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N9.3

This CVE is the Apache Log4j JNDI Command Execution Vulnerability (also known as  Log4shell). As you can see, a few metrics were added in the new version, and they significantly affected the score:

  • Attack Requirements (AT) – this one was missing in the previous version and gets the value None (N), which has an increasing nature to the score.
  • Instead of Scope (S) and the general Confidentiality (C), Integrity (I) and Availability (A), we have Vulnerable System Confidentiality (VC), Integrity (VI) and Availability (VA) with the addition of Subsequent System Confidentiality (SC), Integrity (SI) and Availability(SA). While the first part of the vulnerable system remains the same, the Subsequent System values (because this vulnerability is not affecting subsequent systems) are None (N), which contributes to the score decrease.

#2. CVE-2022-22965 (Spring4Shell)

VERSIONCVSS BASE VECTORSCORE
CVSS 3.1CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H9.8
CVSS 4CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N9.2

In this example of the Spring Arbitrary Code Execution vulnerability, we again see a contribution of the metrics Attack Requirements, Vulnerable System and Subsequent System. However, in this example the attack requirements (AT) are present (P), because there are some configurations required for a successful exploitation (the JDK 9+). Therefore we see another reduction of the score.

#3. CVE-2014-0160 (Heartbleed)

VERSIONCVSS BASE VECTORSCORE
CVSS 3.1CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N7.5
CVSS 4CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N8.7

With the OpenSSL “Heartbleed” vulnerability however, we actually see an increase in the score. Like the previous vulnerabilities, we see the change of Scope (S) vs. Vulnerable System and Subsequent System. But, we also see that there are no attack requirements. Therefore, the exploitation probability of this score increases, and the overall score increases with it. 

#4. CVE-2022-41741 (NGINX)

VERSIONCVSS BASE VECTORSCORE
CVSS 3.1AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H7.0
CVSS 4CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N7.3

Another example where the score is increased is the NGINX memory corruption vulnerability. This vulnerability is very prevalent among NGINX users and affects many versions. Although version 4 takes into account the fact that there are many prerequisites to exploit this vulnerability, the new calculation of the Confidentiality, Integrity and availability increases the score.

#5. CVE-2022-42252 (Tomcat Request Smuggling)

VERSIONCVSS BASE VECTORSCORE
CVSS 3.1AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N7.5
CVSS 4CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N8.5

Here’s another example of an increasing score. For this CVE we also have the Requirements (AT) present (because the server should be positioned behind a reverse proxy), but the Confidentiality, Integrity and availability increases the score in this new calculation.

CVSS Bake Off Reveal

Even though we did find that in several cases the scores of CVEs increased, in general we concluded that CVSS v4 produces considerably lower scores, and is actually much more realistic in terms of the actual danger posed by the vulnerability. CVSS v3 tended to ‘overscore’ vulnerabilities, even if they were very difficult to exploit.

In conclusion, CVSS v4 will significantly reduce vulnerability alert fatigue, since it will help teams understand that some vulnerabilities are less in need of fixing since it’s highly unlikely that they will be exploited in the wild. This allows organizations to focus on the more dangerous vulnerabilities and fix those first. 

Most importantly however, as we describe below, it’s extremely important for security teams to understand that CVSS scores can only provide you very limited information, and without the big picture they could actually be misleading and lead you to go down a rabbit hole instead of remediating the actual critical risks.

Why CVSS Scores Should Not be Your Only Prioritization Metric

Although CVSS is constantly being improved, it can only consider the identified vulnerability, but not the context of the vulnerability in the actual cloud environment, which limits its usability.

  • First, the CVSS score is still not a complete metric. Although it now better reflects the probability of exploitation with the Attack Requirements metric addition, it is still not taking into consideration issues that could affect the prioritization of patching this vulnerability in the first place. Questions like – Are the attack requirements part of a common configuration? For instance if they are part of the default configuration, this adds a significant risk. Or, maybe, the prerequisites for the attack are so far from reality, that they shouldn’t be prioritized at all.
  • Second, is the context. Let’s illustrate this with an example: Server 1 and Server 2 are both Apache web servers. They are both using a vulnerable library (CVE-2018-1176). Other solutions will report the risk on Server 1 and Server 2 as exactly the same, i.e. the CVSS score of the vulnerability is 8.8.

However, Orca’s context engine sees from the cloud configuration data that Server 1 is Internet facing and easily accessible to attackers. In addition, Server 1 exposes a key to an adjacent asset that contains PII. Therefore, Orca prioritizes the CVE on Server 1 to ‘Critical’. On the other hand, Server 2 is an intranet server that is not publicly accessible and exposes no other exploitable risks. Therefore, this CVE poses a minimal threat to the organization and Orca categorizes it as ‘Low’.

  • Finally, the trendiness or the popularity of a vulnerability is an important factor as well. Sources like CISA’s Known Exploited Vulnerabilities (KEV) catalog or our proprietary Orca engine, reflect how popular a vulnerability is among attackers. This data helps to predict the probability that someone will try to use the exploit. For some vulnerabilities it could be a matter of minutes, for others, never. These are also important considerations when deciding which vulnerabilities need patching first. Although FIRST do consider the exploitability of a vulnerability, it’s not part of the basic score metric calculation, which means that it’s not considered for the final CVSS score that we get from vendors, which is an important omission.

Vulnerability Management with Orca Security

Since Orca scans every layer of your cloud estate, including cloud workloads, configurations, and identities, Orca can see the actual risk context and prioritizes risks accordingly based on many factors, not just the CVSS score.

The Orca risk score ranges from 1.0 – 10 and considers risk context in the actual environment

Orca implements its own risk scoring system that ranges from 1.0 – 10 and includes one decimal to further fine-tune the priority of the alert. The score is determined by considering the full contextual picture of the risk and the surrounding cloud environment, giving you the information needed to understand the severity and urgency of each alert.

Would you like to learn more about the Orca Cloud Security Platform? Reach out to us to schedule a 1:1 demo with one of our cloud experts.