Software Identity in the Vulnerability Management Ecosystem

Software Identity in the Vulnerability Management Ecosystem

Speakers: Alex Hmers (Moderator), Megazone, Steve Springett, Chris Turner, Andrew

Conference: VulnCon

YouTube: https://www.youtube.com/watch?v=2cNX66z-YLY

Overview

This panel discussion, moderated by Alex Hmers, MITRE CVE and CW Project Lead, delves into the intricate world of software identification within the vulnerability management ecosystem. The core assertion grounding the discussion is that effective and efficient vulnerability management critically relies on software being trackable and correlatable with other vital information, such as known vulnerabilities, available patches, approved software lists, and adversary activities. The panel convenes experts from various domains to discuss the current landscape, acknowledging that a multi-identifier ecosystem currently exists and will likely persist, as no single identifier can fully address every software identity use case and challenge.

The esteemed panelists include Megazone, Principal Security Engineer at F5 and Co-chair of the CVE Program Quality Working Group; Steve Springett, Director of Product Security at ServiceNow and Chair of CycloneDX and ECMA TC54; Chris Turner, Senior Adviser at the National Vulnerability Database (NVD) focusing on Common Platform Enumeration (CPE); and Andrew, Principal Engineer at MITRE and core team member of the Omnibore project. Their collective expertise provides a comprehensive look at the strengths, limitations, and future directions of prominent software identification schemes like CPE, Package URL (PURL), and Omnibore, and their integration into critical security frameworks like the CVE Program.

The talk highlights the ongoing efforts to standardize and integrate these diverse identifiers, emphasizing the need for flexibility and collaboration across the industry. It underscores the challenges of scaling identification efforts, the differing granularities offered by each scheme, and the imperative for defenders to navigate this evolving landscape effectively. The discussion ultimately aims to shed light on how the security community can move closer to achieving precise and actionable software identification, thereby bolstering overall vulnerability management capabilities.

Background

▶ Watch: Introduction, core assertions, and panelist introductions (0:00)

The fundamental challenge in modern vulnerability management stems from the sheer complexity and interconnectedness of software components. Organizations struggle to accurately identify every piece of software running within their environments, making it nearly impossible to correlate this inventory with known vulnerabilities. This problem is exacerbated by the diverse ways software is developed, packaged, distributed, and deployed, leading to a fragmented approach to identity.

Historically, Common Platform Enumeration (CPE), developed by NIST, emerged as a prominent standard for naming applications, operating systems, and hardware devices. It provides a structured naming scheme for IT products and has been extensively used by the National Vulnerability Database (NVD) to define vulnerable software configurations. However, CPE, while foundational, has faced significant challenges. Its centralized dictionary model struggles with scalability, particularly in handling the rapid proliferation of new software versions, acquisitions, and the sheer volume of products requiring identification. Creating applicability statements – defining which specific versions or configurations are affected by a vulnerability – at scale has proven to be a monumental task, often requiring manual effort to track tens of thousands of different identifiers for large, long-standing products.

More recently, the rise of modern software development practices, particularly the heavy reliance on open-source components and package managers, led to the emergence of Package URL (PURL). Initiated by Philip Omdan around 2016-2017, PURL offers a decentralized approach that naturally integrates with package managers like Python, npm, and Java. It derives its naming and versioning directly from these package ecosystems, reducing human intervention and offering a more automated way to identify software dependencies. While initially perceived as primarily for open source, PURL's extensibility is actively being developed to encompass commercial software and other types of artifacts, including a SWID (Software Identification Tag) PURL type.

Further pushing the boundaries of precision, the Omnibore project introduces an inherent identifier scheme. Unlike CPE and PURL, which rely on central taxonomies or federated lists of package hosts, Omnibore artifact IDs are derived solely from the artifact itself (e.g., binaries, source files). This provides the highest level of granularity, identifying concrete things rather than broader products or packages. Omnibore aims to address the need for cryptographic-level assurance of artifact identity, crucial for supply chain integrity, but as the newest scheme, it is still gaining adoption.

