What is the Common Vulnerability Scoring System (CVSS)?

The Common Vulnerability Scoring System (CVSS) is a widely used framework for classifying and rating software vulnerabilities.

Through this open framework, organizations can calculate a CVSS score, which is a numerical score that represents the severity of a vulnerability. The characteristics of a vulnerability that contributed to the CVSS score are represented in a chain of text known as a CVSS vector string.

There have been several versions of CVSS since 2005. The most recent version, CVSS v4.0, was released in 2022. The nonprofit group FIRST.org, Inc., also known as the Forum of Incident Response and Security Teams, manages this framework.

CVSS is an important tool for vulnerability management, which is the continuous discovery, prioritization and resolution of security vulnerabilities in an organization’s IT infrastructure and software. Identifying and resolving errors and cybersecurity weaknesses, such as firewall misconfigurations and unpatched bugs, is critical to ensuring the full functionality of IT infrastructure and software.

Resolution measures can include:

• Remediation: ensuring a vulnerability can no longer be exploited.
  
• Mitigation: making a vulnerability more difficult to exploit while reducing the potential impact of its exploitation.
  
• Acceptance: leaving a vulnerability in place if it’s unlikely to be exploited or would cause little damage.

Given the complexity of today’s IT systems and their large volume of vulnerabilities and cyberthreats, determining which issues to address and resolve first can be challenging for IT managers.

That’s where CVSS proves valuable: It provides IT managers with a systematic approach to assessing the severity of a vulnerability, helping inform their decisions on prioritizing and planning vulnerability resolutions for affected systems.¹

CVSS scores can be incorporated into risk assessments, but a CVSS assessment on its own should not be used in place of a comprehensive risk assessment, according to FIRST.org. CVSS user guides advise that comprehensive assessments should include factors outside the scope of CVSS.²

CVSS began as a research project commissioned by the National Infrastructure Advisory Council (NIAC) in 2003. At the time, the landscape for software vulnerability assessments was a disjointed one: Computer security vendors and nonprofit groups used different procedures and metrics, resulting in an array of unique, often proprietary scoring systems that were incompatible with one another.³ This incongruity made it difficult for security teams at different organizations to collaborate.⁴

NIAC researchers created CVSS to standardize vulnerability assessments. They designed it to be an open system that might be customized for and adopted by different IT systems and environments.⁵

CVSS v4.0 consists of 4 metric groups.⁶

• Base
• Threat
• Environmental
• Supplemental

These metric groups represent different characteristics and qualities of software vulnerabilities. Under the CVSS v4.0 framework, the groups can be described as follows:

Base metrics represent the intrinsic qualities of vulnerabilities that are constant across user environments and over time. Base metrics consist of 2 sets, Exploitability and Impact metrics.

Exploitability metrics indicate how easily a vulnerability can be successfully exploited. Examples of Exploitability metrics include:

• Measures of how much user interaction an attacker needs in order to exploit a vulnerability
• Whether an attacker can access a system locally or remotely (“attack vector”)
• What level of privileges an attacker needs to be successful (“privileges required”)
• Whether specific conditions or advanced knowledge are needed to carry out an attack (“attack complexity”)

Impact metrics represent the results of a successful exploit, the impact on a vulnerable system (such as a software application or operating system) and the downstream impacts on other systems. Examples of Impact metrics include:

• Measures of the loss of confidentiality, such as access to restricted information
• Loss of integrity, such as when the attacker modifies system data
• Availability impact, referring to whether an attack reduces a system's performance or denies system access to legitimate users

Threat metrics represent the vulnerability characteristics that change over time. Exploit maturity is the principle metric in this category, measuring the likelihood of a specific vulnerability being attacked.

The availability of exploit codes, the state of exploit techniques and real-life instances of attacks determine the metric value assigned to the exploit maturity metric. Such values include:

• “Attacked” (signifying that attacks have been reported on this vulnerability)
• “Proof-of-concept” (indicating that exploit codes are available but there have been no known attacks)
• “Unreported” (indicating no known proof-of-concept exploit codes nor attempts to exploit the vulnerability)

When there is no reliable threat intelligence to determine exploit maturity, a default value—“not defined”—is used.

The Environmental metric group represents vulnerability characteristics that are unique to a user’s environment. Like the Base metrics group, the Environmental group includes confidentiality, integrity and availability, with each metric being assigned a value reflecting the importance of the vulnerable asset in the organization. This is in contrast to the intrinsic focus of Base metrics.

In addition, through the Environmental metric group, analysts can override various original base metrics with modified base metrics if the situation in a specific environment suggests a different value is warranted.

