CVE Unmoored: Implications of the Removal of the Technology Requirement

CVE Unmoored: Implications of the Removal of the Technology Requirement

Speakers: Jonathan Evans, Curator, GitHub Advisory Database

Conference: VulnCon

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

Overview

Jonathan Evans, a seasoned expert from GitHub's Advisory Database and a former member of MITRE's CVE team, delivered a compelling talk at VulnCon titled "CVE Unmoored: Implications of the Removal of the Technology Requirement within the CVE Rules." This presentation delved into the profound changes to the Common Vulnerabilities and Exposures (CVE) program rules, specifically the removal of the long-standing "technology requirement." This seemingly subtle alteration carries significant ramifications, broadening the scope of what can be assigned a CVE ID and introducing new complexities for both vulnerability researchers and CNA (CVE Numbering Authority) organizations.

The core of Evans' talk revolved around exploring how this rule change expands the definition of a "vulnerability" to encompass a much wider array of issues, moving beyond traditional software and hardware products. He presented a series of thought-provoking scenarios, prompting the audience to consider whether various issues—from cloud service buffer overflows to physical lock bypasses and even quantum computing breakthroughs—would now qualify for a CVE under the revised guidelines. The discussion highlighted the increased reliance on CNA judgment and the potential for a dramatic increase in the volume and diversity of CVE assignments.

The talk is critically important for anyone involved in cybersecurity, vulnerability management, or product security. It sheds light on the evolving landscape of vulnerability identification and disclosure, emphasizing that the boundaries of what constitutes a security flaw are expanding. Understanding these new rules is crucial for organizations to accurately assess risks, for researchers to properly report findings, and for the CVE program itself to maintain its relevance and efficacy in an increasingly complex technological and physical threat environment.

Background

▶ Watch: Introduction and speaker's background (0:00)

For many years, the CVE program operated under a set of rules that implicitly, and often explicitly, limited the scope of assignable CVE IDs to vulnerabilities residing within specific technological products or services that were not "customer controlled." Jonathan Evans, having spent a decade on the CVE team at MITRE, provided valuable historical context for these old rules.

One primary reason for the "customer-controlled" exclusion was practical: if a vulnerability existed in a service entirely managed by a provider (e.g., a SaaS application), the provider would ideally fix it for all users without requiring individual customer action. Therefore, a CVE was often deemed unnecessary as the issue was resolved centrally. Another significant factor was MITRE's capacity and technical limitations as the sole CVE assignment authority in the program's early days. It was challenging for MITRE to definitively determine if a reported vulnerability in a service was truly a new flaw in the service itself or an issue stemming from an underlying dependency that the service utilized. This ambiguity made it difficult to confidently assign a unique CVE ID without deep insight into the service's internal architecture.

However, the cybersecurity landscape has undergone a radical transformation. The proliferation of cloud services, the emergence of AI (Artificial Intelligence) technologies, and the increasing interconnectedness of systems—including those that blur the lines between software, hardware, and even physical security—created a growing demand for a more flexible vulnerability identification system. Researchers and industry stakeholders began advocating for the ability to assign CVE IDs to vulnerabilities found in cloud infrastructure, AI vulnerabilities, and other non-traditional targets. Recognizing this shift, the CVE program evolved, leading to the pivotal change: the removal of the explicit "technology requirement." The new rules now specifically state "no technology requirements," signaling a fundamental departure from previous constraints and placing a greater emphasis on the CNA's judgment to determine the appropriateness of a CVE for a "vulnerability-like thing."

Key Findings

▶ Watch: Scenario: CDN buffer overflow (cloud vulnerability) (2:40)

The central "finding" of Evans' talk is the profound and multifaceted impact of removing the technology requirement from the CVE rules. This change is not merely a bureaucratic tweak but a fundamental redefinition of what can be considered a Common Vulnerability and Exposure. The key findings can be summarized as:

1. Expanded Scope of Vulnerabilities: The most significant outcome is the dramatic expansion of what can now be assigned a CVE ID. This includes vulnerabilities in cloud services, AI services, custom websites (even university portals), CI/CD (Continuous Integration/Continuous Delivery) scripts that leak secrets, physical security bypasses (if security claims are made), and even issues related to quantum computing breaking cryptographic primitives. This moves the CVE program beyond its traditional focus on software and hardware products.

