When one scanner flags a package and another stays silent, treat the finding as unconfirmed, not wrong. Check whether both tools saw the same package and version, whether the advisory lists your version as affected, and whether the finding applies to code you ship. Then record the decision.
Start with the question, not the verdict
A gap between two tools is a prompt to ask why, not a vote. Either tool can be right for a reason that has nothing to do with quality. The tools may have read different files, used different advisory sources, or counted different kinds of dependencies.
Work through the steps below in order. Most disagreements are settled by step 2 or 3.
The five checks
- Same package, same version? Pull the package name and exact version from both reports. If one tool shows 4.17.20 and the other shows 4.17.21, you have found the cause already. Look at which file each tool read, because a manifest and a lockfile can name different versions.
- Same package identity? Names can be written differently across tools. Python names, for example, are compared after lowercasing and collapsing runs of dots, dashes and underscores into a single dash, according to the Python Packaging specification. A tool that skips that step can miss a match.
- Does the advisory list your version? Read the advisory itself. Check the affected range and the fixed version. A tool may be using an entry with a narrower or wider range.
- Is the package in the shipped artifact? A test only or build only dependency may appear in one report and be filtered out of the other.
- Is the vulnerable code reachable? A present package is not the same as an exploitable one. This is a priority question, not a correctness question.
What each outcome means
| Outcome after checks | What it usually means | What to do |
|---|---|---|
| Versions differ between tools | Different input files | Align on the lockfile or the built artifact |
| Names differ in format | Identity mismatch | Normalize names before comparing |
| Advisory ranges differ | Different data entries | Read the advisory, decide, record |
| One tool includes dev scope | Scope setting differs | Pick a policy and apply it to both |
| All checks agree it is real | A true gap in the quieter tool | Fix, then note the gap |
Do not average the two tools
It is tempting to treat a finding as real only if both tools agree. That rule hides true positives that one tool saw first. It also rewards the tool with the weaker database. A finding needs evidence, and agreement is only one kind.
A better rule is to keep every finding open until someone has written down one of three outcomes: confirmed and fixed, confirmed and accepted with a reason and an expiry, or not applicable with the evidence. That record is what an auditor or a customer reviewer will ask for later.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how each package carries an exact version, because that is the first thing to compare between two reports.
Where Safeguard fits
Safeguard produces an SBOM and dependency scan with reachability analysis, so a finding arrives with its exact package, version and a view of whether the vulnerable code is called. You can try a free scan at gold.safeguard.sh/scan and compare it with your current tool.
Quick check
If both scanners disagree, should I fix the package anyway?
If the advisory lists your exact version as affected and the package ships, yes, in priority order. Disagreement does not lower the risk. It only means one tool needs a closer look.
Is the scanner that reports more findings the better one?
No. More findings can mean broader coverage or more noise. Compare on confirmed findings, not on totals.
Sources
Last reviewed: 19 October 2026.
