Two SBOMs for the same image can differ because they scanned a different scope, used different tools, used different formats, or ran at different times. A difference is a prompt to check, not proof that something is wrong. Compare them by image digest first, then work through the causes below.
Cause one: scope
Docker documents that, by default, BuildKit only scans the final stage of an image. The resulting SBOM does not include build time dependencies installed in earlier stages or ones in the build context. It describes build arguments that widen the scope.
So a build time SBOM generated with widened scope can list far more than one generated from the finished image in a registry. Neither is wrong. They answer different questions: what went into the build, and what is in the artifact.
Cause two: the tool
Different generators detect packages differently. One may read operating system package databases only. Another may also find language packages by reading manifest files, or may inspect binaries. A package installed without a package manager, such as a binary downloaded in a Dockerfile, may appear in one and not the other.
Cause three: the format
SBOM formats such as SPDX and CycloneDX describe components with different fields. Docker's tooling writes SPDX JSON in its example output. When you convert between formats, some fields map cleanly and some do not. Comparing counts across formats is risky, since one component may become two entries.
Cause four: timing and identity
An SBOM lists what is in the image, which does not change for a given digest. But an SBOM generated for a tag at two different times may describe two different images, since the tag moved. Always compare by digest. If the digests differ, you are comparing different images and the SBOMs should differ.
A comparison routine
| Step | Question |
|---|---|
| 1 | Are both for the same digest? |
| 2 | Were both generated with the same scope, including build stages? |
| 3 | Were both generated with the same tool and version? |
| 4 | Are both in the same format, or was one converted? |
| 5 | Of the packages that differ, where do they live on disk? |
Step five usually explains the rest. Differences cluster in one place, such as a language directory or a downloaded binary.
What to do about it
Pick one generator and one scope as your standard so that records are comparable over time. Keep any widened build scope SBOM as a separate artifact with a clear name. When a customer or auditor asks, say which one you are giving them and why.
Validate the standard on a few images by hand. If the SBOM says an image has no packages, check whether it is a scratch image or whether the scan saw nothing.
Where Safeguard fits
Safeguard generates SBOMs for container images with a consistent scope and keeps them by image, so comparisons over time come from the same method. The free scan at https://gold.safeguard.sh/scan lets you see the output.
Quick check
Which SBOM should I trust more?
Neither blindly. Trust the one whose scope matches your question, and confirm by digest.
Is a bigger SBOM a better one?
Not automatically. A larger list may include build time items that never shipped. Match scope to purpose.
Sources
Last reviewed: 19 October 2026.
