With Docker BuildKit, add an SBOM attestation at build time using the sbom shorthand or the attest option, then inspect the SPDX output. By default only the final stage of a multi stage build is scanned, so decide whether you also need build stage dependencies.
The commands
Docker's documentation shows how to attach an SBOM when building and pushing an image:
docker buildx build --tag namespace/image:version --attest type=sbom --push .
The shorthand is the sbom flag set to true. To look at the result before pushing, export it locally:
docker buildx build --sbom=true --output type=local,dest=out .
This writes the SBOM to out/sbom.spdx.json. The format follows the SPDX standard, attached to the image as a JSON encoded SPDX document in the in-toto SPDX predicate format.
What is in it
According to the same page, the examples include OS packages installed through apt and language dependencies such as a Go module with a package URL. The page does not give a full list of package types, so test with your own stack and read the output rather than assuming coverage.
By default the SBOM is produced by a scanner plugin that ships with BuildKit, and you can choose a different generator with the generator option.
The multi stage catch
Docker states that by default only the final stage of a multi stage build is scanned, and the SBOM does not include build time dependencies installed in earlier stages. To widen scope, declare an ARG named BUILDKIT_SBOM_SCAN_CONTEXT to scan the build context, or BUILDKIT_SBOM_SCAN_STAGE to scan additional stages. Stage scanning only covers stages that are actually built.
| Question | Where the answer sits |
|---|---|
| What shipped in the final image? | Default SBOM |
| What tools built it? | Extra stage scan |
| Which files did the build copy in? | Build context scan |
Which one you need depends on the audience. Customers asking for an SBOM want what they receive. An internal security review of the build pipeline wants the build tools too. For the reasoning behind multi stage builds, see multi stage builds shrink the attack surface.
Keep it useful
- Generate the SBOM in CI on every build, and store it with the image digest.
- Re-scan old SBOMs against new advisories. An SBOM is an inventory, and advisories arrive after you ship.
- Record statically linked components too. See why statically linked binaries ignore apt upgrades.
- Use the inventory to answer "are we affected?" questions fast, as in find Log4j everywhere: inventory before patch.
Try it yourself
Click through the inventory view and see how components group by type and source.
Click through it at your own pace, or open it full screen.
Check the output, do not trust the count
After generating an SBOM, open the file and spot check it. Pick three packages you know are in the image and confirm they appear with the right version. Pick one dependency from your application and confirm it too. If any are missing, your inventory has a gap, and any scan that uses it will have the same gap.
Quick check
Which format does the BuildKit SBOM use?
SPDX, attached as a JSON encoded document in the in-toto SPDX predicate format.
Does it include build tools from earlier stages?
Not by default. Set the stage scan argument if you need them.
Safeguard generates and analyses SBOMs and dependency inventories, and you can start with a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