The ongoing discussions within the CVE Program, particularly the Quality Working Group, underscore the industry's recognition that no single identifier can be a panacea. Instead, the focus has shifted towards supporting a multi-identifier ecosystem, allowing for the integration and correlation of these different schemes to provide a more complete and accurate picture of software identity. This evolution is driven by market forces, including governmental requirements for SBOMs (Software Bill of Materials) and VEX (Vulnerability Exploitability eXchange) statements, which necessitate robust and flexible software identification mechanisms.

Key Findings

▶ Watch: CVE's role: supporting industry, not solving unified identifier problem (4:00)

The panel discussion crystallized several key findings regarding the current state and future direction of software identity in vulnerability management:

1. Acceptance of a Multi-Identifier Ecosystem: The central assertion that "there currently exists and will likely continue to exist a multi-identifier ecosystem where no single identifier fully addresses every software identity use case and challenge" was universally accepted by the panelists. This fundamental understanding underpins all current and future integration efforts.
2. CVE Program's Evolving Identifier Support:

• CPE Integration: The CVE record format (officially "CVE Record Format") has recently added "actual support" for CPE, moving beyond a simple array of values to a structured format directly compatible with the NVD specification. This allows CVE Numbering Authorities (CNAs) like Microsoft and Red Hat to provide CPEs in a meaningful way, enabling easier consumption by downstream tools.
• PURL and Omnibore in Discussion: The CVE Quality Working Group is actively exploring and discussing proposals (specifically, pull requests) to integrate both PURL and Omnibore into the CVE record format. PURL is noted as being "a little farther along in the discussion." The goal is not to solve the "unified software identifier problem" but to support what the industry is using.

1. A Taxonomy of Identifiers: SISA's "Software Identification Ecosystem Option Analysis" paper (late 2023) introduced a useful taxonomy:

• Defined Identifiers: Rely on a central taxonomy or list (e.g., CPE dictionary, PURL types list).
• Inherent Identifiers: Based solely on the thing being identified (e.g., Omnibore artifact IDs).
• This further translates into models of production: Centralized (CPE), Federated (PURL), and Distributed (Omnibore).

1. Granularity and the "Funnel" Concept: Steve Springett eloquently described the relationship between the identifiers as a "funnel":

• CPE is at the broad top, identifying products.
• PURL is in the middle, identifying packages, where "most people want to be" for hyper-automation.
• Omnibore is at the bottom, offering the highest precision for specific artifacts (binaries, source files).

The ability to "mix and match" these granularities in CVE records is seen as crucial for achieving the necessary precision.

1. Challenges with Existing Standards:

• CPE's Age and Scalability: CPE 2.3 is recognized as "totally outdated" (13-14 years old) and struggles with scaling, versioning schemes, and timely updates to the NIST CPE dictionary due to resource limitations. There's a clear need for revision, including a move to a JSON-based schema.
• PURL's Version Range Limitation: A current challenge for PURL integration into CVE records is its lack of native support for version ranges within the PURL string itself. However, the proposed CVE integration plans to address this by reusing the existing CVE record mechanism for expressing version constraints, similar to how CPE ranges are handled.

1. Driving Forces for Adoption: Market forces, including requirements for SBOMs and VEX statements from governments and industries, are increasingly driving the demand for robust and interoperable software identifiers. While the CVE program makes identifier provision possible, it avoids mandating specific types, respecting varied CNA capabilities and preferences.
2. The Role of ADPs: The concept of Authorized Data Publishers (ADPs) was highlighted as a potential solution for enriching CVE records with additional, vendor-specific, or context-specific identifier data. This would allow entities like Ubuntu to add PURLs for their packages to a CVE affecting a base component like curl, or for vendors like F5 to add how a CVE affects their specific product implementation, without requiring the original CNA to update their container directly.

Technical Deep Dive

