CVE Record Format - Purl and CPE Workshop

CVE Record Format - Purl and CPE Workshop

Speakers: Chris Coffin (CVE Board Member, Co-Chair of Quality Working Group, MITRE); MZ MegaZone (Co-Chair of Quality Working Group, F5, Inc.)

Conference: VulnCon

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

Overview

In a detailed session at VulnCon, Chris Coffin from MITRE and MZ MegaZone from F5, both co-chairs of the CVE Quality Working Group, illuminated significant enhancements to the CVE record format. Their talk, "CVE Record Format - Purl and CPE Workshop," focused on the integration of Package URL (PURL) and Common Platform Enumeration (CPE), marking a pivotal step towards more precise and unambiguous software identification in vulnerability records. These additions, introduced in CVE record format versions 5.2.0 (for PURL) and 5.1.1 (for CPE), aim to address long-standing challenges in reliably identifying affected products across diverse and often inconsistent naming conventions.

The speakers provided a comprehensive overview of what PURL and CPE are, how they are structured, and their practical application within the CVE JSON schema. They emphasized the importance of these standardized identifiers for improved automation, data interoperability, and the overall quality of vulnerability information. While acknowledging the ongoing evolution and the optional nature of these fields, Coffin and MegaZone underscored the CVE program's commitment to adapting its record format to meet the growing demands of the cybersecurity ecosystem, particularly in the realm of software supply chain security and automated vulnerability management.

Background

▶ Watch: Introduction to CVE record format, PURL, and CPE (0:00)

The CVE record format serves as the foundational JSON schema used by CVE Numbering Authorities (CNAs) and authorized data publishers to describe vulnerabilities. This format is crucial for third-party tools to ingest, display, and process CVE records, enabling a standardized approach to vulnerability information exchange. Historically, identifying software packages reliably across various ecosystems and distribution channels has been a persistent challenge. Different vendors, projects, and package managers often employ unique naming conventions, leading to ambiguity and hindering automated analysis.

Prior to the recent updates, the CVE record format had a rudimentary mechanism for including CPE data, which proved largely ineffective. This older approach allowed for an array of CPE values, but crucially lacked the necessary context or "applicability statements" to clarify what those CPEs represented – whether they were fixed versions, vulnerable versions, or a mix. As a result, this led to inconsistent usage by CNAs, rendering the data difficult to parse and automate reliably. This deficiency highlighted a critical need for a more structured and expressive method for software identification, especially as the volume and complexity of vulnerabilities grew, and the demand for automated vulnerability management intensified. The CVE Quality Working Group, co-chaired by the speakers, took on the task of addressing these issues, leading to the strategic decision to integrate robust, standardized identifiers like PURL and CPE applicability statements into the core CVE record format.

Key Findings

▶ Watch: How PURL is added to CVE record format (7:00)

The central contributions of this talk revolve around the strategic and technical decisions behind integrating PURL and CPE into the CVE record format.

1. Adoption of Package URL (PURL) in CVE Record Format 5.2.0: PURL provides a universal, URL-based syntax for identifying software packages, designed to cut through the ambiguity of diverse naming conventions across ecosystems (e.g., RPM, NPM, Gem). Its recent adoption by ECMA (version 1.0.0, quickly updated to 1.0.02) signifies its growing recognition as an industry standard. The CVE format now allows for the inclusion of PURL as a single object, though notably, the version component within the PURL string itself is not supported. Instead, CNAs are instructed to use the existing versions array within the CVE record's affected array to define version ranges, preventing potential conflicts and inconsistencies if two different versioning mechanisms were simultaneously active.

1. Enhanced Common Platform Enumeration (CPE) Integration with Applicability Language in CVE Record Format 5.1.1: Building on the existing but flawed CPE integration, CVE 5.1.1 introduced the CPE Applicability Language. This robust mechanism, closely mirroring the NIST NVD schema, allows for complex logical expressions of CPEs. It moves beyond simple lists to define precise conditions under which a product is affected (e.g., "product X running on OS Y"). This structured approach overcomes the prior "broken" CPE array, which lacked context regarding whether listed CPEs represented fixed or vulnerable versions, leading to inconsistent and unusable data for automation.

