The Vulnerability Ecosystem’s Vendor Bias — Exposed by Open Source

The Vulnerability Ecosystem’s Vendor Bias — Exposed by Open Source

Speakers: Pete Allor (FIRST Liaison, CVE Board), Yogesh Mittal (Product Manager, Red Hat)

Conference: VulnCon

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

Overview

In a critical presentation at VulnCon, Pete Allor and Yogesh Mittal illuminated a fundamental flaw in the global vulnerability ecosystem: its inherent bias towards traditional, centralized vendors, which creates significant friction and unsustainable burdens when applied to the decentralized world of open-source software (OSS). The talk, titled "The Vulnerability Ecosystem’s Vendor Bias — Exposed by Open Source," dissects how decades of established practices, designed for well-resourced manufacturers with dedicated security teams, are failing the volunteers and unfunded maintainers who power the vast majority of today's software.

Allor and Mittal, both deeply embedded in the CVE program and open-source communities, systematically exposed five key biases. These issues range from misaligned severity assessments and the bottleneck of vulnerability reporting to an "asymmetry of expectations" between enterprise consumers and OSS maintainers. Their core argument is that the current model mistakenly expects open-source creators to possess the same capacity, budget, and downstream visibility as large commercial entities, leading to burnout, inaccurate risk assessments, and a breakdown of trust.

The speakers not only highlighted these pervasive problems but also proposed actionable solutions. They advocated for a shift towards a federated responsibility model, leveraging initiatives like stewardship programs (e.g., EU-CERT) and technical advancements such as the Authoritative Source for IDP (ASIDP) to provide crucial contextual information. This evolution aims to alleviate the burden on maintainers, enhance the clarity of risk for enterprises, and ultimately foster a more resilient and equitable vulnerability management landscape for the ubiquitous open-source components underpinning modern infrastructure.

Background

▶ Watch: Introduction: Vendor-centric vs. decentralized open source vulnerability ecos... (0:00)

The modern software landscape is undeniably dominated by open-source components. Yogesh Mittal emphasized this ubiquity, citing statistics that 76% of commercial applications today incorporate open-source software. This translates to an astonishing 40 million component versions, a figure that has grown exponentially, with Red Hat alone managing 4.5 million components years ago. Critically, the vast majority of these 40 million components are maintained by unfunded, single maintainers—volunteers driven by passion, not corporate budgets or dedicated security teams.

The challenge arises from the fact that the existing global vulnerability ecosystem, meticulously built over the last 25 years, was designed around a very different paradigm: the traditional vendor. This "traditional vendor" is characterized by a centralized manufacturing process, a dedicated security budget, and a funded incident response team. These assumptions are deeply embedded in how vulnerabilities are reported, tracked, and managed, from initial disclosure to patch deployment.

However, when this vendor-centric framework is imposed upon the decentralized, volunteer-driven open-source ecosystem, a fundamental friction emerges. As Pete Allor and Yogesh Mittal explained, the system effectively treats these open-source volunteers as if they were large manufacturers. This leads to unrealistic expectations: expecting them to have the capacity for detailed vulnerability triage, the budget for extensive security operations, and, most importantly, perfect downstream visibility.

The speaker provided the Linux kernel as a prime example. Kernel maintainers, while responsible for the core code, have no way of knowing the myriad contexts in which their code is deployed—whether it's running on an Android phone, a home desktop, or a data center server. This lack of context means they cannot accurately assess the specific risk for every potential customer environment. The prevailing assumption, therefore, is that the "creator" (the open-source maintainer) owns the entire downstream risk and challenge, an untenable position that forms the crux of the ecosystem's vendor bias. This systemic mismatch was a key finding from the OSS CNA Users Group, an initiative started by Mittal and Allor, which brought together various distro CNAs, as well as representatives from projects like Curl, Kernel, Cpan, and Mozilla, to discuss these very issues.

Key Findings

▶ Watch: Five biases in vulnerability ecosystem affecting open source (4:20)

