Use the final image SBOM to answer what you shipped and what customers run. Add build stage coverage when you need to know which compilers, tools and base layers touched the build. They answer different questions, so decide which one a reader needs before choosing, and say which one you are sharing.
Two questions, two scopes
A multi-stage build compiles in one image and copies only the result into a smaller final image. That means the software present during the build is not the software present at runtime.
| Question | Right scope |
|---|---|
| What vulnerable packages could be running in production? | Final image |
| What did we hand to the customer? | Final image |
| Which build tools and base images were involved in making it? | Build stages |
| Could a compromised build tool have affected the output? | Build stages |
Docker's documentation on SBOM attestations makes the second point directly: indexing the contents of an image during the build has benefits over scanning a final image, because you can detect software you used to build the image, which may not show up in the final image.
How the build tool handles it
BuildKit based builds can attach an SBOM attestation to the image. The documented switches are an attest option of type sbom, or a shorthand sbom flag, on the build command. By default, the scan covers the final stage. The documentation says that to scan more than the final stage, you set an argument called BUILDKIT_SBOM_SCAN_STAGE to true, globally or in specific stages, and that to scan the build context you set BUILDKIT_SBOM_SCAN_CONTEXT to true. These must be declared as ARG instructions in the Dockerfile to take effect.
The generated SBOMs follow the SPDX standard and attach to the final image as a JSON encoded document, according to the same page. You can inspect them with the imagetools inspect command and read the SBOM attribute.
A decision guide
- Publishing to customers or regulators: share the final image SBOM, since it describes the delivered artifact.
- Investigating a build tool advisory: turn on stage scanning for that build and check which stages used the tool.
- Keeping an internal record: keep both, labelled, so an incident responder can see the build and the result.
- Using a base image from outside: record its identity in the SBOM or provenance so a reader can trace it.
Mistakes to avoid
- Mixing scopes without saying so. A stage SBOM listing a compiler looks alarming to a customer who assumes it shipped.
- Assuming the final image has no build residue. Copy steps can bring unwanted files across. Scan the final image as it will run.
- Scanning only the source. A source SBOM misses operating system packages from the base image.
Try it yourself
Click through it at your own pace, or open it full screen. Look at which findings come from the base image and which come from the application layer.
Where Safeguard fits
Safeguard scans container images for vulnerable packages and produces SBOM output. Try the free scan at gold.safeguard.sh/scan and compare what it reports for the image you ship.
Quick check
Do build tools belong in the customer SBOM?
Usually no, if they are not in the delivered image. Keep that detail in an internal build record.
Is scanning the final stage the default in BuildKit?
According to Docker's documentation, yes, and other stages need BUILDKIT_SBOM_SCAN_STAGE set.
Sources
Last reviewed: 19 October 2026.
