Three Musketeers: CVE, CSAF, and VEX

Three Musketeers: CVE, CSAF, and VEX

Speakers: Eoin Wilson-Manion (Tharros Labs); Tyler Zellers (Tharros Labs); Jonathan Spring (CISA)

Conference: VulnCon

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

Overview

This talk, "Three Musketeers: CVE, CSAF, and VEX," delivered by Eoin Wilson-Manion and Tyler Zellers from Tharros Labs, alongside Jonathan Spring from CISA, delves into the critical role of interoperable data standards in modern vulnerability management and disclosure. The presentation illuminates CISA's strategic approach to leveraging CVE (Common Vulnerabilities and Exposures), CSAF (Common Security Advisory Framework), and VEX (Vulnerability Exploitability eXchange) to generate high-quality, machine-readable, and actionable vulnerability information. It underscores the necessity of robust tooling and standardized formats to address the complexities of national-level risk management.

The speakers articulate how CISA, in its mission to lead national efforts in managing risks to cyber and physical infrastructure, relies on these "three musketeers" to ensure software security by design. Acknowledging that no software is perfect, the talk emphasizes the importance of efficient vulnerability disclosure policies (VDPs) and the rapid distribution of fixes. By detailing their practical implementation challenges and custom solutions, the team demonstrates how these standards facilitate the collection, analysis, coordination, and application of mitigations, ultimately enhancing public safety by protecting critical infrastructure from evolving cyber threats.

The core message revolves around the transition from fragmented, manual processes to an integrated, automated workflow for vulnerability information. This shift is vital for fostering semantic agreement across the cybersecurity ecosystem, enabling organizations to make informed, timely decisions about patching and risk mitigation. The discussion highlights CISA's commitment to setting a high standard for vulnerability information quality, serving as a reliable provider and an example for the broader community.

Background

▶ Watch: CISA's mission and Secure by Design context (0:00)

CISA's overarching mission is to lead the national effort to manage risks to the cyber and physical infrastructure that Americans rely on. This broad mandate translates directly into a critical need for effective cybersecurity practices, particularly concerning software vulnerabilities. A fundamental principle CISA advocates is secure by design, which inherently includes a robust vulnerability disclosure policy (VDP). As Jonathan Spring notes, "providing good information about your CVEs is part of secure by design," acknowledging that perfection in software is unattainable and that continuous identification and remediation of vulnerabilities are essential.

This emphasis on VDPs is not merely a recommendation; for federal agencies, it's a directive outlined in Binding Operational Directive (BOD) 20-01. The talk highlights that if a federal agency has a CVE within a year of signing a secure by design pledge, they are expected to provide comprehensive information. This commitment is part of a broader move towards a "quality era" in vulnerability management, requiring federated efforts and, crucially, interoperable data standards to achieve semantic agreement across diverse stakeholders.

The practical challenges CISA faces in executing this mission are significant. Owen Wilson-Manion and Tyler Zellers detail the array of questions that arise during public disclosure: What information is truly needed (ID, problem type, CWE, metrics)? What can be obtained from the initial vulnerability report or the vendor, and what requires internal investigation? Furthermore, the formats in which this information is typically received are often unstructured—ranging from plain text to large PDFs—making efficient processing and automation difficult. Historically, CISA's operations involved a fragmented toolchain, utilizing Vulnogram for CVE JSON generation, Sec Vizigram for CSAF JSON validation, and even basic text editors like Notepad, Nano, or Vim. This ad-hoc approach often led to inefficiencies, loss of detail, and inconsistent data quality, making the integration of disparate formats a primary objective. The need for a standardized, machine-readable, and scalable solution became paramount to support CISA's national mission.

Key Findings

▶ Watch: Requirements for a quality vulnerability record (10:00)

The central finding of the talk is CISA's successful development and implementation of a custom platform that harmonizes the previously fragmented processes for generating CVE and CSAF records, incorporating VEX statements. This bespoke solution addresses the critical need for a unified, automated, and scalable approach to vulnerability disclosure, moving beyond disparate tools and manual efforts.