▶ Watch: NVD's perspective: CPE strengths, challenges, and scalability issues (4:30)

The panel provided a comprehensive technical overview of CPE, Package URL (PURL), and Omnibore, detailing their design philosophies, strengths, and current limitations.

Common Platform Enumeration (CPE)

CPE serves as a structured naming scheme for IT products and has been a cornerstone of vulnerability identification, particularly within the National Vulnerability Database (NVD). Chris Turner, from NVD, elaborated on its characteristics:

• Identification Scope: CPE aims for broad identification, covering operating systems, applications, and hardware. It "does do identification to an extent that covers most bases."
• Centralized Model: CPE relies on a central dictionary maintained by NIST, which defines the allowed values and attributes for product names, vendors, versions, and other components. This centralization ensures a degree of consistency but introduces scalability challenges.
• Challenges:
• Scaling Operations: Managing the CPE dictionary at scale is difficult due to the sheer volume of software versions, vendor acquisitions, and the need to establish consistent attributes.
• Applicability Statements: The most significant challenge is accurately and timely creating applicability statements. For large products, this can involve tracking "tens of thousands of different identifiers." The NVD uses applicability language to create matches between product descriptions and CPE names.
• Authoritative Contributions: The process for CNAs to contribute accurate applicability statements directly has historically been cumbersome.
• CVE Integration: Within the last year, the CVE record format added "actual support for CPE." Previously, CPE was a generic array, leading to ambiguous usage (affected vs. unaffected values). The new implementation aligns with the NVD's established specification, making it directly compatible and consumable. This allows CNAs to provide applicability language directly within CVE records, a crucial first step in offloading some of the NVD's burden and enabling more direct, actionable information.
• Future Directions: CPE 2.3 is acknowledged as "totally outdated" (13-14 years old). Plans are underway to revise the specification, including modernizing the serialization to be JSON-based rather than XML, and enhancing its ability to handle evolving product information.

Package URL (PURL)

PURL offers a decentralized, practical approach to software identification, particularly well-suited for modern software development that heavily relies on package managers. Steve Springett provided insights into PURL's design:

• Decentralized Nature: Unlike CPE, PURL does not rely on a central dictionary for defining package names and versions. Instead, it leverages the existing naming and versioning schemes of various package managers (e.g., Python, npm, Java, Maven). This makes it "naturally compatible with all existing software."
• Origins: The specification was initiated by Philip Omdan around 2016-2017 and has since become one of the most widely used software identifiers.
• Reduced Human Out-of-Loop: PURL names are created by developers using their package managers and existing publishing mechanisms, significantly reducing human error and manual effort compared to centralized systems.
• Extensibility: PURL is an extensible specification, allowing for the definition of custom PURL types for various ecosystems. While widely used for open-source packages, it is not limited to them.
• SWID PURL Type: A notable extension is the SWID PURL type, designed to represent commercial software. While the full SWID (Software Identification) specification is behind an ISO paywall and XML-based, the PURL type captures the essential, mandatory fields of a SWID tag, enabling decentralized representation of commercial software. This includes distinguishing between the original tag creator (manufacturer) and third-party creators. Furthermore, PURL can include a subpath to represent specific modules within a product, offering greater granularity than CPE.
• Standardization: PURL is currently undergoing the ECMA standardization process, with aspirations to become an international standard by December.
• CVE Integration Proposal: The current proposal for adding PURL to the CVE record format addresses the lack of native version range support within the PURL string itself. It plans to reuse the existing CVE record mechanism for expressing version constraints (start/end versions, inclusive/exclusive), similar to how CPE ranges are handled. This means a base PURL identifies the package, and separate fields constrain the version.

Omnibore

Omnibore represents the bleeding edge of software identification, focusing on inherent, artifact-level identity, crucial for supply chain integrity. Andrew from MITRE elaborated on its unique attributes:

