Your SBOM changes when you switch scanners because tools differ in what they detect, how they name components and what they include, such as dev dependencies or container layers. Before relying on the new output, compare component identifiers, counts by ecosystem and scope between old and new on the same project.
What an SBOM is for
CISA describes an SBOM as a nested inventory, a list of the ingredients that make up software components. If the list changes with the tool, customers and auditors comparing your documents over time will notice, so it is worth understanding why.
Common reasons for differences
- Detection method. Reading a lockfile, reading a build, or inspecting an image produce different lists.
- Scope. Whether development and test dependencies are included. See dev dependencies in a CycloneDX SBOM.
- Naming. The same package can be written differently unless a standard identifier is used. The package URL specification exists so that tools name the same package the same way across formats and vulnerability databases.
- Transitive depth. How deep the tree is resolved.
- Format and version. Output differences between spec versions. See CycloneDX versus SPDX.
How to compare
- Pick two or three projects and generate an SBOM from each tool at the same commit.
- Normalize to package URLs where possible and diff the two lists.
- Group differences: only in old, only in new, same package different version.
- Investigate a sample of each group in the lockfile or image.
- Decide which tool is right for each difference and why.
| Difference | Likely cause | Action |
|---|---|---|
| Only in old | New tool misses a source, or old over-reports | Verify in the build |
| Only in new | Deeper resolution or image layers | Likely an improvement |
| Same name, different version | Resolution method | Check lockfile |
| Different identifiers | Naming | Normalize to package URLs |
Tell customers when the format shifts
If you share SBOMs, add a short note when the generator changes: which tool, which version, what the scope is. Check output quality as in evaluating SBOM quality before you buy.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the inventory and look at how each component is identified and where it comes from. Those are the fields to compare.
Sources
Quick check
Is a bigger SBOM always better?
No. It may include out of scope items. Accuracy and a clear scope matter more than count.
Do vulnerability counts change too?
Yes, since they follow the component list and the advisory sources each tool uses.
Safeguard covers SBOM and dependency scanning, reachability analysis, policies and gates, and compliance evidence automation. You can try a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
