The Quality Imperative for CVEs: The Need For Enhancing Vulnerability Reporting Standards

The Quality Imperative for CVEs: The Need For Enhancing Vulnerability Reporting Standards

Speakers: Jerry Gamblin, Threat Detection and Response Group, Cisco

Conference: VulnCon

YouTube: https://www.youtube.com/watch?v=qkc6uj99La2g

Overview

In an insightful and candid presentation at VulnCon, Jerry Gamblin, a prominent figure in Cisco's Threat Detection and Response group, delivered a critical assessment of the current state of Common Vulnerabilities and Exposures (CVE) data quality. His talk, "The Quality Imperative for CVEs," highlighted systemic issues within the CVE program and the National Vulnerability Database (NVD), emphasizing that while the data is foundational for cybersecurity, its current structure and inconsistent quality hinder its effectiveness. Gamblin's perspective is unique, stemming not from a CVE Numbering Authority (CNA) but from a significant consumer of CVE data, integrating it daily into Cisco's security products.

Gamblin stressed that his criticisms were not intended to embarrass but to foster community improvement. He relies heavily on NVD and CVE data to protect internet users, making the integrity and completeness of this information paramount. The core of his argument centers on the minimal requirements for CVE publication, the lack of robust quality checks, and the fragmented nature of data access, all of which compromise the utility of CVEs for downstream consumers. The talk concluded with a series of actionable recommendations, urging the community and the CVE program to collaborate on enhancing reporting standards, tooling, and accessibility to ensure CVEs remain a reliable cornerstone of global cybersecurity.

Background

▶ Watch: Introduction and talk's community improvement focus (0:00)

The concept of Common Vulnerabilities and Exposures (CVEs) was established to provide a standardized, unique identifier for publicly known cybersecurity vulnerabilities. This system, maintained by the MITRE Corporation and supported by the CVE program, aims to facilitate data sharing and enable organizations to track and manage vulnerabilities effectively. The National Vulnerability Database (NVD), maintained by NIST, further enriches CVE records with additional information such as Common Vulnerability Scoring System (CVSS) scores, Common Weakness Enumeration (CWE) mappings, and Common Platform Enumeration (CPE) identifiers. These resources are critical for security professionals, researchers, and product developers who rely on this data to identify, prioritize, and remediate security risks.

Despite their foundational role, Gamblin points out that the CVE and NVD ecosystems face significant challenges that undermine their intended purpose. The primary issue stems from the historically low bar for publishing a CVE. Currently, a CNA is only required to provide three data points to publish a CVE record. Gamblin revealed a startling statistic: the only quality check performed on these three fields is that the description must be a string between 1 and 4,916 characters. This minimal barrier has led to an influx of incomplete, vague, or outright unhelpful CVE descriptions, some as short as three or four words, rendering them almost useless for actionable intelligence. This problem is exacerbated by the fact that, according to data from Dr. Benjamin Edwards, 20% of all published CVEs don't even meet the minimum three-field requirement, often missing essential product information.

Beyond the minimal publication requirements, the underlying data schemas themselves present significant hurdles. The CVE schema boasts 163 keys, yet only 60% of these keys have a description, and a mere 50% specify the expected data type. Of the nine total required fields for CVE publication, six are automated, leaving just three to be supplied by the CNA. The NVD schema is even more opaque, with 262 keys, only 3% of which have descriptions, and just one field is strictly required for NVD publication. This lack of clarity and enforcement in schema design contributes directly to the inconsistent and often incomplete data that proliferates through the system. Furthermore, the fragmentation of data sources—CVE.org's GitHub repository, NVD's bulk downloads (using schema 1.1), and NVD's API (using schema 2.0)—creates a complex and often contradictory landscape for data consumers, making it challenging to establish a single source of truth or to perform consistent data analysis.

Key Findings

▶ Watch: Examples of unhelpfully short CVE descriptions (3:00)

Gamblin's presentation illuminated several critical findings regarding the quality and accessibility of CVE data, which collectively paint a picture of a system struggling to meet the demands of modern cybersecurity.

First, the most striking finding is the minimalist approach to CVE publication requirements and quality control. With only three required fields for a CVE record, and the sole quality check being a character count for the description, the system is inherently prone to receiving insufficient data. Gamblin showcased real-world examples of CVE descriptions that were just a few words long, such as "Elevation of privilege," which provide no context or actionable information for defenders. This lax standard means that a significant portion of published CVEs offers little practical value, forcing consumers to spend additional time and resources to enrich the data themselves, if possible.

