Where Do We Aim? A Look at the State of Vulnerable Software Identification and Its Future

Where Do We Aim? A Look at the State of Vulnerable Software Identification and Its Future

Speakers: Andrew Sudter, Product Security Group, PERT Team, BlackBerry

Conference: VulnCon

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

Overview

In this insightful talk, Andrew Sudter of BlackBerry's PERT team addresses the critical and often overlooked challenges in accurately identifying vulnerable software components, exploring the current landscape of identification schemes and vulnerability enrichment programs. Titled "Where Do We Aim? A Look at the State of Vulnerable Software Identification and Its Future," the presentation dissects the limitations and strengths of established standards like CPE (Common Platform Enumeration) and the emerging PURL (Package URL), while critically evaluating the scalability and accuracy of key initiatives from NIST's NVD (National Vulnerability Database) and CISA's ADP (Authoritative Data Program).

Sudter, drawing on nearly two decades of experience in product security, highlights a looming crisis in vulnerability data—specifically, the diminishing availability of machine-readable data essential for effective SBOMs (Software Bill of Materials) and automated vulnerability management. The talk serves as a compelling call to action for software producers to embrace their role as authoritative CNAs (CVE Numbering Authorities), urging them to proactively contribute accurate and comprehensive vulnerability identification data. This shift, he argues, is vital for overcoming the current bottlenecks and ensuring the future scalability and reliability of vulnerability intelligence.

The core message underscores that relying on centralized enrichment programs alone is no longer sustainable given the exponential growth of vulnerabilities. Instead, a decentralized, cooperative model where producers contribute their own product-specific data is presented as the only viable path forward. This paradigm shift not only enhances data accuracy but also empowers the entire software supply chain to better understand and mitigate risks, making the talk highly relevant for anyone involved in software development, security, or compliance.

Background

▶ Watch: Talk introduction, speaker background, and agenda overview (0:00)

The increasing complexity of modern software, heavily reliant on open-source components and third-party libraries, has amplified the need for robust and accurate methods of identifying vulnerable software. This problem is exacerbated by several factors: the sheer volume of new vulnerabilities discovered daily, the intricate web of dependencies within applications, and the varying ways software components are distributed and maintained (e.g., upstream vs. downstream redistribution with backported patches).

Historically, efforts to standardize vulnerable software identification have centered around schemes like CPE, which has been around for a considerable time. However, as the software ecosystem evolved, particularly with the proliferation of package repositories and diverse distribution channels, the limitations of these early schemes became apparent. The challenge lies in precisely mapping a known vulnerability (identified by a CVE) to the specific software components, versions, and even distribution points that are actually affected. Without this precise mapping, organizations struggle to accurately assess their risk posture, prioritize patching, and leverage the full potential of tools like SBOMs.

The talk frames this problem within the context of current vulnerability enrichment programs, primarily those run by NIST through the NVD and, more recently, CISA through its ADP. These programs were established to augment raw CVE data with additional context, including affected product information, CVSS scores, and CWEs. However, the speaker reveals that these centralized efforts are buckling under the strain of ever-increasing CVE submissions, leading to significant backlogs and questions about their long-term sustainability. The reliance on third-party enrichment, while valuable, introduces potential inaccuracies and often lags behind the pace of new disclosures. Sudter emphasizes that software producers, possessing the deepest understanding of their own products, are the most authoritative source for this critical data, yet they often fall short in providing it in machine-readable formats. His experience with organizations like FIRST PERT, CVSSIGs, AutoISAC, and OASP provides a comprehensive understanding of both the producer and consumer perspectives in application security.

Key Findings

▶ Watch: Analyzing CPE: strengths, weaknesses, and NVD's role (2:00)

Andrew Sudter's presentation reveals several critical findings regarding the state and future of vulnerable software identification:

