Scanning one SBOM with two tools removes the input as a variable, so any remaining difference comes from advisory data, matching rules or how each tool reads the SBOM. It is a clean way to see data differences, but it cannot add packages the SBOM never listed.
What stays the same
The component list. Both tools start from the same names, versions and, if present, package URLs. A package absent from the SBOM stays invisible to both. This is the main limit of the method, and it is worth saying out loud: the SBOM is only as complete as the process that built it.
What can still differ
| Factor | Why results shift |
|---|---|
| Identifier used | A tool may match on package URL, another on name and version, another on a CPE style name |
| Advisory source | One tool reads reviewed advisories, another a wider feed |
| Range logic | Version comparison rules differ at the edges |
| Handling of missing fields | An entry without a package URL may be skipped by one tool and guessed by another |
| Data timing | The two tools may have ingested a new advisory on different days |
The Package-URL introduction says a purl is a standard URL based syntax to identify software packages, independent from their ecosystem or distribution channel. If your SBOM carries a purl for each component, matching becomes more consistent between tools. If it does not, expect more disagreement.
A procedure
- Check the SBOM first. Count components, and count how many have a package URL and a version. A component without a version cannot be matched reliably.
- Run both tools on the identical file. Record the file hash so the input is provable.
- Export results and normalize. Use one key, such as the package URL plus advisory ID.
- Bucket differences. Identifier issue, advisory source, range logic, missing fields, timing.
- Investigate a sample. Read the advisory for each sampled difference and decide who is right.
- Fix the SBOM if needed. Missing versions or identifiers are generator problems, not scanner problems. Correct them upstream.
What this tells you about your generator
If both tools struggle with the same components, the likely cause is the SBOM. Entries with no version, odd names, or no identifier tend to get skipped or mis-matched. Fixing those entries at the source helps every consumer of the SBOM, including customers who receive it.
If the tools agree on the SBOM but disagree on your source scan, the difference lies in how each tool builds its own component list. That points back to the input files, scope and resolution rather than advisory data.
Do not mistake agreement for completeness
Two tools can agree on a list that is missing a package. Compare the SBOM against the built artifact from time to time, for example by checking that the number of installed packages in the image matches the number in the SBOM.
Try it yourself
Click through it at your own pace, or open it full screen. Check that each component shows a name and exact version, which is what any scanner needs to match an advisory.
Quick check
If I scan an SBOM, am I scanning my software?
You are scanning the list the SBOM claims. If the list is incomplete, so is the scan.
Do package URLs reduce disagreements?
They help, because tools can match the same identifier. They do not remove differences in advisory data.
Sources
Last reviewed: 19 October 2026.
