Open Interchange on CPE - Purl Between Communities of Interest and the CVE and NVD Programs

Open Interchange on CPE - Purl Between Communities of Interest and the CVE and NVD Programs

Speakers: Pete, Chris (and various community members)

Conference: VulnCon

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

Overview

This VulnCon session delves into the intricate challenges of software identification within the vulnerability management ecosystem, focusing on the interplay between Common Platform Enumeration (CPE) and Package URL (PURL). Facilitated by Pete and Chris, the discussion brings together experts from various organizations, including Red Hat, MongoDB, Cisco, Oracle, and MITRE, to explore how these identifiers can be better utilized and integrated into the CVE (Common Vulnerabilities and Exposures) and NVD (National Vulnerability Database) programs. The core problem addressed is the pervasive difficulty faced by data consumers—such as security scanners and end-users—in accurately identifying vulnerable software components and understanding the applicability of CVEs to their specific environments.

The talk highlights a critical shift in focus from data producers to data consumers, emphasizing the need for standardized, consistent, and comprehensive software identification to resolve ambiguities and reduce false positives. Participants share their experiences and frustrations with the current state of vulnerability data, particularly concerning versioning, backporting, and the distinction between product and component-level vulnerabilities. The overarching goal is to foster a collaborative environment to refine existing identification mechanisms and explore new approaches that enhance the utility and accuracy of vulnerability intelligence for all stakeholders.

The discussion underscores the urgent need for a unified approach to software identification. With the rapid growth of software supply chains and the increasing complexity of modern applications, the current fragmented landscape of identifiers and inconsistent data practices create significant operational hurdles for effective vulnerability management. By openly discussing these challenges and soliciting community feedback, the session aims to lay the groundwork for a more robust and interoperable future for software security.

Background

▶ Watch: Introduction and Problem Framing: CPE, Purl, Data Consumers (0:00)

The landscape of software vulnerability management is fraught with complexities, largely stemming from inconsistent and often inadequate methods of software identification. Historically, CPE (Common Platform Enumeration) has served as a primary mechanism for naming software applications and operating systems. However, as Pete notes, the CVE dictionary, primarily maintained by NVD, struggles with the breadth and depth required to accurately identify the vast and ever-evolving software landscape. The initial design of CPE, particularly its 2.2 and 2.3 versions, was string-based, making it difficult to handle special characters, complex version ranges, and the granular identification of individual components within larger products.

This limitation has led to a significant "data classification problem," as Pete describes it, where aggregating vulnerability data becomes a headache for consumers. Vulnerability scanners often generate their own CPEs or make assumptions due to a lack of authoritative information from CNAs (CVE Numbering Authorities). As a participant from MongoDB highlighted, CNAs, who are arguably the most authoritative source for their own products, often do not include CPEs in their CVE JSON files, forcing downstream tools to "make it up on the spot." This creates a fragmented ecosystem where a single source of truth is elusive.

The problem is further exacerbated by practices like backporting, common in Linux distributions like Red Hat, where security fixes are applied to older software versions without changing the version number, leading scanners to misinterpret the vulnerability status. Pete from Red Hat emphasizes that vendors often rescore vulnerabilities based on their specific product usage, deviating from the initial CVSS (Common Vulnerability Scoring System) base score, which further complicates accurate assessment for consumers. The inadequacy of CPE for granular component identification has paved the way for alternative identifiers like PURL (Package URL), which are better suited for packages and modules, and Omnibore, designed for non-package manager ecosystems. The session underscores that the industry has historically focused on data producers, but the current challenges demand a pivot towards meeting the needs of data consumers, who are struggling to determine if they are truly vulnerable.

Key Findings

▶ Watch: Challenge of backports and scanner interpretation for consumers (3:45)

The VulnCon discussion unveiled several critical issues and observations regarding software identification and vulnerability management:

1. Lack of a Single Source of Truth: A pervasive problem is the absence of an authoritative, universally adopted source for software product and component identification. While CNAs are considered authoritative for their own products, many do not consistently provide CPEs or PURLs in CVE records. This forces vulnerability scanners and data aggregators to create their own identifiers or make inferences, leading to widespread inconsistencies and false positives.
2. CPE's Limitations and NVD's Backlog: The existing CPE 2.2/2.3 standard is recognized as outdated and insufficient for modern software identification, particularly concerning complex version ranges and specific component details. NVD's role in maintaining the CPE dictionary has also been questioned, with observations that CPE assignments to CVEs have significantly declined, sometimes covering only one-third of new CVEs. This backlog and lack of comprehensive coverage render the CPE dictionary less reliable as an authoritative source.
3. Product vs. Component Identification Dichotomy: A significant challenge is distinguishing between vulnerable products and vulnerable components within those products. Red Hat, for instance, uses CPE for application-level products and PURL for granular component-level identification. This distinction is crucial for accurate vulnerability assessment, especially in complex supply chains or nested software structures (the "parent-child problem").
4. Inconsistent Vulnerability Scoring and Backporting: Vendors like Red Hat often rescore CVEs based on their product's specific usage and protective measures, rather than relying solely on the initial CVSS base score. Additionally, backporting security fixes to older versions without updating package version numbers creates confusion for scanners that rely on version-based identification. The lack of standardized communication for these nuances leads to significant discrepancies in vulnerability reporting.
5. Data Exchange and Standardization Gaps: There's a clear need for better mechanisms to exchange detailed vulnerability data, especially through VEX (Vulnerability Exploitability eXchange) files. While some vendors (like Red Hat) produce VEX data, many downstream consumers and scanning vendors do not yet consume it effectively, leading to critical information gaps. The absence of standardization in how identifiers like CPE and PURL are used across the industry further complicates data interoperability.
6. Guidance Deficit for CNAs: Smaller and newer CNAs, such as MongoDB, expressed a desire for clearer guidance on how to provide comprehensive and useful product identification data in their CVE records. The current onboarding process for CNAs does not adequately prepare them for the nuances of identifier usage, contributing to the overall data inconsistency.
7. The "Parent-Child" Problem: The hierarchical nature of software, where components are nested within other components (e.g., libraries within packages, packages within applications, applications within containers), presents a complex identification challenge. Tracking vulnerabilities through these layers and ensuring consistent naming and identification across different contexts (e.g., a component as a top-level entity vs. a dependency) is a major hurdle.

Technical Deep Dive

▶ Watch: CVE Program: CNAs as authoritative source for product CPEs (6:00)

The discussion heavily revolved around the technical specifications and practical applications of various software identifiers and vulnerability data formats.

Common Platform Enumeration (CPE):

CPE, initially conceived as a URI-like string, has evolved but still faces significant challenges. The existing CPE 2.2 and 2.3 standards are widely acknowledged as inadequate for the granular and dynamic nature of modern software. As Fung (from Oracle) pointed out, the original string format struggled with special characters and representing complex version ranges. NVD's attempt to address this involved workarounds like adding "version ending" and "version starting" fields in JSON, but this doesn't fundamentally solve the underlying schema limitations. The consensus among participants was that a new, modern, JSON-based schema for CPE is needed to facilitate better mapping to other identifiers like PURL. The discussion also highlighted that CPE has historically been seen as more applicable to identifying products or applications rather than individual components.

Package URL (PURL):

PURL emerges as a more suitable identifier for components and packages, particularly within package manager ecosystems. Red Hat's internal processes exemplify this dual approach: they use CPE for identifying applications (e.g., Red Hat Enterprise Linux) but PURL for individual software components (e.g., RPMs, Maven jars). This distinction is critical because an application might contain multiple vulnerable components, and PURL provides the necessary granularity. Martin from Red Hat mentioned that Red Hat has published detailed PURL guidelines outlining how they name and version components, including qualifiers for specific package types. The CVE Quality Working Group (QWG) is actively discussing proposals to officially support PURL identifiers within CVE records, potentially using a structure similar to CPE applicability statements.

Vulnerability Exploitability eXchange (VEX):

VEX documents are crucial for providing detailed, context-specific information about vulnerability applicability. Pete from Red Hat emphasized that VEX files are essential for addressing issues like backporting and vendor-specific rescoring. Red Hat's VEX data outlines CPEs and PURLs along with the amended code and variations, providing a precise state of each issue as it changes. This is vital for data scientists and automated tools seeking accurate vulnerability status. CISA is actively working to make VEX an ISO standard, which is expected to increase its visibility and adoption among vendors. The challenge, however, is the current low adoption rate among vendors for producing VEX and among scanning tools for consuming it.

CVSS (Common Vulnerability Scoring System):