1. Increased Reliance on CNA Judgment: With the removal of rigid technological constraints, CNAs are now explicitly instructed to "use their own judgment on whether or not a CVE is appropriate." This shifts the burden of interpretation and decision-making to individual CNAs, potentially leading to inconsistencies but also allowing for greater flexibility in addressing novel vulnerability types.

1. Potential for Proliferation of CVEs: Evans highlighted the concern that this broadened scope could lead to an overwhelming increase in the number of CVEs issued. For instance, every custom website with a SQL injection could theoretically receive a CVE, a scenario that could flood the system, particularly impacting the CNA of Last Resort (currently MITRE).

1. Blurring Lines Between Security and Other Issues: The new rules challenge conventional distinctions. Issues like physical attacks, safety concerns (e.g., a car pedal sticking randomly), or even the existence of quantum computing itself breaking algorithms, now require careful consideration. The rules attempt to draw lines (e.g., physical attacks generally excluded unless a claim is made, jamming frequencies are brute force), but these lines are often debated.

1. Emergence of New Vulnerability Categories: The talk implicitly points to the emergence of new categories of vulnerabilities that were previously difficult to classify under the old rules. Examples include typosquatting in package dependencies, or side-channel attacks leveraging hardware noises to extract encryption keys.

1. Need for Evolving Consensus: The rules acknowledge that "technological and other changes over time may be considered vulnerabilities" and that if a "vulnerability-like thing" gains consensus, it should be added to the rules. This indicates an adaptive framework, but also one that is constantly in flux, requiring ongoing community engagement (e.g., the AI working group).

These findings collectively underscore a pivotal moment for the CVE program, moving it from a product-centric model to a more expansive, judgment-based system designed to keep pace with the rapidly evolving threat landscape.

Technical Deep Dive

▶ Watch: Scenario: University portal SQLi (expanded scope) (4:20)

The core of the technical change lies in the explicit removal of the "technology requirement" within the CVE rules, a shift that fundamentally redefines the boundaries of what constitutes a "vulnerability" for the purpose of CVE assignment. Previously, a vulnerability had to be tied to a specific product or service that was not "customer controlled" by the reporter. The new rules, however, state "no technology requirements," giving CNAs significantly more latitude. This shift is particularly driven by the need to address vulnerabilities in cloud services and AI vulnerabilities, which often don't fit the traditional product model. The rules now emphasize that CNAs must "use their own judgment" and that "technological and other changes over time may be considered vulnerabilities."

Evans illustrated these changes through a series of scenarios, highlighting the nuanced interpretations required:

1. Cloud Service Vulnerabilities: A content distribution network (CDN) experiencing a buffer overflow that leaks server memory to users is now a clear candidate for a CVE. This was a primary driver for the rule change, allowing cloud vulnerabilities to be formally recognized.

1. AI Service Bypass: An attacker bypassing deep fake protections in an AI service is generally not considered a CVE. Evans referenced recent AI guidance from CVE, likening it to a vulnerability scanner missing something—it's an expected limitation, not a security flaw in the underlying technology itself. This highlights the distinction between a system failing to meet an expectation versus a specific exploitable vulnerability. However, the existence of an AI working group within CVE suggests that consensus on what constitutes an AI vulnerability is still evolving.

1. Custom Websites: A SQL injection in a university's custom student portal does get a CVE. This is a significant expansion, as it implies that virtually any custom-developed website, previously considered "customer-controlled" and thus outside CVE scope, can now be assigned a CVE. This dramatically broadens the potential pool of CVEs.

1. Vulnerabilities in Common Plugins: A vulnerability in a website caused by a common plugin can get a CVE, which is consistent with traditional CVE assignment for reusable components. However, Evans noted the practical challenge: a researcher might simply report the flaw to every affected website rather than the plugin vendor or MITRE, making it difficult for the CVE system to track the root cause effectively.

1. Physical Attacks and Security Claims:

• Music Video Resonance: A music video's resonance causing a device to malfunction is generally not a CVE under the new rules, as physical attacks are usually excluded unless the product specifically claims to protect against them. The old rules might have allowed this, showing a tightening in some areas.
• Padlock with Weak Spring: A padlock bypass due to a weak spring can get a CVE if the padlock makes explicit "security claims" about protecting against access. This introduces the concept of a "security claim" as a trigger for CVE eligibility in the physical realm.
• Tamper-Proof Seal Bypass: A tamper-proof seal on a physical Bitcoin bypassed by pressing down and feeling a key did not get a CVE under old MITRE rules but would under the new rules, again due to the explicit security claim of "tamper-proof."

