CSAF VEX documents now generally available

In June 2022, we started publishing CSAF advisory files in their beta format, hoping to gather feedback from customers, partners, and the security community. With your inputs we worked on improving the final version of the files and they are now ready for public consumption in production use cases at https://access.redhat.com/security/data/csaf/v2/advisories/.

The v2 version in the URL path tracks the version of the standard itself: CSAF 2.0. Any minor version updates to the standard will be reflected in the files under this location; we are committed to always supporting the latest version of the standard.

With the production version of the CSAF files now in place, we’d like to remind any users that the existing CVRF files are now considered deprecated. They continue to be published and updated until September 1st, 2023. On that date, the available files will be stored in a single archive file and placed under https://access.redhat.com/security/data/archive and available indefinitely. Refer to the CVRF compatibility article for more information.

Publishing VEX

The final version of CSAF files published at the present time has changed from the beta version in one significant way: the content itself now meets the requirements of the VEX profile (Vulnerability Exploitability eXchange), and the document type has thus changed from csaf_security_advisory to csaf_vex. The actual data change within the files was relatively minor: a flags attribute was added that contains a machine-readable value that marks all components shipped in an advisory that are not affected by a specific vulnerability; the rest of the components are assumed as fixed.

As a real-world example, let’s look at the RHSA-2023:0069 security advisory. This advisory shipped an update for the OpenShift Container Platform that fixed, among other things, one vulnerability: CVE-2023-0296. This vulnerability affected the openshift4/ose-etcd container image (specifically the grpc-proxy component within that container image), which is one of the container images that make up the entire OpenShift Container Platform. In the VEX file for this advisory, openshift4/ose-etcd is marked as a fixed component, while all of the other container images provided by that advisory are marked as not affected:

"product_status": { "fixed": [ “8Base-RHOSE-4.11:openshift4/ose-etcd:v4.11.0-202301041324.p0.gc50e9aa.assembly.stream” ], "known_not_affected": [ "8Base-RHOSE-4.11:openshift4/cloud-network-config-controller-rhel8:v4.11.0-202301051554.p0.g5dd318b.assembly.stream", "8Base-RHOSE-4.11:openshift4/network-tools-rhel8:v4.11.0-202301070325.p0.g4e87286.assembly.stream", "8Base-RHOSE-4.11:openshift4/ose-baremetal-installer-rhel8:v4.11.0-202301042055.p0.gf746e45.assembly.stream", "8Base-RHOSE-4.11:openshift4/ose-cluster-baremetal-operator-rhel8:v4.11.0-202301091615.p0.g1f1ea53.assembly.stream", […full list truncated…] ] }

The VEX profile also requires that the unaffected components are marked up with an explanation of why they are not affected. We do this in our files by using the component_not_present flag:

"flags": [ { "label": "component_not_present", "product_ids": [ "8Base-RHOSE-4.11:openshift4/cloud-network-config-controller-rhel8:v4.11.0-202301051554.p0.g5dd318b.assembly.stream", "8Base-RHOSE-4.11:openshift4/network-tools-rhel8:v4.11.0-202301070325.p0.g4e87286.assembly.stream", "8Base-RHOSE-4.11:openshift4/ose-baremetal-installer-rhel8:v4.11.0-202301042055.p0.gf746e45.assembly.stream", "8Base-RHOSE-4.11:openshift4/ose-cluster-baremetal-operator-rhel8:v4.11.0-202301091615.p0.g1f1ea53.assembly.stream", […full list truncated…] ] } ]

The CSAF documentation provides recommendations for vendors on how to distribute CSAF files. Our publishing meets the requirements of the trusted provider role as defined in the standard. All published CSAF files have an accompanying detached signature file to verify each CSAF file’s authenticity as well as a file containing the hash of the CSAF file to ensure its integrity. The provider-metadata.json file contains the information on the signing key used and the canonical locations of all relevant CSAF artifacts.

For more information about the contents of our CSAF files that remain unchanged from their Beta versions, please refer to the previous blog post’s Implementation details section.

Future CSAF improvements

The CSAF VEX files published today contain the mapping of vulnerabilities to products using the security advisory as a logical grouping. One security advisory can provide an update to one or more product versions for a set of one or more vulnerabilities. This allows users to build out a mapping of fixed vulnerabilities in any given product.

In the coming months, we’ll also be evaluating publishing VEX files containing information on the product affectedness per each vulnerability (identified by a CVE). For example, products A, B, and C may be affected by a vulnerability, but only product A has had the vulnerability addressed via a security advisory. For product A, a CSAF VEX file would exist that would represent the advisory and contain information about the fixed components.

For products B and C, one may be out of support scope, and the other in the process of being updated. A VEX file would be available, marking those products using one of the product status attributes: fixed, known_affected, known_not_affected, or under_investigation. With this information, users could build out a mapping of unfixed vulnerabilities in any given product.

If you are consuming CSAF files from Red Hat and are interested in collaborating with us on defining the contents of our future VEX file publishing (or improving our existing CSAF files), please contact us using the information below.

More information

For more information about the CSAF standard, see the OASIS CSAF website. If you wish to submit corrections, ask questions, or get more information about the Red Hat implementation of CSAF, contact Red Hat Product Security at [email protected] or file an issue in the SECDATA Jira project.