Neither is automatically right. They usually describe different things: a build input versus a delivered artifact, a source tree versus a binary, or two different versions. Compare scope, version and method first, then treat each difference as a question for the supplier, not as proof of error.
Why they differ
An SBOM is data assembled at a point in time by a particular author with a particular method. The NTIA minimum elements report records the author of the SBOM data and a timestamp for exactly this reason. Two lists made by different authors at different times can both be honest and still disagree.
Common causes:
- Different versions. The supplier described the latest release; you scanned the one you run.
- Different stage. One list comes from source and lockfiles, the other from the built package or container image.
- Different depth. One tool includes transitive and operating system packages, the other stops at declared dependencies.
- Different naming. The same library appears under two identifiers and looks like two components.
- Real omissions. A component is present in the shipped software but missing from the supplier list.
Step by step
- Confirm both describe the same product and version. Compare the hash or file name of the artifact you scanned against what the supplier states.
- Check the timestamps. If the supplier file is older than the artifact, ask for a newer one.
- Note the method on each side: source, build, image or binary analysis.
- Normalize identifiers. Compare by package URL where available, not by display name.
- Sort differences into three groups: in the supplier list only, in your scan only, and in both with different versions.
- Send the supplier the groups with a short question for each.
What each group usually means
| Difference | Likely cause | Question for the supplier |
|---|---|---|
| Supplier only | Build tooling, dev dependencies, or a different release | Is this shipped to customers? |
| Your scan only | Transitive or OS packages the supplier did not list | Does your SBOM include these levels? |
| Both, versions differ | Different release or a patched build | Which version do we run? |
If your scan finds components the supplier never listed, that is not proof of bad faith. The NTIA report asks consumers to be tolerant of good-faith errors and says suppliers should issue revised SBOMs when they learn of mistakes. It also says the tolerance should not extend to intentional obfuscation. Use the response to the question, not the discrepancy alone, to tell the difference.
Which to rely on in the meantime
For risk decisions, use the union. If either source says a vulnerable component is present, treat it as present until someone shows otherwise. For records you keep, store both with their dates and methods so you can explain later why they differed.
Try it yourself
Click through it at your own pace, or open it full screen. Notice that a scan of a built image lists operating system packages that a source-level list would not.
Safeguard's SBOM and dependency scanning can scan what you actually received, and the free scan is at gold.safeguard.sh/scan.
Quick check
If our scan finds more components, is the supplier SBOM wrong?
Not necessarily. It may cover a different stage or depth. Ask the supplier which method they used and whether OS and transitive packages are included.
Should we store both lists?
Yes. Keep each with its timestamp and method so you can explain differences later.
Sources
Last reviewed: 19 October 2026.
