Examples in this article are illustrative, not customer case studies. Product availability and coverage are described on the linked capability pages.
A software bill of materials (SBOM) is a machine-readable inventory of the components inside a piece of software: each package, its version, its supplier, a unique identifier and how it relates to the others. It records what an artefact contains, so that when a new vulnerability is published you can answer whether you shipped it using retained inventory, with further analysis when coverage is incomplete.
Most teams meet SBOMs as a procurement request: a customer’s security questionnaire asks for one, and someone exports a file the night before the deadline. This guide explains what an SBOM should contain, how the two main formats differ, where in the pipeline to generate one, and how VEX turns a component list into a useful answer.
The worked example is a team shipping a payments API as a container image. A large customer’s procurement team has asked for an SBOM with every release, and the team’s own security lead wants to know which releases are affected the next time a widely used library has a critical advisory.
An SBOM records composition, not vulnerabilities
An SBOM lists what is in the artefact. It does not, on its own, say what is wrong with it. The US National Telecommunications and Information Administration published a set of minimum elements in 2021 that provide a widely used historical baseline: supplier name, component name, version, other unique identifiers such as a package URL, the dependency relationship, the author of the SBOM data and a timestamp.
For the payments API, that means the base image’s operating system packages, the language runtime, every direct and transitive library, and the relationships between them. Vulnerability status is derived later by matching those components against advisories. That separation is the point: the SBOM records the inventory known at generation time, while vulnerability knowledge changes every day. The difference between this inventory and the scanning that judges it is covered in SCA vs SBOM.
CycloneDX vs SPDX: two SBOM formats with different origins
Two formats dominate. CycloneDX is an OWASP project designed for security use cases, and it is also published as an Ecma International standard. SPDX comes from the Linux Foundation, started with licence compliance in mind, and an earlier version is published as ISO/IEC 5962. Both are widely supported by generators and consumers, and both can express the minimum elements.
| Aspect | CycloneDX | SPDX |
|---|---|---|
| Steward | OWASP | Linux Foundation |
| Original focus | Security and supply chain | Licence compliance |
| Encodings | JSON, XML, Protocol Buffers | JSON, YAML, tag-value, RDF |
| VEX support | Built into the format | Security profile in SPDX 3.0 |
| Typical consumer | Security tooling | Legal and open-source offices |
In practice the choice is usually made by the consumer. If the customer’s procurement portal accepts SPDX, send SPDX. The safest position is to generate from one source of truth and export either format on request, rather than running two generators that disagree.
Generate the SBOM from the built artefact, not the manifest
An SBOM can be produced from source manifests, from the build, or from the finished artefact. Manifest-based generation misses anything the build adds: operating system packages from the base image, vendored code, and libraries pulled in by build scripts. For a container, the most accurate SBOM comes from scanning the image that was actually pushed, identified by its digest.
For the payments API, that means generating the SBOM in CI after the image build, keyed to the image digest, and keeping it alongside the release. A tag such as latest can be moved to a different image tomorrow; a digest cannot. An SBOM tied to a tag describes whatever the tag pointed at when someone last looked.
VEX communicates a product-specific assessment
An SBOM that lists a vulnerable library invites a question the SBOM cannot answer: does the vulnerability affect this product? Vulnerability Exploitability eXchange (VEX) is the answer format. A VEX statement names a product, a vulnerability and a status: not affected, affected, fixed or under investigation, and a not-affected status carries a justification such as the vulnerable code not being present or not being reachable.
CISA has published guidance on VEX use cases and minimum requirements. VEX can be carried inside CycloneDX, or as a separate document in OpenVEX or CSAF. For the payments team, VEX is what stops every advisory turning into a customer support thread: the customer’s scanner flags the library, and the VEX statement explains that the vulnerable function is never called.
An SBOM is only useful if you can query it later
The value of an SBOM arrives months after it is written, on the day a new advisory lands. If the files sit in a release bucket nobody can search, the security lead still has to rebuild and re-scan old images to answer which releases are affected. If SBOMs are stored as queryable data and linked to the workloads running each digest, the answer is a lookup, as described in new CVE response: use SBOMs to find which images shipped it.
Key takeaways
- Generate the SBOM from the built image after CI pushes it, and key it to the image digest rather than the tag.
- Produce both CycloneDX and SPDX from one source of truth so the consumer chooses the format, not your tooling.
- Publish VEX statements with a justification whenever a listed vulnerability does not affect the product.
- Store SBOMs as queryable data linked to running workloads, not as files in a release bucket.
How SecurityVault approaches this
SecurityVault retains generated SBOMs for export and comparison, with supported CycloneDX and SPDX outputs. VEX workflows let teams record a product-specific vulnerability assessment and its justification. Review inventory completeness, product identity and supporting evidence before publishing a not-affected statement; an unobserved call path alone is not a universal guarantee.
During evaluation, export an inventory for a known release and validate that your intended consumer can parse it. Check package identifiers, version information, relationships and any missing fields rather than relying on the file extension alone. Compare two releases and review whether the changes match the build record. For VEX, ask the authorised reviewer to document the product scope, assessment date and justification. This gives procurement and engineering a shared process for producing useful release evidence without presenting generated metadata as an independent assurance of completeness.
Explore SCA, SBOM and VEX or talk to our team about an evaluation with your engineering, security and compliance stakeholders.