CPE Metadata: Know IT ALL

CPE Metadata: Know IT ALL

Speakers: [Speaker Name Not Provided], Infosec Engineer, MongoDB

Conference: VulnCon

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

Overview

In the rapidly evolving landscape of cybersecurity, effective vulnerability management is paramount for organizations striving to maintain robust security postures and ensure compliance. This talk, "CPE Metadata: Know IT ALL," delivered by an Infosec Engineer from MongoDB, delves into the critical, yet often overlooked, role of Common Platform Enumeration (CPE) metadata within Common Vulnerabilities and Exposures (CVE) records. The presentation highlights a significant challenge posed by the National Vulnerability Database (NVD)'s recent slowdown in enriching CVEs with crucial metadata, arguing for a paradigm shift towards CVE Numbering Authority (CNA) self-enrichment.

The speaker, an Infosec Engineer at MongoDB leading their bug bounty program and CVE disclosure process, underscores why a deeper understanding and proactive integration of CPE metadata are essential. With an increasing volume of CVEs being issued annually and a growing reliance on automated security tools, the absence or delay of accurate CPEs can lead to miscategorized vulnerabilities, inefficient patch management, and ultimately, persistent system vulnerabilities. The talk serves as a call to action for CNAs to embrace their responsibility in providing comprehensive and accurate vulnerability data from the outset, thereby empowering the entire security ecosystem.

Background

▶ Watch: Introduction and talk overview (0:00)

The foundation of modern vulnerability management rests on standardized frameworks and identifiers, with CVEs at its core. A CVE record provides a unique identifier for a publicly known security vulnerability, but its true utility is unlocked by the accompanying metadata. Key metadata elements include the Common Vulnerability Scoring System (CVSS), which quantifies severity; the Common Weakness Enumeration (CWE), which categorizes the underlying weakness; and crucially, Common Platform Enumeration (CPE), which precisely identifies the affected product and version.

CPE, developed and maintained by the NVD (a supporting body of the CVE program), is a standardized naming scheme for IT systems, software, and packages. It provides a consistent way to name software or hardware down to specific versions and configurations, enabling security professionals and tools to accurately pinpoint where a vulnerability exists. The NVD historically maintained an invaluable resource, the CPE dictionary, which compiles all known CPEs and is updated daily, often through NVD analysts manually adding CPEs to CVEs after publication. This dictionary, accessible via NVD APIs or direct download, has been a critical data source for vulnerability scanners and security management tools.

Historically, the NVD has been a primary provider of enriched CVEs, particularly with CVSS scores and CPEs, which are essential for CVE consumers like vendors and vulnerability scanner developers. However, a significant problem emerged in early 2024 when the NVD announced a slowdown in its process of enriching CVEs with this crucial metadata. This announcement sparked industry-wide discussions about its potential impact, particularly on how organizations' customers experience CVEs. The slowdown means that the necessary metadata might not be added as swiftly or comprehensively as before, leading to potential miscategorization of vulnerabilities and leaving systems exposed.

While CNAs have the ability to issue CVEs using a JSON schema provided by the CVE program, they are not required to apply metadata. Support for CVSS and CWE metadata is relatively widespread, with over 50% of all CVEs historically including them. However, CPE metadata has received significantly less attention. The speaker revealed a stark discrepancy: historically, only 13.3% of all CVEs issued contained CPEs. This substantial gap highlights a critical area for improvement in vulnerability enrichment, especially considering the NVD's reduced capacity.

Adding to the complexity, the number of CVEs issued annually has been accelerating. From modest numbers under 10,000 per year, there was a pivotal doubling in 2017. Since then, the trend has continued, with a 38% increase in 2024 compared to the previous year. This growth, coupled with an increasing number of CNAs (447 at the time of data collection in 2025), signifies a global community becoming more familiar with CVEs but also places greater strain on the enrichment process. If the NVD cannot keep pace with this volume, the responsibility for comprehensive metadata, particularly CPEs, must shift to the CNAs themselves.

Key Findings

▶ Watch: Crucial CVE metadata: CBSS, CWE, CPE (4:00)

The research presented in the talk uncovered several critical findings that underscore the current state and future direction of CPE metadata in vulnerability management:

Firstly, the NVD's slowdown in metadata enrichment has created a significant and widening gap in the availability of crucial CPE data. While NVD historically bore much of the burden for adding CPEs to CVEs, their reduced capacity necessitates a shift in responsibility. The speaker cited discussions from other VulnCon talks, including one by Andrew, which confirmed that NVD and even CISA are struggling with vulnerability enrichment, reinforcing the urgency of this issue.

Secondly, historical data reveals a substantial deficiency in CPE inclusion by CNAs. Prior to 2023, the percentage of CVEs issued by CNAs that included CPEs remained consistently low, often around 10% or below. This indicated a widespread underutilization of the CPE field within the CVE JSON schema, despite its availability. This low adoption rate meant that a vast majority of CVEs were reliant on NVD for CPE enrichment, exacerbating the impact of the NVD slowdown.