Consider a scenario in which the default configuration of an application requires authentication for access, but the environment home to the application doesn’t require authentication for administrators. In this case, the original base value for the “privileges required” vulnerability of the application is “high," meaning a high level of privilege is required to access it. However, the modified “privileges required” value would be “none” because attackers could theoretically exploit the vulnerability by assuming administrative functions.

The Supplemental metric group provides additional information on extrinsic characteristics of vulnerabilities, focusing on issues beyond technical severity. Examples of Supplemental metrics include:

• “Automatable” (whether an attacker can automate the steps of the attack to reach multiple targets)
• “Safety” (the potential that a human can be injured as a result of a vulnerability being exploited)
• “Recovery” (how well a system recovers after an attack)

CVSS versions vary in the metrics that they include. For example, the Supplemental metric group is a relatively new addition to CVSS. Earlier versions of CVSS (CVSS v1, CVSS v2, CVSS v3 and CVSS v3.1) did not include this set of metrics.

However, older CVSS versions did include other metrics, such as “report confidence” and “remediation level”, which belonged to a metric group called Temporal metrics. The Threat metric category of CVSS v4.0 replaced the Temporal metrics group of older versions.

CVSS v4.0 is also considered as having more granularity in its Base metrics, allowing for a more comprehensive understanding of vulnerabilities.

Different types of CVSS scores reflect the different metric groups considered in evaluating a vulnerability:

• CVSS-B refers to CVSS Base scores
• CVSS-BE refers to Base and Environmental scores
• CVSS-BT refers to CVSS Base and Threat scores
• CVSS-BTE refers to CVSS Base, Threat and Environmental scores⁷

All scores range from 0 to 10, with 0 as the lowest severity rating and 10 as the highest possible severity score. Supplemental metrics do not affect CVSS scores but might be included in CVSS v4.0 vector strings.

Different entities might prioritize different metric groups and scores. For instance, software vendors often specify the Base scores of their products, while consumer organizations might rely on Threat and Environmental metrics to indicate the potential impact of a vulnerability in their environments.⁸

CVSS vector strings are machine-readable text representations of a group of CVSS metrics for a vulnerability. Different abbreviations within vector strings correspond to specific metric values, helping to contextualize that vulnerability’s CVSS score.⁹

For example, a vulnerability with an “attack vector” value of “L” (for “local”) would have “AV:L” in its vector string. If that vulnerability required that an attacker have a high level of privileges to successfully exploit it, the “privileges required” value would be “H” (for “high” and its vector string would include “PR:H.”

In a vector string, each value is separated by a forward slash (“/”) and must be listed in a prescribed order, as specified by the CVSS framework. The different values from the Base, Threat and Environmental metrics groups can be combined into 15 million distinct vector strings.¹⁰

CVSS can be helpful for assessing specific types of cybersecurity vulnerabilities that are often discovered in AI applications, including model poisoning, denial of service or information disclosure. However, CVSS might be less helpful for AI-related vulnerabilities that relate mostly to bias, ethics or legal concerns, according to FIRST.org. Such vulnerabilities relate to inference, model inversion and prompt injection.¹¹

While CVSS is a framework for assessing vulnerabilities, CVE (an abbreviation for Common Vulnerabilities and Exposures) is a glossary of publicly disclosed cybersecurity vulnerabilities. The vulnerabilities included in the CVE program are assigned unique identifiers called CVE IDs. The program is maintained by the nonprofit MITRE corporation and sponsored by the US Department of Homeland Security.

The severity of vulnerabilities cataloged by the CVE program can be assessed using the CVSS framework. However, when it comes to CVE-published vulnerabilities, CVE organizations might choose to forego doing their own calculations and instead rely on CVSS scores provided by the National Vulnerability Database (NVD). NVD is a standards repository of vulnerability management data from the National Institute of Standards and Technology (NIST). NVD hosts a searchable online database of vulnerabilities identified by CVE paired with supplemental information, including CVSS Base scores and vector strings.

Organizations can use online calculators to determine several types of CVSS scores, including CVSS scores based on older versions of CVSS. CVSS calculators are available on the CVSS and NVD websites. CVSS documentation includes a recommendation that organizations use automation to scan for threats to inform the Threat and Environmental metrics portion of the assessment.¹²

Organizations can also take advantage of vulnerability management tools and platforms that incorporate CVSS assessments. Leading vulnerability assessment software solutions reference CVSS scores among multiple key factors, including compliance benchmarks, vendor security guides and industry research. Such solutions might also include AI-powered features such as automated, real-time data discovery that can help improve an organization’s incident response and privacy management.