Two scanners disagree because they look at different things, in different ways, with different data. One reads source, another probes a running app, a third matches package versions. Disagreement is often expected, not a defect. Reconcile by method, scope and evidence before deciding which to believe.
Cause 1: different vantage points
Static analysis reads code without running it. Dynamic scanning looks from outside at a running app. OWASP describes dynamic scanners as examining web applications "normally from the outside", and static tools as analysing source or compiled code. A flaw in a code path no request reaches appears in the first and never in the second. A misconfigured header appears in the second and not in the first, since configuration is not represented in code.
Cause 2: different scope
One tool may scan the main repository while another scans the deployed container. The deployed image can include packages and a base operating system the repository never mentions. Always compare what each tool was pointed at.
Cause 3: different data sources
Dependency scanners match components against advisory databases. Databases differ in coverage, update speed and how they describe affected versions. Two tools can legitimately disagree on whether a version is affected, especially for newly published flaws.
Cause 4: different rules and thresholds
Each tool has its own rules, severity labels and confidence settings. A finding one tool calls high, another may call medium or suppress. Compare the underlying weakness type, not the label.
Cause 5: different versions and timing
A scan from Tuesday and a scan from Friday see different advisory data. A scan before a dependency update differs from one after. Check timestamps and versions first.
How to reconcile
- Normalise. Export findings in a common format and map each to a weakness type or advisory ID.
- Group by component or location. Put findings about the same package or file side by side.
- Classify each mismatch using the five causes above.
- Verify a sample. Pick a few findings that only one tool reports and test them by hand.
- Record the decision so the next person does not repeat the investigation.
| Mismatch | Likely cause | Action |
|---|---|---|
| Only static tool reports a code flaw | Unreachable path, or true positive in unused code | Check reachability |
| Only dynamic tool reports a header issue | Configuration, not code | Fix in server settings |
| Packages differ between tools | Repository versus image scope | Align scan targets |
| Same package, different verdict | Advisory data differs | Check the primary advisory |
Should you keep both?
Often yes. Disagreement that traces to different vantage points means each tool contributes coverage. Disagreement that traces to the same method and same scope means you probably have a duplicate.
Where Safeguard fits
For dependency findings, Safeguard's reachability analysis and exploitability checks help decide which reported flaws matter for your code, which narrows disputes between lists. It does not reconcile static or dynamic results. The free scan is at https://gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Follow how a single finding is checked for whether it can actually be exploited.
Quick check
Which scanner is right when they disagree?
Often both. Check scope, vantage point and data first, then verify a sample by hand.
Is disagreement a sign of a bad tool?
Not necessarily. It is expected when methods differ. Worry when two tools of the same type on the same target disagree widely.
Sources
Last reviewed: 19 October 2026.
