With VEX, The Possibilities are (Almost) Limitless!

With VEX, The Possibilities are (Almost) Limitless!

Speakers: Vincent Dan, Vice President of Red Hat Product Security

Conference: VulnCon

YouTube: https://www.youtube.com/watch?v=QGC-SpuSRWg

Overview

In this insightful talk at VulnCon, Vincent Dan, Vice President of Red Hat Product Security, delved into the transformative potential of Vulnerability Exploitability eXchange (VEX) documents. Dan presented VEX not merely as an incremental improvement but as a fundamental shift in how organizations can accurately assess and manage software vulnerabilities. His presentation highlighted Red Hat's journey in adopting VEX, moving from legacy formats like OVAL (Open Vulnerability and Assessment Language), and critically, the absence of readily available tooling for end-users to leverage VEX data. This gap prompted Dan to develop his own open-source tools, demonstrating the expansive capabilities of VEX beyond simple vulnerability declarations.

The core problem VEX aims to solve, as articulated by Dan, is the pervasive inaccuracy in current vulnerability scanning methodologies, which frequently produce both false positives and, more dangerously, false negatives. VEX offers a precise, vendor-provided statement on whether a product is affected by a specific vulnerability under particular conditions, thereby offering a more reliable source of truth than scanner heuristics. This talk is significant because it not only champions the adoption of VEX but also provides concrete, open-source examples of how VEX data can be consumed, processed, and integrated with other security intelligence sources to create robust, real-time vulnerability management solutions.

Dan's personal initiative to build practical VEX tooling underscores a broader industry challenge: the need for accessible, user-friendly mechanisms to harness new security data formats. By showcasing how VEX can power dynamic CVE pages, feed into AI-driven analytics, and enable disconnected vulnerability assessment, the talk positions VEX as a cornerstone for future-proof vulnerability management strategies. It serves as a compelling call to action for both software vendors to publish comprehensive VEX documents and for scanning vendors to integrate this richer, more accurate information into their products.

Background

▶ Watch: Red Hat's VEX adoption timeline (2023-2024) (1:00)

The landscape of vulnerability management has long been plagued by ambiguity and inefficiency, primarily stemming from the reliance on generic vulnerability databases and heuristic-based scanning tools. Vincent Dan highlighted a critical issue: despite the proliferation of vulnerability scanners, many still produce an overwhelming number of false positives and, more concerningly, false negatives. He illustrated this with an example of an up-to-date Red Hat Enterprise Linux 9.5 virtual machine, which, despite having no known critical or important vulnerabilities, was reported by a scanner to have over 600 "important findings." This lack of accuracy leads to wasted resources, alert fatigue, and a diminished ability for organizations to prioritize actual risks.

Red Hat has a long-standing commitment to transparency in vulnerability management, maintaining a public CVE database for over 25 years. This database evolved from static pages to dynamic, comprehensive portals offering detailed information on CVEs, their impact, associated AATA (Asynchronous and Atomic Transaction Architecture) fixes, affected packages, fix status, CVSS (Common Vulnerability Scoring System) scores, CWE (Common Weakness Enumeration) information, statements, and mitigations. Crucially, these pages have always been publicly available, reflecting Red Hat's philosophy of empowering customers with maximum information for risk mitigation. However, a persistent challenge for customers has been accessing this critical CVE information in disconnected environments.

For years, Red Hat produced OVAL documents, a standard for expressing technical details about security configuration and vulnerability states. While OVAL served its purpose, it had limitations. The idea of VEX as a replacement for OVAL was initially met with skepticism within Red Hat but eventually gained traction. Red Hat began publishing VEX documents for testing in 2023 and as primary security documents in 2024. The fundamental difference is that VEX provides explicit statements about the applicability of a vulnerability to a specific product, directly addressing the false positive/negative problem by offering a definitive answer from the vendor. This shift necessitated new tooling, as Red Hat's existing Open Scap tools, which read OVAL, did not support VEX. Dan's personal project was born from this void, driven by the realization that producing VEX documents without providing customers with the means to consume them would be akin to providing SBOMs (Software Bill of Materials) without guidance—a valuable data format left unused.

Key Findings

▶ Watch: Scanner inaccuracy example: 600+ false important findings (2:25)

The talk unveiled several key findings and contributions that underscore the versatility and importance of VEX documents in modern vulnerability management:

1. VEX as a Solution for Disconnected Vulnerability Information: A primary finding was VEX's capability to provide a complete, vendor-authored representation of CVE information that can be consumed in disconnected environments. This directly addresses a long-standing customer request for Red Hat's comprehensive CVE data to be available offline, enabling more robust risk assessment without constant internet connectivity.

