You cannot search a database for a true zero-day, because by definition no fix or public advisory exists yet. What you can do is keep a current inventory of every dependency, watch advisory feeds and the exploited-vulnerability list, and match each new entry to that inventory within hours instead of days.
What "zero-day in a dependency" means in practice
A zero-day is a flaw that attackers or researchers know about before the maintainer has shipped a fix. For your team, the practical version is narrower: a dependency you already run has a flaw, and the fix is not available yet or was published only minutes ago.
Two things are in your control. First, how fast you learn a new flaw exists. Second, how fast you can say which of your products contain the affected package and version.
Where the signals come from
| Signal | What it tells you | Weak spot |
|---|---|---|
| Open advisory databases such as OSV and the GitHub Advisory Database | Package, affected version ranges, fixed version when known | Entry appears after disclosure, not before |
| CISA's Known Exploited Vulnerabilities catalog | Flaws confirmed as exploited in the wild | Covers a small share of all advisories |
| Maintainer issue trackers and security mailing lists | Early notice, sometimes before an ID exists | Unstructured, hard to match automatically |
| Your own inventory (SBOM) | Which products contain the package | Only as good as its last refresh |
The OSV API accepts a package and version and returns matching vulnerabilities, and it has a batch endpoint for many queries at once. The KEV catalog is published as CSV and as a JSON feed, so a script can poll it. Those two facts are enough to build a basic watch.
Steps to build a watch
- Generate an SBOM for every product and keep it current. Regenerate on each build, not once a quarter.
- Store components with exact versions and package URLs so they can be matched by machine.
- Poll an advisory source on a schedule and re-match your whole inventory, not just new projects. A package that was clean yesterday may not be today.
- Poll the KEV feed separately and treat any match as urgent.
- When a match fires, ask three questions: is the affected version range ours, is the vulnerable code reachable from our entry points, and is there a fix or a mitigation.
- If no fix exists, apply a mitigation (disable the feature, block the route, pin to a safe version) and write down the exception with an owner and a review date.
The matching job is the part teams skip. Feeds are easy to read. Joining them to an accurate, current inventory is what turns news into a list of affected repositories.
Try it yourself
Open the demo, watch a new advisory arrive, and look at how it is matched to the components in the sample inventory.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard's SBOM and dependency scanning keep the inventory, zero-day discovery adds early findings, and reachability analysis shows whether a flagged function is actually called. You can run a free scan to see what your own manifest contains.
Quick check
Can a scanner detect a zero-day that has no advisory yet?
Not by lookup. A database match needs an entry. Discovery work on code, or early signals from maintainers, can surface a flaw before an ID exists, but you should treat those as leads that need confirmation.
Is a KEV match always more urgent than a high CVSS score?
A KEV entry means exploitation has been observed, so it usually deserves faster attention. Still check that the affected version and code path are yours before you drop other work.
Sources
- OSV API documentation, google.github.io/osv.dev/api (query and querybatch endpoints).
- CISA Known Exploited Vulnerabilities Catalog (CSV and JSON feed formats).
- GitHub Docs, About the GitHub Advisory Database (OSV format, reviewed and unreviewed advisories).
Last reviewed: 19 October 2026.
