Delay comes from four places: the CVE record itself, enrichment by NVD, aggregation into ecosystem databases such as OSV and GitHub, and your own scanner's update cycle. The CVE list updates about every 7 minutes, but NVD now enriches by risk, so the slowest stage is often the one you cannot see.
Stage 1: the CVE record
The CVE Program's cvelistV5 repository says it updates about every 7 minutes from the official CVE Services API. A record only exists once a CNA publishes it, and the content depends on the CNA. Nothing downstream can be faster than this, and it can be incomplete.
Stage 2: enrichment
NVD adds scores, weakness types and product match data. Per NIST's 15 April 2026 announcement, it now prioritizes CVEs in the CISA KEV catalog, federal-use software and critical software, with a goal of enriching KEV CVEs within one business day. Others are labelled "Lowest Priority" or "Not Scheduled". If your scanner waits for NVD product matches, it can wait a long time. See what the NVD labels mean.
Stage 3: aggregation
OSV says its data is continuously exported to a storage bucket, with a file listing recent changes sorted newest first, but gives no fixed interval. Sources feed OSV at their own pace. GitHub's advisory database has reviewed advisories, which are checked, and unreviewed ones published automatically from the NVD feed without checking. Dependabot alerts are generated for reviewed advisories only, per GitHub.
Stage 4: your tool
Your scanner has its own update schedule, its own cache and its own rescan trigger. A tool that pulls its database weekly adds up to a week. A tool that scans only on commit will not tell you a new advisory landed against code you already shipped.
The summary table
| Stage | Documented figure | What can go wrong |
|---|---|---|
| CVE list | About 7 minutes (repository statement) | Record has little detail |
| NVD enrichment | KEV goal one business day; others not scheduled | No score or product match |
| OSV export | Continuous, no fixed interval stated | Source lags |
| GitHub review | Reviewed vs unreviewed, no timing stated | Unreviewed has no alert |
| Your scanner | Whatever you configured | Weekly pull, commit-only scans |
Only the first two rows give a number, and they are the publishers' own statements. For the rest, measure it yourself with a freshness test or how to measure advisory to alert time.
What to do about it
- Use more than one source for the same package.
- Rescan stored SBOMs when new advisories land, not only on commits.
- Treat KEV as a separate trigger, since it is explicit evidence of exploitation.
- Measure your own advisory to alert time monthly.
- Ask vendors to state each stage in their own pipeline.
The related post on real-time monitoring, myth versus fact covers what "real time" should mean in a contract.
Where Safeguard fits
Safeguard offers zero-day discovery, continuous monitoring and SBOM and dependency scanning. The demo below shows monitoring after a build. For your own project, use the free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch what triggers a re-check after the original scan.
Quick check
Which stage is usually slowest?
Often NVD enrichment for lower priority CVEs, since NVD now enriches by risk, though you should measure your own pipeline.
Do unreviewed GitHub advisories create Dependabot alerts?
No. GitHub says alerts are generated for reviewed advisories only.
Sources
- CVE Program, cvelistV5 repository README, fetched 19 October 2026.
- NIST, NVD program page and announcements, fetched 19 October 2026.
- OSV.dev, Data dumps and sources, fetched 19 October 2026.
- GitHub Docs, About the GitHub Advisory Database, fetched 19 October 2026.
Last reviewed: 19 October 2026.