1. CPE's Limitations and PURL's Potential, but Low Adoption: While CPE has been the long-standing standard, its centralized maintenance by NVD (a single point of failure) and struggles with accuracy and identifying diverse distribution points limit its effectiveness for modern software supply chains. PURL offers a more decentralized, distribution-aware approach, particularly suited for libraries and open-source components, but suffers from "rather low adoption," with only two mentions ever found in the CVE database by Sudter's search.
2. NVD's Unsustainable Backlog: The NVD, a primary source for vulnerability enrichment, is facing a rapidly growing backlog. Sudter highlights NIST's statement projecting a 32% increase in CVE submissions for 2025, making it impossible for them to keep pace with current enrichment rates. This continuous growth, coupled with potential funding reductions, renders the NVD's current model unscalable. Disputes over CVSS scores, exemplified by the Curl project's vocal criticism, further underscore issues with third-party scoring.
3. CISA's Critical Role and Impending Data Gap: CISA's ADP has been an "excellent enrichment program," acting as the only authorized data publisher for the CVE program and adding missing CVSS, CWE, and CPE data for high-priority vulnerabilities. Crucially, Sudter's analysis of CVE.org data from 2015 onwards demonstrates that CISA has been providing most of the CPE data that exists in the CVE database since around 2020. However, a significant finding is CISA's decision to cease providing CPE data as of December 10, 2024.
4. Projected "Bottoming Out" of CPE Data: The cessation of CISA's CPE contributions, combined with NVD's struggles, will lead to a drastic reduction in available machine-readable CPE data. Sudter’s projections, even assuming a modest 15% increase in CVE submissions and a 50% increase in CPE data provided by CNAs, still show the data line "really bottoming out." This will severely impede the ability to correlate SBOMs with vulnerabilities.
5. Software Producers as the Authoritative Source (But Not Providing Data): Sudter strongly asserts that software producers, especially when acting as CNAs, possess unique insight into their products, including access to source code for closed-source applications. They are, therefore, the most authoritative source for accurate vulnerability impact data. However, a major finding is that despite this authority, most CNAs are not currently providing machine-readable CPE or PURL data, leading to the data gaps identified.
6. Vulnerability Enrichment Programs Are Not Fully Reliable or Scalable: The talk concludes that while NVD and CISA provide valuable services, their centralized nature makes them susceptible to funding changes, shifting priorities, and scalability limitations. Relying solely on these programs for comprehensive vulnerable software identification is not a sustainable long-term strategy, necessitating a distributed approach.

Technical Deep Dive

▶ Watch: Exploring Pearl: decentralized nature and distribution points (3:27)

The core of Sudter's technical discussion revolves around the mechanisms and limitations of two primary software identification schemes, CPE and PURL, and how their use (or lack thereof) impacts vulnerability enrichment programs.

Common Platform Enumeration (CPE)

CPE is presented as the "grandfather" of software identification, a structured naming scheme for IT systems, platforms, and packages. It's designed to identify software by a specific vendor, product name, and version, for example, cpe:/a:apache:http_server:2.4.56.

