Why do two scanners report different vulnerability counts?

Two scanners disagree because they read different things, match against different data, and count in different units. One may scan lockfiles and another a built image. One counts each CVE once, another counts it per package and per path. The gap is usually explainable, not a sign that one tool is wrong.

The five usual causes

1. Different scope. One tool scans the repository, another scans a container image, another the running host. Each sees a different set of components. A repository scan may include development dependencies that never ship, and an image scan may include operating system packages that the repository never mentions.

2. Different vulnerability data. Sources include national databases and ecosystem advisories, and tools differ in which they use and how quickly they update. A flaw published this morning may appear in one tool this morning and in another tomorrow.

3. Different matching rules. Matching a package version to an advisory is not trivial. Version ranges, renamed packages and backported fixes can produce a match in one tool and a miss in another.

4. Different counting units. One report lists unique CVEs. Another lists every occurrence, so one CVE in five services counts as five. A third counts per package. The same data can yield wildly different headline numbers.

5. Different handling of context. Some tools hide findings flagged unreachable or fixed in a later layer. Others show everything and let you filter.

A reconciliation method

1. Align scope. Scan the same artifact, such as one image digest, with both tools.
2. Align the unit. Export unique pairs of CVE and component version from each.
3. Diff the lists. Mark what appears in both, only in one, and only in the other.
4. Sample the differences. Check five items from each side by hand against the advisory text.
5. Record the cause. Data lag, matching, scope or context. Keep the notes for next time.

Do not average the two counts or take the larger one. Neither number is the truth. The reconciled list is.

What to do with the result

If most differences come from scope, decide which scopes your program needs and scan them deliberately. If they come from data lag, check how often each tool refreshes its sources. If they come from counting units, choose one unit for reporting and apply it everywhere.

For ranking, use evidence that does not depend on either tool. The CISA KEV catalog lists vulnerabilities exploited in the wild, and EPSS from FIRST publishes a daily exploitation probability for every CVE. Both are keyed by CVE, so they join cleanly to either tool's export.

OWASP's guidance on vulnerable and outdated components recommends continuously inventorying component versions and monitoring sources like CVE and the National Vulnerability Database. Using a consistent inventory as the base makes comparisons far easier.

When the gap signals a real problem

A large gap on the same scope and the same unit, with sampled items showing missed real flaws, means one tool has a coverage problem. Raise it with the vendor with concrete examples.

A worked example

Take one container image and two scanners. Illustrative numbers follow.

• Scanner one reports 40 findings. It counts each CVE once for each affected package, and includes operating system packages in the base layer.
• Scanner two reports 25 findings. It counts unique CVEs only, and its data source updates a day later than scanner one.

Is one tool better? Reconcile them.

1. Align the unit. Export unique pairs of CVE and component version from both. Scanner one now shows 31 pairs, scanner two 25.
2. Diff the lists. 24 pairs appear in both. Seven appear only in scanner one, one appears only in scanner two.
3. Sample the differences. Four of the seven are operating system packages that scanner two excluded by configuration. Two are CVEs published the day before. One is a version matching difference where the distribution backported a fix.
4. Check the single. The one finding only in scanner two is a transitive dependency that scanner one missed.

The result is a reconciled list of 32 unique pairs, with notes on why each tool differed. Neither original number was the truth.

Step by step: build a repeatable comparison

1. Choose three artifacts of different size and language mix.
2. Run both tools on each, the same day.
3. Normalize the export to CVE plus component, version and application.
4. Compute overlap and the two exclusive sets.
5. Sample 5 to 10 items from each exclusive set and verify against the advisory text.
6. Classify causes as scope, data lag, matching, unit or context.
7. Write a one page note you can reuse in future reviews.

Reading the pattern of differences

When to stop comparing

Once you understand the causes and have chosen a tool and a unit for reporting, stop. Running two tools forever doubles triage with little gain unless they cover different artifacts on purpose.

Try it yourself

Scan the sample image and compare the layers that report findings with the application layer.

Click through it at your own pace, or open it full screen.

Where Safeguard fits

Safeguard scans dependencies and generates SBOMs so you have a consistent inventory to compare against, and reachability analysis helps decide which differences matter. A free scan is at gold.safeguard.sh/scan.

Quick check

Sources

• CISA Known Exploited Vulnerabilities Catalog
• FIRST, EPSS
• OWASP Top 10:2021, A06 Vulnerable and Outdated Components

Last reviewed: 19 October 2026.