Red Hat VEX files for CVEs are now generally available

In October 2023, Red Hat Product Security announced the publishing of Vulnerability Exploitability eXchange (VEX) files, in beta form, for every single CVE ID that is recorded in the Red Hat CVE Database. Since then, we have actively collected feedback from our customers and discussed the best implementation with security scanning vendors. With this valuable input, we have worked on improving the production version of the files.

We are pleased to announce that the VEX files are now ready for public consumption in production use cases. You can find these files in the following location:

https://access.redhat.com/security/data/csaf/v2/vex/

Key information

In our previous articles, “The future of Red Hat security data” and “Vulnerability Exploitability eXchange (VEX) beta files now available”, we highlighted that Red Hat security data is a central, authoritative source of truth for published, known vulnerabilities and their impact on the Red Hat portfolio. Red Hat has been working on providing this new security data format to cover all current software production methods, as providing this type of expanded information was not feasible with the older OVAL data format.

Currently, Red Hat Product Security publishes CSAF advisories for every single security advisory and VEX files for every single CVE record that is associated with the Red Hat portfolio in any way. CSAF advisories and VEX files both use the CSAF machine-readable data standard that allows vendors to assert whether specific vulnerabilities affect a given product and its components.

The CSAF advisories cover only a subset of the component statuses defined in the CSAF standard. These advisories contain information about components that have been patched (fixed status) in specific product releases for specific vulnerabilities. They may also contain information about components in the same product release that are not affected by the same vulnerabilities (known_not_affected status).

The VEX file for a single, public CVE ID covers all the component statuses defined in the CSAF standard:

• Fixed: Contains the same fixed component versions and other details (product_tree objects) that the CSAF advisory reports for that CVE
• Known Affected: Confirmation that the specific component and product is affected by a particular CVE
• Known Not Affected: Confirmation that the specific component and product is not affected by a particular CVE
• Under Investigation: Information that the Red Hat Product Security team is verifying the applicability and impact of a specific CVE to the specific component and product

Content scope

Each file generally consists of three major sections:

1. Document metadata
2. Product tree array
3. Vulnerability metadata

As a real-world example, let’s look at the RHSA-2024:3889 security advisory for the OpenShift Container Platform (OCP) 4.15.18 update. In the CSAF file for this advisory, you will find general information about the published document itself (the "document": {…} object), the product(s), version(s) and components that have been updated (the "product_tree": {…} object) and correlation to the vulnerabilities that have been fixed (the "vulnerabilities": […] object).

The CSAF file is always associated with one specific advisory and a given advisory may include one or more product version(s) and one or more components, depending on the product type and update scope. The advisory can also include updates to address one or more vulnerabilities. The RHSA-2024:3889 advisory delivers security fixes for three vulnerabilities: CVE-2023-45288, CVE-2023-49568, and CVE-2024-4369.

In the "vulnerabilities": […] object, there are many important details about each vulnerability and correlation to the components that are included in this product update, such as the “product_status”: {…}, useful “references”: […] or “remediations”: […] information, and the vulnerability’s impact in the “threats”: […] object. The overall advisory impact is described in the main "document": {…} object in the “aggregate_severity” field.

A VEX file for a single, public CVE ID contains detailed information about a particular vulnerability itself, and a comprehensive list of all Red Hat software (products and their components) that is related to this vulnerability. For example CVE-2023-45288, which is fixed in the RHSA-2024:3889 OCP 4.15.18 advisory, affects many more products. The overall security impact of CVE-2023-45288 is Important, but for some components on certain products, the impact is reduced to Low.

The VEX file for CVE-2023-45288 contains information about this vulnerability and how it is related to any products in the Red Hat portfolio. Similarly to the CSAF advisory, the overall CVE severity is included in the main "document": {…} object in the “aggregate_severity” field. The "product_tree": {…} object contains the list of products, their components, and the relationships between them. The "vulnerabilities": […] object identifies the affected components in the "product_status": {…} object, the product specific remediation status in the "remediations": {…} object, and the product specific impact in the “threats”: […] object. These are all associated with specific product or component identifiers as given in the "product_tree": {…} object.

