Two scanners disagree on the same image because they read different package databases, use different advisory sources, match versions by different rules, count duplicates differently and treat unfixed or disputed findings differently. A different total is not proof that one is wrong. Compare the findings one by one.
The usual causes
A container image is a stack of layers described by a manifest, as the OCI image specification lays out. A scanner unpacks those layers, finds installed packages, and looks each one up in advisory data. Every step has choices.
| Source of difference | What happens |
|---|---|
| Package detection | One tool reads only the OS package database, another also finds language packages and loose binaries |
| Advisory source | Distro security trackers, a national database and ecosystem advisories each list different things |
| Version matching | A distro backports a fix without changing the upstream version number, so a naive match reports a false hit |
| Unfixed findings | Some tools hide issues with no fix by default, others show them |
| Severity | Vendor severity and base CVSS score can differ for the same CVE |
| Deduplication | One CVE found in three layers may count once or three times |
| Database freshness | A scan from this morning and one cached last week see different advisories |
Backports are the biggest trap
Distributions often patch an older upstream version rather than upgrading it. The package keeps a version string that looks vulnerable to a tool that compares only upstream numbers. A scanner that reads the distro's own security data knows the fix is in. One that does not will report a finding that is already resolved. When two tools differ by dozens of OS package findings, check this first.
How to run a fair comparison
- Pick three images: one you built, one vendor image, one old image you know is stale.
- Scan the same image digest, not a tag, so both see identical bytes.
- Update each tool's database immediately before the run and record the date.
- Export results as JSON and compare by CVE id plus package name plus installed version.
- Sort the differences into four piles: only in A, only in B, same CVE with different severity, same finding counted twice.
- Sample ten items from each pile and verify them against the distro tracker or the upstream advisory.
Write down the result as precision (how many reported items were real) and coverage (how many known issues each tool found). A single total hides both.
What to do with the differences
If a finding appears in only one tool, do not average. Decide which source you trust for that package type. For OS packages, the distro's own tracker is usually the authority. For language packages, the ecosystem advisory plus reachability evidence matters more. Our post on why scanners disagree on severity covers the scoring side.
Try it yourself
Click through it at your own pace, or open it full screen.
Click into a finding and look at which package and layer it came from. That is the evidence you need to compare tools.
Safeguard scans dependencies and SBOMs and applies policies and gates to the results; you can run a free scan at gold.safeguard.sh/scan and compare it with what you use today.
Quick check
Is the scanner with the higher count better?
No. A higher count can mean broader coverage or more false positives. Verify a sample of findings before judging.
Should I compare scans by image tag?
Compare by digest. Tags move, so two scans by tag may have looked at different images.
Sources
Last reviewed: 19 October 2026.
