The Common Vulnerability Scoring System (CVSS) provides software developers, testers, and security and IT professionals with a standardized process for assessing vulnerabilities. You can use the CVSS to assess the threat level of each vulnerability, and then prioritize mitigation accordingly.

This article explains how the CVSS works, including a review of its components, and describes the importance of using a standardize process for assessing vulnerabilities.

What is a software vulnerability?

A software vulnerability is any weakness in the codebase that can be exploited. Vulnerabilities can result from a variety of coding mistakes, including faulty logic, inadequate validation mechanisms, or lack of protection against buffer overflows. Unprotected APIs and issues contributed by third-party libraries are also common sources of vulnerabilities.

Regardless of the source of the vulnerability, all present some risk to users and organizations. Until vulnerabilities are discovered and patched, or fixed in a software update, attackers can exploit them to damage systems, cause outages, steal data, or deploy and spread malware.

How vulnerabilities are reported

The way in which vulnerabilities are reported depends on the type of software they are discovered on and the type of vulnerability they appear to be. In addition, the perceived importance of the vulnerability to the finder is a factor in how it’s reported.

Typically, vulnerabilities are found and reported by security researchers, penetration testers, and users themselves. Security researchers and penetration testers may work full-time for organizations or they may function as freelancers working under a bug bounty program.

When vulnerabilities are minor or can be easily fixed by the user without vendor or community help, issues are more likely to go unreported. Likewise, if a severe issue is discovered by a black hat researcher, or cybercriminal, it may not be reported. Generally, however, vulnerabilities are reported to organizations or developers when found.

If a vulnerability is found in proprietary software, it may be reported directly to the vendor or to a third-party oversight organization, such as the non-profit security organization, MITRE. If one is found in open-source software, it may be reported to the community as a whole, to the project managers, or to an oversight group.

When vulnerabilities are reported to a group like MITRE, the organization assigns the issue an ID number and notifies the vendor or project manager. The responsible party then has 30 to 90 days to develop a fix or patch the issue before the information is made public. This reduces the chance that attackers can exploit the vulnerability before a solution is available.

What is CVSS?

The Common Vulnerability Scoring System (CVSS) is a set of free, open standards. These standards are maintained by the Forum of Incident Response and Security Teams (FIRST), a non-profit security organization. The standards use a scale of 0.0 to 10.0, with 10.0 representing the highest severity. The most recent version released is CVSS 3.1, released in June 2019.

These standards are used to help security researchers, software users, and vulnerability tracking organizations measure and report on the severity of vulnerabilities. CVSS can also help security teams and developers prioritize threats and allocate resources effectively.

How CVSS scoring works

CVSS scoring is based on a combination of several subsets of scores. The only requirement for categorizing a vulnerability with a CVSS is the completion of the base score components. However, it is recommended that reporters also include temporal scores and environmental metrics for a more accurate evaluation.

The base score of the CVSS is assessed using an exploitability subscore, an impact subscore, and a scope subscore. These three contain metrics for assessing the scope of attacks, the importance of impacted data and systems, and the scope subscore assesses the impact of the attack on seemingly unaffected systems.

Base score

The base score is meant to represent the inherent qualities of a vulnerability. These qualities should not change over time nor should qualities be dependent on individual environments. To calculate the base score, reporters must calculate the composite of three subscores.

Exploitability subscore

The exploitability subscore measures the qualities of a vulnerable component. These qualities help researchers define how easily a vulnerability can be exploited by attackers. This subscore is composed of the following metrics:

Metric	Measurement	Scale (low to high)
Attack vector (AV)	How easy it is for attackers to access a vulnerability	Physical (presence) Local (presence) Adjacent (connected networks) Network (remote)
Attack complexity (AC)	What prerequisites are necessary for exploitation	Low High
Privileges required (PR)	The level of privileges needed to exploit the vulnerability	None Low High
User interaction (UI)	Whether exploitation requires actions from a tertiary user	Binary—either None or Required

Impact subscore

The impact subscore measures the effects that successful exploitation has on the vulnerable component. It defines how a component is affected based on the change from pre to post exploit. This subscore is composed of the following metrics:

Metric	Measurement	Scale
Confidentiality (C)	Loss of data confidentiality in the component or wider systems	None Low High
Integrity (I)	Loss of data integrity throughout the component system	None Low High
Availability (A)	Loss of availability of the component or attached systems	None Low High

Scope subscore

The scope score measures what impact a vulnerability may have on components other than the one affected by the vulnerability. It tries to account for the overall system damage that an attacker can execute by exploiting the reported vulnerability. This is a binary scoring with scope being changed or unchanged.

Temporal score

The temporal score measures aspects of the vulnerability according to its current status as a known vulnerability. This score includes the following metrics:

Metric	Measurement	Scale (from low to high)
Exploit code maturity (E)	The availability of tools or code that can be used to exploit the vulnerability	Proof of concept Functional Unproven High Not defined
Remediation level (RL)	The level of remediation currently available to users	Official fix Workaround Temporary fix Unavailable Not defined
Report confidence (RC)	The degree of accuracy of the vulnerability report	Unknown Reasonable Confirmed Not defined

Environmental metrics

Environmental metrics measure the severity of the vulnerability adjusted for its impact on individual systems. These metrics are customizations of the metrics used to calculate the base score. Environmental metrics are most useful when applied internally by security teams calculating severity in relation to their own systems.

The importance of standardization

CVSS provides comprehensive guidelines for assessing vulnerabilities. This scoring system is used by many and has a wide range of applications. However, perhaps the most important aspect of the CVSS is that it provides a unified standard for all relevant parties. Standardization is crucial when responding to risks and prioritizing mitigation.

CVSS scores are more than just a means of standardization. These scores have practical applications and can have a significant impact in helping security teams and product developers prioritize their efforts. 

Within an organization, security teams can use CVSS scores to efficiently allocate limited resources. These resources may include monitoring capabilities, time devoted to patching, or even threat hunting to determine if a vulnerability has already been exploited. This is particularly valuable for small teams who may not have the resources necessary to address every vulnerability.

CVSS scores can also be useful for security researchers. These scores can help highlight components that are especially vulnerable or tactics and tools that are particularly effective. Researchers can then apply this knowledge to developing new security practices and tools to help detect and eliminate threats from the start. 

Finally, CVSS scores can be informative for developers and testers in preventing vulnerabilities in the first place. Careful analysis of high ranking vulnerabilities can help software development teams prioritize testing. It can also help highlight areas where code security best practices can be improved. Rather than waiting until their own product is discovered to be vulnerable, teams can learn from other’s mistakes