An SBOM (Software Bill of Materials) is your software’s “ingredient list”: the complete inventory of packages, libraries, versions and dependencies an image contains. Like a nutrition label, it tells you exactly what is inside.
Its value becomes obvious on the day of a critical vulnerability: instead of manually tracking dozens of images, you query the SBOM and know in seconds which images contain the affected component and at what version.
Why it matters for your images
- Fast CVE response: you instantly identify whether a new vulnerability affects you.
- Supply chain security: you know where every component comes from.
- Compliance: more and more frameworks and customers request it as evidence.
- Transparency: if you publish images, an SBOM builds trust with whoever uses them.
Standard formats
| Format | Origin | Notes |
|---|---|---|
| SPDX | Linux Foundation / ISO | ISO standard, widely used in compliance |
| CycloneDX | OWASP | Security oriented, rich for vulnerability analysis |
The two dominant SBOM formats; many tools export to both.
How to generate an image SBOM, step by step
- Choose the tool: Syft, from Anchore, is a de facto standard for generating SBOMs of images and filesystems; there are cloud-native options too.
- Generate it in the pipeline: during the AMI build, scan the filesystem and produce the SBOM, for instance in CycloneDX and SPDX.
- Analyse vulnerabilities: run the SBOM through Grype or Trivy to cross-reference it with CVE databases.
- Sign and archive: sign the SBOM —with cosign, for instance— and store it as an artefact tied to the image version.
- Query it when needed: when a new CVE appears, check your archived SBOMs to establish the scope.
The regulatory context of 2026
SBOMs have been gaining weight for years as a supply chain security good practice. The regulatory picture, however, is nuanced: in the United States the administration revised inherited software attestation mandates in 2026 towards a more risk-based approach, while in the European Union rules such as the Cyber Resilience Act push software transparency and component inventories. Practical conclusion: regardless of regulatory swings, having SBOMs is a defensive and commercial advantage worth adopting.
Best practices
- Generate the SBOM automatically on every build, not by hand.
- Store it versioned alongside the image it belongs to.
- Combine it with vulnerability scanning so it is actionable.
- Sign it to guarantee its integrity and provenance.
Frequently asked questions
Is an SBOM the same as a vulnerability scan?
No. The SBOM is the component inventory; the scan cross-references that inventory with CVE databases to find vulnerabilities. They complement each other: first you know what you have, then whether it is vulnerable.
SPDX or CycloneDX?
SPDX is an ISO standard widely used in compliance; CycloneDX is more security oriented. Many tools export to both, so you do not have to pick just one.
Do I need an SBOM if I only consume third-party images?
Yes. Requesting or generating the SBOM for the images you use lets you assess their risk and respond quickly to vulnerabilities, even if you did not build them.
At imaxe.cloud we bet on traceability: inventorying and documenting the software in our images is part of building them well.