A key strategic decision was to standardize on CVE and CSAF. As a CNA (CVE Numbering Authority) under the CISA CG (Civilian Government) umbrella, CISA publishes CVEs and utilizes CSAF to fulfill the public reference requirement for CVE records, specifically citing CNA rules 5.3.1. This ensures that every CVE has an accessible, machine-readable public reference, even when no external vendor advisory exists. The custom platform acts as the bridge, integrating the various data points required by both standards.

The team identified and codified specific requirements for a "quality record": completeness (filling every field, even if with "not enough info"), accuracy, consistency, and actionability. This includes standardizing the inclusion of title, description, problem type, and references. Crucially, CISA now performs three different versions of vulnerability scoring for each record: CVSS 3.1, CVSS 4.0, and SSVC 2.0. The talk also emphasizes the paramount importance of status information within records, as it provides clear, actionable guidance on affected and fixed products.

Furthermore, the custom platform explicitly supports the generation of VEX statements using the CSAF VEX profile. This profile is valued for its explicit product statuses such as "fixed," "known affected," "known not affected," and "under investigation," along with an impact statement for "known not affected" statuses. This detailed status information, combined with explicit statements of fixed versions in CVE descriptions, represents a significant advancement in providing granular, actionable intelligence to downstream consumers. While SSVC 2.0 is not yet fully supported in CSAF 2.0, CISA has implemented a workaround by embedding the SSVC string as a vulnerability note, demonstrating their commitment to incorporating emerging standards despite current limitations.

Technical Deep Dive

▶ Watch: The "naming problem" in product and versioning (14:00)

CISA's approach to vulnerability disclosure is deeply rooted in the technical integration and harmonization of key industry standards: CVE, CSAF, and VEX. As a CNA, specifically CISA CG, the agency is responsible for publishing CVEs. The talk highlights that CSAF plays a crucial role in this process by fulfilling the public reference requirement for CVE records, as mandated by CNA rules 5.3.1. When a public reference doesn't exist, CISA generates a CSAF document, makes it publicly available, and links the CVE record to it. This ensures machine-readability and a well-defined, evolving standard for vulnerability information.

To overcome the limitations of fragmented tools like Vulnogram (for CVE JSON), Sec Vizigram (for CSAF JSON validation), and manual editing, CISA developed a custom platform. This internal tool is designed to integrate the various formats, ensuring a unified, efficient, automatable, and scalable process. The goal is to produce information that is both human-readable and machine-readable, and reliably of high quality.

Record Requirements and Status:

For every vulnerability record, CISA adheres to strict requirements to ensure quality. Records must be complete, with every field filled, even if it's "not enough info" to signal that the field was considered. Essential fields include title, description, problem type (preferably CWE), and references. The most critical component is status, which provides actionable information about what products and versions are affected or fixed.

VEX Statements and Mapping:

CISA leverages the CSAF VEX profile to generate explicit VEX statements. This profile is preferred because it includes explicit product statuses: "fixed," "known affected," "known not affected," and "under investigation." It also allows for an impact statement for "known not affected" statuses.

A significant technical challenge is mapping the status fields between CVE and CSAF:

• CVE statuses: affected, unknown, unaffected.
• CSAF statuses: fixed, known affected, known not affected, under investigation.

CISA's mapping strategy assigns "fixed" to CVE's "unaffected" field, and "known not affected" (if confirmed) also to "unaffected." "Affected" and "unknown" map directly to their CSAF counterparts. Crucially, CISA explicitly states the "fixed version" in both the CVE record and the CSAF document, providing clear guidance beyond just an affected range. For CSAF, this is managed via a product tree and VERS (Vulnerability Exploitability Rating System) or VERS-like VLS, populating CSAF PIDs for each status.

Product Naming and Versioning:

The talk highlights the "intractable problem" of product naming and versioning across the software industry (illustrated by a candy bar analogy). Variations include semantic versioning, custom schemes, versionless indicators (e.g., dates), and unique identifiers. CISA's custom solution automatically maps these diverse versioning conventions into both CSAF and CVE schemas, a necessity given the complexity.