1. Non-Traditional Attack Vectors:

• Phone Number Port-Out: Impersonating a victim to port out their phone number is a "maybe" for a CVE. The rules state "technological and other changes over time may be considered vulnerabilities," allowing for interpretation. Evans leans towards "no" based on judgment, but acknowledges its eligibility.
• Radio Jamming: Radio jamming to disable a military drone is explicitly not a CVE, as it's lumped in with other brute force attacks that are also generally excluded.
• Pickle Scan Failure: A security tool like "pickle scan" (designed to detect pickle attacks) missing an attack because the object uses pip.mate did get a CVE. This is because the tool explicitly claimed to detect a pattern and failed. This highlights that failures in security tools themselves, when they make specific claims, can be CVE-worthy.

1. CI/CD Pipeline Vulnerabilities: Mistakes in GitHub action scripts leading to secret exposure in a CI/CD pipeline can now get a CVE. Previously, these were in a gray area because they didn't directly affect the final package but rather the development workflow. The new rules, lacking a technology requirement, treat this as a service-like vulnerability.

1. Biological Computers and Quantum Computing:

• RNA-based computer virus: A virus for a biological-based RNA computer is a "maybe." It could fall under "technological changes" but also borders on a "physical attack," which are generally excluded.
• Quantum Computing Breaking Hashes: The ability of quantum computing to break existing hash mechanisms and encryption definitely gets a CVE. This is a prime example of "technological changes over time" rendering previously secure systems vulnerable, validating the need for this specific clause in the rules. The debate shifts to at what level the CVE should be assigned (system, standard, or application).

1. Non-Security Issues: A new car model with a pedal that randomly sticks, causing uncontrollable acceleration, is not a CVE. This is a safety issue, not a security issue, as there's no attacker vector. This reinforces that CVEs are specifically for security vulnerabilities.

1. Insecure Default Configurations: Elevators sharing the same key to bypass floor access restrictions is considered "no" by Evans. While insecure default configurations can be considered, they are not always required to be CVEs, especially when necessary for emergency services.

This deep dive reveals a significant paradigm shift. The CVE program is attempting to adapt to a world where "technology" is no longer confined to discrete products, and security boundaries are increasingly permeable. The emphasis on CNA judgment, while necessary for flexibility, also introduces potential for inconsistency and a heavier burden on the vulnerability management ecosystem.

Demo / Proof of Concept

▶ Watch: Physical attacks and CVEs under new rules (6:00)

While the talk did not feature a traditional software or hardware demonstration, Jonathan Evans effectively utilized an interactive "guessing game" as a proof of concept for the new CVE rules. Through a series of hypothetical scenarios, he demonstrated in real-time how the removal of the technology requirement and the emphasis on CNA judgment impact the eligibility of various issues for a CVE ID.

Each scenario, ranging from a CDN buffer overflow to a physical padlock bypass or the implications of quantum computing on cryptography, served as a mini-demonstration of the rules' application. By asking the audience for a show of hands on whether a scenario should receive a CVE, Evans actively engaged participants in the interpretive process that CNAs now face. He then revealed the official or most likely interpretation, often explaining the specific rule clauses or underlying principles (e.g., security claims, physical attacks, technological changes) that governed the decision. This interactive format effectively illustrated the complexities, ambiguities, and expanded scope introduced by the new CVE guidelines, making the theoretical changes tangible and understandable.

Defensive Implications

▶ Watch: Scenario: Tamper-proof seal bypass (physical claims) (10:50)

The removal of the technology requirement from CVE rules has profound implications for defenders across various sectors, necessitating a re-evaluation of vulnerability management strategies and risk assessment frameworks.

1. Expanded Attack Surface Awareness: Organizations must now recognize that their potential attack surface, as defined by CVE-eligible vulnerabilities, extends far beyond traditional software and hardware products. This includes custom-developed internal applications, bespoke websites, CI/CD pipelines (e.g., GitHub action scripts leaking secrets), and even certain aspects of physical security where explicit claims are made (e.g., tamper-proof seals). Defenders need to broaden their scope of security assessments to include these previously gray areas.

