Towards a Minimum Viable Enumeration of Vulnerabilities

Towards a Minimum Viable Enumeration of Vulnerabilities

Speakers: Art and Jay

Conference: VulnCon

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

Overview

In an era defined by the rapid proliferation of vulnerability data sources, the challenge of effectively managing and responding to security flaws has grown exponentially. The talk "Towards a Minimum Viable Enumeration of Vulnerabilities" (MVVE) delivered by Art and Jay at VulnCon delves into a fundamental question: what is the absolute minimum information required in a vulnerability record to uniquely identify a vulnerability and enable the initiation of its management process? This presentation, born from ongoing discussions between the speakers, both deeply involved with CVE.org, proposes a parsimonious yet powerful definition for essential vulnerability data.

The impetus for this research stems from the overwhelming volume of information presented across numerous vulnerability databases, from OSV and GitHub Security Advisories to national NVDs like JPERT and the Chinese NVD. While each aims to provide valuable context, the sheer quantity of data can hinder efficient risk management. Art and Jay argue that by identifying the core, indispensable elements, organizations can streamline their vulnerability management workflows, reduce overhead, and ensure that critical information is consistently available, regardless of the originating database.

Background

▶ Watch: Introduction to Minimum Viable Vulnerability Enumeration (MVVE) (0:00)

The landscape of vulnerability information has become increasingly complex. As Jay highlighted, the emergence of numerous databases such as OSV, GitHub Security Advisories, JPERT (the Canadian NVD), and the Chinese NVD, alongside established entities like CVE.org, presents both opportunities and challenges. While these platforms aim to provide comprehensive details, the sheer volume of data can be paralyzing. Art visually represented this with a "word cloud" of terms commonly found in vulnerability records, illustrating the potential for information overload. The question arises: do we truly need all these details, and do they provide a benefit commensurate with the cost of their acquisition and maintenance?

This challenge is not entirely new. Art referenced a seminal paper from 1999, which explored similar questions about the content of vulnerability databases in the early days of CVE. This historical context underscores that the debate over what constitutes essential vulnerability data is a persistent one, evolving with the complexity of software ecosystems. Ultimately, vulnerability management is a form of risk management. Organizations cannot eliminate all vulnerabilities, nor can they fix them all simultaneously. The core challenge is to identify, prioritize, and manage these risks effectively, a process that is hampered when the foundational information is either insufficient or excessively verbose. The speakers emphasized their focus on the "absolute absolute minimum" required to cut through this complexity and establish a universal baseline for vulnerability records.

Key Findings

▶ Watch: The challenge of many different vulnerability databases (2:00)

The core contribution of Art and Jay's talk is the definition of Minimum Viable Vulnerability Enumeration (MVVE), a set of stringent criteria for what constitutes essential information in a vulnerability record. They established three fundamental requirements for MVVE:

1. Unique and Public Identifier: Each vulnerability record must possess a unique and publicly accessible identifier. For primary databases like CVE.org, this would be a CVE ID. For secondary sources, which enrich primary identifiers (e.g., EPSS scores linked to a CVE ID), they may not need their own unique ID, but they must reference one.
2. Information for Vulnerability Management Initiation: The record must contain enough data to allow a product consumer to initiate their vulnerability management process. This means providing sufficient context for a consumer to recognize a vulnerability relevant to their environment.
3. Sufficient Disambiguation: The information provided must be adequate to "disambiguate" or "disentangle" one vulnerability from another. Even if a perfect, universally agreed-upon definition of "a vulnerability" vs. "multiple vulnerabilities" remains elusive, the record must allow consumers to distinguish between distinct security flaws.

To validate these requirements, the speakers proposed a simple yet effective test: if any one of the defined minimum elements is removed from a record, the record should "fall apart" and cease to be functional for its intended purpose. This "removal test" ensures that each MVVE component is truly indispensable. Furthermore, they advocated for parsimonious data representation, meaning vulnerability records should represent affected or non-affected states in the most efficient way possible, avoiding unnecessary replication or overly complex structures. This focus on efficiency and precision underpins the entire MVVE concept.

Technical Deep Dive

▶ Watch: MVVE Element 1: Unique and public identifier (4:50)

To rigorously define MVVE, Art and Jay first established a conceptual framework comprising key vulnerability management phases and stakeholder roles. While acknowledging that their proposed phases are an idealized timeline, they serve as a crucial context for evaluating the necessity of information elements.

Vulnerability Management Phases

The speakers outlined an 11-step idealized vulnerability management timeline, emphasizing that this linear progression represents a "risk minimizing defensive coordinated vulnerability disclosure" scenario:

1. Discovery (private): A vulnerability is initially found, often by a researcher or internal team.
2. Report (private): The discovery is reported to a coordinator or vendor.
3. Coordination (private): A private period of collaboration between the reporter and vendor to develop a fix.
4. Public Disclosure: The vulnerability is publicly announced, often with an associated identifier. This marks a critical pivot point from private to public knowledge.
5. Public Discovery: Stakeholders (e.g., product consumers) become aware of the vulnerability through public sources. This is another crucial pivot point for vulnerability management.
6. Prioritization: Organizations assess the severity, exploitability, and impact of the vulnerability to determine remediation order.
7. Local Instance Discovery: Identification of specific vulnerable instances within an organization's environment, considering local context (e.g., special configurations, platform specifics like ARM). The speakers noted this step is becoming increasingly critical for prioritization.
8. Remediation: The process of applying patches or mitigation strategies.
9. Communication/Coordination: For larger organizations, this involves tasking and communicating remediation efforts across different teams. This phase is often overlooked but critical in complex environments.
10. Monitoring: Ongoing vigilance to ensure remediation effectiveness and detect new related threats.
11. Reporting: Documenting the vulnerability management process and its outcomes.

While this timeline is idealized and real-world scenarios often deviate (e.g., an O-day exploit skipping directly from discovery to compromised instances), it provides a structured means to evaluate why certain information elements are needed at specific points in the process. For instance, an information element is deemed necessary if it facilitates tasks in a particular phase, such as identifying local instances in phase 6.

Stakeholder Roles

The initial exploration of stakeholder roles was highly detailed, but for the purpose of defining MVVE, Art and Jay simplified it to four core roles:

1. Producer: The entity creating the product (e.g., open-source developer, IoT manufacturer).
2. Consumer: The entity using the product, typically responsible for remediation.
3. Vulnerability Manager: An individual or team (internal or outsourced) assisting the consumer with vulnerability processes.
4. Coordinator: An entity facilitating communication and tasking, especially in large organizations.

This simplification helps focus on the essential information flow between the entities most directly involved in identifying and addressing vulnerabilities.

The Absolute MVVE: The "Big Reveal"

After laying this groundwork, the speakers presented their "big reveal" for the absolute minimum viable vulnerability enumeration. They boiled it down to just two indispensable elements:

1. Vulnerability ID: This is the "name the thing" component. It must be a unique and public identifier for the vulnerability itself. Examples include CVE IDs, OSV IDs, or even a GUID (though the latter is less human-friendly). Without this, the vulnerability cannot be referenced or tracked. As Art put it, "I have an ID for this thing."
2. Product Identifier: This addresses the "the what" component—what product is affected by the vulnerability. This term is used broadly and encompasses crucial details such as version numbers, build numbers, patch numbers, and even release dates. The specificity of this identifier is paramount; it must enable a consumer to definitively match the vulnerability to a specific instance of a product in their environment. As Jay emphasized, "we need to be able to look at this reference and be able to go to the thing in our environment and say yes these two match this thing is talking about this exact thing."

The rationale is clear: if you possess these two pieces of information, you have the foundational data to begin the vulnerability management process. You can search for the vulnerability ID, combine it with the product information, and start gathering further details, even if it's via a simple web search. Without these, no meaningful action can be taken.

MVVE++: Adequate Enumeration

While the MVVE defines the absolute minimum, the speakers acknowledged that this bare minimum can feel "empty" because it lacks information critical for efficient prioritization and action. They introduced the concept of MVVE++, or Adequate Enumeration, which adds one crucial element to the core MVVE:

• What to do about it: This refers to remediation information or actionable advice. While not strictly necessary to initiate the process (as one could theoretically Google for a fix), it is "required" for modern, efficient vulnerability management and prioritization. Knowing how to fix a vulnerability significantly accelerates the remediation phase.

Primary vs. Enriching Databases

A key distinction made was between primary and enriching databases. A primary database, like CVE.org, serves the vital role of providing the unique vulnerability identifier. Other databases and sources, such as EPSS, Nvidia's advisories, ADPs (Advisory Data Providers), or vendor websites, then enrich this core identifier with additional information like CVSS scores, exploitability details, and specific remediation instructions. This model suggests that a single vulnerability record (e.g., a CVE entry) does not need to be "everything to everybody" but rather serve as a universal anchor for a distributed ecosystem of vulnerability intelligence.

The discussion also touched upon the importance of data stewardship, with Jay highlighting that good data quality, architecture, and storing information once are crucial for the integrity and usability of vulnerability data, even for the minimal MVVE.

