A standard scanner matches your packages against a database of known advisories, so by definition it cannot report a vulnerability nobody has published. Finding zero days takes other methods: code analysis of dependencies, fuzzing, behaviour monitoring, or early signal tracking. Each catches a different slice.
What "zero day" means when you are shopping
People use the phrase loosely. It can mean a flaw with no public advisory, a flaw with no patch yet, or a flaw already exploited before disclosure. When a vendor says it finds zero days, ask which of these it means. The answer changes what you can expect.
Four approaches and what they need
Deep code analysis of third party packages. Static analysis applied to the dependency source, not just your own. It can flag dangerous patterns that have no advisory. Expect false positives and a need for human review of each lead.
Fuzzing. Feeding malformed input to a library and watching for crashes. It is strong for parsers and native code, weak for logic flaws. It needs a harness per target and compute time.
Behaviour monitoring. Watching what a package does at install or run time, such as unexpected network calls or file writes. Useful for malicious packages, less so for ordinary bugs.
Early signal tracking. Watching maintainer chatter, commits, and fix patches that land before an advisory exists, then matching them to what you use. It narrows the window between a quiet fix and a published CVE.
How to judge a claim
Ask for a worked example with the package, the version, the date the tool flagged it, and the date a public advisory appeared. Treat a missing example as a sign to test it yourself. Also ask who validates leads, because unvalidated leads create triage work rather than saving it.
What you can do for free
Subscribe to the security feeds of your top ten dependencies, pin versions so a bad release does not land silently, and add a cooling off period before adopting brand new releases. None of that finds a zero day, but it limits how fast one reaches you.
A fair way to test a zero day claim
Run a retrospective test. Take a vulnerability that was published last quarter in a package you use. Ask the vendor, or check yourself, whether their method would have flagged it before the advisory. One case proves little, but a vendor who can walk through a real timeline is more credible than one who shows a dashboard.
Also ask what the output looks like. A lead with a file, a function and a reasoning trail can be checked in an hour. A bare score cannot.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a lead is tied back to the packages in a specific project.
Where Safeguard fits
Safeguard includes zero-day discovery and ties findings to the dependencies in your inventory. A free scan shows the inventory side first.
Quick check
Can a regular vulnerability scanner find a zero day?
Not on its own. It reports known, published advisories. Zero days need analysis or monitoring methods.
Is finding zero days worth paying for?
For most small teams, fast patching of known issues pays off first. Zero day discovery matters more when you ship widely used software or hold sensitive data.
Last reviewed: 19 October 2026.
