What's New in CSAF and OpenEoX

What's New in CSAF and OpenEoX

Speakers: Omar Santos (Cisco)

Conference: VulnCon

YouTube: https://www.youtube.com/watch?v=jf7TBdf9h-k

Overview

In this VulnCon session, Omar Santos from Cisco provided a comprehensive update on the advancements in two critical standards for cybersecurity: the Common Security Advisory Framework (CSAF) and the emerging Open End-of-Life Exchange (OpenEoX). Santos, a board member at Oasis Open and a co-leader for both standards, highlighted the ongoing evolution of CSAF towards its 2.1 iteration and introduced the nascent but vital efforts behind OpenEoX. The talk underscored a fundamental shift in vulnerability and product lifecycle management: moving beyond human-readable documents to fully machine-consumable data, essential for automation and integration into modern security operations.

The presentation emphasized the increasing need for standardized, machine-readable formats to exchange critical security information, particularly in the age of AI and complex software supply chains. Santos detailed the challenges of discoverability for security advisories and the complete lack of a standardized way to communicate product end-of-life (EOL) or end-of-support (EOS) information. He outlined how CSAF 2.1 addresses these gaps with significant schema enhancements, improved discoverability mechanisms, and broader support for various vulnerability metrics and product identifiers.

Crucially, the talk also shed light on OpenEoX, an initiative born out of the recognition that without machine-readable EOL/EOS data, organizations struggle to manage risk effectively, especially concerning open-source components and rapidly evolving AI models. By focusing on a common taxonomy and a lightweight schema, OpenEoX aims to provide the foundational data necessary for automated decision-making, ensuring transparency and international standardization in product lifecycle information. This combined effort represents a concerted push by the security community to enhance the speed, accuracy, and automation capabilities of vulnerability and product lifecycle management across the global ecosystem.

Background

▶ Watch: Welcome and overview of CSAF and OpenEoX updates (0:00)

The journey to modern, machine-readable security advisories began with the Common Vulnerability Reporting Framework (CVRF), a predecessor to CSAF. Initiated around 2012 under the Iicassi organization (which later merged with FIRST), CVRF aimed to standardize the exchange of vulnerability information. However, the initial ambition quickly evolved beyond simple human-to-human communication. The community recognized a pressing need to enable machines to exchange vulnerability data at "machine speed," a challenge that, as Santos noted, persists even in the age of AI.

The transition from CVRF to CSAF involved moving the standard under Oasis Open, a recognized standards organization, to address intellectual property (IPR) concerns and foster broader international collaboration. This move culminated in CSAF 2.0, which gained traction globally and is now an ISO standard, though its public release is still pending. A core problem CSAF sought to solve was not just the creation of a standardized JSON document, but the discoverability of these documents. A perfectly structured advisory is useless if it cannot be found and automatically ingested by consuming systems. This led to the development of mechanisms like provider metadata and the integration of standards like Rolley to ensure advisories are easily locatable.

The impetus for OpenEoX arose from a similar gap in standardization, identified during discussions at RSA. While significant progress has been made with Software Bill of Materials (SBOMs) and Vulnerability Exploitability Exchange (VEX), a glaring omission remained: a machine-readable standard for communicating end-of-life, end-of-sales, end-of-software-maintenance, or end-of-support dates. This lack of standardization extends even within large organizations like Cisco, where different business units (e.g., Splunk, Meraki, Enterprise Networking, Security BU) often maintain their own, disparate interpretations and data formats for product lifecycle information. The challenge is particularly acute for open-source components and emerging technologies like AI models, where consistent support structures are often non-existent. OpenEoX was thus launched under Oasis Open to address this critical need, starting with the fundamental task of defining a common taxonomy for product lifecycle stages.

Key Findings

▶ Watch: CSAF's evolution from CVRF and machine-speed goal (3:45)

The talk highlighted significant advancements and ongoing work in both CSAF and OpenEoX, aimed at improving automation, discoverability, and precision in security information exchange.

CSAF 2.1 Enhancements (currently in draft):