However, a positive trend emerged in recent years, likely spurred by the NVD's announcement. The percentage of CVEs self-enriched with CPEs by CNAs saw a significant spike: 26% in 2023 and a remarkable 54% in 2024. This over-doubling of CPE inclusion in 2024 compared to 2023 suggests that CNAs are beginning to recognize and act upon the necessity of self-enrichment. The speaker's data collection specifically focused on CPEs within the CNA container of the CVE JSON files, confirming that these enrichments were indeed provided by the CNAs themselves, not by the NVD or an Authorized Data Publisher (ADP).

Despite this recent uptick, the overall percentage of CVEs ever issued that include CPEs remains low at 13.3%. Even though 288 out of 447 CNAs (64%) have, at some point, issued CVEs with CPEs, this doesn't translate to consistent inclusion across all their CVEs. This inconsistency suggests that adding CPEs can be labor-intensive, requiring research and manual creation, and some CNAs may only do so for specific vulnerabilities or when their role allows for it (e.g., when issuing CVEs for their own products versus those of other organizations).

Finally, the talk highlighted that CNAs possess both the capability and the responsibility to self-enrich their CVEs. The CVE JSON schema explicitly accommodates CPEs, providing an affected section with a CPEs array for this purpose. MongoDB, as a CNA, has proactively adopted a self-enrichment strategy for CPEs in response to the NVD's announcement, recognizing it as crucial for better serving its customers. This shift ensures that accurate and comprehensive vulnerability data is available from the "get-go," reducing reliance on external entities and improving the overall quality and utility of CVEs.

Technical Deep Dive

▶ Watch: The NVD metadata enrichment slowdown (6:00)

The technical core of the talk revolves around the structure and integration of CPE metadata within the CVE JSON schema, and the process CNAs can adopt for self-enrichment.

CVEs are published as JSON files, which are publicly accessible on the CVE program's website and GitHub repository. The JSON schema, established by the CVE program, is designed to accommodate various metadata, including CPEs. Specifically, the schema includes an affected section, which contains an array named CPEs. This is the designated location where CNAs can directly insert the CPE strings relevant to the affected products and versions.

A CPE string follows a standardized, structured format to ensure consistency and machine readability. The basic structure is:

cpe:/2.3:part:vendor:product:version:update:edition:language:sw_edition:target_sw:target_hw:other

Let's break down an example using one of MongoDB's CPEs for their Rust Driver:

• cpe:/2.3: This prefix indicates that the CPE adheres to version 2.3 of the CPE specification, which is crucial for maintaining consistency across systems and tools that parse CPEs.
• :a: This is the part component. It identifies the type of entity being described. Common values include a for application, o for operating system, and h for hardware. In this case, it signifies an application.
• :mongodb: This is the vendor component, specifying the organization responsible for the product.
• :rust_driver: This is the product component, identifying the specific software or hardware product.
• :0.10.0: This is the version component, which is critical for precise vulnerability identification and patch management. It pinpoints the exact version of the product affected by the vulnerability.
• : (remaining components): The subsequent components (update, edition, language, software edition, target software, target hardware, and other) are optional. In many cases, including the MongoDB example, these are represented by wildcards (*) when they are unspecified or not relevant for the specific identification.

A peculiar example from MongoDB's experience highlighted the importance of CNA control: for their "MongoDB server" product, the CPE dictionary historically listed it simply as "MongoDB." This led to the need for more granular detail in their self-enriched CPEs, such as using mongodb in the target_sw component to explicitly link the Rust driver to the "MongoDB server" context, thereby providing a clearer and more accurate product identification. This illustrates how CNAs, with their intimate product knowledge, can provide a level of detail that external entities might miss.

The process for a CNA to self-enrich CVEs with CPEs typically involves:

1. Checking the CPE dictionary: Before creating a new CPE, CNAs should verify if a scheme already exists for their product or version to maintain consistency with existing entries.
2. Creating new CPEs: If a new product or version isn't listed, the CNA can create a new CPE string following the specification.
3. Integration: The generated CPE strings are then copied and pasted into the CPEs array within the affected section of the CVE JSON file.
4. Maintenance: While the initial setup might involve some manual parsing of the CPE dictionary, ongoing maintenance, especially for product releases, becomes straightforward, often managed via simple internal databases like a Google Sheet, as MongoDB does.

The speaker emphasized that while NVD has played a monumental role in the CVE system, they are neither a CNA nor an Authorized Data Publisher (ADP). Their historical metadata enrichment, though invaluable, was based on publicly available information, which might not always be the most current or comprehensive. By self-enriching, CNAs leverage their direct product knowledge to provide superior data accuracy. The speaker clarified that the data presented on CPE inclusion rates specifically analyzed the CNA container in the JSON files, confirming that the observed increases were due to CNAs proactively adding CPEs.

Demo / Proof of Concept

▶ Watch: CPE metadata: A significant adoption gap (7:00)

