Vulnerability Exploitability eXchange (VEX)

What is VEX?#

Vulnerability Exploitability eXchange (VEX) is a specification for documenting the exploitability status of vulnerabilities within software components. VEX is primarily defined through industry standards such as CSAF (OASIS) and CycloneDX VEX, with the U.S. Cybersecurity and Infrastructure Security Agency (CISA) encouraging its adoption. VEX complements CVE (Common Vulnerabilities and Exposures) identifiers by adding producer-asserted status information, indicating whether a vulnerability is exploitable in the product as shipped. This helps organizations prioritize remediation efforts by identifying vulnerabilities that do not affect their specific product configurations.

For how VEX affects vulnerability counts and scanner selection, see Scanner integrations. To scan a DHI with VEX support, see Scan Docker Hardened Images.

VEX status reference#

Each VEX statement includes a status field that records Docker's exploitability assessment for a given CVE and image. OpenVEX defines four status values. DHI uses three of them:

Status	Meaning
not_affected	The CVE was reported against a package in the image, but Docker has assessed it is not exploitable as shipped
under_investigation	Docker is aware of the CVE and is actively evaluating whether it affects the image
affected	Docker has confirmed the CVE is exploitable in the image and a fix is not yet available
fixed	The vulnerability has been remediated in this version. DHI does not use this status (see below).

You can view the VEX statements for any DHI using Docker Scout. See Scan Docker Hardened Images. To query suppressed CVEs programmatically by image digest, see Query suppressed CVEs for a DHI by digest.

not_affected justification codes#

not_affected statements include a machine-readable justification field explaining why the vulnerability does not apply:

Justification	Meaning
component_not_present	The vulnerable component is not present in this image; the CVE matched by name against a different package
vulnerable_code_not_present	The vulnerable code path was not compiled into this build
vulnerable_code_not_in_execute_path	The vulnerable code exists in the package but is not called in this image's runtime configuration
vulnerable_code_cannot_be_controlled_by_adversary	The vulnerable code exists but an attacker cannot trigger it in this configuration
inline_mitigations_already_exist	Docker has applied a backport or patch that addresses the CVE

Why DHI does not use fixed#

DHI does not use fixed. VEX-enabled scanners may not handle fixed consistently, so when Docker backports an upstream patch where the version number alone would not reflect the fix, it uses not_affected with inline_mitigations_already_exist justification instead.