Ask which advisory sources a tool uses, how fast new entries appear, which ecosystems are covered in depth, and what happens when sources disagree. Detection logic is similar across tools. The data behind it is where results diverge, so it deserves a section in any evaluation.
Which sources feed it?
Public databases, vendor advisories, ecosystem specific lists and a vendor's own research all differ in scope and speed. A tool using a single source inherits its gaps. Ask for the list and what each contributes.
How fresh is it?
Measure it. Pick a recently published advisory and check when each candidate reports it. A one day lag and a one week lag matter little in quiet times and a lot during active exploitation.
How deep per ecosystem?
Coverage is uneven. Some ecosystems have rich, well structured advisories, others have sparse ones. Ask for coverage for each language you actually use, and test one known issue in each.
Conflicting data
Sources can disagree about affected versions or severity. Ask how conflicts are resolved and whether you can see both values. A tool that silently picks one hides a judgement call that you may want to make.
Version matching quality
Many false positives come from imprecise matching of package names and version ranges. Ask how the tool handles forks, renamed packages, backported fixes in distribution packages and pre release versions.
Own research versus aggregation
Vendors that publish their own research can find issues before public databases do. That helps only if the findings are documented, dated and corrected when wrong. Ask to see examples and corrections.
What to record
For the proof of concept, log source list, report latency on one fresh advisory, and misses per ecosystem. Those three numbers compare tools fairly.
Do not forget distribution packages. Operating system vendors often backport fixes without changing the upstream version number, which makes naive version matching report issues that are already fixed. Ask each vendor how that case is handled and test one example.
Where Safeguard fits
Safeguard covers SBOM and dependency scanning, reachability analysis, policies and gates, and fix pull requests that stay off until you turn them on. You can try a free scan on a repository before you commit to anything.
Try it yourself
Open the zero day watch and look at how a new issue appears over time and what details are attached to it.
Click through it at your own pace, or open it full screen.
Quick check
Is more sources always better?
More sources help only if conflicts are resolved visibly. Otherwise they add noise.
Do I need to check this if I use an open source scanner?
Yes. The same questions apply, and the answers are usually public.
Last reviewed: 19 October 2026.