• Inherent Identifier: Omnibore's central distinction is that its artifact IDs are derived only from the artifact itself. This means they are not dependent on any central taxonomy, list, or external definition. Anyone can produce an Omnibore ID for a given artifact, and it will always be the same.
• Granularity: Omnibore identifies "very concrete things," specifically artifacts such as binaries or source files. This provides the highest level of precision, sitting at the "very bottom of the funnel" compared to CPE's products and PURL's packages.
• Distributed Model: Omnibore is completely distributed. Unlike CPE (centralized) or PURL (federated via a central types list), there is no central authority or list that defines Omnibore identifiers.
• Development State: The project has an open and public specification, a reference implementation (Rust-based), and is beginning to gain adoption. It is currently the newest and least used of the discussed schemes.
• Mapping Capabilities: Due to its inherent nature, Omnibore can facilitate mappings to other identifiers. For example, a member of the Omnibore core team has created a "giant mapping" of PURLs from Maven Central to Omnibore artifact IDs, allowing cross-referencing between the two schemes.
• Challenges: The high granularity also presents challenges. An artifact like lib C could exist in numerous packages and products, leading to a many-to-one relationship where one Omnibore ID maps to many PURLs and CPEs.

The panel emphasized that these schemes are complementary. The ability to mix and match them within CVE records, as proposed by the CVE Quality Working Group, will allow for expressing the precise level of identification needed for any given vulnerability.

Demo / Proof of Concept

▶ Watch: Improving CPE: Need for authoritative contributions and direct action (6:00)

This session was a panel discussion focused on conceptual frameworks, current challenges, and future directions in software identity, rather than a live technical demonstration or proof of concept. While no direct demo was presented, the discussion itself served as a "proof of concept" for the evolving multi-identifier strategy within the CVE Program.

The practical application of the discussed concepts is evident in the recent updates to the CVE record format, which now includes robust support for CPE applicability statements. This allows CNAs to directly provide structured CPE data, demonstrating how a "defined identifier" can be effectively integrated into a vulnerability record. Furthermore, the active discussions within the CVE Quality Working Group regarding the integration of PURL and Omnibore serve as ongoing "proof of concept" work, showcasing the community's commitment to supporting a diverse identifier ecosystem. The panel's acknowledgment of a Rust reference implementation for Omnibore and the Maven Central mapping project for PURL and Omnibore also highlight real-world tools and efforts that validate the feasibility and utility of these identification schemes.

Defensive Implications

▶ Watch: Steve Springett introduces Package URL (PURL) origins and role (7:30)

The panel's insights into the multi-identifier ecosystem have profound implications for security defenders, necessitating a strategic shift in how organizations approach vulnerability management.

1. Embrace Multi-Identifier Consumption: Defenders must move beyond relying on a single software identification scheme. Their vulnerability management tools, asset inventory systems, and security analytics platforms need to be capable of consuming, parsing, and correlating data from CPE, Package URL (PURL), and Omnibore. This means updating tooling to support the evolving CVE record format, which is actively integrating these identifiers.
2. Leverage Granularity for Precision: Understanding the different granularities offered by each identifier is crucial.

• For broad product identification and compliance reporting, CPE remains relevant, especially with its improved integration into CVE records. Defenders should prioritize consuming CPE applicability statements from CVEs to quickly assess affected products.
• For managing software dependencies, particularly in modern development pipelines and for open-source components, PURL becomes indispensable. Its decentralized nature and integration with package managers enable "hyper-automation" of dependency scanning and vulnerability correlation, significantly reducing manual effort. Organizations should integrate PURL-aware tools into their CI/CD pipelines and SBOM generation processes.
• For high-assurance environments, critical infrastructure, or deep supply chain integrity checks, Omnibore's inherent artifact identification offers unparalleled precision. Defenders dealing with specific binaries or source files should explore Omnibore integration to verify the exact components in use, especially when dealing with patched or custom code.