CVE Description Writing:

To ensure consistency and completeness, CISA uses a "Mad Lib" template for CVE descriptions. This structured approach includes:

1. Vendor's name
2. Product
3. Affected versions or range
4. Attack vector and required privileges
5. Impact of the vulnerability
6. Explicit fixed versions

Vulnerability Scoring:

CISA employs three scoring methodologies:

1. CVSS 3.1: Widely used and compatible with current CVE and CSAF 2.0. The tool ensures it's outputted to both formats.
2. CVSS 4.0: Features additions and evolutions. While compatible with the current CVE schema, it is not compatible with the current CSAF 2.0 schema. CISA's custom platform automatically handles this, preventing CVSS 4.0 from being outputted in CSAF 2.0 documents, thus avoiding validation errors. This will be resolved with CSAF 2.1.
3. SSVC 2.0 (Stakeholder Specific Vulnerability Categorization): CISA uses its "coordinator decision tree" with five decision points: exploitation, automatable, technical impact, mission prevalence, and public well-being impact. For the CVE record, only the first three (exploitation, automatable, technical impact) are outputted, allowing downstream consumers to apply their own context for the last two stakeholder-specific points. SSVC is currently not supported in CSAF 2.0 but will be in 2.1. As a workaround, CISA embeds the SSVC string as a vulnerability note in the CSAF document. While it doesn't render on cve.org, it is present in the CVE JSON file and renders on the CISA ADP (Advisory Development Platform) on cve.org.

Problem Type and References:

The "problem type" field is required, with CWE being the recommended standard. CISA prefers base or variant CWEs over pillar or class types. If a specific CWE cannot be determined, "CWE no info" is used. For references, every CVE requires a public reference, and CSAF requires a self-reference. CISA addresses this by having the CVE and CSAF documents reference each other. If no vendor advisory or researcher publication is available, CISA's CSAF advisory serves as the public reference.

Publication Process:

CISA operates as a CSAF Trusted Provider, which entails meeting stringent requirements:

• Publisher Requirements: Valid JSON, proper file naming, hosted on a website with TLS, and freely accessible (for TLP:WHITE disclosures).
• Provider Requirements: Updating a ROLIE feed, maintaining a changes file, hosting provider metadata on the CISA website.
• Trusted Provider Requirements: Adding a digital signature, a hash file, and a public OpenPGP key.

This entire process is automated via a shell script. Once a CSAF draft is complete, the script executes git commands, sending a pull request to GitHub. Upon acceptance, the CSAF document, its signature, and hash file are published, and the ROLIE feed and changes file are updated. The speakers acknowledge a "race condition" where the CVE is published first, and the link to the CSAF on GitHub is temporarily broken until the pull request is merged, a known challenge in the current workflow. The internal tool also supports CVE services for publishing, syncing, and editing CVEs.

Demo / Proof of Concept

▶ Watch: Data quality vs. format compliance challenge (28:00)

While the talk did not feature a live, interactive demo of a specific tool, the speakers extensively described their custom, internal platform as their proof of concept and operational solution. This platform is CISA's answer to the challenges of integrating and automating CVE, CSAF, and VEX processes. It is an "evolving" system that harmonizes formats, automatically maps data fields, generates structured descriptions, and manages the intricate publication workflow. The shell script used for pushing CSAF documents to GitHub, generating signatures and hashes, and updating ROLIE feeds, serves as a tangible example of the automation achieved by this internal tooling. The discussion of its capabilities, such as handling CVSS 4.0 incompatibility with CSAF 2.0 and embedding SSVC as a note, effectively illustrates its function and success in real-world application.

Defensive Implications

▶ Watch: Q&A: Why two vulnerability formats (CVE, CSAF)? (40:00)

The detailed insights into CISA's vulnerability disclosure processes carry significant implications for defenders. The emphasis on high-quality, consistent, and actionable vulnerability information directly empowers defensive operations.

