Panel: CVE Record Disputes Discussion: Policy, Process, and Opportunities for Improvement

Panel: CVE Record Disputes Discussion: Policy, Process, and Opportunities for Improvement

Speakers: Alec Summers (CVE and CWE Project Lead, The MITRE Corporation); Yogesh Mittal (Red Hat); Lisa Olson (Microsoft); Lindsey Cerkovnik (Branch Chief of Vulnerability Response and Coordination, CISA); Jimmy Calderon (Manager of Pwn2Own, TrendAI); Saeed Abu Sayeed (Senior Manager for Security Research, Qualys)

Conference: VulnCon

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

Overview

The Common Vulnerabilities and Exposures (CVE) program serves as the cornerstone for identifying and cataloging cybersecurity vulnerabilities, providing a standardized identifier (CVE ID) for each unique issue. However, the process of assigning and validating these records is not always straightforward, leading to complex situations known as CVE record disputes. This panel discussion at VulnCon brought together a diverse group of experts from across the cybersecurity ecosystem—including representatives from The MITRE Corporation, Trend Micro Zero Day Initiative (ZDI), CISA, Microsoft, Red Hat, and Qualys—to dissect the intricacies of these disputes. The conversation delved into the existing policies, the challenges faced by various stakeholders, and potential avenues for improvement.

Moderated by Alec Summers, CVE and CWE Project Lead at The MITRE Corporation, the panel highlighted that CVE record disputes are a significant point of contention and challenge for many, ranging from vulnerability researchers and software vendors to open-source communities and vulnerability management solution providers. The discussion underscored the importance of transparency, clarity, and effective communication in resolving these disagreements, which often have far-reaching implications for an organization's security posture and compliance obligations. MITRE has actively engaged with the community on this topic, publishing a dedicated dispute policy on cve.org, a blog post in December, and a podcast, all aimed at fostering a better understanding of this critical yet often opaque aspect of vulnerability management.

The panel explored the multifaceted nature of disputes, from fundamental disagreements about what constitutes a "vulnerability" to procedural issues in CVE assignment. By bringing together perspectives from those who discover vulnerabilities, those who fix them, those who track them for national security, and those who provide detection for them, the discussion painted a comprehensive picture of the current state of CVE record disputes. The insights shared revealed not only the technical and operational complexities but also the human element of frustration, differing priorities, and the constant struggle to balance speed, accuracy, and completeness in a rapidly evolving threat landscape.

Background

▶ Watch: Overview of CVE record dispute policy (3:50)

The CVE program's foundation rests on a community-driven approach, with policies and processes developed through extensive deliberations among its participants. The CVE record dispute policy, a key outcome of these discussions, was formally released in July of the previous year, following approximately six months of dedicated effort by the CVE community. This policy outlines the framework for addressing disagreements concerning CVE records, which typically fall into two primary categories:

1. Disputes over whether an issue constitutes a vulnerability: This involves fundamental disagreements on the technical nature of a flaw, its impact, or whether it meets the criteria for a CVE-worthy vulnerability.
2. Disputes regarding CNA operational rule violations: These occur when a CVE Numbering Authority (CNA) is perceived to have assigned a CVE ID inappropriately, such as assigning it to something that doesn't meet the program's definition of a vulnerability, or incorrectly counting the number of vulnerabilities for a single issue. Lisa Olson from Microsoft highlighted an example where "somebody took a hammer to a box and started banging on it," which clearly does not qualify as a CVE according to the rules.

The formal process for initiating and resolving a CVE record dispute is designed to be structured, albeit with acknowledged challenges. As Yogesh Mittal from Red Hat explained, the first step for anyone wishing to dispute a CVE record is to identify the CNA that assigned it, using contact details available on cve.org. The assigning CNA is then expected to acknowledge the dispute within three business days. Following acknowledgement, the CNA validates the legitimacy of the dispute and, if deemed valid, applies a disputed tag to the CVE record. A decision on the dispute is expected within five business days. If the disagreement persists or if the resolution process exceeds 15 days, the disputing party has the right to escalate the matter to a Root CNA or even the Top-Level Root CNA.

A critical aspect of the CVE program's distributed nature is the role of the CNA of Last Resort (CNALR). Lindsey Cerkovnik of CISA, a CNALR, noted that these entities have specific rules requiring them to consult the supplier CNA and ensure they have the first right of refusal before assigning a CVE ID. This can lead to nuanced situations where a supplier might not wish to assign a CVE themselves but permits a CNALR like MITRE to do so.

