Vulnerability Exploitability eXchange (VEX) - Definition & Use Cases

What is VEX?

Vulnerability Exploitability eXchange (VEX), is a standardized format used to convey information about the exploitability of vulnerabilities in software products and share it with scanning tools.

VEX is important because just because a vulnerability scanner identifies a vulnerability in an application doesn’t mean the vulnerability is exploitable under a specific application configuration. For example, attackers may only be able to exploit a vulnerability if an application is hosted on a specific operating system or if a certain application feature is enabled. When securing scanners know this information, they are able to generate more actionable information about which vulnerabilities are actually relevant in a given IT environment or under a certain application configuration.

In turn, VEX gives security teams and developers an easy, automated way of identifying the conditions under which a vulnerability is exploitable. As a result, they can quickly determine whether vulnerabilities actually affect their organizations. In cases where scanners identify a high volume of vulnerabilities and teams don’t have time to fix all of them immediately, VEX makes it possible to decide which vulnerabilities to prioritize by focusing on the ones that are exploitable.

VEX was introduced in 2021 by the National Telecommunications and Information Administration, or NTIA, a U.S. government agency, to help streamline the sharing of information about vulnerabilities.

What are the differences between VEX and SBOM?

Scanners can use VEX to include information about vulnerability exploitability when they produce Software Bills of Material, or SBOMs. However, VEX is distinct from an SBOM itself.

An SBOM, which is typically formatted using a standard like SPDX or CycloneD, provides various types of information about the components within an application’s software supply chain, such as which versions they are and where they originated. Thus, the main purpose of an SBOM is to provide an easy way of tracking software supply chain components and contextual information associated with them.

In contrast, the focus of VEX is on describing vulnerabilities. VEX can be integrated into an SBOM to add information about vulnerabilities that relate to any components within a software supply chain. But unlike an SBOM, VEX only describes information about vulnerabilities, not other data about software supply chain components.

How is VEX generated?

To generate VEX as part of vulnerability scanning, first generate an SBOM. For example:

trivy image --format cyclonedx --output debian11.sbom.cdx debian:11

This command uses Trivy, an open source vulnerability and misconfiguration scanning tool, to create an SBOM for version 11 of Debian Linux.

Then, you can create a VEX by writing code in a VEX implementation of your choosing (for more on VEX implementations, see below) that describes vulnerability exploitability. For example:

{

  "bomFormat": "CycloneDX",

  "specVersion": "1.4",

  "version": 1,

  "vulnerabilities": [

    {

      "id": "CVE-2020-8911",

      "analysis": {

        "state": "not_affected",

        "justification": "code_not_reachable",

        "response": ["will_not_fix", "update"],

        "detail": "The vulnerable function is not called"

      },

      "affects": [

        {

          "ref": "urn:cdx:3e671687-395b-41f5-a30f-a58921a69b79/1#pkg:golang/github.com/aws/[email protected]"

        }

      ]

    }

  ]

}

EOF

This VEX indicates that the vulnerability described in CVE-2020-8911 is not exploitable. The ref: section includes three important values:

• A serialNumber (in this case, urn:cdx:3e671687-395b-41f5-a30f-a58921a69b79) that matches the serialNumber defined in the SBOM.
• A version (in this case, 1) that is also defined in the SBOM.
• A bom-ref (in this case, pkg:golang/github.com/aws/[email protected]) that matches the package identified by the vulnerability.

We can save this VEX as a file (we’ll call it trivy.vex.cdx), then feed it into our vulnerability scanner using the following command:

trivy sbom debian11.sbom.cdx --vex trivy.vex.cdx

This tells the vulnerability scanner to ignore vulnerability CVE-2020-8911 when reporting scanning for vulnerabilities based on the Debian 11 SBOM that we created above. As a result, Trivy won’t flag this vulnerability when it generates a list of vulnerabilities for Debian 11.

VEX implementations

As we mentioned, there are multiple implementations of VEX. The three major options at present include:

• OpenVEX
• CSAF VEX
• CycloneDX VEX

Each implementation uses different formatting and syntax to describe the exploitability of vulnerabilities. But all implementations make it possible to share the same basic information.

Kubernetes security and VEX

VEX is valuable across a variety of software ecosystems, but one place where it has gained notable momentum is the world of Kubernetes security. Given that there are millions of public container images that could be subject to container security vulnerabilities, the ability to describe and share vulnerability data in a consistent way helps organizations that use Kubernetes and other container-centric platforms to get ahead of security risks.

With VEX, you can take advantage of the flexibility of Kubernetes, while also keeping tabs on any vulnerabilities that exist in container images you use – as well as vulnerabilities that affect the components of Kubernetes itself.

VEX use cases

VEX can assist with several use cases related to vulnerability scanning:

• Allowing software vendors or packagers to share information about the conditions under which a vulnerability is exploitable.
• Reducing the “noise” generated by vulnerability scanners by filtering out non-exploitable vulnerabilities.
• Helping security teams and developers identify the conditions under which a vulnerability is exploitable so that they can avoid implementing them.
• Allowing security auditors to determine which portion of vulnerabilities inside an IT environment are actually exploitable – which is a more meaningful reflection of risk than total vulnerability count.

Getting the most from VEX with Aqua

Aqua has been a major proponent of VEX since the concept’s introduction, which is why Aqua Trivy (OSS) was one of the first scanners to support VEX. By using Trivy to generate SBOMs and filter vulnerabilities, you can quickly determine not only which components exist in your software supply chain, but also which vulnerabilities impact them. In turn, you can decide which risks to prioritize and mitigate them faster.

In addition, Aqua has built VEX Hub, a centralized repository where software vendors can share VEX attestations, and where security teams can download them and use them during scanning. This is important because although the VEX standard offers an easy way of sharing vulnerability information, there was not previously a central location for finding and downloading VEX attestations. With VEX Hub, Aqua has closed this gap, making it easy users of Trivy (and, potentially, other scanners) to find VEX attestations and use them to filter scanning results.