SBOM and VEX: components and vulnerability impact
Sytance · Updated
An SBOM identifies the software components in a product. Vulnerability Exploitability eXchange (VEX) communicates whether a particular vulnerability affects that product. The assessment depends on the product version, its configuration and how it uses the component.
Component inventory, matching and impact
The inventory records whether a component is present. A vulnerability match shows that an advisory names the component or its version. Impact analysis then checks whether the vulnerable code is present and exploitable in the product’s actual build and use.
CycloneDX uses VEX to communicate the assessment for a specific product. For example, a component can be present while an optional vulnerable feature was excluded during the build. That distinction requires build information and analysis.
The four OpenVEX statuses
OpenVEX defines four statuses. Each status applies to the product version and vulnerability identified by the statement.
| OpenVEX status | Meaning |
|---|---|
| under_investigation | Impact is still being assessed |
| affected | The identified product is affected |
| fixed | The identified version includes a fix |
| not_affected | The identified product is not affected |
An optional decoder in a gateway
Consider a fictional gateway containing a parser library with an optional decoder. Suppose a vulnerability affects that decoder. The assessment starts by establishing which library build is in the shipped image and whether the decoder was compiled into it.
If build settings and analysis of the binary confirm that the vulnerable decoder is absent, they can support a not_affected statement with the reason vulnerable_code_not_present. The statement applies to that build.
If the code is present but execution is unclear, keep the assessment under investigation while checking the entry points and execution paths. If the product is affected and a later release includes the fix, the earlier release remains affected; the later release receives its own statement.
Reasons for a not-affected status
OpenVEX requires a not_affected statement to include a justification or impact statement. Its machine-readable justifications distinguish missing components, missing vulnerable code, code outside the execution path, attacker-control limits and built-in mitigations.
Each reason has different conditions. A network restriction does not remove vulnerable code. For the built-in mitigation reason, OpenVEX specifies protection that prevents exploitation and cannot be disabled or reconfigured by the user.
For a code-path conclusion, identify the affected function, the paths checked and the configuration limits. Revisit the assessment if those conditions change. If the conclusion depends on a customer-controlled setting, communicate that dependency clearly.
Using a supplier’s VEX statement
A supplier’s VEX statement can help filter alerts or change their priority. Before using it, confirm that the source is trusted and the product version matches. Check the publication time, revisions, applicable configuration and recommended actions.
If a trusted vendor and your own analysis disagree, preserve both records and resolve the difference. A broad product-family statement may not cover a custom build with different components or options.
An SBOM remains useful after a VEX statement is published. New advisories can change what needs investigation, and a revised product can invalidate an old conclusion. Keep inventory updates and impact assessments linked while preserving their separate histories.