Skip to Content
SCA & DependenciesVEX Documents

VEX (Vulnerability Exploitability eXchange)

VEX is a standard for communicating whether known vulnerabilities in software components are actually exploitable in a specific product or deployment context. CodeStax supports generating VEX documents and importing SBOMs with vulnerability enrichment.

What VEX Is

Not every vulnerability affects every consumer of a library. A CVE may exist in a function your application never calls, or behind a configuration you do not use. VEX documents formally state the exploitability status of each vulnerability so downstream consumers (security teams, customers, auditors) can make informed decisions without re-analyzing every CVE.

VEX statuses include:

  • Not Affected — The vulnerability is present in the dependency but does not affect your product.
  • Affected — The vulnerability is confirmed to be exploitable in your context.
  • Fixed — The vulnerability was previously affected and has been remediated.
  • Under Investigation — Analysis is ongoing.

Generating CycloneDX VEX Documents

CodeStax produces VEX output in CycloneDX format:

  1. Navigate to SCA > VEX.
  2. Select the repository and scan you want to generate VEX for.
  3. Click Generate VEX. The status of each statement is derived automatically from the analysis properties of the underlying finding (see How VEX Status Is Determined below) — findings flagged as false positives or as unreachable map to not_affected, while all other findings map to affected.
  4. Download the resulting .json file. It conforms to the CycloneDX VEX specification and can be shared with customers or fed into other tools.

SBOM Import with Vulnerability Enrichment

CodeStax can import existing Software Bill of Materials files and enrich them with vulnerability data:

Supported Formats

  • CycloneDX (JSON and XML)
  • SPDX (JSON)

Import Process

  1. Go to SCA > SBOM Import.
  2. Upload your SBOM file.
  3. CodeStax parses the component list and queries global threat intelligence databases for known vulnerabilities affecting each component.
  4. Results appear in the standard SCA vulnerability table, tagged with an “SBOM Import” source label.

This is useful when you receive SBOMs from vendors or upstream projects and want to assess their security posture within CodeStax.

How VEX Status Is Determined

VEX status is derived automatically from the analysis properties of each finding, not from its triage workflow status. Each statement’s status is computed as follows:

Finding PropertyVEX StatusJustification
Marked as false positiveNot Affectedfalse_positive
Reachability analysis found the vulnerable code is not in the execution pathNot Affectedvulnerable_code_not_in_execute_path
All other findings (including those with an available fix that has not yet been applied)Affected

The finding’s AI risk explanation is included in the VEX document as the impact_statement, and its recommended fix or remediation guidance is included as the action_statement, giving downstream consumers context for the assessment.

Best Practices

  • Mark confirmed false positives and run reachability analysis before generating VEX, since these properties drive the not_affected status.
  • Regenerate VEX documents after each scan to keep them current.
  • Share VEX documents alongside your SBOM when distributing software to customers.
  • Use SBOM import to evaluate third-party dependencies before onboarding new vendors.