1. Reproducing Comprehensive CVE Pages with Lightweight Tooling: Dan successfully demonstrated that Red Hat's rich, dynamic CVE portal pages, which typically rely on complex backend systems and databases, could be reproduced using only VEX documents as input, augmented by external APIs. This illustrated that vendors could create their own comprehensive CVE pages with a remarkably lightweight web application, decoupling them from monolithic customer portals and enabling rapid updates and feature improvements.

1. VEX Data for AI/ML-Driven Security Insights: A significant finding was the potential of VEX data to fuel Artificial Intelligence and Machine Learning initiatives. A Red Hat team member successfully used AI to generate code that parses VEX documents and transforms them into a Hugging Face dataset. This enabled AI systems to gain insights into vulnerability trends (e.g., most common CWEs, most affected components) and potentially assist security analysts in assigning severity ratings and CVSS scores more consistently. This highlights VEX as a structured, machine-readable format ideal for advanced analytics.

1. Querying VEX Data Like a SQL Database: For those preferring traditional data analysis, Dan introduced the use of DuckDB to query a VEX-derived Hugging Face dataset as if it were a SQL database. This finding offers a familiar and powerful way for analysts to mine VEX data for specific information without the need to manually import all VEX documents into a separate database, making complex queries accessible.

1. Challenges in VEX Interoperability and Consistency: Through attempts to parse VEX documents from other vendors (SUSE, Cisco), Dan uncovered critical differences in implementation, even within the CESAF VEX format. This included variations in how ISO dates were represented, leading to a Python 3.9 bug, and disparities in the richness and quantity of information provided. This finding highlights a potential hurdle for broad VEX adoption: the need for greater consistency and standardization across vendor implementations to ensure seamless consumption by scanning vendors and other tools.

1. The Complementary Role of VEX and SBOMs: The Q&A session brought forth a key finding regarding the relationship between VEX and SBOMs. While an SBOM identifies the components within a software product, VEX provides the crucial context of whether those components are actually vulnerable to specific CVEs in that product's configuration. Dan argued that for vulnerability management, VEX could potentially negate the direct need for SBOMs if a running program could provide its own VEX. However, he also emphasized that the two are highly complementary, with SBOMs detailing what you have and VEX clarifying what is vulnerable, offering a more complete picture when combined.

Technical Deep Dive

▶ Watch: Realizing Red Hat lacked VEX tooling for end-users (3:00)

The technical foundation of Vincent Dan's exploration into VEX capabilities rests on his open-source Python library, VEX reader, and a lightweight web application built upon it.

The VEX Reader Python Library

Facing a lack of Red Hat-provided tools to consume their new VEX documents, Dan initiated the development of VEX reader in July 2023. This Python module, made available on PyPI, is designed to parse CESAF VEX documents, particularly those generated by Red Hat. While initially a proof of concept, its goal was to illustrate VEX's utility to a broader audience.

The library's core function is to take a VEX document, which is essentially a JSON file, and extract its structured information. Dan's initial objective was to present this data in an organized, human-readable format on the command line. This involved parsing fields related to CVEs, product status (affected, not affected, fixed, vulnerable_fix_not_planned, under_investigation), and associated details. A crucial caveat noted by Dan is that VEX reader currently works best with Red Hat's CESAF VEX implementations and has not yet been thoroughly tested with OpenVEX documents or all variations of other vendors' CESAF VEX files.

The Flask Web Application

Building on VEX reader, Dan developed a Python Flask web application to achieve his challenge of reproducing Red Hat's comprehensive CVE pages using only VEX as input. This application is a testament to the power of VEX as a standalone data source for vulnerability information.

The Flask application operates without a traditional backend database. Instead, it dynamically pulls VEX documents directly from Red Hat's website. To enrich the vulnerability information beyond what Red Hat initially included in its VEX data, the application integrates with several external APIs:

• NVD (National Vulnerability Database): To retrieve additional generic CVE details.
• cv.org: To collect ADP CVSS (Attacker Driven Predicate Common Vulnerability Scoring System) scores, offering an alternative or supplementary risk metric.
• FIRST (Forum of Incident Response and Security Teams): To pull EPSS (Exploit Prediction Scoring System) data, providing insights into the likelihood of a vulnerability being exploited in the wild.

This architecture allows the application to present a comprehensive, almost real-time (due to a 1-hour cache) view of CVEs, mirroring the richness of Red Hat's official customer portal pages. The application runs on Python Anywhere, demonstrating a lightweight, scalable deployment model for VEX-powered information portals.

AI Integration with Hugging Face and DuckDB