The speaker did not present a live demo or a dedicated proof-of-concept tool during the talk. Instead, the focus was on explaining the internal process adopted by MongoDB as a CNA for self-enriching their CVEs with CPE metadata. This included a detailed breakdown of the CPE string structure and how it is integrated into the CVE JSON schema, as well as a description of MongoDB's manual, but effective, approach using an internal CPE database. The "demo" was conceptual, illustrating the technical components and the practical steps involved in CNA-driven CPE inclusion rather than a live software demonstration.

Defensive Implications

▶ Watch: Rising tide: CVE and CNA growth (8:00)

The insights shared in this talk carry significant defensive implications for both CNAs and organizations consuming CVE data for vulnerability management.

For CVE Numbering Authorities (CNAs), the message is clear: self-enrichment of CVEs with CPE metadata is no longer optional but a critical responsibility.

• Enhanced Accuracy and Completeness: By including CPEs from the outset, CNAs ensure that their CVEs provide a complete and precise picture of affected products and versions. This minimizes ambiguity and reduces the need for external entities like NVD to guess or infer details based on potentially outdated or incomplete public information.
• Improved Customer Experience: CNAs can directly address customer queries regarding discrepancies in vulnerability severity (e.g., CVSS scores) or affected products between their own advisories and NVD's data. Providing accurate CPEs from the start reduces confusion, builds trust, and streamlines customer support efforts. As the speaker noted, customers often ask why CVSS scores differ between a CNA's assessment and NVD's.
• Greater Control Over Information: Self-enrichment grants CNAs full control over the narrative and technical details surrounding their product vulnerabilities. This ensures that the most up-to-date and accurate information is disseminated, reflecting their internal assessments and product knowledge.
• Consistency and Maintainability: Establishing an internal CPE database, even a simple one like MongoDB's Google Sheet, allows CNAs to maintain consistent CPE naming conventions across all their product releases and CVEs. This makes the process of adding CPEs straightforward after the initial setup.
• Industry Leadership: CNAs that proactively self-enrich with CPEs contribute to a more robust and reliable vulnerability management ecosystem, setting a positive example for other CNAs and ultimately benefiting the entire security community.

For Organizations Consuming CVEs (Defenders), the implications are equally vital:

• Reduced Reliance on NVD: Given the NVD's slowdown, defenders can no longer solely depend on NVD APIs for comprehensive CPE data. Prioritizing CVEs that are self-enriched by CNAs ensures faster access to critical identification information.
• Improved Automation and Efficiency: Standardized and accurate CPEs are the backbone of automated vulnerability scanners and asset management systems. With precise CPEs, these tools can more effectively identify vulnerable systems within an environment, improving the efficiency and accuracy of vulnerability assessments.
• Effective Patch Management: Knowing the exact product and version affected, as provided by CPEs, allows organizations to target their patching efforts precisely, reducing the scope of unnecessary updates and minimizing operational disruption.
• Better Risk Prioritization: When vulnerability scanners can accurately identify affected assets using CPEs, organizations can better prioritize remediation efforts based on the actual exposure within their environment.
• Advocacy and Demand: Defenders should encourage and demand that their vendors (CNAs) include CPEs in their CVEs. This collective pressure can drive wider adoption of self-enrichment practices across the industry.

In essence, the widespread integration of CPEs alongside other metadata like CVSS and CWE by CNAs is a strategic imperative. It ensures that security is prioritized, customers are well-served with actionable information, and the principle that "enrichment equals enablement" becomes a reality for everyone involved in the vulnerability management lifecycle.

Key Takeaways

• The NVD's slowdown in enriching CVEs with crucial metadata, particularly CPEs, creates a significant challenge for accurate and timely vulnerability identification in the security industry.
• CNAs have the ability and a growing responsibility to self-enrich their CVEs with CPE metadata, ensuring comprehensive and precise vulnerability data is available from the initial publication.
• While historically only 13.3% of all CVEs included CPEs, recent years show a positive trend, with CNA self-enrichment spiking to 26% in 2023 and 54% in 2024, likely in response to the NVD's announcement.
• Standardized CPEs, following formats like cpe:/2.3:a:vendor:product:version, are fundamental for automated vulnerability scanning, efficient patch management, and consistent communication across the security ecosystem.
• Self-enrichment by CNAs, exemplified by MongoDB's approach, empowers organizations to maintain better control over their vulnerability information, reduce customer confusion, and enhance the reliability of CVE data.
• The industry must collectively prioritize and encourage widespread CPE integration from the "get-go" to ensure that all stakeholders have access to the complete and actionable vulnerability intelligence necessary for robust defense.

About the Speaker(s)

The speaker for this talk, whose name was not provided in the presentation or metadata, is an Infosec Engineer at MongoDB. They bring a background in risk assessment and management from experience as a consultant in one of the "big four" firms. Currently, their primary focus is product security, where they lead MongoDB's bug bounty program and manage its CVE disclosure process. The speaker mentioned traveling from London to present at VulnCon.