1. Prioritize SBOM and VEX Adoption: The market forces driving identifier adoption, such as requirements for SBOMs and VEX statements, directly impact defenders. Organizations must actively generate and consume SBOMs (containing various identifiers) and VEX documents to understand the exploitability of vulnerabilities within their specific context. The richer identifier data in CVE records will make these processes more effective.
2. Advocate for and Contribute to Data Enrichment: Defenders, especially those within CNAs or vendor organizations, have a role to play in improving the ecosystem. Providing accurate and comprehensive identifier data (CPE applicability, PURLs, Omnibore IDs) directly in CVE records enhances the collective security posture. For organizations that cannot or will not provide certain identifiers, supporting the concept of Authorized Data Publishers (ADPs) could allow third parties to enrich CVE records with additional context, bridging data gaps.
3. Prepare for Evolving Standards and Tooling: The identification landscape is dynamic. Defenders should stay informed about the revision of CPE 2.3 to a JSON-based format, the ECMA standardization of PURL, and the ongoing development of Omnibore. This includes monitoring updates from NIST, ECMA TC54, and the Omnibore project. Investing in flexible tooling that can adapt to new identifier types and serialization formats will be key to long-term success.
4. Internal Inventory and Mapping: Organizations need robust internal processes to map their unique software inventory to these various external identifiers. This might involve creating internal mappings between proprietary product names and standardized CPEs, or between deployed binaries and their corresponding PURL and Omnibore IDs. This internal mapping is critical for translating external vulnerability intelligence into actionable internal remediation efforts.

By strategically integrating and leveraging these diverse software identification schemes, defenders can achieve a more granular, automated, and accurate understanding of their software assets and their associated vulnerabilities, moving closer to the goal of effective and efficient vulnerability management.

Key Takeaways

• Multi-Identifier Future is Inevitable: Effective vulnerability management requires software to be trackable, but no single identifier addresses all use cases. A multi-identifier ecosystem featuring CPE, PURL, and Omnibore is established and will continue to evolve.
• Granularity Dictates Choice: CPE provides broad product identification, PURL offers package-level identification for hyper-automation, and Omnibore delivers artifact-level precision. Defenders must understand and leverage these different granularities.
• CVE Program is Adapting: The CVE record format now supports structured CPE and is actively working towards integrating PURL and Omnibore, allowing for a richer, more precise representation of affected software.
• Decentralization and Inherent Identity are Key Trends: PURL's decentralized, package manager-driven approach and Omnibore's inherent, artifact-derived identity are crucial for scaling identification in modern software supply chains.
• Collaboration and Tooling are Essential: Overcoming challenges like CPE's outdated specification and scaling issues requires community involvement, ongoing tooling development, and potential mechanisms like Authorized Data Publishers (ADPs) to enrich vulnerability data.
• Defenders Must Evolve: Organizations need to adapt their vulnerability management strategies to consume and correlate data from multiple identifier types, integrate PURL into automation, consider Omnibore for high-assurance needs, and actively support the adoption of SBOMs and VEX.

About the Speaker(s)

• Alex Hmers (Moderator): Serves as the MITRE CVE and CW Project Lead, guiding discussions and initiatives related to common vulnerabilities and exposures.
• Megazone: A Principal Security Engineer with the F5 Security Incident Response Team. He also co-chairs the CVE Program Quality Working Group, where critical discussions about software identification integration and CVE record format enhancements take place.
• Steve Springett: The Director of Product Security at ServiceNow. He is a prominent figure in the software supply chain security space, chairing both the CycloneDX project (a leading SBOM standard) and ECMA TC54, which is involved in the standardization of Package URL (PURL).
• Chris Turner: A Senior Adviser at the National Vulnerability Database (NVD). His work deeply involves Common Platform Enumeration (CPE), focusing on its effectiveness, ongoing challenges, and future development.
• Andrew: A Principal Engineer at MITRE and a core team member of the Omnibore project. He plays a key role in developing and promoting Omnibore, a promising new software identification scheme emphasizing provenance and supply chain integrity through inherent identifiers.