Second, the speaker highlighted the incompleteness of CNA records. Citing research from Dr. Benjamin Edwards, Gamblin noted that outside of the top three required fields, the completeness of CVE records drops off dramatically across CNAs. Alarmingly, 20% of all CVEs published on CVE.org fail to include the third implied required field, often the affected product information, making them fundamentally incomplete even by the current low standards. This pervasive incompleteness undermines the very purpose of CVEs as a universal identifier for vulnerabilities.

Third, Gamblin identified a significant problem with data schema documentation and enforcement. Both the CVE and NVD schemas, despite their complexity, suffer from poor documentation. The CVE schema has 163 keys, but only 60% are described, and 50% lack data type specifications. The NVD schema is worse, with 262 keys and only 3% described. This lack of clear definitions makes it difficult for CNAs to correctly populate fields and for consumers to accurately interpret the data. The absence of strict validation means that even when fields are populated, there's no guarantee of consistency or correctness.

Fourth, the talk underscored the fragmentation and instability of CVE data access. The CVE program's decision to deprecate its public API in favor of a GitHub repository for bulk data access has created new barriers. While GitHub offers cost-effective storage, its structure (data organized by CVE identifier year, not publication year) complicates quick data analysis and integration into open-source projects. Gamblin noted a significant drop in open-source projects utilizing raw CVE data since this change. Concurrently, the NVD suffers from instability and schema inconsistencies, offering bulk downloads in a 1.1 schema and an API in a 2.0 schema, making data comparison and integration a constant challenge. This multi-source, inconsistent environment forces data consumers to build complex ingestion pipelines, often dealing with conflicting information.

Finally, Gamblin pointed out the reliance on unsupported community tooling. The most popular tool for publishing CVEs, Vulnerogram, is an open-source project maintained by a single individual without official support or compensation from the CVE program. This reliance creates a single point of failure and has even stalled schema updates because the maintainer lacked the time to update the tool. This situation highlights a critical gap in the CVE program's operational strategy, where essential functions depend on altruistic community efforts rather than formalized, program-backed support.

Technical Deep Dive

▶ Watch: Poor quality and documentation of CVE and NVD schemas (3:30)

The technical underpinnings of the CVE data quality issue are multifaceted, revolving around schema design, data access mechanisms, and the absence of robust validation. Gamblin meticulously dissected these areas, revealing the technical debt and architectural choices that contribute to the current challenges.

At the core of the problem lie the CVE and NVD schemas. The CVE schema is a complex structure with 163 unique keys. However, a significant deficiency is the lack of comprehensive documentation: only 60% of these keys have a description, and a mere 50% define the expected data type. This ambiguity creates a fertile ground for inconsistent data entry and interpretation. While nine fields are technically "required" for a CVE record to pass through the publication system, only three of these are expected to be manually provided by the CNA. The remaining six are automated, meaning the program itself injects them. This leaves a critical reliance on CNAs to provide essential details such as product information, which, as Gamblin highlighted, is often missing in 20% of published CVEs.

The NVD schema presents an even more dire technical landscape. It encompasses 262 keys, yet an astonishingly low 3% of these keys are described. Furthermore, only one field is strictly required for NVD publication. While the NVD enriches CVEs with crucial metadata like CVSS scores and CWE identifiers, the underlying schema's lack of clarity makes it a challenging platform for consistent data contribution and consumption. The stark contrast in schema documentation and required fields between CVE.org and NVD contributes to the "source of truth" dilemma, where consumers are left to reconcile potentially conflicting or incomplete information from different feeds.

The data access strategy employed by the CVE program further exacerbates technical difficulties. The CVE program has transitioned away from a public API, opting instead to publish all CVE data to a GitHub repository. While this approach reduces operational costs for the program, it introduces significant technical overhead for data consumers. The data in the GitHub repository is structured into folders based on the CVE identifier year (e.g., CVE-2025-XXXXX), not the publication year. This means that to find all CVEs published in 2025, a user cannot simply download the "2025" folder; they would need to download the entire dataset and then parse it by the datePublished field, which is computationally inefficient and complex for quick analysis or integration into open-source projects. Gamblin noted that this change has "really stopped the use of CVE data in open source projects. Period."

