Skip to main content

SBOM VEX Workflow

Vulnerability Exploitability eXchange or VEX communicates the exploitability of components with known vulnerabilities in the context of the product in which they are used. (source CycloneDX documentation). The actual risk of a vulnerable component may be significantly lower when the vulnerable method is not referenced in the application's call flow or when development has isolated the risk from the rest of the application.

Using reachability analysis, developers determine when their applications are at risk of discovered vulnerabilities and use SBOM Manager to annotate their application's SBOM to communicate the exploitability status to their stakeholders.

The following steps are an overview of the VEX Workflow:

  1. Analyze the application SBOM for vulnerabilities

  2. Review the vulnerabilities from the Bill of Materials

  3. Annotate the status of vulnerabilities

  4. Share annotated SBOM with stakeholders

  5. Audit SBOMs for newly discovered vulnerabilities

Adding VEX Annotations to Vulnerabilities

VEX annotations are added from the SBOM Bill of Material View or through the SBOM Manager API.

  1. Selecting a component displays its component details.

  2. Add or Edit the VEX Annotations to a disclosed vulnerability using the button in the actions column.

  3. Select Save to update the vulnerability with VEX Annotations.

Bill of Materials - Components
Component Details - Vulnerabilities
Vulnerability Annotation

VEX Annotations

VEX Annotations are a set of normalized statuses for known vulnerabilities on open-source dependencies found in an SBOM. The status is used to simplify the process of informing stakeholders of remediation efforts.

The following are the components of a VEX annotation for a vulnerability. Details are sourced from the CycloneDX specifications. The analysis status is the only required field.

Analysis status

Declares the current state of an occurrence of a vulnerability, after automated or manual analysis.


Default value for status and indicates no value has been selected

In triage

the vulnerability is being investigated.


the vulnerability may be directly or indirectly exploitable.

False positive

the vulnerability is not specific to the component or service and was falsely identified or associated.

Not affected

the component or service is not affected by the vulnerability. Justification should be specified for all not_affected cases.


the vulnerability has been remediated.

Resolved with pedigree

the vulnerability has been remediated and evidence of the changes are provided in the affected components pedigree containing verifiable commit history and/or diff(s).


The rationale of why the impact analysis state was asserted.


Default value for justification and indicates no value has been selected

Code not present

the code has been removed or tree-shaked.

Code not reachable

the vulnerable code is not invoked at runtime.

Protected at permeter

attacks are blocked at physical, logical, or network perimeter.

Protected at runtime

exploits are prevented at runtime.

Protected by complier

exploitability requires a compiler flag to be set/unset.

Protected by mitigating control

preventative measures have been implemented that reduce the likelihood and/or impact of the vulnerability.

Requires configuration

exploitability requires a configurable option to be set/unset.

Requires dependency

exploitability requires a dependency that is not present.

Requires environment

exploitability requires a certain environment that is not present.


A response to the vulnerability by the manufacturer, supplier, or project responsible for the affected component or service. Responses are strongly encouraged for vulnerabilities where the analysis state is exploitable.


issue cannot be fixed at this time


issue will not be fixed at this time


consumer should upgrade to a newer version


consumer should rollback to another version


consumer will need to implement the workaround


Detailed description of the impact including methods used during assessment. If a vulnerability is not exploitable, this field should include specific details on why the component or service is not impacted by this vulnerability.

VEX Use cases

Learn more from VEX Use-cases