Further showcasing VEX's versatility, a member of Dan's team leveraged AI to extend the utility of the VEX reader library. AI was used to generate code capable of parsing VEX documents and transforming their content into a Hugging Face dataset. Hugging Face is a platform for machine learning models and datasets, making the VEX data easily consumable by AI systems.

This dataset enables various advanced analytics:

• Vulnerability Insights: AI can query the dataset to identify trends, such as the most frequently occurring CWEs over time, or which components are associated with the most CVEs.
• Automated Severity Assignment: The data can potentially aid security analysts in more quickly and consistently assigning severity ratings and CVSS scores by learning from previous assignments, vulnerability descriptions, and component types.
• Data Discrepancy Detection: The AI-driven analysis of the VEX dataset has already helped identify discrepancies in Red Hat's vulnerability data, allowing for improvements in accuracy.

For those preferring traditional data querying, Dan also explored DuckDB, an in-process SQL OLAP database designed for analytical queries. DuckDB allows users to download the Hugging Face VEX dataset and query it directly using familiar SQL syntax. This eliminates the need for manual ETL (Extract, Transform, Load) processes to import VEX data into a separate relational database, providing a powerful and accessible method for data mining.

Interoperability Challenges

Dan's experience with VEX from other vendors highlighted crucial interoperability challenges. When attempting to load SUSE's VEX files with VEX reader, he encountered differences in how ISO date strings were represented. This specific issue exposed a bug in Python 3.9's handling of ISO format date strings, causing a crash. While a pull request eventually fixed this, it underscored the potential for subtle variations in VEX implementations to break tooling.

He also observed that while Cisco's VEX files were readable, they often contained less information than Red Hat's, suggesting varying levels of data granularity and transparency among vendors. These differences, even within the CESAF VEX standard, point to a need for greater consistency or more robust, adaptable parsing tools if VEX is to achieve widespread, seamless adoption across the industry. The existence of OpenVEX as an alternative to CESAF VEX further complicates the landscape, emphasizing the need for common ground or universal parsers.

Demo / Proof of Concept

▶ Watch: Introducing the open-source VEX reader Python library (6:50)

Vincent Dan’s presentation effectively served as a demonstration of the practical application and immense potential of VEX through his personal projects. The core proof of concept revolved around his open-source VEX reader Python library and the Python Flask web application built on top of it.

1. The VEX Reader Library:

