There is no single answer, because an advisory passes through several steps before a scanner can flag it: publication, ingestion by a database, review or mapping to packages, and matching against your inventory. Each step can add delay, and the public documentation rarely promises a time.
The four hops
Think of the path as a relay. Any runner can be slow.
| Hop | What happens | Where delay hides |
|---|---|---|
| Publish | A maintainer, CNA or ecosystem team publishes a record | Disclosure timing, embargoes |
| Ingest | An aggregator copies the record into its database | Sync schedules, format conversion |
| Review | The record is checked and mapped to package names and version ranges | Manual review queues |
| Match | Your scanner compares the record with your dependency list | Scan cadence, stale inventory |
The OSV project describes its sources as continuously exported, but it gives no fixed interval for when an upstream change shows up. GitHub's documentation says new vulnerabilities "may take time to appear" in its advisory database and trigger alerts. Neither source offers a number of minutes or hours, so do not invent one for your own reporting.
Reviewed records trigger alerts, unreviewed ones do not
GitHub separates reviewed advisories from unreviewed ones. Unreviewed records are published automatically from the National Vulnerability Database feed and are not checked for validity or completeness. Only reviewed advisories generate Dependabot alerts. That means a CVE can be public while the alert system for a given package stays quiet. If you rely on one database, you inherit its review queue.
What you control
You cannot speed up a maintainer, but you can shorten the last two hops.
- Match against a stored inventory, so a new record is checked against every build you track without a rebuild.
- Use more than one advisory source, and know which ones your scanner reads.
- Treat the KEV catalog as a separate, faster signal for the small set of vulnerabilities with confirmed exploitation.
- Record the timestamps: when the advisory was published, when your tool first showed it, when a ticket opened.
That last step turns a vague worry into a number you can improve. The post on measuring detection lag shows how.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a new disclosure moves from a feed to an affected project, and note which step still needs a human.
Where Safeguard fits
Safeguard's SBOM and dependency scanning keeps an inventory of what you ship, so a newly published advisory can be matched to it. Its zero-day discovery work covers findings that do not yet have an advisory. You can try a free scan to see the inventory side.
Quick check
Does a CVE ID mean my scanner already knows about it?
No. A CVE record can exist before a database maps it to package versions. Until that mapping exists, many scanners cannot match it to your dependencies.
Is there a guaranteed time from publication to alert?
Not in the sources reviewed here. The GitHub and OSV documentation describe the process but give no delivery window, so measure your own lag instead.
Sources
- About Dependabot alerts, GitHub Docs
- About the GitHub Advisory Database, GitHub Docs
- OSV data sources, osv.dev
Last reviewed: 19 October 2026.
