A Vulnerability Management Crisis: The Issues with CVE

For decades, the cybersecurity industry has relied on the Common Vulnerabilities and Exposures (CVE) program to standardize vulnerability documentation and guide threat intelligence. The program assigns a unique identifier to each discovered security vulnerability. Then, it ranks the vulnerability's severity using the Common Vulnerability Scoring System (CVSS).

Despite the widespread reliance on CVE, the system has had few updates over the many years that it has existed. We have found that the increasing complexity and scale of modern cybersecurity challenges has outpaced the capabilities of CVE. Below, get an overview of the major challenges that CVE faces in the current landscape.

You can also find a more in-depth look at these issues and their potential solutions in our latest publication.

Data Quality and Fidelity

Most of the CVEs coming out right now lack important metadata information. This can include specific impact details, impacted libraries, and other essential data. Impact details are especially important for discerning the importance of various vulnerabilities.

Moreover, many CVEs have outdated information. This can be especially detrimental, as evidenced by the Heartbleed bug. Researchers initially gave the CVE a medium severity score. However, even after realizing the vulnerability's real-world danger and impact on internet security, no one updated the score.

Perverse Incentives to Not Create CVEs

While many companies submit the vulnerabilities they find, there are incentives to hide them as well. Addressing vulnerabilities is often at the bottom of a company’s priority list. Instead, they choose to direct resources toward initiatives that directly grow and benefit the company.

Additionally, if they don't publish a vulnerability, an organization can quietly fix it without the public’s knowledge. This protects the company’s image.

Finding Relevant Vulnerability Data

With researchers publishing new CVEs daily, it becomes increasingly difficult to search through this data and identify vulnerabilities that are relevant to you. Numerous vulnerability management software tools try to address this. However, these tools often struggle with slow scanning speeds and false positives.

Additionally, no one notifies the owner of a project about CVEs that pertain to their project. This leads to incorrect information within the CVE. This is a huge problem that adds unnecessary complexity for vulnerability management teams.

Lack of Interoperability

The various vulnerability databases and sources largely don’t work together, increasing the complexity for organizations. The first part of this problem is the wide array of data formats that different vulnerability databases use. Formats such as CVE, GitHub Advisory Database, and Open Source Vulnerabilities each use a different structure. This creates disparities between the databases and the information they hold.

Organizations have to use multiple APIs to keep track of vulnerabilities across databases. This puts a lot of work on security teams and incurs extra operational costs. Despite the prevalence of this problem, the major vulnerability databases have made little progress to address it.

Resolving Disputes

When someone publishes a CVE with incorrect information, the process to dispute it lacks transparency. While a CVE is under dispute, it remains in the database. False information spreads until someone can resolve the dispute.

Complexity of Reporting Vulnerabilities

Many people find the CVE submission process to be confusing and complex, discouraging potential submitters. Here’s an overview of the process:

• Initial Reporter: The person finding the vulnerability and trying to disclose it to be categorized as a CVE.
• Choosing a CVE Partner: Next, the reporter has to identify which CVE partner they would be using. That can be hard, since there are hundreds of them, each with a CNA scope.
• Means of Submission: The means vary depending on the partner. Microsoft and CISA have a form. Most of them provide an email address for submissions but do not indicate what information they require. In many cases, this leads to an extended email chain between the reporter and the CVE partner.
• CVE Publication: After making the submission, the CNA obtains a CVE ID and then publishes it. This process can take several weeks or even months. Communication with the initial reporter often breaks down, leaving them uncertain as to what has happened to their CVE.
• Potential Rejection: The CNA can decide that the CVE is out of scope or doesn't meet its criteria. Then, the reporter has to either submit directly to MITRE or drop the process altogether.
• Lack of Feedback: There is no feedback system for CVEs. Reporters find it hard to understand what makes a good submission.

Overall, the system of vulnerability reporting is inconsistent and complicated. This deters submissions and negatively impacts the quality and effectiveness of the CVE process.

Handling False or Low-Quality Reports

With the recent surge in CVE submissions, there has been a growing problem of people submitting false or low-quality data. Getting a CVE published is a huge and desirable accomplishment for a security professional. This means that some people are willing to submit low-quality or even false CVEs just to add it to their resume.

Another reason for low-quality CVEs is CVE misuse. One example of this is engineers using CVEs to backport patches. Many companies don’t prioritize patches for older, stable kernel versions. To make them a priority, engineers will submit these patches as CVEs.

Increasing Number of CVEs Every Year

Another significant challenge is the sheer volume of CVEs that people discover and report each year. The number of reported CVEs has been rising consistently, from 321 CVEs in 1999 to 28,961 in 2023.

This continuous growth exacerbates several existing issues within the CVE system. As people publish more CVEs, it becomes impossible to ensure each entry is accurate, detailed, and actionable. Additionally, it becomes increasingly difficult to prioritize remediation efforts effectively. The existing CVSS scoring system, while helpful, is not sufficient to deal with this volume.

CVSS

When analyzing the severity of vulnerabilities, it is crucial to consider scoring systems that weigh the vulnerability threat levels. The Common Vulnerability Scoring System (CVSS) is one of the most widely used severity scoring systems. The issues with CVSS include:

• Inability to Prioritize Risk: A variety of research underlines that CVSS cannot prioritize certain elements. One example is the material consequences to the business if an adversary exploits the vulnerability.
• Limited Awareness of Context: There are many important factors that CVSS does not consider. One of these critical limitations is the fact that CVSS cannot prioritize a threat differently for different environments. Since CVSS assigns a universal score to a CVE, it appears that the vulnerability is consistent across all systems.
• Static Scoring System: CVSS statically assigns a severity score to a vulnerability within a short period after its discovery. The problem with this system is that, in most cases, no one updates the base score after the initial assignment. Therefore, the score becomes static and reflects no change in vulnerability impact or threat level over time.

Learn More

The rapidly evolving threat landscape demands innovative solutions to address the many challenges in vulnerability data management. Continue the exploration of CVE and CVSS challenges and alternatives in CSA's Top Concerns with Vulnerability Data publication.