Despite these established procedures, many CVE records remain permanently disputed. Lindsey Cerkovnik elaborated on the reasons for this persistence, noting that a "disputed forever" tag, while frustrating for those seeking closure, often indicates fundamental disagreements. These can include differing organizational definitions of what constitutes a CVE-worthy vulnerability, technical disagreements about the nature or exploitability of a flaw, or the simple reality that in a program as large and distributed as CVE, not all disagreements can be resolved to mutual satisfaction. The tag, in such cases, serves as a transparent indicator of ongoing disagreement. CISA's experience with its Known Exploited Vulnerabilities (KEV) catalog provides a unique perspective; they occasionally add disputed CVEs to the KEV. While initially a concern, CISA has learned that the world continues to move forward, and patching these vulnerabilities often proves to be a good idea regardless of the dispute's eventual outcome, even if a CVE is later rejected.

Key Findings

▶ Watch: Why some CVEs remain permanently disputed (9:00)

The panel discussion illuminated several critical findings regarding CVE record disputes, highlighting the significant challenges they pose across the cybersecurity landscape:

1. The "Catch-22" for Vulnerability Management Vendors: Saeed Abu Sayeed from Qualys articulated a common dilemma faced by vulnerability management (VM) vendors. Their customers demand detection and resolution for vulnerabilities, yet vendors often dispute or refuse to fix certain issues. This creates a "catch-22" where VM providers must choose between annoying customers with detections for issues a vendor considers a "false positive" or risking a false negative if an unaddressed, disputed vulnerability is weaponized in the wild. This is particularly acute for high-severity CVEs, those with a CVSS score of 9.8, and issues impacting PCI compliance, where auditors demand clear answers and remediation.

2. Researcher Frustration and Vendor Resistance: Jimmy Calderon of Trend Micro ZDI, which manages Pwn2Own, shed light on the challenges from a researcher's perspective. Researchers often struggle to get CVEs assigned, especially for high-profile vulnerabilities that may later be exploited in the wild. He described scenarios where vendors, including major CNAs, either don't respond to reports ("CBD for me, but not for thee") or refuse to assign a CVE, claiming an issue is "not worth it" despite releasing a fix. This practice can be problematic, as lower CVSS vulnerabilities are increasingly used as exploit primitives for initial access in sophisticated attack campaigns. Calderon also highlighted issues with vulnerability chains, where vendors might only patch the initial access bug, leaving more impactful vulnerabilities (e.g., system or root access) unaddressed, leading to easy bypasses.

3. The Open Source Ecosystem's Deadlock: Yogesh Mittal of Red Hat detailed the unique challenges within the open-source community. Disputes often arise between researchers and upstream community maintainers. Many maintainers, due to various reasons, may "stop caring" about fixing or formally disputing vulnerabilities, leading to "unknown disputes" that are not visible in the public CVE record. This leaves downstream vendors like Red Hat in a precarious position, respecting upstream's assessment while facing demands for fixes from enterprise customers and scanning vendors. This creates a "deadlock situation" where the code expert may not provide a fix, but the entire open-source supply chain expects one.

4. The Scale Challenge for Large Vendors: Lisa Olson from Microsoft MSRC underscored the immense scale of vulnerability reports handled by large organizations. Microsoft, for instance, receives approximately 50,000 submissions annually, which boil down to around 10,000 cases and result in 1,000 to 1,200 CVEs assigned each year. This volume creates significant time and resource constraints, forcing prioritization. Olson warned of a "tsunami" of vulnerabilities, particularly with the advent of AI-identified flaws, suggesting that vendors may soon need to address "everything," even breaking their own rules on low and medium severity cutoffs.

5. Underreported Disputes and Misleading Statistics: The panel agreed that the official number of publicly disputed records—typically 80 to 100 per year—is likely a severe underrepresentation of the actual number of disagreements. This discrepancy stems from factors like "unknown disputes" in open source, vendors stating an intent to dispute but not following through, or internal disagreements that never reach the formal dispute process. Jimmy Calderon recounted instances where vendors would ghost researchers until a CVE was published, then react "like wildfire," sometimes threatening disputes but not executing them.

6. The "Disputed" Tag's Double-Edged Sword: While the panel acknowledged that attackers are likely interested in the underlying vulnerability rather than its dispute status, Lindsey Cerkovnik noted that the "disputed" tag does draw attention from defenders. Seeing such a tag prompts security professionals to re-read the description and investigate further, highlighting the importance of clear dispute explanations within the CVE record. This increased scrutiny, while beneficial, also underscores the ambiguity and lack of definitive guidance that disputed records often convey.

Technical Deep Dive

▶ Watch: Challenges for customers and auditors with disputes (12:40)

