CVE Record Format - Past, Present, and Future

CVE Record Format - Past, Present, and Future

Speakers: Chris Coffin, MITRE; MZ, Principal Security Engineer, F5

Conference: VulnCon

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

Overview

This talk, presented by Chris Coffin from MITRE and MZ from F5—both co-chairs of the CVE Quality Working Group (QWG) and CVE Board members—delves into the evolution and future trajectory of the CVE record format. The presentation offers a comprehensive look at the current state, recent enhancements, and upcoming changes to the JSON schema that underpins how vulnerability information is ingested, stored, and displayed by the CVE Program. It highlights the critical role of the format in standardizing vulnerability data, ensuring consistency, and facilitating its consumption across the cybersecurity ecosystem.

The speakers emphasize the program's shifting focus from primarily supporting CNAs (CVE Numbering Authorities) in data submission to actively engaging consumers of CVE data. This strategic pivot aims to enhance the utility and quality of vulnerability information for a broader audience, enabling better automation, prioritization, and defensive strategies. The discussion covers significant updates like the integration of CVSS4 and robust CPE applicability statements, alongside future considerations such as standardized semantic versioning (SEver), support for alternative software identifiers like Pearl, and formalizing Stakeholder-Specific Vulnerability Classification (SSVC).

Ultimately, the talk underscores the CVE Program's commitment to continuous improvement, data quality, and community collaboration. By detailing the mechanisms for format evolution—including GitHub pull requests and working group discussions—Coffin and MZ invite active participation from both data producers and consumers. This collaborative approach is vital for shaping a CVE record format that is not only technically sound but also practically valuable in addressing the complex challenges of modern vulnerability management.

Background

▶ Watch: Introduction to CVE record format and talk overview. (0:00)

The CVE record format serves as the fundamental blueprint—a JSON schema—that dictates the structure and requirements for all vulnerability information within the CVE Program. It defines what data elements CNAs must provide when submitting CVE records and how that data is subsequently displayed to the public. The current stable version of this format is 5.1.1, with work actively underway on 5.1.2. Understanding this format is crucial because it directly influences the type and quality of vulnerability data available to the industry, encompassing critical details like affected products, versions, and severity metrics such as CVSS.

Historically, the CVE Program's efforts have largely focused on supporting CNAs in the supply side of vulnerability disclosure, helping them to define and submit better data. However, as noted by the speakers, this approach has often left consumers of CVE data with an imbalance, where information is published with the expectation that it will simply be consumed, without sufficient feedback mechanisms from the demand side. A significant point of discussion in the talk, echoing sentiments from other conference presentations (such as Andrew Pollock's comparison of CVE and OSV), is the acknowledged need to improve data quality within the CVE Program. The existing minimum requirements for record submissions are currently quite minimal, leading to ongoing debates about what additional requirements, if any, should be enforced to ensure more comprehensive and actionable data.

In response to this, a key initiative highlighted is the program's intent to establish a consumer working group. This initiative marks a strategic shift, aiming to gather organized feedback directly from the consumers of CVE data to better shape the program and its record format. This move recognizes that while CNAs provide the initial data, the ultimate utility and impact of CVEs depend on how effectively that information can be consumed, analyzed, and integrated into defensive strategies by a diverse range of stakeholders. This foundational shift is expected to drive future enhancements, making the CVE record format more robust, flexible, and responsive to the real-world needs of the cybersecurity community.

Key Findings

▶ Watch: Why CVE record format matters for data and requirements. (2:50)

The talk outlined several key findings and developments regarding the CVE record format, highlighting both recent achievements and future directions.

Recent Releases and Enhancements:

• CVE Record Format 5.1.0 (May 2024): This release marked a significant update by adding official support for CVSS4. This was a highly anticipated feature, with major CNAs like Microsoft and Red Hat already beginning to utilize it due to pent-up demand. The release also involved a formal name change from "JSON CVEJ JSON 5" to the more direct "CVE record format" and included general tightening of various schema validations.
• CVE Record Format 5.1.1 (December 2023): A crucial improvement in this version was the ability to add CPE (Common Platform Enumeration) data in a far more robust and usable manner. Previous versions allowed CPEs as a simple array, but without context (e.g., vulnerable vs. fixed), making the data downstream largely useless. Version 5.1.1 adopted a format mirroring the NVD vulnerability details' applicability statements, allowing for clear definition of CPEs, including version ranges and relationships. This change significantly enhanced interoperability and data clarity, with Microsoft being an early flagship adopter. Documentation, including a "Using CPE in CVE Quick Start Guide," was also released to support this.
• Minor Updates: Version 5.1.1 also included a "miscellaneous update" that modified example CVE records to use a non-clashing namespace (e.g., CVE-1900-xxxx) for illustrative purposes.

Upcoming Developments (Working on 5.1.2 and Beyond):

• Schema Tightening (for 5.1.2): Further refinements are underway, specifically targeting the affected array to disallow additional properties and correct mistyped property names, aiming to improve data quality and consistency. Documentation updates are also part of this effort.
• Standardized Version Validation (SEver): A major focus is on introducing a new version type called SEver (Semantic Versioning). Currently, existing version types lack validation, meaning data provided as "SEver" isn't actually checked for compliance. The new sever type will enforce validation against the Zenbear standard, a significant step towards automating data quality and consistency.
• Support for Other Software Identifiers: Recognizing the lack of a universally accepted software identifier, the program is exploring ways to integrate other identifiers like Pearl (widely adopted in open source) and Omnibore. There are ongoing debates about how best to represent these within the format, with current proposals including an applicability language similar to CPE or a more abstracted, generic representation that allows dynamic addition of new schemes without frequent schema changes.
• Official SSVC Support: The Stakeholder-Specific Vulnerability Classification (SSVC), currently used by CISA ADP via a custom metric, is slated for official support. This involves integrating the specific SSVC schema and its properties into the CVE record format, moving away from less standardized "experimental" or "custom" fields, and enabling validation.
• Formal Property Removal/Deprecation Process: Acknowledging that the format will need to evolve by removing or deprecating obsolete properties (like the old, unusable CPE array), the program is beginning to formulate a formal process. This will involve phased approaches, clear communication with CNAs (e.g., 6-12 month migration windows), and mechanisms for warnings and eventual rejection of old formats.

Technical Deep Dive

▶ Watch: Future focus: Consumers and new working group announced. (4:05)

The CVE record format is fundamentally a JSON schema that dictates the precise structure and content requirements for CVE records. This schema acts as a "blueprint" for both CNAs when they submit vulnerability information and for how the CVE Program displays that information to the public. The current version, 5.1.1, is a testament to continuous refinement, with version 5.1.2 already in development.

A significant technical advancement in CVE Record Format 5.1.0 was the integration of CVSS4. This update allowed for the inclusion of the latest version of the Common Vulnerability Scoring System, providing more granular and context-rich severity metrics. The JSON schema was updated to accommodate the specific fields and structures required by CVSS4, making it possible for CNAs to provide this advanced scoring directly within the CVE record.

