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:
Analyze the application SBOM for vulnerabilities
Review the vulnerabilities from the Bill of Materials
Annotate the status of vulnerabilities
Share annotated SBOM with stakeholders
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.
Selecting a component displays its component details.
Add or Edit the VEX Annotations to a disclosed vulnerability using the button in the actions column.
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.
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 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. |
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 | consumer should upgrade to a newer version |
rollback | 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