1. Increased CVE Volume and Prioritization Challenges: Jonathan Evans explicitly warned that the new rules could lead to a "proliferation of CVEs," potentially "killing the system" due to the overwhelming burden on CNAs, especially MITRE as the CNA of Last Resort. For defenders, this means sifting through a much larger volume of reported vulnerabilities. Effective prioritization will become even more critical, requiring sophisticated threat intelligence and risk-scoring mechanisms to identify the most impactful CVEs relevant to their specific environment. The introduction of tags like "solely hosted service" for cloud vulnerabilities might help with filtering, but more such categorization may be needed.

1. Rethinking "Vulnerability" in Cloud and AI: The ability to assign CVEs to cloud vulnerabilities and the ongoing debate around AI vulnerabilities means defenders operating in these spaces need clearer guidance. While a buffer overflow in a CDN is straightforward, discerning what constitutes an AI vulnerability (beyond a simple bypass of deep fake protections) will require close attention to evolving consensus and guidance from groups like the AI working group within CVE.

1. Physical Security Intersections: The rule allowing CVEs for physical bypasses if security claims are made introduces a new dimension. Organizations with products making security claims (e.g., locks, tamper-proof packaging, secure enclosures) must now consider these physical attributes as part of their CVE scope. This necessitates closer collaboration between physical security teams and cybersecurity teams.

1. Supply Chain Security Depth: The example of typosquatting in package dependencies receiving a CVE highlights the need for even deeper scrutiny of the software supply chain. Defenders must implement robust dependency scanning and maintain strict controls over external packages to mitigate risks from such non-traditional vulnerabilities.

1. Judgment and Policy Development: Given the increased reliance on CNA judgment, organizations that act as CNAs, or those that frequently report vulnerabilities, will need to develop clearer internal policies for interpreting the new rules. This includes defining what constitutes a "security claim" for physical products or how to categorize novel issues like quantum computing's impact on cryptography. Evans suggested MITRE might need its own policy to scope out certain issues to manage the load.

1. Proactive Monitoring for "Vulnerability-Like Things": The rule that "if there's a vulnerability-like thing and there's a consensus around it then that vulnerability like things should get added to the rules" implies an ongoing, dynamic evolution of what's considered a CVE. Defenders must stay abreast of industry discussions and emerging threat paradigms to anticipate new categories of CVEs.

In essence, defenders are being called upon to adopt a more holistic and adaptive approach to vulnerability management, recognizing that the scope of what constitutes a "security flaw" is broader and more fluid than ever before. This requires not just technical controls, but also strategic foresight and active engagement with the evolving CVE ecosystem.

Key Takeaways

• The removal of the "technology requirement" fundamentally broadens the scope of what can be assigned a CVE ID, extending beyond traditional software and hardware products to include cloud services, custom websites, and certain physical security claims.
• CNA judgment is now a critical component in determining CVE eligibility, leading to greater flexibility but also potential inconsistencies across different CNAs and a heavier burden on the CVE system.
• New categories of vulnerabilities, such as flaws in CI/CD pipelines (e.g., GitHub action scripts), typosquatting in package dependencies, and the impact of quantum computing on cryptography, are now explicitly or implicitly eligible for CVEs.
• Physical security issues can receive CVEs if the product makes explicit "security claims" that are subsequently bypassed, blurring the lines between cyber and physical security.
• Defenders must expand their threat model and vulnerability management scope to encompass these newly eligible categories, including custom applications, cloud configurations, and specific physical security elements.
• There is a significant concern about a potential "proliferation of CVEs," which could overwhelm the system and necessitate new filtering mechanisms and clearer prioritization strategies for organizations.

About the Speaker(s)

Jonathan Evans is a distinguished expert in vulnerability management and disclosure. Currently, he serves as a Curator on the GitHub Advisory Database at GitHub, where he is responsible for publishing advisories for security issues and assigning CVE IDs to vulnerabilities identified within repositories hosted on GitHub. Prior to his role at GitHub, Evans dedicated a decade of his career to MITRE, working directly on the CVE team. This extensive experience provides him with a unique and invaluable perspective on the historical context, operational nuances, and ongoing evolution of the CVE program, making him a leading voice on its policy changes and future implications.