Diff the two SBOMs by package identifier, sort every difference into an expected cause or a problem, and record the result. Components only in the source SBOM are usually build or test dependencies. Components only in the image are usually operating system packages or files copied in by hand.
Why they differ
A source SBOM describes what your project declares. An image SBOM describes what is inside the artifact you built. Neither is wrong, but they answer different questions, and a mismatch is information.
| Appears in | Typical meaning |
|---|---|
| Source only | Dev, test or build tool dependencies that were not packaged |
| Image only, operating system | Packages from the base image |
| Image only, language | A package installed by a Dockerfile step, not by your manifest |
| Both, different versions | A version resolved differently at build time, or a stale lockfile |
| Both, same version | Expected |
The third and fourth rows are the ones to chase. A language package in the image that your manifest never mentioned came from somewhere, and a version mismatch means the artifact does not match the source you reviewed.
Reconciliation steps
- Generate both SBOMs for the same commit, and pin the base image by digest.
- Normalise identifiers so the same package matches. Package URLs help, as they separate type, namespace, name and version.
- Produce three lists: in both, in source only, in image only.
- For each source only item, check its scope. Dev and test scope is expected.
- For each image only operating system package, confirm it comes from the base image.
- For each image only language package, find the Dockerfile line or script that added it. Decide whether it should be in your manifest.
- For each version mismatch, find out why the build resolved it differently.
Record the outcome
Keep a short reconciliation note with the release. It should contain the commit, the image digest, the counts for each list, and the explanation for every item that is not obvious. If everything matches your expectations, say so in a sentence. If something does not, say what you did about it.
Which SBOM to give a customer
Pick the one that answers their question and say which it is.
- A customer running your container wants the image SBOM.
- A customer building from your source wants the source SBOM.
- A regulator or auditor may want both, with the reconciliation note.
Giving both without explanation invites questions about the differences, so give the note with them.
Automate it
Run the diff in CI on every release. Fail or warn when an image only language package appears, since that is the strongest sign that something was installed outside your reviewed dependencies. Store the diff output beside the two SBOMs.
Try it yourself
Click through it at your own pace, or open it full screen. Pick a component and check whether it is direct or transitive, as you would when sorting your three lists.
Where Safeguard fits
Safeguard provides dependency scanning and SBOM output for source projects and container images, so you can scan both for one release with the free scan at gold.safeguard.sh/scan and compare the results.
Quick check
Should the two SBOMs ever match exactly?
Rarely. Expect differences from scope and the base image, and explain them.
What is the most worrying difference?
A language package in the image that is absent from your manifest, because it was added outside normal review.
Sources
Last reviewed: 19 October 2026.
