The Common Vulnerability Scoring System (CVSS) offers software developers, security and IT experts with a standardized process for evaluating vulnerabilities. CVSS can be used to evaluate the threat level of each vulnerability and then prioritize mitigation accordingly. This article explains the way CVSS works, which includes a review of its components and describes the importance of using a standardized process for evaluating vulnerabilities.

What is a Software Vulnerability?

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

Regardless of the source of the vulnerability, they all have some risk to organizations and users. Until vulnerabilities are discovered and patched or fixed when a software is updated, attackers can exploit them to steal data, damage systems, cause outages or spread malware.

How Vulnerabilities are Reported

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

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

When vulnerabilities are inconsequential and can be fixed by the user without vendor help, issues may likely go unreported. Similarly, if major issues are discovered by a cyber criminal or black hat researcher, it may not be reported. However, vulnerabilities are reported to developers or organizations when found. 

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

When vulnerabilities are discovered and reported to a group like MITRE, they will assign the issue an ID number and notify the project manager or vendor. The party responsible has between 30-90 days to develop a solution or patch the issue before the information is known to the public. This will limit the chances that attackers can exploit the vulnerability before a solution is available. 

What is CVSS?

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

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

How CVSS Scoring Works

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

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

Base Score

The base score is meant to represent the essential characteristics of a vulnerability. These characteristics should not change over time nor should qualities depend on individual environments. To calculate the base score, reporters must calculate the composites of the subscores. 

Exploitability Subscore

The exploitability subscore assesses the qualities of a vulnerable component. These qualities assist researchers to define how easily a vulnerability can be exploited by attackers. This subscore involves the following metrics:

Attack Vector (AV): How easy it is for attackers to access the vulnerability.

Attack Complexity (AC): What prerequisites are necessary for exploitation?

Privileges required (PR): The level of privileges needed to exploit the vulnerability.

User interaction (UI): Whether exploitation requires actions from a tertiary user.

Impact Subscore

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

Metric and Measurement

Confidentiality (C): Loss of data confidentiality in the component or wider systems.

Integrity (I): Loss of data integrity throughout the component system.

Availability (A): Loss of availability of the component or attached systems.

Scope Subscore

The Scope Subscore evaluates the impact a vulnerability may have on components other than the one affected by the vulnerability. It focuses on the overall system damage that an attacker can cause by exploiting the reported vulnerability. 

Temporal Score

The temporal score measures part of the vulnerability based on its present status as a known vulnerability. This score includes the following metrics:

Metric and Measurement

Exploit code maturity (E): The availability of tools or code that can be used to exploit the vulnerability.

Remediation Level (RL): The level of remediation currently available to users.

Report Confidence (RC): The degree of accuracy of the vulnerability report.

Environmental Metrics 

Environmental metrics measure the severity of the vulnerability adjusted for its impact on individual systems. These metrics are customizations of the metrics that are used to calculate the base score. Environmental metrics are mostly used when applied internally by security professionals calculating severity according to their own systems. 

The Importance of Standardization

CVSS offers comprehensive guidelines for assessing vulnerabilities. This scoring system is used by different people and has different applications. The most important aspect of the CVSS is that it offers a unified standard for relevant parties. Standardization is essential when responding to risks and prioritizing mitigation. 

Within an organization, security teams can use CVSS scores to allocate limited resources. These resources may include monitoring capabilities and hunting for threats to determine if a vulnerability has already been exploited. This is ideal for small teams who may not have the resources needed to address every vulnerability. 

In conclusion, CVSS scores can be informative for testers and developers in preventing vulnerabilities. It can also help to highlight areas where code security best practices can be enhanced. Rather than waiting until their own product is discovered to be vulnerable, teams can learn from each other's mistakes. 

Photo by Christopher Paul High on Unsplash