Firstly, the strategic use of CSAF VEX profiles is a game-changer. By providing explicit product statuses ("fixed," "known affected," "known not affected," "under investigation"), CISA delivers precise intelligence that defenders can immediately act upon. This clarity helps prioritize patching efforts, avoid unnecessary remediation for unaffected systems, and track the status of investigations. This granular information is invaluable for efficient asset management and vulnerability management programs, allowing organizations to rapidly assess their exposure and allocate resources effectively.

Secondly, the adoption of SSVC 2.0 provides defenders with a more tailored risk assessment framework. By distinguishing between universal technical impact and stakeholder-specific factors like "mission prevalence" and "public well-being impact," CISA enables organizations to contextualize vulnerabilities within their unique operational environment. Defenders can leverage their own SSVC decision trees or use CISA's top three decision points (exploitation, automatable, technical impact) as a foundation, adding their internal assessments for a more relevant prioritization of threats.

Thirdly, the commitment to machine-readable formats (CVE JSON, CSAF JSON) facilitates automation in defensive tools and workflows. Security teams can ingest these structured data feeds directly into their vulnerability scanners, security information and event management (SIEM) systems, and orchestration platforms to automate vulnerability tracking, alert generation, and patch deployment. This reduces manual effort and accelerates response times.

However, defenders must also be aware of the inherent complexities highlighted by the speakers: the "intractable problem" of product naming and versioning, and the ongoing challenges of semantic mapping between different standards. This means that while automation is key, human intelligence and contextual understanding remain crucial. Defenders need to invest in tools that can parse and normalize diverse versioning schemes and should not solely rely on automated feeds without careful validation. Finally, the acknowledgment that "formats alone do not solve data quality problems" underscores the continued need for vigilance, critical thinking, and robust internal processes for coordinating and validating vulnerability information, even when consuming highly structured data.

Key Takeaways

• Interoperable Standards are Essential: The integration of CVE, CSAF, and VEX is critical for efficient, national-level vulnerability management, ensuring semantic agreement and actionable information across diverse stakeholders.
• Custom Automation is Key: CISA developed a custom platform to overcome fragmented tooling, automating the generation of high-quality, machine-readable CVE and CSAF records, thereby increasing efficiency and scalability.
• Actionable Status Information: Leveraging the CSAF VEX profile provides explicit statuses (fixed, known affected, known not affected) and fixed version details, which are paramount for defenders to prioritize and apply mitigations effectively.
• Comprehensive Scoring and Contextualization: CISA employs CVSS 3.1, CVSS 4.0, and SSVC 2.0 to provide diverse risk perspectives, with SSVC specifically allowing stakeholders to tailor vulnerability impact based on their mission.
• Challenges in Standardization and Data Quality: Significant hurdles remain in resolving inconsistent product naming/versioning, semantic mapping between evolving standards, and coordinating cross-organizational changes, emphasizing that formats alone cannot solve underlying data quality issues.
• CISA as a Trusted Provider: CISA's adherence to stringent CSAF Trusted Provider requirements (including signatures, hashes, and ROLIE feeds) sets a high bar for public vulnerability disclosure, aiming to be a reliable example for the cybersecurity community.

About the Speaker(s)

Jonathan Spring (CISA) represents the overarching mission and strategic vision of CISA, articulating the agency's role in leading national efforts to manage risks to cyber and physical infrastructure. His contributions provide the broader context for why standardized vulnerability disclosure is critical for national security and the secure by design initiative.

Eoin Wilson-Manion (Tharros Labs) and Tyler Zellers (Tharros Labs) are on the front lines of public disclosure, supporting CISA's efforts to implement these standards. They delve into the practical challenges and technical solutions involved in generating high-quality vulnerability records. Tyler, in particular, details the specific requirements for a quality record, the methodology for writing CVE descriptions, and the nuances of vulnerability scoring and mapping between different formats. Their insights provide a practitioner's perspective on the daily work of harmonizing complex vulnerability data.