Generate the image SBOM at build time, tie it to the image digest, and also regenerate or rescan from the registry on a schedule. The build gives you the most context. The later pass catches what changed in advisories and in anything built outside your pipeline.
Three points, three jobs
| Point | What you get | Weakness |
|---|---|---|
| During the build | Rich context: stages, build arguments, source link | Only covers images built this way |
| After push, from the registry | Covers any image that arrives, whoever built it | Less build context |
| On a schedule, for deployed images | Shows what is running today | Needs a way to list running images |
Use all three for different reasons rather than picking one.
What BuildKit does by default
Docker documents SBOM attestations in its build tooling. You request one by passing the SBOM attest option to the build command, or a shorthand flag. By default, BuildKit only scans the final stage. The resulting SBOM does not include build time dependencies installed in earlier stages, or those in the build context. Docker describes build arguments that widen the scan to include them.
That default is often what you want for a deployed image, because earlier stages do not ship. But if you need to know what went into the build, widen the scope and keep both records.
Validate before you push
Docker advises checking the generated SBOM before you push. You can build with the local exporter, which writes the attestation to a file in the export directory instead of creating an image, and read it. Make this check part of the pipeline for new services. An empty or tiny SBOM usually means the scan saw nothing useful, such as a scratch image, and that is worth knowing early.
Key it by digest
Whatever you generate, store it with the image digest, not the tag. Tags move. A digest identifies exact content, so "the SBOM for this digest" stays true. Include the build timestamp and the pipeline run so you can trace it.
Why later passes still matter
An SBOM is a list of what is inside. The list does not change after the build, but what is known about those components does. A new advisory can make an old SBOM interesting. Rescanning stored SBOMs against new data answers that without a rebuild. Separately, a registry pass finds images pushed by people who did not use your pipeline.
A workable setup
- Turn on SBOM generation in the build for every image.
- Validate the SBOM exists and has content before push.
- Store it next to the image digest, either attached in the registry or in your artifact store.
- Run a scheduled scan of the registry to catch strays.
- Rescan stored SBOMs when advisories arrive.
Where Safeguard fits
Safeguard generates SBOMs for container images and dependencies, scans them, and keeps monitoring stored inventory as new advisories arrive, so the three points above feed one record. The free scan at https://gold.safeguard.sh/scan lets you see the output for one image.
Try it yourself
Click through it at your own pace, or open it full screen. Look at what an inventory lists per component, which is the record an image SBOM stores.
Quick check
Is a build time SBOM enough on its own?
It is the richest source of build context, but it does not cover images built elsewhere, and it does not update itself when new advisories appear. Pair it with scheduled rescans.
Does the SBOM include my build tools?
By default the BuildKit scan covers the final stage only, so build stage tools are not included unless you widen the scan.
Sources
Last reviewed: 19 October 2026.
