SBOM vs VEX: Inventory Is Not Exploitability
Published August 2026 by Solarc Labs
An SBOM is a component inventory, not a finished vulnerability decision
CISA describes an SBOM as a formal record of software components and their supply-chain relationships. That transparency is foundational, but component presence is only the start of a vulnerability question. Vulnerability data changes over time, and the existence of a vulnerable upstream component does not automatically establish that the downstream product is affected in the same way.
VEX communicates product-specific vulnerability status
Vulnerability Exploitability eXchange exists to communicate whether a known vulnerability actually affects a product. CISA and NTIA materials describe VEX as a way for suppliers to express states such as affected or not affected with the relevant product and vulnerability context. This reduces the temptation to treat every CVE attached to every transitive component as an identical operational emergency.
Presence, reachability and risk are different questions
A component may be listed in an SBOM while the vulnerable code path is not included, not reachable or otherwise not applicable to the shipped product. Conversely, a supplier saying not affected is still an assertion that needs identity, version and supporting context. The useful workflow preserves the component inventory, the vulnerability source, the VEX status and its justification as separate evidence rather than collapsing them into one score.
Licence review is a third job again
An SBOM can also support open-source licence review, but licence policy and vulnerability exploitability are not interchangeable. A component can be acceptable from a security perspective and still require licence review, or have a permissive licence while carrying a vulnerability that needs remediation. Procurement evidence should therefore keep licence disposition, vulnerability status and product decision boundaries distinct.
Treat SBOM and VEX as versioned evidence
Both datasets need product and version identity. An SBOM is a snapshot of what was built at a point in time; vulnerability knowledge and VEX assertions can change later. Operationally, the strongest handoff records which product build the SBOM describes, which vulnerability source was evaluated, who issued the VEX assertion, its status and justification, and when that evidence was reviewed.
Primary sources
Sources used for this article
Continue the job