Demo / Proof of Concept

▶ Watch: MVVE Element 2: Information to initiate vulnerability management (5:20)

The talk focused on the theoretical and definitional aspects of Minimum Viable Vulnerability Enumeration. There was no live demonstration or proof of concept presented during the session. The speakers primarily used conceptual models, such as the word cloud and the vulnerability management timeline, to illustrate their points and frame their arguments.

Defensive Implications

▶ Watch: The 'minimum' test: removing elements breaks the record (6:40)

The concept of Minimum Viable Vulnerability Enumeration (MVVE) holds significant implications for defenders, offering a critical framework for streamlining and enhancing their security operations. By focusing on the absolute minimum information required, MVVE empowers defenders to cut through noise and establish a robust foundation for action.

Firstly, MVVE provides the essential starting point for vulnerability management. With just a unique Vulnerability ID (e.g., a CVE ID) and a precise Product Identifier (including crucial details like versions, build numbers, and patch levels), defenders can immediately determine if a known vulnerability affects a specific asset in their environment. This ability to perform local instance discovery is paramount; without it, no further defensive action can be taken. As the speakers emphasized, if you can't perform this step, "nothing else matters."

Secondly, MVVE facilitates efficient information gathering and prioritization. While MVVE itself doesn't include severity scores (like CVSS) or exploitability metrics (like EPSS), knowing the core MVVE elements allows defenders to leverage the vast ecosystem of enriching databases. A defender can take a CVE ID and affected product name, then use search engines or dedicated security intelligence platforms (like those from Nvidia or ADPs) to quickly pull in additional context, such as exploit details, impact assessments, and remediation advice. The MVVE++ concept, which adds "what to do about it," directly addresses the need for actionable remediation instructions, significantly accelerating the remediation phase.

Thirdly, for large and complex organizations, the MVVE framework aids in communication and coordination. When a vulnerability is clearly identified by its unique ID and specific affected product, it becomes easier to communicate remediation tasks across different teams and departments. This clarity reduces ambiguity, ensures that the right teams are tasked with the right fixes, and supports the "Communication/Coordination" phase outlined in the idealized vulnerability management timeline.

Finally, the underlying principles of MVVE, particularly the emphasis on parsimonious data representation and good data stewardship, encourage better data practices within defense teams. By understanding what information is truly essential and where it should reside (e.g., unique IDs from primary sources, enrichment from secondary sources), defenders can advocate for and build more efficient and reliable internal vulnerability databases and processes. This prevents the accumulation of redundant or low-value data, ensuring that resources are focused on actionable intelligence. In essence, MVVE provides the bedrock upon which all subsequent defensive actions are built, enabling defenders to move from discovery to remediation with greater precision and speed.

Key Takeaways

• The proliferation of vulnerability databases necessitates defining a Minimum Viable Vulnerability Enumeration (MVVE) to cut through information overload.
• The absolute MVVE consists of two indispensable elements: a unique and public Vulnerability ID (e.g., CVE ID) and a precise Product Identifier (including version, build, and patch numbers).
• These two elements are the bare minimum required to uniquely identify a vulnerability and initiate the vulnerability management process for a product consumer.
• While not strictly minimum, adding "what to do about it" (remediation advice) creates MVVE++ (Adequate Enumeration), which is crucial for efficient prioritization and action.
• The ecosystem of vulnerability information benefits from distinguishing between primary databases (providing unique IDs) and enriching databases (adding context, scores, and remediation details).
• An idealized vulnerability management lifecycle serves as a useful framework for evaluating the necessity and placement of information elements within the overall process.

About the Speaker(s)

The talk was delivered by Art and Jay, both of whom are deeply involved in the domain of vulnerability management and work extensively with CVE.org. Their collaborative discussions on the fundamental question of vulnerability record content led directly to the MVVE concept presented.

Art initiated the core question that sparked this research: "What information do we need in a vulnerability record to uniquely identify a vulnerability?" He is credited with creating the "slightly scientific and slightly artisally crafted" word cloud data visualization used in the presentation to illustrate the complexity of existing vulnerability data.

Jay is a key collaborator in this ongoing research. He highlighted his expertise in data visualization, distinguishing his complex data visualizations from Art's simpler creations. Jay also emphasized the critical importance of data stewardship, advocating for good data quality, architecture, and storing information once, reflecting his role as a significant consumer of vulnerability data.

Together, their shared experience and passion for defining the core elements of vulnerability records underscore the practical relevance and depth of their work on MVVE.