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:
- Navigate to SCA > VEX.
- Select the repository and scan you want to generate VEX for.
- 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 toaffected. - Download the resulting
.jsonfile. 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
- Go to SCA > SBOM Import.
- Upload your SBOM file.
- CodeStax parses the component list and queries global threat intelligence databases for known vulnerabilities affecting each component.
- 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 Property | VEX Status | Justification |
|---|---|---|
| Marked as false positive | Not Affected | false_positive |
| Reachability analysis found the vulnerable code is not in the execution path | Not Affected | vulnerable_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_affectedstatus. - 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.