The CSAF advisories and VEX files for single public CVEs have similar content, and only the scope of information is different. A single CSAF advisory covers one specific product release (advisory) which may be related to many vulnerabilities. A single VEX file covers one single vulnerability (CVE ID) which may be related to many products, whether or not they have released advisories that fix the vulnerability.

Metadata

An overview of the VEX file metadata has already been provided in the Vulnerability Exploitability eXchange (VEX) beta files now available article. Here we will only highlight the most important updates included in this GA release.

Product tree structure

For vulnerabilities that affect many products and components, such as Golang standard library vulnerabilities, the "product_tree": {…} object in the VEX files can be very complex. It contains information about all products, their versions and all of their components, including complex relationships between products and components. To simplify parsing of the VEX file and to make it easier to identify the right product, we now deduplicate the “arch” (architecture), "product_family", and “product_name” branches in the "product_tree": {…} object.

Additionally, all product_name branches (which describe specific versions of a product, like OpenShift 4.10) will now appear nested inside of a product_family branch (which describe overall products, like OpenShift). Previously, some product_name branches for middleware products would appear by themselves, outside of any product_family branch.

Revision history and change tracking

We made several changes to the way updates are tracked. Each set of files (CSAF advisories and VEX files) has its own changes.csv file that contains information about recently updated files. These updated files can be due to source data updates, or due to file format and content updates. In every file there is a detailed “revision_history": […] object that contains information about:

• When the CVE record or security advisory was first public, in the “Initial version”
• The last source data update, in the “Current version”
• The last file format or content update, in the “Last generated version”

Additionally, we added a deletions.csv file where you can find information about deleted files. Typically, a VEX file will only be deleted when the CVE ID is rejected by the CVE program, due to not being considered a security vulnerability. In this case, Red Hat must delete all references to the CVE ID, including any VEX file stating that the CVE is under investigation.

Compressed CSAF and VEX archives

Every set of documents is also available in a compressed archive file that includes all files in the individual per-year directories. The archives use the following format for the filename:

• csaf_advisories_COMPRESSION-DATE.tar.zst
• csaf_vex_COMPRESSION-DATE.tar.zst

For example:

• csaf_advisories_2024-07-07.tar.zst
• csaf_vex_2024-07-07.tar.zst

Every archive contains a detached signature file to verify authenticity as well as a file containing the hash of the archive to ensure its integrity. To easily discover the latest version, in every repository there is an archive_latest.txt file that contains the filename of the most recently generated archive.

The archives are generated weekly and it’s strongly recommended to use them only for new or fresh scanner deployments. Daily or more frequent data updates should be done using the changes.csv and deletions.csv files to ensure that the most accurate security data are used.

Package URLs for unfixed components

In the VEX beta announcement, we noted that Package URL (purl) identifiers will be presented only for components that already had patches released, so are in the “fixed” status. In the VEX GA, we extended the scope of the purl identifiers to unfixed components as well. This includes components in the "known_affected", "known_not_affected", and “under_investigation” statuses. The purl identifiers for unfixed content are only available for rpm, oci (container), andrpmmod (modular) components.

Other Red Hat security data updates

We are committed to continually improving our security data; any future changes to the data itself or the format of the files are tracked in the Red Hat Security Data Changelog.

Recently, we also published an article, Identifying Red Hat components using Package URL, with Red Hat’s recommendation on how purl identifiers should be used, and how Red Hat components are represented in this format.

With the GA announcement of our VEX files, we are officially moving all OVAL v2 content into maintenance mode. Red Hat will continue to produce OVAL v2 content for core products such as Red Hat Enterprise Linux (RHEL) 8 and 9, but OVAL data won’t receive new features and will be limited to critical bug fixes only. OVAL content will not be published for future major RHEL releases (10 and onward) as well as any new products. When maintenance support ends, all remaining OVAL v2 content will be archived, the same way OVAL v1 content was archived.

All customers and scanning vendors are highly encouraged to start using the officially supported and current CSAF and VEX security data produced by Red Hat Product Security.

Please contact Red Hat Product Security with any questions regarding security data at [email protected] or file an issue in the public SECDATA Jira project.