How to use SUSE Rancher’s VEX Reports

The information applies to the following SUSE products:

• Rancher Prime
• RKE
• RKE2
• K3s
• Harvester
• Longhorn
• NeuVector

VEX, which stands for Vulnerability-Exploitability eXchange, is an open specification, developed by NTIA¹, to report if a certain CVE (Common Vulnerabilities and Exposures) is applicable or is a false-positive on a given version of a software.

The VEX initiative is part of a wider industry effort to provide more accurate data about how CVEs affect products from vendors. The reports are in a format that is vendor neutral and can be consumed by multiple security tools and CVE scanners in an effort to reduce the false-positive noise so commonplace today.

These reports are an integral part of the Rancher Security team’s automated CVE scans of the software and container images that are shipped in SUSE Rancher Prime. Any false-positive CVEs are identified by automated and manual reviews of our scanner’s reports. Then the known false-positives are grouped in the VEX reports. With this process we are able to have a more accurate list of applicable CVEs in our software and images, which are then triaged and prioritized by SUSE’s engineering teams.

¹ The United States’ National Telecommunications and Information Administration agency.

Given how effective the results of using VEX reports to remove false-positive CVEs are, the Rancher Security team is publishing the same VEX reports that we use internally to Rancher’s VEX Hub repository. This will allow users that are doing their own CVE scans of our images to benefit from more accurate CVE scan results, with a reduced false-positive signal to noise ratio.

The VEX reports in SUSE Rancher’s VEX Hub repository are organized according to:

• The open source OpenVEX specification - that defines a set of statuses that CVEs must have in order to be considered valid VEX statements and how they are organized inside the VEX report.
• The open source VEX Repository specification - defines how a group of VEX reports must be organized in order to be easily consumed by CVE scanners.

The VEX Report and CVEs Statuses

A minimally valid VEX report according to the OpenVEX specification has the following format:

The status label in the OpenVEX spec must contain one of the following values:

A justification must be provided when a not_affected status label is used. The following labels are currently defined as valid justifications by the OpenVEX spec:

How to Use Rancher’s VEX Reports

The way to consume Rancher’s VEX reports depends on which CVE scanner is being used. Rancher’s VEX reports are distributed in two formats - as a standalone report file and following Trivy’s VEX Hub (the VEX Repository specification).

Standalone Report

The standalone report contains all the VEX statements and is available in https://github.com/rancher/vexhub/blob/main/reports/rancher.openvex.json. The raw version of the file can be downloaded in https://raw.githubusercontent.com/rancher/vexhub/refs/heads/main/reports/rancher.openvex.json.

After downloading the raw file, you can pass it to Trivy with the --vex parameter (--vex rancher.openvex.json --show-suppressed).

 Trivy correctly suppresses CVE-2024-41110 in the Rancher Agent binary (usr/bin/agent) as not_affected because of the vulnerable_code_not_present statement and the source being the rancher.openvex.json report file. 

Note that you must always manually check if there is a newer version available of the standalone report, otherwise you might risk missing new CVEs that are VEXed by the Rancher Security team.

VEX Hub Repository

Using Rancher’s VEX Hub repository might be an easier way to consume the reports, as Trivy will take care of updating its local cache (copy) of the reports with newer versions available in our VEX Hub.

In order to configure Trivy to use Rancher’s VEX Hub repository, add the following lines to your Trivy’s main configuration file (it’s usually located under your home directory in $HOME/.trivy/vex/repository.yaml, but it might change depending on your system, please consult Trivy’s documentation for more information).

In the url field you must point to Rancher’s VEX Hub repo at https://github.com/rancher/vexhub.

It’s advised to download the VEX Hub database before the first run.

Then you can run Trivy with the --vex repo --show-suppressed parameter.

As seen, Trivy is again able to correctly suppress CVE-2024-41110 in the Rancher Agent binary (usr/bin/agent) as not_affected because of the vulnerable_code_not_present statement, but the source is now Rancher’s VEX Hub repository (VEX Repository: rancher-vexhub (https://github.com/rancher/vexhub)).

Note that when using Trivy’s VEX Hub repository feature, your Trivy might already be configured to use Trivy’s default VEX Hub repository that will point to https://github.com/aquasecurity/vexhub. The Rancher Security team strongly advises that when scanning SUSE Rancher Prime images to only use Rancher’s provided VEX reports. Due to obvious security reasons, we cannot attest the VEX reports from third-parties.

Air Gap Setups

For users running SUSE Rancher Prime and CVE scans in air gap environments, we recommend using the standalone VEX report. The standalone report file is easier to download and pass it offline to a CVE scanner in a way that it doesn’t require constant connectivity to the Internet. There are, however, some points that must be observed:

1. Updates of the air gap version of the VEX report - the standalone VEX report must be constantly checked against our VEX Hub and have its local offline version updated. This is because new CVEs can be added at any time as we identify more applicable or false-positives vulnerabilities.
2. Updates of registry-related VEX entries in the report - when CVEs are VEXed against a specific container image, the VEX specification requires that the image’s full registry address be listed in the VEX statement. For example,  “pkg:oci/shell?repository_url=registry.rancher.com%2Francher%2Fshell” has the entry repository_url pointing to the registry address registry.rancher.com. In all similar VEX entries, change only the registry address to point to the address of the air gap registry. For example,  from “pkg:oci/shell?repository_url=registry.rancher.com%2Francher%2Fshell” to “pkg:oci/shell?repository_url=my-own-registry.internal.corp%2Francher%2Fshell”. Any regular text editor can be used to search and replace all of the relevant entries.

Such changes must be done exclusively by the users that have an air gap setup because the report synchronization process and the registry’s address depends exclusively on the air gap setup of each user and its environment.