The technical aspects of CVE record disputes are rooted in the program's evolving policies and the distributed nature of vulnerability disclosure. The CVE program policies are living documents, subject to continuous review and refinement. Lisa Olson explained that this process, often guided by the Strategic Planning Working Group, is far from "smooth sailing" and can take considerable time. For instance, a major revision of the CVE rules took 2 to 3 years, involving intensive weekly meetings, while the dispute policy itself required a solid 6 months of deliberation before its release in July of the previous year. The program now actively encourages community feedback and proposed changes through GitHub issues, aiming for a more agile evolution of policies.

The formal dispute workflow is designed to provide a structured path for disagreements. As detailed earlier, it mandates specific timelines: a CNA must acknowledge a dispute within 3 business days and conclude it within 5 business days of acknowledgement. If unresolved after 15 days, the issue can be escalated. However, even with these timelines, fundamental disagreements can lead to a CVE record remaining permanently tagged as "disputed" with an explanation, a state that reflects the inherent nuance and lack of universal consensus on certain vulnerability interpretations.

A critical nuance in the CVE assignment process is the role of the CNA of Last Resort (CNALR). These entities, such as MITRE or CISA, have specific operational rules that require them to first consult the affected supplier and grant them the first right of refusal to assign a CVE. This can lead to situations where a supplier might not want to take ownership of a CVE assignment for various reasons (e.g., resource constraints, disagreement on severity) but may permit a CNALR to do so. This highlights the flexibility, but also the potential for friction, within the distributed CVE ecosystem.

Jimmy Calderon provided a specific technical example of how vendor decisions impact vulnerability management, particularly concerning vulnerability chaining. He described a scenario where ZDI submitted a three-bug chain, but the vendor only patched the initial access vulnerability, leaving the two subsequent, more impactful bugs (leading to system or root access) unaddressed. The vendor's rationale was that these remaining bugs "need to be chained with another vulnerability." Calderon countered that ZDI had already provided the full chain, and leaving parts unpatched inevitably leads to bypasses. This demonstrates a technical disagreement on the scope of remediation and the perceived impact of individual components within a complex exploit.

Looking forward, the panel discussed the potential for VEX (Vulnerability Exploitability eXchange) as a technical solution to improve clarity around disputed CVEs. Saeed Abu Sayeed and Yogesh Mittal advocated for VEX, a machine-readable format for conveying vendor's exploitability statements, to address the current manual process of checking multiple vendor blogs and forums for context on disputed issues. VEX could allow vendors to explicitly state whether they are affected by a disputed CVE, whether they plan to fix it, or if it's considered "not a bug" for their specific product, even if the CVE remains formally disputed. This would enable scanning vendors and enterprise consumers to make more informed, automated decisions. This concept aligns with the goals of the SADP (Software Assurance Description Protocol) pilot project, which aims to mature the way vendor context is shared within the vulnerability ecosystem.

Demo / Proof of Concept

▶ Watch: Open source community challenges with vulnerability disputes (24:00)

This event was a panel discussion focused on policy, process, and opportunities for improvement regarding CVE record disputes. As such, there were no live demonstrations or proof-of-concept exploits presented during the session. The discussion revolved entirely around theoretical frameworks, real-world experiences, and proposed solutions for managing the challenges of vulnerability disclosure and resolution.

Defensive Implications

▶ Watch: Panelists' final takeaways and call for involvement (50:00)

The insights from this panel offer critical implications for defenders striving to maintain robust security postures in an increasingly complex threat landscape. Understanding the nuances of CVE record disputes is no longer a peripheral concern but a central component of effective vulnerability management.

Firstly, proactive patching and risk assessment must extend beyond unequivocally accepted CVEs. The experience of CISA's KEV catalog demonstrates that even disputed CVEs can be weaponized and exploited in the wild. Defenders should not dismiss vulnerabilities merely because they carry a "disputed" tag; instead, this should prompt a deeper investigation into the technical details and vendor statements. The recommendation is to err on the side of caution and consider patching or mitigating such issues, especially if they appear to be low-hanging fruit for attackers or are linked to active exploitation.

Secondly, a holistic vulnerability management strategy is essential. The panel highlighted that vendors sometimes choose not to assign CVEs for fixed issues, or they only patch initial access points in complex vulnerability chains, leaving more severe components unaddressed. Defenders must recognize that seemingly "low severity" vulnerabilities (those with lower CVSS scores) can serve as crucial exploit primitives for initial access, paving the way for more impactful attacks. Relying solely on high CVSS scores for prioritization can leave organizations vulnerable to sophisticated multi-stage attacks. A comprehensive approach should factor in contextual risk, potential chaining, and observed exploitation patterns, regardless of assigned CVE status or severity.

