Generate an SBOM on every build, because it costs seconds and cannot be recreated reliably later. Store each one against the image digest. Share and retain differently: keep SBOMs for released and deployed digests for as long as you support them, and let SBOMs for throwaway CI builds expire with the images.
Why generate every time
An SBOM describes a specific artifact. CISA describes an SBOM as a nested inventory, a list of ingredients that make up software components. If you wait until a customer asks, you must rebuild a historical image or guess what it contained. Neither is reliable, especially if the base tag has moved since.
Generating at build time also means the record comes from the build itself. The Docker documentation on SBOM attestations shows BuildKit producing an SBOM as part of the build, with a single option, and attaching it to the image. By default it scans only the final stage, so build-only tools in earlier stages do not appear. That matches what ships.
Three decisions to make
| Decision | Options | A sensible default |
|---|---|---|
| When to generate | Every build, release only | Every build |
| Where to store | Attached to the image, separate store | Both, keyed by digest |
| What to retain | Everything, released only | Released and deployed, plus rollback window |
Storing by digest matters. A tag can move, and an SBOM linked to a tag can end up describing a different image than the one it was generated for.
What to retain, and for how long
Keep the SBOM for as long as the image can still run or be redeployed, plus any period your contracts or auditors require. Ask your auditor for the figure and write it into your retention policy, since we cannot tell you what yours needs. For CI builds that never leave the pipeline, retention equal to the image retention is fine.
What to share externally
Not every SBOM is a customer deliverable. Publish or send SBOMs for released versions, and think about the format your recipient wants. See the comparison of SBOM sharing patterns.
Check the output before you rely on it
Validate that the file lists what you expect. The Docker page recommends validating the generated SBOM before pushing, using a local export. Look for:
- Operating system packages from the base image.
- Language packages from the application layer.
- Versions present, not blank.
- A reference to the image digest or name.
If package counts look low, your image may lack package metadata. See what a container image SBOM contains and misses.
Try it yourself
Click through it at your own pace, or open it full screen.
Open a component in the demo and note the package name, version and source, the fields an SBOM should always carry.
Where Safeguard fits
Safeguard produces SBOM and dependency inventory per image and keeps findings tied to them. The free scan will show the inventory for one of your images.
Quick check
Is an SBOM per build too much storage?
Usually not. SBOMs are small text files. The cost is in deciding retention, so expire the ones for images you delete.
Can I generate the SBOM after the image is built?
Yes, by scanning the image, but a build-time SBOM is better for provenance. Either way, key it by digest.
Sources
Last reviewed: 19 October 2026.