Compounding this, the NVD provides bulk download access using its 1.1 schema, while its API operates on the newer 2.0 schema. This schema version disparity means that organizations attempting to combine data from NVD's bulk downloads and its API must contend with two different data structures, making data comparison and integration a non-trivial task. This technical inconsistency, coupled with NVD's known instability, leaves data consumers with a fragmented and unreliable ecosystem for obtaining comprehensive vulnerability information.

Gamblin also proposed several technical enhancements, including making CVSS, CPE, and CWE mandatory fields. This would necessitate a more robust validation framework, potentially involving regular expressions (regex) for basic structural checks and, critically, minimal AI tooling. He suggested that AI could be employed to "suggest improving descriptions," "suggest CWEs and CVSS scores and CPEs." Citing a previous talk, he mentioned a simple AI model that could predict CWEs with 95% accuracy for fractions of a cent per run. Such tooling, if integrated into officially supported CNA publication tools (GUI, CLI, SDKs), could dramatically improve data quality at the point of origin, ensuring richer, more consistent records without placing an undue burden on CNAs. The concept of including VEX (Vulnerability Exploitability eXchange) or simple markdown/plain text versions of advisories directly into CVE records is a technical solution to the pervasive problem of link rot, ensuring historical context remains available even if original source links disappear.

In summary, the technical deep dive reveals a CVE ecosystem characterized by underspecified schemas, challenging data access mechanisms, and a lack of integrated, officially supported tooling and validation processes. Addressing these technical shortcomings is paramount to elevating the quality and utility of CVE data.

Demo / Proof of Concept

▶ Watch: The fundamental "source of truth" problem for CVE data (6:00)

While Jerry Gamblin's talk did not include a live demonstration or a new proof of concept for exploiting vulnerabilities, he alluded to the potential of AI tooling as a powerful proof of concept for improving CVE data quality. He referenced a specific example where a simple AI model was developed to suggest CWEs based on vulnerability descriptions. This model, costing "0.001 cent to run," reportedly achieved "95% accuracy" in its predictions.

Gamblin emphasized that such AI-driven capabilities already exist and could be integrated into the CVE publication process. The vision is for AI to assist CNAs by:

• Suggesting improved descriptions to enhance clarity and completeness.
• Proposing appropriate CWEs to categorize vulnerabilities accurately.
• Estimating CVSS scores to aid in severity assessment.
• Identifying relevant CPEs for product identification.

The core idea is that even a "95% accuracy guess" from an AI is significantly better than blank fields or manually entered, inconsistent data. This concept serves as a compelling proof of concept for how technology, specifically AI, could be leveraged to automate and standardize the enrichment of CVE records, moving beyond the current manual, error-prone, and often incomplete data entry methods. The absence of a live demo underscored the current gap: while the technology exists, the CVE program has yet to invest in or integrate such tooling into its official workflows, leaving a significant opportunity for improvement untapped.

Defensive Implications

▶ Watch: Difficulties with bulk CVE data access and APIs (6:50)

The implications of poor CVE data quality for defenders are profound and far-reaching. Organizations and security professionals rely on CVEs as a primary source of truth for identifying and managing vulnerabilities within their systems. When this data is incomplete, inaccurate, or difficult to access, their ability to protect assets is severely hampered.

For vulnerability management teams:

• Increased Manual Effort: Incomplete CVE descriptions or missing metadata (CVSS, CWE, CPE) force teams to spend significant time manually researching each vulnerability, cross-referencing multiple sources, and attempting to infer critical details. This diverts resources from actual remediation efforts.
• Ineffective Prioritization: Without reliable CVSS scores, accurate CPEs, or clear CWE mappings, it becomes nearly impossible to prioritize vulnerabilities effectively. Defenders may over-prioritize low-risk issues or, more dangerously, miss critical vulnerabilities that pose an immediate threat.
• Delayed Patching Cycles: The ambiguity in CVE data can lead to delays in identifying affected products and applying necessary patches, leaving systems exposed for longer periods.
• Supply Chain Risk: When software bills of materials (SBOMs) are generated, they rely on accurate CVEs to identify known vulnerabilities in components. Poor CVE data means SBOMs might be less effective in conveying actual risk.