Thirdly, there is a clear need for improved information flow and standardization. The current reliance on manual review of vendor blogs, forums, and CVE change logs for understanding dispute context is unsustainable and prone to error. The proposal for widespread adoption of VEX (Vulnerability Exploitability eXchange) is a significant defensive implication. VEX, by providing machine-readable vendor statements on exploitability and affected status, could dramatically enhance the ability of automated vulnerability management tools and enterprise security teams to quickly and accurately assess their exposure to disputed CVEs. This would streamline decision-making for patching, compliance (e.g., PCI compliance), and audit reporting. Defenders should advocate for and adopt tools that support VEX.

Finally, community engagement and advocacy are crucial. The CVE program's policies are living documents, shaped by community input. Defenders, including security managers, compliance auditors, and enterprise consumers, have a vital role to play in providing feedback on the dispute policy. Their perspectives on the real-world impact of disputed CVEs—from operational overhead to audit failures—are invaluable for refining policies that better serve the entire ecosystem. Getting involved in CVE working groups can directly influence the future direction of vulnerability disclosure and dispute resolution, ensuring that defensive needs are adequately addressed.

Key Takeaways

• Complexity and Pervasiveness of Disputes: CVE record disputes are a fundamental, often frustrating, aspect of vulnerability management, impacting all stakeholders from researchers to end-users. The official count of 80-100 disputed CVEs per year is a significant underrepresentation of actual disagreements.
• Diverse Challenges Across Stakeholders: Researchers struggle with CVE assignment and partial fixes, open-source communities face maintainers who "don't care," and large vendors grapple with immense scale (e.g., Microsoft's 50,000 annual submissions). Vulnerability management vendors are caught between customer demands and vendor denials, impacting compliance.
• Disputes are Not Necessarily Dismissible: Even disputed CVEs can be weaponized in the wild, as demonstrated by CISA's experience with the KEV catalog. Defenders should treat disputed tags as a prompt for deeper investigation rather than an excuse to ignore potential threats, especially when low CVSS vulnerabilities are used as exploit primitives.
• Need for Improved Information Flow: The current reliance on manual checks of vendor blogs and forums for dispute context is inefficient. VEX (Vulnerability Exploitability eXchange) is proposed as a crucial, machine-readable standard to provide clear vendor statements on exploitability, enabling better automated decision-making for defenders and auditors.
• Community-Driven Policy Evolution: The CVE dispute policy is a living document, refined through ongoing community deliberation. Active participation from defenders, auditors, and enterprise consumers in CVE program working groups is essential to ensure policies address real-world challenges and foster a more effective vulnerability ecosystem.
• Beyond the CVE: Nuance and Responsibility: The panel emphasized accepting nuance in vulnerability assessment and the need for vendors to take responsibility beyond just high-severity issues. Fixing a vulnerability without assigning a CVE, or only patching parts of a vulnerability chain, can leave significant attack surfaces open.

About the Speaker(s)

• Alec Summers: As the CVE and CWE Project Lead at The MITRE Corporation, Alec Summers moderated the panel, guiding the discussion on CVE record disputes and highlighting the program's efforts to provide resources and gather feedback.
• Yogesh Mittal: Representing Red Hat as a Root and CNALR, Yogesh Mittal focuses on ensuring that CVE data is accurate, fair, and useful for the open-source supply chain. His insights often touch upon the unique challenges faced by upstream maintainers and downstream consumers in the open-source ecosystem.
• Lisa Olson: From Microsoft MSRC, Lisa Olson has managed Patch Tuesday for 13 years and has been a member of the CVE Board since 2018. She provided a vendor's perspective on the massive scale of vulnerability reports and the resource challenges in addressing them.
• Lindsey Cerkovnik: As the Branch Chief of Vulnerability Response and Coordination at CISA, Lindsey Cerkovnik oversees the Known Exploited Vulnerabilities (KEV) catalog, CISA's coordinated vulnerability disclosure efforts, and SSVC triage for federal agencies. She offered critical insights into the national security implications of disputed CVEs.
• Jimmy Calderon: Manager of Pwn2Own at Trend Micro Zero Day Initiative (ZDI), Jimmy Calderon's team purchases vulnerabilities across various platforms and industries. He shared the researcher's perspective, detailing the difficulties in getting CVEs assigned and the impact of partial vendor fixes on exploit chains.
• Saeed Abu Sayeed: As a Senior Manager for Security Research at Qualys Threat Research Unit, Saeed Abu Sayeed's team builds detection for CVEs, conducts vulnerability research, and hunts for zero-days for Qualys's extensive customer base. He articulated the challenges faced by vulnerability management vendors and their customers regarding disputed CVEs and compliance.