Panel: The CVE Supplier ADP (SADP) Pilot: Am I Affected byUpstream?

Panel: The CVE Supplier ADP (SADP) Pilot: Am I Affected by Upstream?

Speakers: Art Manion (Tharros Labs), Jeremy Daigneau (MITRE), Lisa Olson (Microsoft), Yogesh Mittal (Red Hat), Saeed Abbasi (Qualys)

Conference: VulnCon

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

Overview

In the complex landscape of modern software development, where applications are increasingly composed of numerous third-party and open-source components, understanding the true impact of an upstream vulnerability on downstream products is a pervasive challenge. The "CVE Supplier ADP Pilot: Am I Affected by Upstream?" panel at VulnCon 2026 addressed this critical problem head-on, introducing a novel initiative to integrate Vulnerability Exploitability eXchange (VEX)-like information directly into CVE (Common Vulnerabilities and Exposures) records. Moderated by Art Manion of Tharros Labs, the panel featured insights from industry leaders: Jeremy Daigneau from MITRE, Lisa Olson from Microsoft, Yogesh Mittal from Red Hat, and Saeed Abbasi from Qualys.

The core of the discussion revolved around the Supplier Additional Data Provider (SADP) pilot program. This initiative aims to streamline the process by which downstream software suppliers can formally attest to whether their products are affected by a vulnerability identified in an upstream component. By leveraging existing CVE infrastructure, specifically ADP (Additional Data Provider) containers, SADP seeks to provide a centralized, machine-readable, and authoritative source of vulnerability context, moving beyond the current fragmented system of individual advisories and disparate information feeds. This pilot is a direct response to the growing demand for more efficient and accurate vulnerability management across the software supply chain.

The talk highlighted the significant burden placed on both upstream maintainers, who often lack the context to assess impact across diverse downstream environments, and downstream vendors, who must currently expend considerable resources to track and interpret numerous vulnerability disclosures. The SADP pilot promises to alleviate these pressures by offering a standardized mechanism for expressing vulnerability status, thereby enhancing transparency, accelerating remediation efforts, and ultimately strengthening the overall security posture of the software ecosystem.

Background

▶ Watch: Explaining the core "affected by upstream" problem and SADP (4:15)

The problem addressed by the SADP pilot is rooted in the fundamental reality of contemporary software: nearly all applications are built upon layers of other software. This intricate web of dependencies, while enabling rapid innovation, also creates a complex challenge when a vulnerability is discovered in an upstream component. The central question for any downstream consumer becomes: "Am I affected by this upstream vulnerability?" The answer is rarely straightforward; it depends on how the component is used, configured, or even compiled within the downstream product.

Historically, addressing this "am I affected" question has been a largely manual, decentralized, and inefficient process. Upstream projects, especially open-source ones like the Linux kernel or curl, often publish CVEs for vulnerabilities in their code. However, they typically lack the specific environmental context to determine the exact impact or CVSS (Common Vulnerability Scoring System) severity for every conceivable downstream deployment. Forcing them to do so often leads to a "worst-case scenario" assessment (e.g., a critical rating for a data center server), which might not apply to an Android phone using the same component, causing unnecessary panic and remediation efforts.

Downstream vendors, in turn, have had to develop their own elaborate systems to track these upstream vulnerabilities, assess their impact on their specific products, and then communicate that status to their customers. This involves subscribing to countless security advisory mailing lists, RSS feeds, and CISA feeds, followed by extensive internal automation to collect, parse, and act on this information. As Saeed Abbasi of Qualys pointed out, a single vulnerability in a widely used component like OpenSSH could necessitate the creation of dozens of unique detection signatures for different vendor implementations, a process that is currently highly fragmented and time-consuming.

