Send an SBOM when the customer asks what is inside your software. Send a VEX when they ask whether a specific known vulnerability affects you. The SBOM is an inventory. The VEX is a statement about exploitability. Sending one without the other often creates follow-up questions you can avoid by sending both.
Definitions
CISA describes an SBOM as a nested inventory, a list of the ingredients that make up software components. CISA describes a Vulnerability Exploitability eXchange, or VEX, as an attestation: a form of security advisory that indicates whether a product or products are affected by a known vulnerability or vulnerabilities.
CISA also notes that it published 2026 updates to the minimum elements for an SBOM, adding new data fields, practices and processes. Before you generate files for customers, read the current CISA guidance so your fields match what the market expects.
When to send which
| Customer question | Send | Why |
|---|---|---|
| What components do you ship? | SBOM | Inventory answers it |
| Are you affected by a named vulnerability? | VEX | A status statement answers it |
| Which licences are in the product? | SBOM | Components carry licence data |
| Why does your scan show a flaw you say is not exploitable? | VEX with a justification | Explains the difference |
Why an SBOM alone causes friction
If a customer runs their own scanner over your SBOM, they will see every known vulnerability in every listed component. Many will not be reachable in your product. Without a VEX, they will ask you about each one. A VEX with a clear status and reason answers that in advance.
Steps to send them well
- Generate the SBOM from the build, not from memory, and record the product version it describes.
- Check the file for completeness against the CISA minimum elements.
- For each flagged vulnerability, record a status: affected, not affected, fixed, or under investigation.
- For every not affected status, write the reason, such as the vulnerable function not being called.
- Have a second engineer verify those reasons for the most severe items.
- Date and version both files, and send them together with a short cover note.
- Set a rule for when you reissue: each release, and when a major new vulnerability appears in a listed component.
Staleness
An SBOM describes one build. A VEX describes one moment. Both go stale. Put the product version and date in the file name, and tell customers which release they apply to. When you ship a new release, the old files should say so.
Wording to avoid
Do not say "no known vulnerabilities" because a scan returned nothing today. State the date and the data source. Do not mark an item not affected without a reason a reviewer can check. A VEX is an attestation about your product, so treat it with the care you would give any claim you sign.
Where Safeguard fits
Safeguard's SBOM and dependency scanning produce the inventory, and reachability analysis helps you decide whether a vulnerable function is actually called. The demo below shows a dependency inventory.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how each component lists a version, since that is the data a customer's scanner will read.
Quick check
Is a VEX required whenever I send an SBOM?
No, but it prevents repeated questions about findings that do not affect your product.
How often should I reissue them?
At least per release, and when a significant new vulnerability affects a listed component.
Sources
Last reviewed: 19 October 2026.
