The Forum of Incident Response and Security Teams (FIRST) officially launched the fourth version of the Common Vulnerability Scoring System (CVSS 4.0), in November 2023.
CVSS 4.0, the industry standard for assessing the severity of computer system security vulnerabilities, is a significant update from the previous versions of the CVSS and brings several changes that will impact how organizations assess and prioritize vulnerabilities.
In this article, we will take a closer look at all the standards used to register and track software vulnerabilities and the scoring systems to assess their criticality.
What is a Software Vulnerability?
In computer science, vulnerabilities are flaws or glitches that weaken a system's overall security. Vulnerabilities can be weaknesses in either the hardware itself or the software that runs on it.
Vulnerabilities can be exploited by threat actors to obtain privilege access levels, either by leveraging a flaw to gain unauthorised access or by exploiting a loophole that has been missed out by the software development team to gain access that appears to be authorised.
Vulnerability scanning is the process of identifying security weaknesses and flaws in systems and software running on them. This is an integral component of a vulnerability management programme, which has one overarching goal – to protect the organisation from breaches and the exposure of sensitive data.
How Does the CVE System Work?
The Common Vulnerabilities and Exposures (CVE) system lists publicly known information security vulnerabilities and exposures.
It was founded in 1999 by the MITRE Corporation in collaboration with the US Department of Homeland Security (DHS) and the US Cybersecurity and Infrastructure Security Agency (CISA).
Each entry in the CVE list is assigned a unique CVE identifier, a four-part identifier consisting of the year the vulnerability was discovered and a sequential number.
For example, the CVE identifier for the recent Citrix Bleed vulnerability is CVE-2023-4966.
Additionally, a CVE entry includes some essential information about the vulnerability for managing information security risks. These include:
- A description of the vulnerability, which includes information such as the affected software, the potential impact of the vulnerability, and the mitigation steps
- A severity score, based on the potential impact of the vulnerability if it is exploited
- References to other sources of information
By using the CVE system, organizations can identify, prioritize and mitigate vulnerabilities.
Who is Responsible for Registering and Maintaining CVEs?
CVEs are first registered by a CVE Numbering Authority (CAN). This organization is authorized by the CVE Program to assign CVE IDs to vulnerabilities and publish CVE records within their own specific scopes of coverage.
Organizations that meet specific criteria, such as having a public vulnerability disclosure policy and a public source for new vulnerability disclosures, can apply to become CNAs. The CVE Program has a rigorous review process for CNA applications to ensure that only qualified organizations are authorized to assign CVE IDs.
CVEs are maintained by MITRE and stored in the National Vulnerability Database (NVD), a US government repository of standards-based vulnerability management data.
NVD is put together using the Security Content Automation Protocol (SCAP), a method for using specific standards to enable automated vulnerability management, measurement, and policy compliance evaluation of systems deployed in an organization.
Other Vulnerability Classification Systems
The Common Weakness Enumeration (CWE) is a hierarchical taxonomy of software weaknesses that can lead to vulnerabilities, which will later be attributed a CVE.
The project is also maintained by MITRE and sponsored by the DHS and CISA offices, with support from US-CERT and the DHS’ National Cyber Security Division.
Each CWE entry is assigned a unique identifier and includes information about the weakness, such as its type, potential consequences, and mitigation techniques.
CWE has over 600 categories, including classes for buffer overflows, path/directory tree traversal errors, race conditions, cross-site scripting, hard-coded passwords, and insecure random numbers.
Additionally, the Open Web Application Security Project (OWASP) maintains lists of the top 10 vulnerabilities in areas like application security (AppSec), machine learning or large language models (LLMs).
Read more: What the OWASP Top 10 for LLMs Means for the Future of AI Security
How to Measure the Criticality of a Vulnerability
Measuring the criticality of a vulnerability is essential for prioritizing remediation efforts and effectively managing cybersecurity risks. Several factors can contribute to the criticality of a vulnerability, including its severity, exploitability, and potential impact:
- Vulnerability severity, which refers to the potential harm that can be caused by exploiting the vulnerability. The Common Vulnerability Scoring System (CVSS) is a widely used framework for assessing vulnerability severity.
- Vulnerability exploitability, which refers to the ease with which an attacker can exploit the vulnerability. Factors that affect exploitability include the availability of public exploits, the required level of attacker skill, and the need for special privileges or conditions.
- Potential impact, which refers to the extent of harm that can be caused if the vulnerability is exploited. This impact can be measured in various ways, such as operational disruption, financial loss, reputational damage or legal and regulatory consequences.
What is the CVSS System?
The Common Vulnerability Scoring System (CVSS) is an open industry standard for assessing the severity of computer system security vulnerabilities.
It provides a common language for describing the characteristics and impacts of vulnerabilities, making it easier to share and compare vulnerability information among security professionals and organizations.
The system was developed by the US National Infrastructure Advisory Council (NIAC) in 2005 but was later transferred to the Forum of Incident Response and Security Teams (FIRST), which now maintains and updates the scoring system.
CVSS is based on three groups of metrics: base, temporal, and environmental.
Base metrics assess the inherent characteristics of a vulnerability and include the following criteria:
- Exploitation potential: The likelihood that a vulnerability can be successfully exploited.
- Access vector: The ease with which an attacker can access the vulnerable system or component.
- Impact: The potential consequences of exploiting the vulnerability, such as loss of confidentiality, integrity, or availability.
Temporal metrics reflect the changing nature of vulnerabilities over time and include the following criteria:
- Exploit code availability: Whether publicly available exploit code exists for the vulnerability.
- Remediation existence: Whether a patch or fix is available to address the vulnerability.
- Confidence: The confidence in the accuracy of the vulnerability information.
Environmental metrics consider the specific context of the vulnerability within an organization’s IT environment and include the following criteria:
- Collateral damage potential: The likelihood that exploiting the vulnerability will cause unintended damage to other systems or components.
- Target distribution: The prevalence of the vulnerable system or component within the organization’s IT environment.
- Impact modifiers: Additional factors that can affect the impact of the vulnerability, such as the organisation's security posture and the value of the affected assets.
CVSS assigns a severity score based on these metrics. A higher CVSS score indicates a more severe vulnerability. The CVSS score can be used to prioritize vulnerability remediation efforts and make informed decisions about mitigating cybersecurity risks.
What does CVSS 4.0 Change?
The latest revision to the CVSS standard came four years after the previous version, CVSS 3.1, was introduced. It aims to address some of the criticisms CVSS 3.1, such as a general lack of granularity allowed to assess a vulnerability’s criticality and failures to address industrial control systems (ICS).
CVSS 4.0 provides supplemental metrics for vulnerability assessment, such as Safety (S), Automatable (A), Recovery (R), Value Density (V), Vulnerability Response Effort (RE), and Provider Urgency (U).
It also introduces a new nomenclature to enumerate CVSS scores using a combination of Base (CVSS-B), Base + Threat (CVSS-BT), Base + Environmental (CVSS-BE), and Base + Threat + Environmental (CVSS-BTE) severity ratings.
According to FIRST, the idea behind CVSS 4.0 is to reinforce the concept that CVSS is not just the Base score.