• Granularity: It works well when the level of granularity needed is simply a vendor, product, and version.
• Maintenance: The CPE dictionary is maintained by NVD at NIST. This dictionary enumerates known packages, which is both a pro and a con. While it allows for discovery, the NVD's role as the sole maintainer creates a "single point of failure" for updates and dictionary downloads, as experienced by Sudter himself during his preparation. Updates are currently handled over email, a process described as cumbersome and slow.
• Features: CPE does support version ranges (e.g., 2.4.0 to 2.4.56), which is helpful for specifying affected software without listing every single vulnerable version individually.
• Limitations: Sudter notes that CPE is "not great at identifying things like distribution points" (e.g., a specific Linux distribution's version of OpenSSL). Furthermore, it struggles with "being accurate" due to maintenance difficulties and missing entries.

Package URL (PURL)

PURL is introduced as a more modern, decentralized alternative designed with different use cases in mind. It aims to provide a reliable and concise way to refer to a software package.

• Decentralized Nature: Unlike CPE, PURL does not rely on a central repository for package enumeration. The standard itself is maintained by a group, but the package data is distributed.
• Distribution Points: PURL is "built with the distribution points in mind," making it highly suitable for scenarios where downstream maintainers (like Linux distributions rebundling upstream software such as OpenSSL or Perl) apply their own patches or maintain long-term versions. This allows for distinguishing between the upstream package and its various redistributed forms.
• Target Use Cases: It "really shines" for libraries distributed through platforms like GitHub, GitLab, or Maven, as opposed to closed-source full products.
• Adoption Challenges: Despite its advantages, PURL has seen "rather low adoption." Sudter's search of the CVE database found only "two" mentions ever, highlighting a significant barrier to its widespread use.
• Assumptions and Types: PURL generally assumes the adoption of a package repository. It does offer specific package types like SWID tags (though Sudter notes even less uptake for SWID) and a "generic" type to mitigate this.
• Potential for Explosion: A concern raised is the potential for the list of impacted PURL URLs to "absolutely explode" for popular packages like OpenSSL, given the number of different distributions and backporting scenarios. While PURL supports version ranges, it lacks support for ranges of package locations, which could contribute to this proliferation.

Vulnerability Enrichment Programs: NVD and CISA ADP

The talk then shifts to the programs responsible for enriching CVEs with identification data.

• NVD's Struggles: The NVD is the most well-known enrichment program. It faces significant scaling issues due to the continuous growth of CVE submissions. NIST's projection of a 32% increase in CVE submissions for 2025 means they cannot keep up with the current rate of enrichment. The program is also vulnerable to "ongoing reductions" in funding. Disputes over CVSS scores, such as those from the Curl project regarding NVD's scoring, are common, leading to pushback from maintainers. Critically, NVD has historically generated much of its data or relied on CISA, rather than consistently including CNA-provided data.
• CISA ADP's Role and Retreat: CISA ADP is described as an "excellent enrichment program" and the "only authorized data publisher for the CVE program." Its scope is specific: enriching CVEs that score high on technical impact, are automatable, or have proof-of-concept/active exploitation, and are lacking CVSS, CWE, or CPE data. A key technical detail is that CISA defers to CNAs: it will not overwrite CNA-provided data, and if a CNA later adds its own data (e.g., a CWE), CISA will remove its own contribution. This deference acknowledges the CNA as the ultimate authority.
• The Critical Shift: The most impactful technical finding related to CISA is its decision to no longer provide CPE data as of December 10, 2024. Sudter's visualization of CVE.org data clearly shows that CISA has been the primary contributor of CPE data since around 2020. This policy change creates a massive impending data void. Even with a projected 50% increase in CPE data provided by CNAs, the overall availability is expected to "bottom out," making it extremely difficult to use SBOMs effectively for vulnerability correlation.

The Role of CNAs and MITRE/NIST's Future Contributions

Sudter argues that CNAs (typically software producers) are the "authoritative source" due to their unique insight and access to source code. If they don't provide the data, third-party enrichment programs will, potentially leading to inaccuracies.

• MITRE's Role: MITRE, which oversees the CVE program, currently recognizes CNAs that perform "some level of enrichment," including "affected data" (which can be human-readable). Sudter suggests that MITRE should adjust its recognition to specifically encourage or even mandate the provision of "machine-readable affected set of data" (i.e., CPE or PURL data). This would incentivize CNAs to provide this critical information.
• NVD's Potential Delegation: For NVD specifically, Sudter proposes "delegation of the CPE dictionary" maintenance. With NVD adding "thousands of CPE entries per month" and receiving updates via email, this centralized approach is unsustainable. Delegating maintenance to CNAs—similar to how CNAs manage their own CVEs via tools like Vulnerogram—would distribute the workload and improve accuracy.

In summary, the technical deep dive reveals a system under immense strain, where legacy identification schemes are struggling, newer ones lack adoption, and centralized enrichment programs are hitting scalability limits and undergoing critical policy shifts. The solution, Sudter argues, lies in empowering and obligating the software producers themselves to provide the necessary machine-readable data.

Demo / Proof of Concept

▶ Watch: Issues with NVD's vulnerability enrichment program (6:00)

The talk "Where Do We Aim? A Look at the State of Vulnerable Software Identification and Its Future" is an analytical and data-driven presentation rather than a demonstration of a specific tool, exploit, or proof of concept. Andrew Sudter does not showcase live code, a vulnerability being exploited, or a new security product. Instead, he presents his findings through qualitative analysis of existing standards and programs, supported by quantitative data visualizations, such as the graph illustrating the historical contribution of CPE data by CISA and the projected decline after their policy change. His "proof" lies in the trends and statistics derived from CVE and NVD data, underpinning his arguments for a necessary shift in how vulnerable software is identified and managed.

Defensive Implications

▶ Watch: CISA ADP program: scope and recent CPE data changes (7:59)

The implications of the current state of vulnerable software identification, as presented by Andrew Sudter, are profound for both software producers and consumers (defenders). The impending data gap and the unscalability of current enrichment programs necessitate a fundamental shift in defensive strategies.

1. Prioritize Becoming a CNA and Providing Machine-Readable Data: For software producers, the most critical defensive implication is the urgent need to become a CNA and, more importantly, to actively provide accurate, machine-readable CPE or PURL data with every CVE they issue. As Sudter emphasizes, producers have unique insight into their products and are the authoritative source. Failing to provide this data means relying on third parties who may introduce inaccuracies or, as CISA's decision shows, may simply stop providing it. This proactive contribution is essential for their customers to effectively manage vulnerabilities.
2. Rethink Reliance on Centralized Enrichment: Defenders who rely heavily on NVD and CISA for comprehensive CPE data will face significant challenges. With NVD's backlog and CISA ceasing CPE contributions, the quality and completeness of automatically available identification data will degrade. Organizations must prepare for a scenario where they receive less structured, machine-readable data, requiring more manual effort or alternative data sources to correlate vulnerabilities with their deployed software.
3. Enhance SBOM Utilization and Data Validation: The effective use of SBOMs for vulnerability tracking hinges on accurate component identification. Without reliable CPE/PURL data, SBOMs become less actionable, requiring manual correlation, which is not scalable. Defenders should push their vendors to provide SBOMs with robust, machine-readable component identifiers and be prepared to validate the accuracy of this data. The talk implicitly suggests that if a vendor doesn't provide this data, the value of their SBOM for automated vulnerability management is severely diminished.
4. Advocate for Standardized Data Contribution: The community needs to collectively advocate for changes within MITRE and NVD. MITRE should incentivize or mandate CNAs to provide machine-readable affected data, potentially by making it a criterion for "gold star" recognition or eventually mandatory for CVE submissions. NVD should delegate CPE dictionary maintenance to CNAs, reducing its bottleneck and improving accuracy. Defenders should support these initiatives to foster a more robust ecosystem.
5. Invest in Internal Component Identification and Mapping: For organizations that consume a lot of software (especially open source), internal processes and tools for software composition analysis (SCA) are vital. Even if external data sources falter, understanding what components are in their products (as BlackBerry does internally with vulnerability scanners and SCA tools) allows for better internal vulnerability management. This also positions them to contribute accurate data if they become CNAs for their own products.
6. Educate on Proper Data Production: A question from the audience highlighted the issue of bad data doing more harm than good. This implies a defensive need for education—both for producers on "what does a CPE version range even look like?" and for consumers on how to interpret and potentially validate provided data. Improving the quality of data at the source is a critical defensive measure.

In essence, the talk is a call for a more distributed, cooperative, and producer-driven model of vulnerability identification. Defenders must move away from passively consuming potentially incomplete or delayed data and actively engage with their suppliers and the broader security community to ensure the creation and dissemination of high-quality, machine-readable vulnerability intelligence.

Key Takeaways

• The current centralized models for vulnerable software identification, primarily through NVD and CISA, are unsustainable due to exponential CVE growth and CISA's cessation of CPE data provision.
• CISA's decision to stop providing CPE data as of December 10, 2024, will create a significant void, as they have historically supplied most of this critical machine-readable identification data.
• Software producers, acting as CNAs, are the most authoritative source for accurate vulnerability impact data due to their unique product insight and must proactively provide machine-readable CPE or PURL data.
• Effective SBOM utilization for automated vulnerability management is severely hampered by the lack of consistent, accurate, and machine-readable component identification data.
• MITRE and NVD need to adapt by encouraging or mandating CNA contributions of machine-readable affected data and by delegating the maintenance of the CPE dictionary to distribute the workload.
• A cooperative, decentralized approach where all software producers contribute their own product's vulnerability identification data is the only scalable and reliable path forward for the future of vulnerability intelligence.

About the Speaker(s)

Andrew Sudter is a seasoned professional in the field of product security, currently serving on BlackBerry's PERT (Product Emergency Response Team). He brings extensive experience, having been with BlackBerry for approximately 18 years, with the last decade dedicated specifically to the product security group within PERT. Sudter has been an active participant in the security community, contributing to the first PERT and CVSSIGs (Common Vulnerability Scoring System Special Interest Groups). His prior engagements also include participation with AutoISAC and IICazzi before their integration into the first PERT SIG. His work spans both sides of application security (appsec), understanding the challenges faced by both software producers and consumers, particularly in managing the security of open-source components prevalent in most applications. He clarifies that the views expressed in his talk are his own and do not necessarily represent those of BlackBerry or other groups he is associated with, such as OASP.