Give each product release one stable page or index that lists its SBOM, its VEX statements, and its security advisories, each with a date and format. A customer can then match components to vulnerabilities and read your status without asking. Keep the index current when a release ships or a status changes.
What each artifact answers
Three documents answer three different questions, so a customer needs all of them in reach.
| Artifact | Question it answers |
|---|---|
| SBOM | What components are in this release? |
| VEX | For a given vulnerability, is this product affected, and why or why not? |
| Advisory | What happened, who is affected, and what should they do? |
CISA's 2026 minimum elements guidance describes VEX and CSAF documents as security advisories that communicate the vulnerability status of a software component. It adds that after learning of a new vulnerability, an organization can check whether its SBOMs contain or reference the component, which improves response time.
Build the index per release
Use one row per release and one column per artifact.
| Release | SBOM (format, date) | VEX (date) | Advisories |
|---|---|---|---|
| 4.2.0 | CycloneDX, link | Link | None open |
| 4.1.3 | SPDX, link | Link | Link |
State the SBOM format and version in the file itself. The 2026 minimum elements list the data format name and version as SBOM metadata, so a consumer's tool can read it.
Keep it findable by machines
People read the page. Tools read files. The Transparency Exchange API project, which its README describes as a standard, format-agnostic API for exchanging product artifacts such as BOMs, VEX files, and attestations, models this as products, releases, and versioned collections of artifacts. At the time of writing its README says the API is in beta and is being worked on toward standardization within Ecma. You do not need it to start, but the data model is a useful guide: product, release, and a versioned list of artifacts.
Handle status changes
A VEX statement can change. OpenVEX defines four status labels: not_affected, affected, fixed, and under_investigation. A not_affected status must carry a justification or an impact statement. Plan to publish a new statement when your knowledge changes, for example moving from under_investigation to fixed, rather than editing history. Date every statement.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a finding moves through states. Those states are what a customer-facing VEX statement summarizes.
Where Safeguard fits
Safeguard's SBOM and dependency scanning and its reachability analysis give you the data behind these artifacts. Try a free scan at gold.safeguard.sh/scan.
Quick check
Do I need all three artifacts to start?
No. Start with a per-release SBOM and a clear contact. Add VEX when customers ask about specific vulnerabilities.
Where does the update history go?
Publish a new dated statement or file for each change and keep earlier ones, so readers can see what you knew and when.
Sources
- 2026 Minimum Elements for a Software Bill of Materials (SBOM), CISA
- Transparency Exchange API, CycloneDX on GitHub
- OpenVEX Specification
Last reviewed: 19 October 2026.
