A software bill of materials can identify a component inside a product. It does not automatically establish whether a newly disclosed vulnerability is exploitable in that product's configuration. A Vulnerability Exploitability eXchange statement, or VEX, addresses the product's relationship to a particular vulnerability.
These records are complementary. One describes composition; the other communicates an assessment. A business consuming them needs to know which release they describe and what evidence supports the assessment.
Match the inventory to the shipped release
OWASP's SBOM guidance distinguishes an inventory from the dependency relationships that help explain how components enter a build. It also notes that absent entries do not prove a component is absent from the software. The dependency graph and SBOM guidance describes release binding and completeness limits.
An illustrative supplier delivers version 4.2 of an appliance but provides an inventory generated for version 4.1. Even a well-formed inventory would not establish the contents of the installed release. Product identifiers, versions, artifact hashes, and generation scope make that mismatch visible.
Read the VEX justification
A not-affected statement requires more than a status label. The issuer's identity, product version, vulnerability identifier, and stated justification determine how the claim can be evaluated. A component may be present while a vulnerable feature is absent or unreachable under specified conditions.
The customer's configuration can matter. If the statement assumes a feature is disabled and the customer enables it, the original justification may no longer apply. Keep the supplier statement and the local configuration evidence connected instead of copying the status into a permanent exception.
Work through a release-specific example
Suppose a synthetic product inventory lists a library affected by an advisory. The supplier states that the vulnerable parser is not included in the shipped build. The reviewer can request the exact build scope and supporting analysis, then compare that claim with the deployed artifact and enabled functionality.
If the evidence is incomplete, the result is an unresolved applicability question. It is not proof of exploitation, and it is not proof that the product is unaffected. That distinction supports a measured response while further evidence is collected.
Preserve the decision history
Record the inventory used, supplier statement, local checks, decision owner, and review date. Reassess when the product changes, the advisory is updated, or the assumptions supporting the statement no longer hold. Retain earlier records so an incident review can reconstruct what was known at the time.
An assessment can verify the process by tracing one component from inventory through deployment and vulnerability disposition. This demonstrates whether the organization can act on the records it receives. Merely possessing an SBOM file or accepting every VEX status does not establish that capability.
Sources
CycloneDX: Vulnerability Exploitability Exchange. The appliance and parser example are illustrative.