The talk meticulously outlined five critical failures or "biases" identified through the experiences of the OSS CNA Users Group, highlighting the systemic issues stemming from the vendor-centric vulnerability ecosystem:

1. Criticality Mismatch and Reachability Disconnect: The first bias concerns the assessment of severity. When an open-source maintainer issues a vulnerability record, aggregators or downstream consumers often enrich this information by assigning severity scores, frequently defaulting to a worst-case scenario. This is problematic because maintainers themselves often lack the context to define a vulnerability's true impact across diverse environments. Pete Allor underscored a crucial distinction: "presence of code doesn't equal reachability." Simply because vulnerable code exists in a component doesn't mean it's actively exploitable or poses a risk in a given application. The talk cited a staggering statistic: 88% of vulnerable code components are not reachable, meaning they do not pose an actual risk despite being present. This disconnect between theoretical vulnerability and practical risk leads to numerous false positives and misprioritization.

1. Ambiguity of the Authoritative Source: The CVE program's documentation clearly states that the CNA (CVE Numbering Authority) is the authoritative source for vulnerability information. However, in the open-source context, the question becomes, "Which CNA?" This model worked well 25 years ago for proprietary code where the original vendor was the sole authoritative source. Today, with open-source components integrated into countless products and distributions, the original maintainer (e.g., the Kernel CNA) cannot provide context for every downstream implementation. Aggregators often apply a single, generalized environmental condition to a base CVSS score, failing to capture the nuanced risk profiles of different deployments. This results in a lack of precise, contextualized information for consumers.

1. Vulnerability Reporting Bottleneck and Unfunded Mandate: The ecosystem has "industrialized and incentivized people to report vulnerabilities," leading to a dramatic increase in CVEs. A few years ago, crossing 10,000 vulnerabilities per year was considered problematic; now, the system handles over 40,000 per year, with an anticipated "tsunami" from AI-generated code. This volume, driven by research and resume-building, pushes reporting frameworks to assume the worst-case scenario. This creates an unfunded mandate for open-source maintainers, who are typically volunteers, often working across different time zones, sometimes as single individuals. They are expected to immediately fix a constantly increasing stream of vulnerabilities, leading to severe burnout and an unsustainable workload.

1. Asymmetry of Expectations: A significant disconnect exists between enterprise consumers and open-source maintainers regarding response times. Enterprises, especially large ones, often demand immediate fixes for published CVEs, sometimes within hours, particularly for "critical" vulnerabilities (e.g., CVSS scores above 9.0). This expectation assumes an "enterprise-grade incident response" team. However, open-source maintainers operate on a different clock. Developing a proper patch requires time for development, "soaking" (allowing for testing and stabilization), and adherence to a security development lifecycle (SDL)—processes that span days and weeks, not hours. This fundamental mismatch in expectations leads to frustration, perceived untrustworthiness, and a breakdown in effective vulnerability management.

1. The "Disputed Trap": This bias arises when a reported vulnerability is reviewed by a maintainer who then deems it "not so" or not applicable to their project, leading to a "disputed" record. Pete Allor noted that in 2024 alone, there were 108 disputed CVE records. For an organization consuming open-source software, having 10-20 disputed records affecting their products creates a significant problem. Their customers will see these as unresolved issues, demanding fixes, while the organization's response is often "upstream hasn't fixed it." The "disputed tag" itself, Allor argued, "is killing customer support and customer response," eroding trust and unfairly painting the entire IT industry as "nonplussed" or untrustworthy.

Technical Deep Dive

▶ Watch: Unfunded mandate and burnout for open source maintainers (9:00)

To address the deep-seated vendor bias and the resulting friction in the vulnerability ecosystem, Allor and Mittal proposed a fundamental shift in model and leveraging specific technical mechanisms. The core principle is to move away from the expectation that open-source maintainers (the "creators") alone own the problem, towards a more federated model of responsibility.

This federated approach is exemplified by initiatives such as EU-CERT, which has adopted a stewardship role for open-source projects. In this model, external entities or federations assume responsibility for providing contextualized information and support, rather than solely relying on the original maintainer. This acknowledges that while maintainers own the code, the broader ecosystem owns the contextual understanding of its use and risk.