For security product vendors and open-source projects:

• Product Inaccuracy: Companies like Cisco, which integrate CVE data into their security products (e.g., vulnerability management platforms, XDR, AI platforms), face challenges in providing accurate and actionable intelligence to their customers. Inaccurate source data leads to less effective security tools.
• Hindered Open-Source Development: The difficulty in accessing and parsing CVE data from the GitHub repository, coupled with schema inconsistencies, discourages open-source projects from building tools that leverage this critical information. This stifles innovation and community-driven solutions for vulnerability analysis.

Defensive Actions and Recommendations based on Gamblin's proposals:

1. Demand Higher Quality Data: Defenders should advocate for the CVE program to implement mandatory fields like CVSS, CPE, and CWE. This pressure from data consumers can drive necessary changes.
2. Utilize Multiple Data Sources (for now): Given the current inconsistencies, defenders should not rely solely on NVD or CVE.org. Cross-referencing with other sources like OSV (Open Source Vulnerability), GitHub Security Advisories, and vendor-specific advisories can help fill gaps and validate information.
3. Invest in Internal Data Enrichment: Organizations may need to develop internal processes or tools to enrich incomplete CVE data. This could involve using internal threat intelligence, historical data, or even leveraging commercial tools that specialize in vulnerability intelligence.
4. Support Standardized Tooling and Data Formats: Defenders should support initiatives for official, standardized tooling for CVE publication and the adoption of formats like VEX (Vulnerability Exploitability eXchange). VEX, which indicates whether a product is affected by a vulnerability, directly addresses the problem of missing context.
5. Engage with the CVE Community: Gamblin urged community involvement in working groups (like the Quality Working Group) and suggested activities like hackathons and Kaggle competitions. Defenders can contribute to these efforts to improve data quality and accessibility.
6. Advocate for Transparency and Training: The call for public scorecards for CNAs and certification programs for both CNAs and data consumers would foster accountability and improve understanding of the data. Defenders should encourage their organizations to participate in such training if it becomes available.
7. Push for Better Communication: An official, well-maintained communication channel (like a recognized Slack workspace) would allow defenders to provide feedback, ask questions, and stay informed about program changes more effectively.

Ultimately, the defensive implications of poor CVE data quality underscore the need for a collective effort to raise the bar. Defenders are at the receiving end of this data pipeline, and their ability to secure systems is directly tied to the quality of the information they receive.

Key Takeaways

• CVE Data Quality is Critically Low: The current system allows for the publication of CVEs with minimal information, often just a few words, and lacks robust quality checks, leading to significant gaps and inaccuracies.
• Schema Inconsistencies and Access Barriers: Both CVE.org and NVD suffer from poorly documented schemas and fragmented data access methods (GitHub repo vs. APIs with different schemas), making data difficult to consume and integrate for analysis and product development.
• Mandatory Fields are Essential: To improve utility, fields like CVSS, CPE, and CWE should become mandatory for CVE publication, shifting the responsibility for enrichment back to the CNAs.
• Official Tooling and AI Integration are Needed: The CVE program must invest in developing and maintaining standardized publication tooling (GUI, CLI, SDKs) and integrate minimal AI capabilities to suggest descriptions, CWEs, CVSS scores, and CPEs, improving data quality at the source.
• Community Collaboration is Key: The path forward requires active participation from all stakeholders, including an open-source working group, hackathons, improved communication channels (e.g., an official Slack), and increased presence at major security conferences.
• Transparency and Education are Crucial: Implementing public scorecards for CNA data completeness and offering certification/training programs for both CNAs and data consumers will foster accountability and a deeper understanding of CVE data usage.

About the Speaker(s)

Jerry Gamblin is a member of the Threat Detection and Response group at Cisco. In this role, he is deeply involved in developing and inputting vulnerability data into Cisco's diverse product offerings, including Cisco Vulnerability Management, XDR platforms, and various AI platforms. His work positions him as a significant consumer of CVE and NVD data, giving him a unique perspective on the challenges of data quality, distinct from those involved in Cisco's CNA groups like Talos. Beyond his work at Cisco, Gamblin is an active participant in the CVE program's Quality Working Group and Automation Working Group, reflecting his commitment to improving the integrity and utility of vulnerability information for the entire cybersecurity community.