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 the SBOM Manager API.

  1. Selecting a component displays its component details.

  2. Add, Edit, Copy, or Delete the VEX Annotations to a disclosed vulnerability using the actions ellipsis control accordion. Only applicable options are available in the dropdown.

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

Bill of Materials - Components
sbom-bill-of-material-components.png
Component Details - Vulnerabilities
sbom-discolsed-vulnerablities.png
Vulnerability Annotation
sbom-vex-annoation.png

Copy VEX Annotations from Previous Versions

When the previous version of the application has been annotated with a VEX status and justification, those annotations may be copied to the current version's vulnerabilities to reduce the time your team spends on vulnerability management.

sbom-vex-copy.png

  1. From the component details list of vulnerabilities, under the Actions column, the ellipsis control accordion can copy the previous annotations when available.

  2. Selecting Copy Annotation will update the VEX annotations to this version.

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 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.

SELECT

Default value for status and indicates no value has been selected

In triage

the vulnerability is being investigated.

Exploitable

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.

Resolved

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).

Justification

The rationale of why the impact analysis state was asserted.

SELECT

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 perimeter

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

Protected at runtime

exploits are prevented at runtime.

Protected by compiler

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.

Response

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.

can_not_fix

issue cannot be fixed at this time

will_not_fix

issue will not be fixed at this time

update

the consumer should upgrade to a newer version

rollback

the consumer should rollback to another version

workaround_available

consumer will need to implement the workaround

Description

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 CISA.org VEX Use-cases