Perhaps the most impactful technical change in 5.1.1 was the overhaul of how CPE (Common Platform Enumeration) data is handled, introducing CPE applicability statements. Prior to this, the format allowed for a simple array of CPE strings, which proved largely unusable. As MZ explained, "there was nothing to indicate what those values actually meant." Some CNAs used it for fixed CPEs, others for vulnerable CPEs, leading to ambiguity for consumers. The solution involved adopting a format highly similar to the NVD vulnerability details' "configurations" section. This new structure allows CNAs to define CPEs with context, specifying whether a product is "vulnerable," "affected," or "fixed," and supports complex version ranges (e.g., versionStartIncluding, versionEndExcluding). Although the top-level name was changed to CPE applicability, the underlying JSON structure closely mirrors NVD, facilitating data portability and consistency. The schema now permits defining a CPE identifier, its version, and a vulnerable: true flag, providing clear, machine-readable context. While the NVD's match criteria ID is not required (as it's NIST-generated), it is allowed for one-to-one mapping.

Further schema tightening is planned for 5.1.2, specifically around the affected array. This involves disallowing additionalProperties and addressing mistyped property names to enhance validation and data integrity. These incremental improvements, as noted by Coffin and MZ, are driven by real-world observations of data submissions, aiming to prevent common errors and improve the overall quality of CVE data.

A major upcoming feature is the introduction of validated SEver (Semantic Versioning). Currently, while the format supports various version types, there's no inherent validation for the data provided against these types. For example, if a CNA specifies a version as SEver, the system doesn't check if it actually adheres to the Semantic Versioning specification. The proposed change involves a new sever version type that will enforce validation according to the Zenbear standard. This is a crucial step for automation, ensuring that version information is consistent and machine-readable. The discussion also touched upon the verse standard, developed in the Pearl community and being adopted as an EMCA standard. Verse offers a generic scheme for handling different versioning systems (npm, pip, etc.) dynamically, potentially allowing the schema to accommodate new versioning schemes without constant modification, thereby reducing maintenance overhead. The Automation Working Group (AWG), which handles CVE services, is also involved in implementing programmatic validations that might not be feasible directly within the JSON schema.

Looking beyond versioning, the CVE Program is actively exploring support for other software identifiers. Recognizing that "there is no universally accepted software identifier right now," the goal is to enable CNAs to use identifiers that best suit their context. Pearl (Package URL), widely adopted in the open-source community, is a prime candidate, with a pull request already existing to add it using an applicability language similar to CPE. Another identifier, Omnibore, also has a pending pull request. A third proposal suggests a generic, abstracted representation to dynamically add new identifier types without modifying the core schema each time.

Finally, the talk highlighted the planned official support for Stakeholder-Specific Vulnerability Classification (SSVC). Currently, CISA ADPs provide SSVC data using a custom metric within experimental fields (e.g., X-generator). The plan is to integrate the specific SSVC schema and its properties, moving it from an ad-hoc implementation to a standardized, validated component of the CVE record. This will ensure consistent data representation and allow for validation, improving the utility and trustworthiness of SSVC information for consumers. The broader discussion of X-generator fields implies a move towards standardizing metadata about the tools used to generate CVEs.

The discussion also touched on the challenging topic of deprecation and property removal. The example of the old, unusable CPE array was cited as a prime candidate for removal. The proposed strategy involves a phased approach, including issuing warnings to CNAs using deprecated fields, providing a migration window (e.g., 6-12 months, as suggested by an audience member drawing on API versioning experience), and eventually rejecting records that do not comply with the updated format. This proactive approach aims to prevent the CVE record format from becoming bloated with obsolete or poorly defined elements, ensuring its long-term maintainability and effectiveness.

Demo / Proof of Concept

▶ Watch: Recent update: CVE Record Format 5.1.0 with CVSS4. (5:15)

This technical article details a conference talk focused on the evolution and future of the CVE record format itself, rather than a demonstration of a specific vulnerability or exploit. As such, the presentation did not include a live demo or a proof of concept of a technical attack. Instead, the "demonstration" was primarily conceptual, illustrating the structure and changes to the JSON schema through examples of how CPE applicability statements are now represented in the format. The speakers showcased basic JSON snippets comparing the old, less usable CPE array with the new, structured format, providing a clear visual of the data improvement.

Defensive Implications

▶ Watch: Recent update: CVE Record Format 5.1.1 with robust CPE. (6:15)

The ongoing evolution of the CVE record format carries significant implications for defenders, promising more robust, actionable, and standardized vulnerability intelligence.

1. Enhanced Data Quality and Automation: The tightening of the schema, especially around the affected array and the introduction of validated SEver, directly translates to higher quality and more consistent data. Defenders relying on automated tools for vulnerability scanning, asset management, and patch prioritization will benefit from cleaner, more reliable input. The ability to automatically validate version strings (e.g., adherence to Zenbear standard for SEver) reduces ambiguity and the need for manual interpretation, improving the accuracy of vulnerability assessments against their asset inventory.
2. Improved Asset Identification and Correlation: The robust CPE applicability statements in 5.1.1 are a game-changer for asset management. By clearly distinguishing between vulnerable and fixed CPEs, and supporting version ranges, defenders can more accurately identify which specific product versions in their environment are affected by a given CVE. This precision reduces false positives and ensures that patching efforts are targeted and efficient, moving away from the "useless" generic CPE arrays of the past.
3. Context-Driven Prioritization with SSVC: The formal integration of SSVC (Stakeholder-Specific Vulnerability Classification) will empower defenders to prioritize vulnerabilities based on their organization's unique operational context. Unlike generic scores like CVSS, SSVC considers factors relevant to the defender, enabling a more nuanced understanding of immediate risk. Standardizing SSVC within the CVE record means defenders can programmatically ingest this context and integrate it into their risk management frameworks, allowing for more strategic resource allocation.
4. Flexibility in Software Identification: The program's openness to incorporating alternative software identifiers like Pearl and Omnibore addresses the diverse landscape of software ecosystems. Defenders working with open-source components, where Pearl is prevalent, will gain direct, standardized links to vulnerability information, simplifying software supply chain security. This flexibility ensures that the CVE record remains relevant across various technology stacks and development practices.
5. Direct Consumer Feedback and Influence: The proposed consumer working group represents a crucial opportunity for defenders to directly shape the CVE record format to meet their operational needs. By participating, defenders can advocate for specific data points, structures, or validations that would enhance their ability to defend effectively. This direct channel ensures that future format developments are driven by practical defensive requirements, not just by data producers.
6. Granular Vendor-Specific Impact (ADP Expansion): The discussion around expanding ADP (Authorized Data Publisher) roles, particularly for vendor CNAs like F5, has profound defensive implications. Currently, a generic CVE might affect a third-party component used in many products (e.g., a Linux kernel CVE). If vendors can publish how such a CVE specifically impacts their products within the CVE record (as an ADP), defenders would no longer need to hunt for separate vendor advisories. This consolidation would provide a single source of truth for product-specific vulnerability impact, streamlining incident response and patch management for complex environments.

In essence, the ongoing improvements to the CVE record format are designed to deliver more precise, context-rich, and machine-readable vulnerability data. This directly aids defenders in automating their security processes, making better-informed decisions, and ultimately strengthening their overall security posture against an ever-evolving threat landscape.

Key Takeaways

• The CVE record format is continuously evolving, with version 5.1.1 currently active and 5.1.2 in development, driven by a focus on data quality and consumer needs.
• Recent major enhancements include the addition of CVSS4 in 5.1.0 and robust CPE applicability statements in 5.1.1, which provide clear context for affected products and versions, mirroring NVD's approach.
• Future developments aim to standardize version validation with SEver (Semantic Versioning), integrate support for alternative software identifiers like Pearl and Omnibore, and formalize Stakeholder-Specific Vulnerability Classification (SSVC).
• The CVE Program is actively seeking feedback from consumers of CVE data, planning to establish a dedicated working group and encouraging participation in the Quality Working Group (QWG) via the CVE-Schema GitHub repo.
• A formal process for deprecation and removal of obsolete properties is being developed to maintain a lean and effective schema, likely involving phased approaches and clear communication to CNAs.
• Expansion of ADPs (Authorized Data Publishers), especially to include vendor CNAs, is being advocated to provide more granular, product-specific vulnerability impact directly within CVE records, reducing the need for defenders to consult multiple external advisories.

About the Speaker(s)

Chris Coffin is a representative from the MITRE Corporation, where he has been working since 2012. A significant portion of his tenure at MITRE has been dedicated to the CVE Program. He is a respected CVE Board member and also serves as a co-chair of the CVE Quality Working Group (QWG), where he primarily focuses on driving the development and refinement of the CVE record format.

MZ is a Principal Security Engineer for F5. Like Chris Coffin, he is also a co-chair of the CVE Quality Working Group and a CVE Board member. MZ brings a strong industry perspective, particularly from the vantage point of a CNA, to the discussions on improving the CVE record format and its utility for both data producers and consumers. Both speakers are deeply committed to enhancing the quality and applicability of CVE data for the global cybersecurity community.