1. Optionality of PURL and CPE: A significant finding and a point of ongoing discussion is the decision to make both PURL and CPE entirely optional within the CVE record format. This choice reflects a pragmatic balancing act. While these identifiers offer immense value for automation and precision, requiring them universally would impose a high barrier to entry for many CNAs, some of whom explicitly state they would cease publishing CVEs if mandatory. This optionality accommodates different community needs (e.g., open source communities often prefer PURL, while commercial vendors might use CPE), varying tooling maturity, and the diverse nature of vulnerabilities (e.g., PURL's current scope is primarily limited to packages, making it unsuitable for commercial software or hardware-level vulnerabilities).

1. Strategic Evolution and Community Engagement: The Quality Working Group actively evaluates other proposed identifiers (e.g., Omnibor) but exercises caution, ensuring sufficient community demand and practical utility before adding them to the standard. This demonstrates a commitment to evolving the format responsibly, avoiding the burden of supporting unused or premature standards. The ongoing discussions about potentially requiring more fields (like CWE or CVSS) indicate a maturation of the CVE program, moving beyond just quantity to focus on the quality and richness of vulnerability data, while still navigating diverse stakeholder opinions.

Technical Deep Dive

▶ Watch: CPE applicability language and rationale for CVE inclusion (14:00)

The integration of PURL and CPE into the CVE record format represents a significant technical upgrade, moving towards more machine-readable and unambiguous vulnerability data.

Package URL (PURL) Integration

PURL, adopted in CVE record format 5.2.0, is a standardized, URL-based syntax designed to identify software packages independently of their ecosystem or distribution channel. Its structure is composed of up to seven parts, designed to decrease in significance from left to right:

pkg:<type>/<namespace>/<name>@<version>?<qualifiers>#<subpath>

1. pkg:: The required scheme or constant value indicating a package URL.
2. <type>: The type of package system or protocol (e.g., npm, maven, rpm, gem). This is required.
3. <namespace>: An optional segment for grouping packages, such as an organization or user name.
4. <name>: The actual name of the package (required).
5. @<version>: The version of the package.
6. ?<qualifiers>: Optional attributes like OS, architecture, or repository.
7. #<subpath>: An optional path within the package.

A critical design decision in CVE's PURL integration is the explicit exclusion of the PURL's native version component (@<version>). Instead, CNAs are required to define the package name within the PURL object without a version, and then use the CVE record's existing versions array within the affected array to specify vulnerable and fixed version ranges. This approach, validated by CVE services, prevents potential inconsistencies and conflicts that could arise from having two disparate versioning mechanisms within the same record. PURL is included as a single object within the CVE JSON, making its integration relatively straightforward, though currently requiring direct JSON editing via Vulnogram's source tab until native editor support is implemented.

Common Platform Enumeration (CPE) Integration

CPE, integrated in CVE record format 5.1.1, is a structured naming scheme for identifying platforms, products, and software packages. While CPE itself has been around since the mid-2000s (with CPE 2.3 released in 2011), its effective integration into CVE records required the adoption of the CPE Applicability Language. This language defines a standard structure for expressing complex logical relationships between multiple CPEs, enabling highly granular vulnerability definitions.

The standard CPE 2.3 format includes 11 fields, with part (application, OS, hardware), vendor, product, and version being the most commonly used. Other fields often appear as asterisks, signifying "any." Unlike PURL, CPE relies on an official dictionary hosted by NIST NVD, making adherence to this dictionary crucial for interoperability and automation.

Within the CVE record format, CPE is included under a dedicated cpeApplicability array, which replaces the configurations array found in the NIST NVD schema to avoid naming conflicts with existing CVE JSON objects. This cpeApplicability array contains nodes, which in turn contain cpeMatch items. Each cpeMatch item can specify one or more CPE names or match criteria, along with properties like vulnerable (true/false) and version ranges.

The power of the CPE Applicability Language lies in its ability to construct complex logical expressions using and and or operators. For example, a vulnerability might affect "Mozilla Firefox 3.6 running on Microsoft Windows Vista." This "running on with" concept is expressed by structuring multiple CPEs within nodes, where an and operator ensures all specified conditions must be met for a match. The or operator allows for multiple distinct conditions that could trigger a match. This intricate structure enables CNAs to precisely define affected environments, moving far beyond simple product-version declarations. For instance, a complex .NET Framework CVE might specify different affected versions conditional on different Windows Server versions and architectures (e.g., X86 or X64).

A key difference from the NIST NVD schema is that while NVD includes a matchCriteriaID to identify its criteria, this field is optional in the CVE record format and not currently used by CVE services, though it's allowed for ease of data migration from NVD. The Vulnogram editor supports adding CPEs, but direct JSON manipulation in the source tab is often required for the most complex applicability statements, with native PURL support still in development. The speakers strongly advise against adding CPEs that do not exist in the NIST NVD official dictionary, as this undermines the purpose of a standardized dictionary.

Demo / Proof of Concept

▶ Watch: Advanced CPE applicability examples for complex scenarios (25:00)

While the talk did not feature a live demonstration of a new tool or a proof-of-concept exploit, the speakers provided extensive and crucial examples of how PURL and CPE are structured and integrated into the CVE record format. These examples served as a "technical walkthrough" rather than a traditional demo, illustrating the practical application of these identifiers within the JSON schema and their mapping to known vulnerability contexts.

For PURL, the examples showcased its concise, URL-based structure (e.g., pkg:npm/mypackage, pkg:maven/org.apache.commons/[email protected]). The critical point demonstrated was how the CVE JSON schema would represent a package URL without its version component, directing users to specify versions in the separate affected array. This highlighted the architectural decision to consolidate version management.

For CPE, the examples were more elaborate, demonstrating the power of the CPE Applicability Language.

1. Single CPE Match: A basic example showed a CPE string (e.g., cpe:2.3:a:microsoft:.net_framework::::::::) with an associated version property defining a range (e.g., upToIncluding: "4.5.7").
2. "Running On With" Configuration: This illustrated how to define a product affected only when it runs on a specific operating system or hardware. An example involving Netgear firmware (an O for OS) running on Netgear hardware (an H for hardware) demonstrated how multiple CPEs are logically ANDed together within a node to represent such a dependency.
3. Multiple Affected Branches with OR Logic: A more complex scenario showed two distinct product branches (e.g., 1.x and 2.x) affected by the same vulnerability. The JSON structure used an or operator within a cpeMatch array, allowing either branch to satisfy the vulnerability condition. Real-world kernel vulnerabilities, often affecting multiple version branches, were cited as prime examples of this structure.
4. Advanced Configurations with AND Logic: The speakers presented intricate examples, such as a product affected only when present on either a specific hardware appliance or a specific operating system (e.g., a Linux kernel). This involved multiple node items within the cpeApplicability array, demonstrating how AND logic can be applied at higher levels to combine conditions. A highly detailed .NET Framework CVE, with numerous affected versions conditional on specific Windows Server versions and architectures (X64, X86), was used to illustrate the complexity achievable with these structures.

The speakers also touched upon the tooling aspect, specifically mentioning Vulnogram. They explained that Vulnogram currently supports adding CPEs, where an "auto-update" feature attempts to generate CPE names based on product and version inputs. However, for precise control or to add PURLs (which lack native editor support today), users must resort to manually editing the JSON in Vulnogram's "source tab." This demonstrated the current state of tooling adoption and the need for CNAs to be comfortable with direct JSON manipulation for advanced use cases.

Defensive Implications

▶ Watch: Q&A: Addressing firmware and future CPE evolution (40:00)

The enhanced CVE record format, with the inclusion of PURL and CPE Applicability Language, carries significant implications for defenders, enabling more precise, automated, and effective vulnerability management strategies.

1. Improved Automation and Tooling: The primary benefit is the ability to automate vulnerability detection and assessment more reliably. Standardized identifiers like PURL and CPE allow security tools, vulnerability scanners, and Software Bill of Materials (SBOM) platforms to parse CVE records with greater accuracy, reducing reliance on natural language processing of descriptions. This means faster, more consistent identification of affected components in a defender's environment.

1. Precise Asset Identification: The CPE Applicability Language is a game-changer for pinpointing vulnerable assets. Instead of merely knowing a product is affected, defenders can now determine if their specific configuration (e.g., "Product A version X running on OS B version Y") is truly vulnerable. This granularity helps prioritize remediation efforts, reducing false positives and focusing resources on actual risks. For instance, a Linux kernel vulnerability might only apply to specific distributions or hardware architectures, which CPE can now explicitly state.

1. Enhanced Software Supply Chain Security: PURL, with its ecosystem-agnostic nature, is particularly valuable for SBOMs. As organizations increasingly rely on open-source components, PURL provides a consistent way to identify these dependencies, regardless of their origin (NPM, Maven, PyPI). This allows defenders to cross-reference SBOMs with CVE data more effectively, improving visibility into the vulnerability posture of their software supply chain.

1. Advocacy for Data Quality: Defenders should advocate for CNAs to include PURL and CPE data in their CVEs. The optional nature of these fields means their utility depends on widespread adoption. Organizations consuming CVE data should encourage their vendors and open-source projects to leverage these identifiers to enrich the vulnerability information provided.

1. Understanding Limitations: It's crucial for defenders to understand that not all CVEs will contain PURL or CPE data, either due to the optionality or the specific nature of the vulnerability (e.g., PURL's current focus on packages). This means fallback mechanisms, such as careful reading of descriptions and leveraging other fields like CWE or CVSS, will still be necessary. Defenders should also be aware that CPEs must exist in the NIST NVD dictionary to be truly useful for automation; if a vendor's product CPE is missing, defenders may need to engage with NIST to have it added.