A key technical solution discussed is the Authoritative Source for IDP (ASIDP) initiative. This program aims to solve the critical issues of context and capacity. The current system lacks a standardized way for downstream vendors or suppliers to provide their specific context and enrich a vulnerability record. For instance, the Linux kernel maintainers cannot realistically provide a CVSS score or CWE impact assessment for every possible deployment scenario. ASIDP addresses this by allowing suppliers to contribute this crucial context.

Under the ASIDP model, a master CVE record will no longer be a monolithic entry but will evolve into a containerized structure. It will include the original CNA container (from the maintainer), a CISA IDP container (potentially from a central authority like CISA), and critically, supplier containers. This means that a vulnerability affecting a specific open-source library could have its initial report from the upstream CNA, and then a downstream Linux distribution (e.g., Red Hat) could add a supplier container detailing how that vulnerability impacts their specific version of the operating system, including their own CVSS assessment, mitigation strategies, or even exploitability details (VEX information). This transforms the CVE record into a one-stop shop for the ecosystem, aggregators, and customers, providing comprehensive and contextualized information.

Red Hat is actively involved in a production pilot for ASIDP, brainstorming how to implement it without "flooding the system" with undifferentiated information. The goal is to provide targeted, actionable context. Pete Allor reinforced this, explaining that splitting responsibility means the original CNA provides the core vulnerability, but each downstream consumer (e.g., 20 versions of Linux) provides their specific context because they often implement and use the software differently. This acknowledges the inherent variability of software deployment.

Beyond ASIDP, the speakers also addressed the "disputed trap" directly. Instead of binary "vulnerable or not vulnerable" decisions that often lead to disputes, they advocate for using machine-readable context (likely through ASIDP/SDP structures) to provide nuance. Pete Allor, being on the dispute policy review panel, highlighted the need to adjust policy to adjudicate dispute resolution processes to be faster and lead to clear conclusions or frameworks, rather than leaving issues in limbo.

Finally, a broader call to action for policy makers was made, prompted by a question regarding "double asking or double reporting." The speakers emphasized the need for a simpler way for small team maintainers to report vulnerabilities to multiple policy bodies (e.g., CVE and potential EU-CERT equivalents) without redundant effort. This speaks to the need for interoperability and streamlined processes at a policy level, complementing the technical solutions. The overarching theme is to "fix the model, not the data," by building frameworks and technical mechanisms that support distributed responsibility and contextualized information exchange.

Demo / Proof of Concept

▶ Watch: The 'disputed tag' problem and its trust impact (12:10)

While the talk did not feature a live, interactive demonstration, the speakers did provide insight into ongoing efforts to implement the proposed solutions. Yogesh Mittal explicitly mentioned that the Authoritative Source for IDP (ASIDP) initiative, a core component of their federated model, is currently in a production pilot phase.

He stated, "We tested something in the staging environment as a pilot. At the moment, we are in production pilot." This indicates that the concepts of ASIDP, including the structured CVE record with CNA, CISA IDP, and supplier containers, are being actively developed and tested within real-world environments. Mittal acknowledged that Red Hat, as an early adopter, is still "brainstorming internally" on the most effective way to utilize ASIDP without overwhelming the system, emphasizing the desire not to simply "dump all of the VEX information into the CVE record, go figure out." This ongoing pilot serves as the practical proof-of-concept for the technical solutions presented, demonstrating a commitment to evolving the vulnerability ecosystem through tangible means.

Defensive Implications

▶ Watch: Call to action: Fix the model, not the data (20:10)

The insights shared by Allor and Mittal carry profound implications for various stakeholders involved in cybersecurity defense, urging a re-evaluation of current practices and a proactive adoption of new models.

For Enterprises, Scanners, and Aggregators:

The most critical defensive implication is the need to recalibrate their understanding of vulnerability versus risk. The speakers' assertion that "presence of code doesn't equal reachability" and that 88% of vulnerable components may not be reachable is a stark reminder to move beyond simplistic vulnerability scanning results. Enterprises must stop demanding "centralized behavior from decentralized communities." Instead, they should invest in tools and processes that can consume and interpret contextualized vulnerability data (e.g., from ASIDP) to make accurate, business-relevant risk decisions. This means asking "better questions" about how a vulnerability impacts their specific environment, rather than just relying on a base CVSS score or an aggregator's worst-case assessment. The goal is to gain "context clarity for their risk," leading to truly "actionable enterprise risk data."

For Policy Makers and Framework Designers:

The talk serves as a clear call to action to design frameworks that are equitable and effective for both traditional vendors and open-source communities. This includes:

• Adopting stewardship models: Like those implemented by EU-CERT, where external entities support open-source projects in vulnerability management.
• Integrating ASIDP/SDP: Ensuring that vulnerability data structures can accommodate federated responsibilities and contextual information from multiple sources.
• Revising dispute resolution policies: To be faster, fairer, and lead to definitive conclusions, thereby restoring trust and reducing customer support burdens.
• Simplifying reporting mechanisms: Eliminating the need for "double reporting" to different authorities, especially for resource-constrained open-source maintainers. Policy should facilitate, not complicate, vulnerability disclosure.

For Open-Source Maintainers:

While the talk largely focuses on the burden on maintainers, it also highlights opportunities for them to leverage emerging solutions. Maintainers should:

• Embrace stewardship programs: To offload some of the downstream contextualization and support responsibilities.
• Utilize ASIDP/SDP initiatives: To provide their core vulnerability information without the impossible task of assessing every downstream impact. This empowers them to focus on code fixes while the ecosystem handles context. Daniel Stenberg of Curl was cited as an example, stating he doesn't mind downstream entities augmenting his records as long as it's clear where consumers should go for support.

In essence, the defensive posture must shift from a reactive, volume-driven approach to a proactive, context-aware strategy. This requires collaboration across the entire vulnerability ecosystem to build resilient processes and systems that acknowledge the realities of open-source software development and consumption.

Key Takeaways

• The existing global vulnerability ecosystem is fundamentally biased towards traditional, centralized vendors, creating unsustainable burdens and friction for decentralized open-source communities and their volunteer maintainers.
• Unrealistic expectations placed on open-source maintainers—to possess enterprise-level capacity, budgets, and downstream visibility—lead to burnout, delayed fixes, and a breakdown of trust.
• Contextualizing vulnerability data is paramount; simply detecting "vulnerable code" does not equate to "actual risk." Factors like reachability and specific deployment environments must be considered for accurate risk assessment.
• A shift towards a federated responsibility model is essential, where maintainers own the code, and downstream entities or stewardship programs provide crucial contextual information and support.
• Technical advancements like the Authoritative Source for IDP (ASIDP) are critical for enabling this federated model, allowing for enriched, multi-source vulnerability records that provide a comprehensive "one-stop shop" for risk data.
• Enterprises, aggregators, and policy makers must adapt their frameworks, expectations, and dispute resolution processes to align with the realities of open-source software, fostering a more equitable and effective vulnerability management ecosystem.

About the Speaker(s)

Yogesh Mittal is a Product Manager at Red Hat, where his team is responsible for managing Red Hat's root CNA LR (CVE Numbering Authority – Last Resort) operations. He is also an active member of the Global Vulnerability Intelligence (GVI) panel, an initiative run by Ole Johnson. Mittal is deeply involved in efforts to improve the vulnerability ecosystem, particularly for open-source software, and played a key role in initiating the OSS CNA Users Group.

Pete Allor is a FIRST Liaison and a current CVE Board member, bringing extensive experience to the vulnerability management space. He is a former Red Hat employee and is now "mostly retired," though he remains actively engaged in shaping the future of the CVE program. Allor was instrumental in encouraging Yogesh Mittal's work with root CNAs and CNA LRs, and he is actively involved in policy discussions, including the dispute policy review panel, advocating for pragmatic solutions to systemic issues.