The session included a critical re-evaluation of CVSS usage. Pete, a co-creator of CVSS V1, highlighted a fundamental misunderstanding: the base score was intended to be immutable, while temporal and environmental scores were meant to be applied by the security industry and customers, respectively. However, the industry largely reverted to using only the base score, leading to inaccuracies. Red Hat, for example, "rescored" the base score to reflect its product's usage and then assigned a severity score to prioritize fixes, rather than relying solely on the original CVSS. This practice underscores the need for more nuanced scoring. The upcoming CVSSv4 aims to address these issues by making the string more inclusive of temporal factors.

Software Bill of Materials (SBOMs):

SBOMs are recognized as foundational for identifying software components. However, their utility is often hampered by being "poorly constructed" or lacking consistent identification. The discussion highlighted that while SBOMs list components, the challenge lies in mapping those components to authoritative identifiers and understanding their hierarchical relationships. Red Hat's internal "manifesting" policy mandates a consistent format for component, package, and application identification, which is then tied to their VEX data.

Other Identifiers and Tools:

Omnibore was mentioned as another identifier, specifically designed to cover artifacts not typically managed by package managers, suggesting a broader need for identifiers beyond CPE and PURL. Various SCA (Software Composition Analysis) tools like Net Rise, Anchor, BlackDuck, and SIFT were discussed. These tools often attempt to enrich CVE records with CPE data, sometimes generating their own, due to the lack of authoritative data. Anchor, for instance, pulls in Red Hat Security Advisories (RHSAs) but struggles with the nuances of Red Hat's VEX files, leading to misinterpretations of severity. The Guac (Graph for Understanding Artifact Composition) project under the OpenSSF was also brought up as an initiative working on understanding how to look up and resolve ambiguous component names, especially in open-source contexts, and dealing with many-to-many mappings.

Demo / Proof of Concept

▶ Watch: CVE Board's stance: CNAs are authoritative, CPE deficit (7:00)

This session was structured as an open discussion and community forum rather than a formal presentation with a live technical demonstration. Therefore, there was no explicit "demo" or "proof of concept" in the traditional sense.

However, the practices and internal processes described by participants, particularly from Red Hat, serve as a real-world proof of concept for advanced software identification and vulnerability management. Red Hat's detailed approach, where they:

1. Utilize CPEs for product/application-level identification.
2. Employ PURLs for granular component-level identification.
3. Generate comprehensive VEX files to communicate the precise applicability and status of vulnerabilities, including details on backports and rescoring.
4. Implement an internal "manifesting" policy to standardize how components, packages, and applications are identified and tracked across their build pipelines.

These sophisticated internal mechanisms demonstrate a working model for addressing many of the challenges discussed. While not a publicly executable demo, Red Hat's experience provides tangible evidence that a multi-identifier, VEX-driven approach can significantly improve the accuracy and utility of vulnerability information, even in complex software ecosystems. The challenges highlighted by Red Hat and other vendors (like Cisco's "alias service") also serve as a "proof of concept" of the immense difficulty and the current fragmented state of software identification across the industry.

Defensive Implications

▶ Watch: MongoDB's experience: vulnerability scanners and CPE sources (9:50)

The detailed discussion on software identification, CPE, PURL, and CVE records offers several critical implications for defenders seeking to enhance their vulnerability management strategies:

1. Prioritize Authoritative Data Sources: Defenders should actively seek out and prioritize vulnerability information that includes product and component identifiers directly from the authoritative CNA (the vendor or project owner). While scanning tools provide value, their auto-generated CPEs or interpretations can introduce inaccuracies. When available, consume VEX files as these offer the most precise and context-specific vulnerability applicability data, especially for complex software like operating systems or large applications with backports.
2. Advocate for Standardized Identifiers: Organizations, particularly those acting as CNAs, should be encouraged to consistently include both CPEs (for products) and PURLs (for components/packages) in their CVE records. This dual approach provides the necessary granularity for accurate inventory and assessment. Defenders should also push for the adoption of a modern, JSON-based schema for CPE and official support for PURL within the CVE record format, as discussed by the QWG.
3. Understand Vendor-Specific Rescoring: Be aware that vendors often rescore CVSS base scores based on how a vulnerability affects their specific product and its default configurations. Relying solely on NVD's base score without considering vendor-provided severity scores or VEX data can lead to misprioritization. Always consult vendor security advisories and VEX files for the most accurate risk assessment.
4. Invest in Robust SBOM and VEX Consumption: Develop capabilities to consume and interpret SBOMs and VEX documents. While SBOMs provide a list of components, VEX is critical for understanding their vulnerability status. Tools and processes should be in place to map internal software inventories to these external data formats, recognizing the "parent-child" relationships of nested components. Projects like Guac offer potential solutions for resolving naming ambiguities in this space.
5. Address the "Parent-Child" Problem: For organizations developing or integrating complex software, establishing internal naming conventions and tracking mechanisms for hierarchical components is crucial. As Red Hat's experience shows, defining clear policies for "manifesting" components and their dependencies can significantly improve internal vulnerability management and enable more accurate external reporting.
6. Support a Tiered CNA Model and Central Naming Service: Actively participate in community discussions (like the CVE QWG) to advocate for a more structured tiered CNA model. This could provide clearer guidance for CNAs on what constitutes a "minimal" vs. "ideal" CVE record, including identifier requirements. Furthermore, the concept of a central "name service" or authoritative registry for product and component names would greatly reduce the current "anarchy" in naming, simplifying data aggregation for everyone.
7. Recognize the Role of Open Source: Understand that many vulnerabilities originate in upstream open-source components. The challenges of identification and tracking are often amplified in this domain due to diverse maintainer practices and naming conventions. Tools and strategies should account for this complexity, possibly by leveraging community-driven efforts like those within the OpenSSF.

By embracing these defensive implications, organizations can move towards a more precise, automated, and effective vulnerability management program, ultimately reducing their attack surface and improving their overall security posture.

Key Takeaways

• Software Identification is Fragmented: The current ecosystem lacks a single, authoritative source for software identification, leading to inconsistent CPE assignments by CNAs and scanners, causing confusion and false positives for data consumers.
• CPE Needs Modernization, PURL for Components: The existing CPE 2.2/2.3 standards are outdated; a new, JSON-based schema is needed. PURL is better suited for granular component-level identification, complementing CPE's product-level focus, and its official support in CVE records is being explored.
• VEX is Crucial for Context: VEX (Vulnerability Exploitability eXchange) documents are essential for communicating nuanced vulnerability applicability, especially for backported fixes and vendor-specific rescoring. Defenders must prioritize consuming VEX data for accurate risk assessment.
• CVSS Rescoring is Common: Organizations like Red Hat frequently rescore vulnerabilities based on product usage, deviating from immutable CVSS base scores. Defenders should consult vendor advisories and VEX files for the most accurate severity context.
• Standardization and Guidance are Paramount: There's an urgent need for standardized usage of identifiers, clearer guidance for CNAs on providing comprehensive CVE data, and potentially a tiered CNA model to improve data quality across the entire vulnerability ecosystem.
• Address the "Parent-Child" Problem: The hierarchical nature of software components requires robust internal and external mechanisms to track vulnerabilities through nested dependencies, ensuring consistent naming and identification at all layers.

About the Speaker(s)

The discussion was primarily led by Pete and Chris, with significant contributions from numerous experts across the industry.

Pete is a prominent figure in the cybersecurity community, identified in the transcript as a CVE board member and a co-creator of CVSS V1. His insights often focused on the systemic data problems within vulnerability management, the historical shortcomings of CVSS, and the need for better collaboration and standardization across the ecosystem, particularly concerning the utility of CPE and PURL. His perspective as someone deeply involved in the foundational aspects of vulnerability scoring and identification provided critical context to the challenges discussed.

Chris coordinates and chairs the CVE Quality Working Group (QWG), indicating his role in shaping the future of CVE record quality and data formats. He actively engaged in discussions about potential enhancements to the CVE record, such as supporting PURL identifiers and defining authoritative sources for product information. His work within the QWG positions him at the forefront of efforts to standardize and improve the practical application of vulnerability data.

While many other individuals contributed valuable perspectives—including Ed (from Oracle, involved in CVE QWG issues), Shane (from MongoDB), Andrew Sudter (from MITRE, part of the Omnibore core team), Martin and Rogue (from Red Hat, providing insights into their internal processes), Lisa (assigning CPEs for her organization), Bruce (from Oracle, discussing naming conventions), Fung (from Oracle, discussing JSON formats), Carmen (from MongoDB, seeking CNA guidance), and Alec (from MITRE, discussing ADP technology)—Pete and Chris served as the primary facilitators guiding the comprehensive discussion on these critical topics.