Yes. CISA's minimum requirements say VEX is designed to integrate with SBOMs, vulnerability databases and advisories but does not require any of them. You can publish status for a product and vulnerability without an SBOM, though product identifiers become harder to match if you skip one.
What the standard says
The document states VEX can be authored by a supplier or third party and that it does not depend on SBOM. Product identifiers should reference existing SBOM identifiers, using the word should, but they may also be URIs, URLs, hashes, commit IDs, versions, version ranges or any other identification system the author creates. The suggested convention is a supplier, product and version construct.
What you lose without an SBOM
| With an SBOM | Without an SBOM |
|---|---|
| Customers match VEX products to components by shared identifiers | Customers match by name and version, which is error prone |
| Component level statements are easy to write | You must define components yourself |
| Tools can automate suppression of false positives | Suppression needs manual checks |
How to do it well anyway
- Name the product and version precisely using the supplier, product and version pattern.
- Use a well known vulnerability identifier such as a CVE number.
- Where the customer will compare against a scan, include identifiers a scanner uses, such as package URLs. The OpenVEX spec says purl is preferred and that you should list as many identifiers as possible.
- State the status and, for not affected, a justification label.
- Add hashes for the product artifact if you can, so the match does not depend on names.
Do you still need an SBOM later?
Probably. Customers who want to automate will ask for one, and the effort of deciding whether components are present is the same effort an SBOM captures. Starting with VEX for your most asked about issues can be a sensible first step, while you build SBOM generation into your release process.
An example statement in words
Product: Example App 2.3. Vulnerability: a library flaw identified by its CVE. Status: not affected. Justification: vulnerable code not in execute path. Impact note: the application never calls the affected function.
Try it yourself
Open the demo and see how exploitability is stated for one component. That is the substance of a VEX statement, with or without an SBOM around it.
Click through it at your own pace, or open it full screen.
Quick check
Is VEX useful if the customer has no SBOM?
Yes, for the specific product and vulnerability it names.
Do we need to list every component?
No. CISA says VEX does not require a complete list of products or components.
Safeguard's SBOM and dependency scanning and reachability analysis can give you the facts to write statements, and the free scan is an easy way to start.
Sources
- Minimum Requirements for Vulnerability Exploitability eXchange (VEX), CISA, April 2023
- OpenVEX specification
Last reviewed: 19 October 2026.
