A container image SBOM is a machine-readable inventory of the components inside an image: OS packages, language libraries, and usually names, versions, package URLs and hashes. It can miss statically linked code, vendored copies, files copied in without a package manager, and anything fetched at runtime.
What it usually contains
CISA describes an SBOM as a nested inventory, a list of the ingredients that make up software components. For an image, the entries typically include:
- OS packages from the distribution's package database
- Language packages found in lockfiles or installed directories
- Package URLs (purl) that identify each component by ecosystem, name and version
- Hashes of components, where the tool can compute them
- The image itself, which CycloneDX models with a component type of container
What it tends to miss
| Gap | Why it happens |
|---|---|
| Statically linked libraries | The code is inside a binary, with no package record |
| Vendored source | Copied into the tree, not installed by a manager |
| Binaries downloaded by a build step | curl into /usr/local/bin leaves no database entry |
| Packages removed from the database but left on disk | The inventory and the filesystem disagree |
| Runtime downloads | Not present when the image is analyzed |
| Layers you cannot read | Encrypted or missing blobs |
None of these gaps are hypothetical. They are the reason an SBOM should be treated as a strong starting point rather than a guarantee.
Where in the lifecycle you generate it
Teams distinguish SBOM types by when they are produced: design, source, build, analyzed, deployed, runtime. Our post on six SBOM types explains the differences. For images, the useful pair is a build SBOM from your pipeline plus an analyzed SBOM from scanning the final image. Compare them. Differences point at packages added late.
Format choice
Both CycloneDX and SPDX can describe an image. Pick the one your consumers can read and stay consistent. See CycloneDX vs SPDX.
Make it useful
- Generate the SBOM from the final image, by digest.
- Store it keyed by digest so you can search it later.
- Attach it to the image in the registry so consumers can fetch it.
- Refresh it when you rebuild, and keep the old one for audit.
Try it yourself
Click through it at your own pace, or open it full screen.
Open a component and check what fields the inventory records for it.
Safeguard generates and scans SBOMs and dependency inventories; you can start with the free scan.
Quick check
Does an SBOM list vulnerabilities?
No. It lists components. Vulnerabilities come from matching those components to advisory data, and VEX statements can say which ones are exploitable.
Is one SBOM per image enough?
One per digest, yes. A new build is a new digest and needs its own SBOM.
Sources
Last reviewed: 19 October 2026.