1. Future-Proofing and Engagement: The ongoing work of the CVE Quality Working Group indicates a continuous evolution of the record format. Defenders who have specific needs or feedback regarding software identification should consider joining relevant CVE working groups (e.g., the Consumer Working Group) to contribute to future improvements and ensure the format meets their operational requirements.

Key Takeaways

• PURL and CPE Integration: The CVE record format has been significantly enhanced with the addition of Package URL (PURL) in version 5.2.0 and the CPE Applicability Language for Common Platform Enumeration (CPE) in version 5.1.1, enabling more precise software identification.
• PURL's Universal Identification: PURL offers a standardized, URL-based syntax (e.g., pkg:npm/mypackage) for identifying software packages across diverse ecosystems, reducing ambiguity in vulnerability data.
• CPE Applicability for Granular Context: The CPE Applicability Language allows for complex logical expressions of CPEs, enabling CNAs to define precise conditions (e.g., "Product A on OS B") under which a vulnerability applies, significantly improving the context of vulnerability records.
• Optionality for Broad Adoption: Both PURL and CPE are optional fields in the CVE record format, a pragmatic decision to balance the desire for rich, structured data with the diverse capabilities and needs of CNAs globally.
• NIST NVD Dictionary for CPE: Effective use of CPE relies on its presence in the official NIST NVD dictionary; CNAs are strongly encouraged to ensure CPEs are registered there, and defenders should be aware of this dependency.
• Continuous Evolution: The CVE Quality Working Group remains committed to evolving the record format, actively considering other identifiers and community feedback to improve the quality and utility of CVE data, though new additions are carefully vetted for widespread demand and practical application.

About the Speaker(s)

Chris Coffin and MZ MegaZone are key figures in the evolution of the CVE program, particularly concerning the CVE record format. Chris Coffin, representing MITRE, is a CVE Board Member and serves as a Co-Chair of the Quality Working Group. MZ MegaZone, from F5, Inc., also holds the position of Co-Chair of the Quality Working Group alongside Chris. Their shared roles involve actively addressing issues related to the CVE record format, driving its enhancements, and overseeing the integration of new standards like PURL and CPE. Their combined expertise is instrumental in guiding the CVE program's technical direction and ensuring the format remains relevant and effective for the global cybersecurity community.