Pick one scanner as the source of truth for the gate and treat the other as a prompt to investigate. A gate that blocks when either tool complains is unpredictable. A gate that follows one tool, with a written reason for each disagreement you resolve, is something developers can learn to trust.
Why scanners disagree
Disagreement is normal and usually has a boring cause. Tools differ in four ways.
- Data sources. The OSV project documents that it aggregates many advisory databases, including the GitHub Advisory Database, language ecosystem databases and others, and converts some sources into its format. A tool that reads one source can report different things from a tool that reads another.
- Timing. An advisory may exist in one database hours or days before it appears in another. GitHub notes that new vulnerabilities may take time to appear in its advisory database, and that only reviewed advisories trigger Dependabot alerts.
- What gets scanned. One tool may read the lockfile, another the built image, another the manifest only. Transitive dependencies, dev dependencies and vendored code are handled differently.
- Matching logic. Package name, version range and ecosystem matching can differ even on identical data.
A decision table
| Disagreement | Likely cause | What the gate should do |
|---|---|---|
| Tool A finds it, tool B does not | Different data source or timing | Follow the gate tool, investigate the other |
| Same CVE, different severity | Different scoring source | Use one severity source and document it |
| Same package, different version found | Different scan target (lockfile vs image) | Decide which artifact is authoritative |
| Tool B finds a package tool A never saw | Coverage gap, such as vendored code | Fix coverage, then re-run |
How to choose the one that gates
- List what you need the gate to be: fast, deterministic, able to scan the artifact you ship, and able to record exceptions.
- Run both tools on the same ten recent releases and compare. Do not compare on one repository.
- For each disagreement, find the cause using the advisory itself. Open the advisory, check the affected version range and your actual version.
- Choose the tool whose misses you can explain and whose findings you can reproduce.
- Write down the choice and the date, so a later audit sees a decision rather than an accident.
What to do with the second scanner
Keep it, but run it as a non blocking job. Its job is to catch gaps in the first tool's data. When it reports something the gate tool missed, triage it by hand. If it is real, add a manual exception or policy entry and tell the tool owner. If it keeps being right, that is evidence to revisit your choice.
Avoid the tempting shortcut of failing on the union of both. You will double the noise, and developers will not know which tool to ask about a block.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how a single prioritised list is easier to act on than several competing ones.
Safeguard provides SBOM and dependency scanning with reachability analysis and policy gates, which can serve as the single decision point. A free scan is available at gold.safeguard.sh/scan.
Quick check
Should the gate fail if either scanner finds a critical issue?
Usually no. Failing on the union makes results hard to explain. Gate on one tool and review the other tool's critical findings by hand within a set time.
How often should I compare the two tools?
Quarterly is a reasonable rhythm, plus after a major ecosystem or tool change. Use the same set of recent releases each time so the comparison is fair.
Sources
- OSV, Data sources
- GitHub Docs, About Dependabot alerts
Last reviewed: 19 October 2026.