Dan first demonstrated the foundational capability of the VEX reader library. His initial goal was to parse a VEX document and present its contents in an organized, readable format on the command line. This proof of concept showed that the library could successfully ingest CESAF VEX (specifically Red Hat's implementation) and extract key details about vulnerabilities, affected components, and their status (e.g., "not affected," "fixed," "vulnerable_fix_not_planned"). While the command-line output was acknowledged as dense, it validated the ability to programmatically access and structure the rich information within VEX files, serving as the essential building block for further applications. This library, available on PyPI, allows any developer to start working with VEX data.

2. Reproducing Red Hat's CVE Pages:

The most compelling demonstration was the Python Flask web application. Dan's challenge was to reproduce Red Hat's detailed CVE pages, which typically reside within their complex customer portal, using only VEX documents as input. The demo illustrated how this lightweight application, hosted on Python Anywhere, dynamically achieved this.

• It pulled VEX documents directly from Red Hat's public website.
• It then integrated data from external sources via their respective APIs, including NVD for generic CVE information, cv.org for ADP CVSS scores, and FIRST for EPSS data.
• The application displayed a comprehensive view for each CVE, including Red Hat's specific status (e.g., "Affected," "Not Affected"), descriptions, mitigation advice, and the aggregated external scoring data.

This proof of concept effectively showed that vendors could create powerful, real-time, and easily updatable CVE information portals without the significant overhead of a traditional database-driven system. The "no database, real-time (with a 1-hour cache) update" aspect was a key highlight, demonstrating agility and efficiency.

3. AI-Driven Insights and SQL Querying:

Further extending the demonstrations, Dan described how his team leveraged VEX data for advanced analytics:

• Hugging Face Dataset: A team member used AI to generate code that converted VEX documents into a Hugging Face dataset. This wasn't a live demo, but the result – an unofficial, daily-updated dataset – was presented as a working proof of concept for AI consumption of VEX. This dataset enabled the AI to identify discrepancies in Red Hat's data and answer complex questions about vulnerability trends.
• DuckDB Integration: For traditional data analysis, Dan introduced DuckDB as a way to query this Hugging Face dataset using SQL. While not a live demonstration, it served as a proof of concept for how VEX data, once transformed into a suitable format, can be explored with familiar tools, empowering analysts who may not be comfortable with AI interfaces.

Collectively, these demonstrations and proofs of concept showcased that VEX is not just a theoretical concept but a practical, versatile data format capable of powering a new generation of accurate and efficient vulnerability management tools.

Defensive Implications

▶ Watch: Expanding VEX data with NVD and CWE information (8:20)

The widespread adoption and intelligent use of VEX documents, as championed by Vincent Dan, carry significant defensive implications for organizations striving for more robust cybersecurity postures.

1. Enhanced Accuracy in Vulnerability Assessment: The most immediate and impactful defensive implication is the drastic reduction of false positives and false negatives in vulnerability scanning. By providing definitive, vendor-authored statements on whether a product is affected by a specific CVE, VEX empowers defenders to focus their limited resources on actual threats. This precision allows for more accurate risk prioritization, preventing wasted effort on non-issues and ensuring critical vulnerabilities are not overlooked. Scanning vendors should integrate VEX to provide far more reliable results than current heuristic-based methods.

1. Facilitating Disconnected Vulnerability Management: For organizations operating in highly secure, air-gapped, or intermittently connected environments, VEX offers a crucial solution. It enables the creation of local, up-to-date CVE databases that reflect the vendor's authoritative stance on vulnerabilities without requiring constant online access to vendor portals. This ensures that even in isolated systems, security teams can make informed, risk-based decisions.

1. Improved Risk-Based Decision Making: With accurate VEX data, defenders can move beyond generic CVSS scores and understand the true applicability and impact of vulnerabilities within their specific deployed software. This allows for more granular risk assessment, enabling organizations to prioritize patching, implement mitigations, or accept risk based on the concrete reality of their environment rather than broad assumptions. The inclusion of EPSS data, as demonstrated in Dan's PoC, further enhances this by indicating the likelihood of exploitation.

1. Strategic Use with SBOMs: While VEX provides vulnerability status, SBOMs identify the software components present in a system. When combined, these two data formats create a powerful synergy. An SBOM tells you what software you have (e.g., "I have Apache Struts version X"), and VEX tells you if that version of Struts, as deployed in your specific product, is actually vulnerable to a given CVE. This combination enables defenders to precisely identify patched and unpatched vulnerabilities even in complex software supply chains, enhancing visibility and control. Tools like Trivy are already starting to demonstrate this combined capability.

1. Proactive Vulnerability Intelligence: The ability to feed VEX data into AI/ML systems (as with the Hugging Face dataset) provides defenders with proactive intelligence. Organizations can analyze trends, predict future attack surfaces, identify common weaknesses (CWEs), and potentially even automate aspects of severity assignment. This shifts defensive strategies from reactive patching to more predictive and data-driven risk management.

1. Incentivizing Vendor Transparency: The push for VEX adoption incentivizes software vendors and open-source projects to be more transparent and precise in their vulnerability disclosures. For VEX to be truly effective, vendors must publish comprehensive VEX documents for both fixed and unfixed vulnerabilities. This vendor-driven clarity empowers end-users with the necessary information to manage their risk effectively, fostering a more secure software ecosystem.

Key Takeaways

• VEX addresses a critical accuracy gap in vulnerability management: It provides vendor-authored, definitive statements on vulnerability applicability, drastically reducing false positives and negatives compared to traditional scanning methods.
• VEX enables robust, disconnected vulnerability information: Organizations can leverage VEX documents to maintain up-to-date CVE data and perform accurate risk assessments even in offline or air-gapped environments.
• VEX can power dynamic and lightweight vulnerability portals: Vincent Dan's open-source VEX reader library and Flask application demonstrate how VEX, augmented by external APIs, can create real-time, comprehensive CVE pages without complex database infrastructures.
• VEX data is a valuable asset for AI/ML and traditional analytics: VEX can be transformed into machine-readable datasets (e.g., Hugging Face) for AI-driven insights into vulnerability trends, or queried like a SQL database (e.g., with DuckDB) for familiar data mining.
• Interoperability and standardization are crucial for broad VEX adoption: Differences in VEX implementation between vendors (even within the CESAF VEX standard) highlight the need for greater consistency to ensure seamless consumption by scanning tools and other security platforms.
• VEX complements SBOMs for comprehensive vulnerability management: While SBOMs list components, VEX provides the crucial context of whether those components are actually vulnerable in a specific product, offering a powerful combination for precise risk assessment.

About the Speaker(s)

Vincent Dan is the Vice President of Red Hat Product Security. With an extensive career spanning nearly 25 years in the open-source security industry, Dan brings a wealth of experience to the field. He has dedicated 16 years to Red Hat and spent eight years prior at Mandriva, where he effectively served as their entire security team. Despite humbly claiming not to be a professional developer, he has written a significant amount of code over the past two and a half decades. His deep understanding of vulnerability management, coupled with a strong commitment to transparency, underpins his work and advocacy for standards like VEX.