• Schema Evolution: CSAF 2.1 introduces crucial enhancements to the core schema, which includes profiles for various use cases such as VEX (Vulnerability Exploitability Exchange), generic security advisories, and even incident reporting.
• Enhanced Discoverability: A major focus is on making CSAF documents easier for machines to find. This involves a provider metadata standard, allowing vendors to publish a predictable URL (e.g., cisco.com/.well-known/csaf-provider-metadata.json) where consumers can discover their security advisories.
• TLP 2.1 Support: The standard is being modernized to fully support Traffic Light Protocol (TLP) version 2.1, ensuring alignment with current information sharing practices.
• Expanded Publisher Object: The publisher object now includes an expanded category enumeration, notably adding multiplier to account for entities involved in multiple roles (e.g., vendor, coordinator, discoverer, translator). This allows for more precise identification of the persona behind the advisory's creation.
• Improved Product Identifications: While CSAF does not aim to reinvent SBOMs, it enhances how vulnerabilities are linked to products. CSAF 2.1 will support PURL (Package URL), allowing for multiple PURL references in an array, which was a limitation in CSAF 2.0. This aids in more granular product identification.
• Plural CWEs: A significant improvement for vulnerability representation is the support for an array of CWEs (Common Weakness Enumerations). This addresses the common scenario where a single vulnerability or an advisory might be associated with multiple CWEs, providing more accurate classification.
• Detailed Date Fields: New fields for disclosure and discovery dates are being added, providing critical timeline information that was previously lacking in the standard.
• Flexible Metrics: The CVSS object has been renamed to metrics to accommodate other scoring methodologies beyond just CVSS. This includes support for SSVC (Stakeholder-Specific Vulnerability Categorization), enabling enterprises and coordination agencies to prioritize vulnerabilities based on a decision tree model.
• Remediation Enhancements: The remediation property and category enumeration are being refined to provide more detailed and actionable remediation guidance.
• Rolley Integration: CSAF is incorporating Rolley (RFC 8631), an Atom publishing feed standard, as a more robust and proper mechanism for announcing the location of security advisories, further boosting discoverability.
• Public PGP Key Enhancements: Improvements are being made to how public PGP keys are referenced, enhancing the integrity and authenticity verification of CSAF documents.

OpenEoX (Emerging Standard):

• Addressing EOL/EOS Gap: OpenEoX aims to create the first machine-readable standard for end-of-life, end-of-sales, and end-of-support information for products and components.
• Common Taxonomy First: The initial and crucial focus is on establishing a standardized taxonomy and common definitions for various end-of-life stages. This tackles the internal inconsistencies within organizations and across the industry.
• Lightweight Schema: The goal is a lightweight schema that can be used in isolation or incorporated into existing standards like SBOMs and CSAF, without reinventing the wheel.
• Automation and Transparency: OpenEoX is designed from the ground up for machine consumption, enabling automation in identifying unsupported components and enhancing transparency across the supply chain.
• International Standardization: The initiative seeks to establish an internationally recognized standard, crucial for global software supply chain security and managing open-source dependencies and AI models.

Technical Deep Dive

▶ Watch: Overview of upcoming CSAF 2.1 enhancements (5:20)

The technical underpinnings of CSAF 2.1 and the conceptual framework for OpenEoX represent a significant leap towards automated security information exchange.

CSAF 2.1 Schema Architecture:

The core of CSAF is its JSON schema, designed to represent a security advisory in a structured, machine-readable format. This schema is flexible, supporting different profiles tailored to specific use cases. The VEX profile, for instance, allows vendors to declare the exploitability status of a known vulnerability in their products (e.g., "affected," "not affected," "fixed," "under investigation"). Other profiles include generic security advisories and even incident reports that may not be direct vulnerabilities.

Discoverability with Provider Metadata and Rolley:

A critical technical challenge addressed by CSAF 2.1 is discoverability. The provider metadata standard leverages the .well-known URI scheme. A vendor like Cisco or Red Hat can host a JSON file at a predictable URL (e.g., https://cisco.com/.well-known/csaf-provider-metadata.json). This file acts as an index, pointing to the locations of their CSAF advisories, their PGP keys, and other relevant information. This standardized approach allows automated tools to find and ingest advisories without prior knowledge of a vendor's specific publishing practices.

Further enhancing discoverability is the integration of Rolley (RFC 8631). Rolley defines an Atom publishing feed for lightweight information exchange of security advisories. Instead of relying solely on directory listings, Rolley provides a more "proper" and structured mechanism for vendors to announce updates and new advisories, making it easier for automated systems to subscribe and receive real-time notifications.

Publisher Object and Persona Identification:

The publisher object in CSAF 2.1 is enhanced to capture more nuanced information about the entity issuing the advisory. The category enumeration now supports values like vendor, coordinator (like CISA or BSI), discoverer (e.g., a security researcher), translator, and other. The introduction of multiplier allows a single publisher to be associated with multiple categories, accurately reflecting complex scenarios where an entity might play several roles in the vulnerability disclosure process. This level of detail is crucial for trust and context in automated processing.

Product Identification with PURL and Weakness Representation with CWEs:

To precisely link vulnerabilities to affected products, CSAF 2.1 is improving its product identification capabilities. While CSAF is not an SBOM, it can reference them. More directly, CSAF 2.1 adds robust support for PURL (Package URL). Unlike CSAF 2.0, which only supported a singular PURL, the new version allows for an array of PURLs, enabling more comprehensive and accurate identification of affected software components.

For describing the nature of vulnerabilities, CSAF 2.1 addresses a long-standing limitation by allowing for plural CWEs. Previously, an advisory or a vulnerability entry might be restricted to a single CWE. Now, an array of CWEs can be associated with a vulnerability, reflecting the reality that complex flaws often map to multiple weakness categories.

Vulnerability Metrics and Prioritization:

The renaming of CVSS to metrics in CSAF 2.1 signifies a broader approach to vulnerability scoring and prioritization. Beyond CVSS (Common Vulnerability Scoring System), the standard now formally supports SSVC (Stakeholder-Specific Vulnerability Categorization). SSVC provides a decision-tree model that helps organizations prioritize vulnerability response based on their specific operational context and risk tolerance. This allows automated systems to consume not just a raw score but also a decision path, enabling more intelligent and context-aware vulnerability management.

OpenEoX Conceptual Schema and Taxonomy:

OpenEoX's technical approach begins with establishing a common taxonomy. This is foundational, as inconsistent definitions of "end-of-life" or "end-of-support" hinder any machine-readable standard. The working group is meticulously defining terms such as end of sales, end of software maintenance, end of support, and other relevant lifecycle stages.

Once the taxonomy is solid, OpenEoX aims for a lightweight schema. This schema will define the minimum required information for communicating product lifecycle status, such as product identifier (e.g., PURL, CPE), the lifecycle event (e.g., EOS), and the associated date. The design philosophy is to make this schema easily embeddable or referenceable within existing standards like SBOMs and CSAF, rather than creating yet another siloed data format. The ultimate goal is to enable automated systems to query and consume EOL/EOS data, allowing for proactive risk management of unsupported software components, especially in dynamic environments involving open-source dependencies and AI models.

Demo / Proof of Concept

▶ Watch: CSAF schema enhancements and document discovery via well-known (5:55)

The talk by Omar Santos at VulnCon was primarily a technical update and strategic overview of the CSAF and OpenEoX standards, rather than a live demonstration of tools or a proof of concept. While the speaker mentioned the concept of a "show and tell" at the beginning, the session focused on detailing the ongoing developments, schema enhancements, and the collaborative process behind these standards. No specific software demonstration or exploit was presented during the session.

Defensive Implications

▶ Watch: CSAF 2.1 adds TLP 2.0 and expanded publisher object (7:50)

The advancements in CSAF 2.1 and the emergence of OpenEoX carry profound defensive implications, empowering organizations to build more resilient and automated security programs.

For CSAF 2.1:

• Automated Vulnerability Management: Defenders can automate the ingestion and parsing of security advisories, significantly reducing the manual effort involved in tracking vulnerabilities. This allows for faster identification of affected products and quicker response times.
• Improved Prioritization: With native support for SSVC, security teams can move beyond generic CVSS scores to prioritize vulnerabilities based on their organization's specific context, asset criticality, and operational impact. This enables more efficient allocation of resources to address the most pressing threats.
• Enhanced Asset Inventory Mapping: The expanded support for PURL and other product identifiers allows for more accurate and automated mapping of advisories to specific components within an organization's asset inventory, including open-source libraries and commercial software.
• Proactive Discoverability: The standardized provider metadata and Rolley integration mean that defenders can set up automated feeds to discover new advisories from vendors, rather than manually checking websites or mailing lists. This ensures they receive critical information as soon as it's published.
• Granular Vulnerability Tracking: The ability to include multiple CWEs provides a more precise understanding of the underlying weakness types, aiding in root cause analysis and the development of more effective long-term mitigations. The new disclosure and discovery date fields offer crucial forensic and timeline data.
• VEX Integration: Leveraging CSAF's VEX profile allows defenders to quickly ascertain whether a known vulnerability actually affects their specific deployment of a product, reducing alert fatigue and focusing efforts on truly exploitable issues.

For OpenEoX:

• Automated End-of-Life Management: OpenEoX will enable automated identification of software and hardware components that are approaching or have reached their end-of-life or end-of-support dates. This is critical for managing technical debt and ensuring compliance.
• Proactive Risk Mitigation: By integrating machine-readable EOL/EOS data into security tools, defenders can proactively flag and plan for the replacement or upgrade of unsupported components, which often become unpatched attack vectors.
• Supply Chain Security: OpenEoX offers a standardized way to assess the lifecycle status of third-party dependencies, including open-source libraries and AI models, within the software supply chain. This helps in making informed decisions about component adoption and managing associated risks.
• Policy Enforcement: Organizations can integrate OpenEoX data into their CI/CD pipelines or asset management systems to enforce policies that prevent the deployment or continued use of unsupported software, thereby reducing the attack surface.
• Compliance and Auditing: Standardized EOL/EOS data will simplify compliance reporting and auditing processes, providing clear, machine-attestable evidence of product lifecycle management.

Together, CSAF 2.1 and OpenEoX provide a powerful framework for moving security operations from reactive, manual processes to proactive, automated, and intelligence-driven defense.

Key Takeaways

• CSAF 2.1 is Advancing Automation and Discoverability: The Common Security Advisory Framework is undergoing significant enhancements in its 2.1 iteration, focusing on improving machine-readability, automating vulnerability advisory ingestion, and standardizing discoverability through mechanisms like provider metadata and Rolley.
• OpenEoX Addresses a Critical Gap in Lifecycle Management: The Open End-of-Life Exchange is a new initiative aimed at creating the first machine-readable standard for end-of-life and end-of-support information, crucial for managing risks associated with unsupported software components, open-source dependencies, and AI models.
• Interoperability and Common Taxonomies are Paramount: Both standards emphasize the importance of consistent definitions and interoperability with other supply chain security standards like SBOMs and VEX to ensure a holistic, automated approach to security.
• Enhanced Precision for Defenders: CSAF 2.1 introduces features like support for multiple CWEs, detailed disclosure/discovery dates, PURL for product identification, and SSVC for context-aware prioritization, providing defenders with more precise and actionable vulnerability intelligence.
• Community Contribution is Essential for Adoption: The success and widespread adoption of CSAF and OpenEoX rely heavily on community involvement from vendors, consumers, and security researchers to provide feedback, develop tools, and integrate the standards into their processes.
• Driving a Shift to Machine-Consumable Security Data: The overarching goal of both CSAF and OpenEoX is to transition from human-centric security documents to fully machine-consumable data, enabling faster, more accurate, and more automated security responses across the entire ecosystem.

About the Speaker(s)

Omar Santos is a distinguished engineer at Cisco, where he is a key member of the Security and Trust organization. In this role, he oversees critical technical responsibilities, focusing on how to secure Cisco's internal infrastructure and its vast product portfolio, as well as assisting customers in protecting their environments. Beyond his work at Cisco, Omar is a highly influential figure in the cybersecurity standards community. He serves on the board of Oasis Open, a prominent standards organization, where he co-leads the development efforts for both CSAF and OpenEoX. Furthermore, he holds the esteemed position of co-chair for the Coalition for Secure AI, working alongside industry leaders from Anthropic, OpenAI, and Nvidia to guide the industry on securing emerging AI technologies. Omar has a long-standing history and extensive expertise in vulnerability disclosure.

While not present at the talk due to a family emergency, Justin from CISA was acknowledged by Omar Santos as an "amazing contributor" to the community. Justin plays a significant role in the development of both CSAF and OpenEoX, as well as contributing to the broader SBOM ecosystem and the Vulnerability Exploitability Exchange (VEX).

Omar Santos also highlighted the critical contributions of Thomas Schaefer from BSI (Germany). Santos credited Schaefer, stating that "if it wasn't for this guy, probably even CSAF would not exist right now." Schaefer is recognized for his invaluable work on the technical aspects of the standards and for creating a "plethora" of open-source tools that support their implementation and adoption.