The VEX (Vulnerability Exploitability eXchange) specification emerged from this need, providing a structured way to convey the affected status of a product concerning a specific vulnerability. VEX allows a software provider to state, for example, "Yes, I use WolfSSL, but not in a way that is exploitable by this particular CVE." While VEX documents exist, their distribution and aggregation remain a challenge. The SADP pilot seeks to build upon the VEX concept by integrating this crucial contextual information directly into the universally recognized CVE record, leveraging the existing ADP (Additional Data Provider) container mechanism within the CVE program to provide a more standardized and accessible solution.

Key Findings

▶ Watch: Red Hat's perspective: upstream lacks end-user context in open source (14:30)

The SADP pilot represents a significant stride towards centralizing and standardizing vulnerability impact information within the CVE ecosystem. The key findings and contributions highlighted by the panel include:

1. Proof of Concept Validation: The pilot is a "live experiment" demonstrating the feasibility of integrating VEX-like data into CVE records via ADP containers. This involves early production data contributions from participants like Siemens, Microsoft, and Red Hat, validating the technical approach. Siemens, for instance, has already published approximately 20 production pilot SADP content records.
2. Centralized Contextualization: SADP allows downstream suppliers to append their specific assessment of an upstream CVE directly to the CVE record. This addresses the critical need for contextualized data, enabling vendors like Microsoft (for Edge and Azure Linux) and Red Hat (for its Linux distributions) to clarify whether their products are affected, not affected, or remediated by a particular vulnerability, accounting for their unique implementations.
3. Efficiency Gains for Vulnerability Management: For vulnerability management (VM) vendors and security scanners like Qualys, SADP promises substantial efficiency improvements. Instead of relying on hundreds of disparate scrapers and feed readers to gather vulnerability advisories from individual suppliers, a centralized CVE record enriched with SADP containers could provide a single, authoritative source. This would drastically reduce the time and effort required to build detection signatures, accelerating the median 12-hour response time for critical and zero-day vulnerabilities currently experienced by Qualys.
4. Reduced Burden on Upstream Maintainers: Upstream projects often struggle to provide accurate impact assessments for their vulnerabilities across the vast array of downstream consumers. SADP shifts this responsibility to the downstream suppliers, who possess the necessary environmental context. This allows upstream maintainers to focus on identifying and fixing vulnerabilities, while downstream vendors provide the specific impact details relevant to their products. The Linux kernel, for example, openly advocates for downstream distributions to perform their own CVSS evaluations.
5. Enhanced Transparency and Trust: By clearly attributing the additional data to specific suppliers via ADP containers, the SADP pilot enhances transparency. Each container is "owned by someone," establishing provenance and helping consumers understand who is making a particular statement about vulnerability status. This fosters greater trust in the information provided, as scanning vendors can rely on authoritative sources directly associated with the CVE record.
6. Addressing the Scale Challenge (Initial Insights): While the ultimate scale of software dependencies is "astronomically geologically bigger" than current CVE infrastructure can handle, the pilot is beginning to explore architectural considerations. Discussions include potential limitations on the number of SADP containers per record, restrictions on who can publish, and the possibility of a distributed database approach to manage the expected explosion of data.

In essence, the SADP pilot is demonstrating a practical, if nascent, solution to a long-standing problem in software supply chain security, offering a path towards a more informed, efficient, and transparent vulnerability disclosure and management process.

Technical Deep Dive

▶ Watch: Audience question: How is SADP different from S-BOM? (26:30)

The CVE Supplier ADP (SADP) pilot is fundamentally an extension of the existing CVE Program infrastructure, designed to incorporate VEX (Vulnerability Exploitability eXchange)-like information directly into CVE records. This is achieved by leveraging ADP (Additional Data Provider) containers, a generic mechanism within the CVE framework for adding structured, attributable information to a CVE record.

A standard CVE record minimally contains a CNA (CVE Numbering Authority) container, which holds the primary vulnerability details provided by the CNA that assigned the CVE ID. The CVE Program also allows for other ADP containers, such as CISA's full enrichment or a references container. The SADP pilot utilizes this existing ADP container concept to allow downstream suppliers to publish their specific affected status regarding an upstream CVE. The key here is provenance: each container is explicitly owned by a specific entity, ensuring clarity on who is asserting what information.

From a technical implementation standpoint, SADP containers use the exact same endpoint and schema as other ADP containers within the CVE services infrastructure. This means no new, specialized APIs or data structures were needed for the pilot's core functionality. Jeremy Daigneau from MITRE emphasized that this approach minimizes friction and leverages existing tools. Users can currently search for SADP records on the cve.org website, where they are marked with a distinct badge, and the raw JSON data for these records is available in a public GitHub repository (public_SADP_data folder), automatically updated via GitHub Actions.

The content of an SADP container is critical. It must explicitly state the status of the downstream software concerning the upstream CVE. This requires providing:

• An affected array detailing the software components.
• CPE (Common Platform Enumeration) or Package URL (PURL) identifiers to precisely identify the software in question.
• The status (e.g., "affected," "not affected," "fixed," "under investigation").
• An impact statement or CVSS score contextualized for the downstream product.

Microsoft's participation illustrates a phased approach to SADP implementation:

1. Phase 1 (Simplest): Publishing references to Chrome CVEs that have been fixed in Microsoft Edge. Since Edge consumes Chrome, Microsoft regularly republishes Chrome CVEs once they've integrated the fixes. This is a direct, clear-cut use case.
2. Phase 2 (Deeper VEX Integration): Publishing VEX attestations for Azure Linux. Azure Linux, a Linux distribution, already generates thousands of VEX files for CVEs relevant to its packages. Integrating these as SADP containers would significantly expand the scope.
3. Phase 3 (Cross-Vendor Contextualization): Interpreting kernel.org CVEs by different vendors. This would demonstrate how various distributors like Red Hat and Microsoft (for Azure Linux) can provide their specific impact assessments for common upstream components.

Red Hat's perspective as a root CNA and CNA LR for open-source CNAs further highlights the technical utility. Open-source upstreams like kernel.org cannot provide environmental context or specific CVSS scores for end-users (Android phones, desktops, data centers). SADP enables downstream distros to "fill that gap," providing contextualized data directly within the CVE record, eliminating the need for consumers to consult multiple vendor portals.

A significant challenge, however, is the scale of data. The "software in other software" dependency graph is enormous. While the pilot currently involves a manageable number of records, a full-scale implementation could lead to an "astronomically geologically bigger" volume of information than CVE currently handles. MITRE is aware of this and is exploring solutions such as:

• Limiting the number of SADP containers per record.
• Restricting which entities can publish SADP containers.
• Considering a distributed database architecture to manage the data load, moving away from a purely centralized model.

Another technical consideration is whether SADP containers should embed all the VEX data directly within the CVE record or provide robust external references (e.g., a URL with metadata indicating the format like CSAF fix JSON, namespace, and version) that point to external VEX documents. Both approaches have pros and cons regarding data aggregation, trust, and infrastructure burden. The pilot aims to experiment with both to determine the most effective balance.

Demo / Proof of Concept

▶ Watch: Addressing the 'ginormous' scale of software dependencies (38:30)

The SADP pilot itself serves as the ongoing "live experiment" and proof of concept for integrating VEX-like data into CVE records. While the panel did not feature a live, interactive demonstration in the traditional sense, several key aspects of the pilot's functionality and early results were highlighted:

1. cve.org Integration and Visual Cues: Jeremy Daigneau demonstrated that SADP records are already visible on the official cve.org website. When users search for SADP-related CVEs, these records feature a "neat little badge" that visually distinguishes them as containing SADP content. This immediate visual feedback helps consumers identify and prioritize these enriched records.
2. Production Data Availability: The pilot has moved beyond mere test data. As of the conference, Siemens had published approximately 20 production pilot SADP content records. This real-world usage signifies concrete progress and provides tangible examples for the community to review and analyze.
3. GitHub Repository for Raw Data: For those seeking deeper technical inspection, a dedicated GitHub repository hosts the raw JSON of CVE records containing SADP containers. Specifically, the public_SADP_data folder is automatically updated with production diff records. An archive_pilot_data folder also exists with non-production test data, offering a larger set of examples for schema exploration.
4. Microsoft's Phased Rollout: Lisa Olson detailed Microsoft's planned and ongoing contributions. The first phase involves Microsoft publishing SADP references for Chrome CVEs that are fixed in Microsoft Edge, demonstrating a direct upstream-to-downstream dependency use case. A more ambitious second phase involves publishing VEX attestations for Azure Linux, where Microsoft already maintains 8,000-9,000 VEX files for its Linux distribution. These real-world, large-scale VEX data sets will provide crucial insights into the pilot's scalability and utility.
5. Qualys's Internal System as a Benchmark: Saeed Abbasi from Qualys provided a compelling real-world "proof of concept" for the need of SADP. He described Qualys's sophisticated internal system that processes over 100,000 signatures across 46,000 CVEs annually, achieving a median 12-hour response time for critical vulnerabilities. This system, however, relies on extensive automation to scrape hundreds of disparate security advisory sources. Abbasi cited the OpenSSH regression vulnerability (CVE-2020-15778, for example, though not explicitly named, the description matches a known regression) where Qualys released 79 signatures for the same CVE across 79 different vendors, none originating from a centralized source. This vividly illustrates the current fragmentation and the efficiency gains SADP promises by providing a single, authoritative repository of downstream status.

While the panel format naturally precluded a live coding demo, the discussion effectively conveyed the operational status of the pilot, its technical underpinnings, and its direct relevance to real-world vulnerability management challenges faced by major software vendors and security solution providers.

Defensive Implications

▶ Watch: How to handle disagreements or conflicting SADP information (50:00)

The SADP pilot carries significant defensive implications for organizations across the software supply chain, from upstream open-source projects to downstream product vendors and end-user enterprises.

1. Streamlined Vulnerability Management for Downstream Consumers: For security teams tasked with identifying and remediating vulnerabilities, SADP offers a potentially transformative shift. Instead of manually correlating upstream CVEs with numerous vendor advisories, they could find the definitive "affected" or "not affected" status directly within the CVE record. This reduces the noise generated by generic vulnerability scanners (SCA tools) that flag upstream components without considering their actual exploitability in a specific product. This direct, contextualized information saves considerable time and resources in triage and remediation planning.
2. Faster Detection and Response for VM Vendors: Companies like Qualys, which provide vulnerability scanning and management solutions, stand to gain immense efficiency. Saeed Abbasi articulated how SADP could lower the "barrier for every single CNA to start contributing" by providing a centralized, machine-readable data source. This would enable VM vendors to build and deploy detection signatures much faster and with greater accuracy, moving away from the current model of scraping hundreds of individual vendor advisories. This directly translates to quicker protection for customers against newly disclosed vulnerabilities.
3. Reduced Support Burden for Upstream Maintainers: Upstream projects often face a deluge of questions from downstream consumers about the applicability and impact of a CVE. By enabling downstream vendors to publish their own contextualized assessments, SADP can significantly reduce this support overhead. Upstream maintainers can focus on their core mission of developing and securing their components, confident that downstream users will find relevant information from their product providers. As Art Manion noted, the Linux kernel explicitly encourages downstream distributions to perform their own CVSS evaluations.
4. Enhanced Transparency and Trust through Provenance: A critical defensive aspect is the provenance of the information. Each ADP container clearly indicates who provided the data. This means that if Microsoft states its product is "not affected," that statement is attributed directly to Microsoft, fostering trust and accountability. Pete from the audience emphasized that this authoritative sourcing is crucial for scanning vendors to invest in consuming SADP data, as it provides the necessary "level of assurance."
5. Foundation for Automated Tooling: The machine-readable nature of SADP containers (JSON format) is key for automation. Security orchestration, automation, and response (SOAR) platforms, vulnerability scanners, and asset management systems can be designed to automatically ingest and process this data, enabling faster decision-making and more efficient workflows. This is particularly relevant in the age of AI-driven vulnerability discovery, where the volume of CVEs is expected to increase.
6. Challenges and Considerations for Defenders:

• Scale Management: The sheer volume of potential SADP data poses an architectural challenge. Defenders will need reliable, scalable access to this information without being "flooded" by irrelevant "not affected" statements for software they don't even use.
• Conflict Resolution: The panel acknowledged the potential for disagreements or conflicts between different SADP containers or between an SADP container and the original CNA's assessment. While Yogesh Mittal suggested that each SADP container is vendor-specific and contextualized, the mechanism for resolving outright conflicting information needs to be clearly defined to maintain trust.
• Data Completeness vs. Pointers: The decision of whether to embed full VEX data directly in the CVE record or provide robust external pointers will impact how defenders consume and store this information. A balance is needed to ensure usability without overwhelming the CVE corpus.

In summary, the SADP pilot aims to empower defenders with more accurate, timely, and contextualized vulnerability information, enabling them to make better-informed decisions and improve their overall security posture in an increasingly complex software supply chain.

Key Takeaways

• Addressing Upstream/Downstream Vulnerability Impact: The SADP pilot directly tackles the pervasive problem of determining whether a downstream product is affected by a vulnerability in an upstream component, a critical challenge in modern software supply chains.
• Centralized VEX-like Information in CVE Records: SADP leverages existing CVE Additional Data Provider (ADP) containers to integrate Vulnerability Exploitability eXchange (VEX)-like attestations directly into CVE records, providing a single, authoritative source for vulnerability context.
• Enhanced Efficiency for Vulnerability Management: By centralizing contextualized vulnerability data, SADP promises significant efficiency gains for vulnerability management vendors and security teams, reducing the need for manual data aggregation and accelerating detection and remediation.
• Contextualized Data for Consumers: Downstream suppliers can now provide their specific assessment of an upstream CVE's impact on their products, offering consumers accurate and relevant information tailored to their particular deployment environments.
• Pilot Status and Future Challenges: The SADP is a "live experiment" with early production data contributions from major vendors like Siemens, Microsoft, and Red Hat. However, significant architectural challenges related to data scale, governance, and potential information conflicts remain to be addressed for full-scale adoption.
• Trust and Provenance are Crucial: The clear attribution of SADP container content to specific providers is essential for building trust and ensuring the authoritative nature of the information, which is critical for widespread adoption and investment by the security community.

About the Speaker(s)

• Art Manion (Tharros Labs): Serving as the moderator for the panel, Art Manion is deeply involved in vulnerability-related work, primarily supporting CISA. He is a prominent member of the CVE board and actively participates in several working groups, including the Strategic Planning Working Group, which oversees the SADP pilot.
• Jeremy Daigneau (MITRE): With 10 years at MITRE and 4 years dedicated to the CVE project, Jeremy Daigneau leads the automation infrastructure work for CVE. His expertise is crucial for developing the technical backbone that supports advanced CVE program initiatives like SADP.
• Lisa Olson (Microsoft): Lisa Olson works at Microsoft in MSRC, where she manages the company's "Patch Tuesday" releases. A long-standing member of the CVE board since 2018, she brings extensive experience in vulnerability management from a major software vendor's perspective.
• Yogesh Mittal (Red Hat): A manager at Red Hat, Yogesh Mittal represents a key player in the open-source ecosystem. Red Hat acts as a root and CNA LR (CNA-of-Last-Resort) for numerous open-source CNAs, and Mittal is instrumental in running the Open Source CNA Users Group, providing invaluable insights into upstream/downstream challenges.
• Saeed Abbasi (Qualys): As a Senior Manager for Security Research at Qualys, Saeed Abbasi offers the perspective of a large-scale vulnerability management vendor. His team consumes vast numbers of CVEs, builds detection signatures for over 10,000 customers, and conducts extensive vulnerability research and zero-day hunting.