The time from a new advisory to your alert is the sum of four clocks: when the advisory is published, when your scanner ingests it, when it is matched against your inventory, and when you are notified. You only control some of them. Measuring each separately shows where delay really comes from.
The four clocks
| Clock | Starts | Ends | Who controls it |
|---|---|---|---|
| 1. Publication | Flaw is known | Advisory is public | Maintainers and databases |
| 2. Ingestion | Advisory is public | Scanner holds the record | Scanner vendor or your sync |
| 3. Matching | Record ingested | Findings computed for your projects | Scanner design and your schedule |
| 4. Notification | Finding exists | A person sees it | Your routing and alert rules |
Clock 1: publication
Public records do not all appear at once. A package ecosystem advisory might appear before a general database entry, or after. GitHub documents that its unreviewed advisories are published automatically from the National Vulnerability Database feed, while reviewed advisories are checked for validity and mapped to packages. That difference means two sources can show the same flaw at different times and with different completeness.
You cannot speed this clock up, but you can read more than one source.
Clock 2: ingestion
How often does your scanner refresh? Hourly, daily and weekly are very different. Ask for the refresh interval in writing, and ask what happens when a source is slow or down.
Clock 3: matching
A scanner that only matches when code is rebuilt will not alert you to a new advisory on an unchanged project. A scanner that keeps inventories and rematches them when data updates will. This is the clock many teams forget. If your last scan ran Friday and the advisory landed Saturday, the finding does not exist until the next scan, however fast ingestion was.
Clock 4: notification
Even a finding produced instantly is useless if it lands in an inbox nobody reads. Check routing: does a critical, exploited finding reach an on-call person or a shared channel, and does a low one wait for a weekly digest? Public signals help here. CISA's Known Exploited Vulnerabilities catalog records a date added for each entry, which is a clean trigger for an urgent rescan.
How to measure your own pipeline
- Pick three recent advisories that affected you.
- For each, record the public date, the time your scanner first showed the record, the time a finding appeared, and the time someone acted.
- Compute the four gaps.
- Fix the biggest one first.
Most teams find that clocks 3 and 4 are the largest, and those are the ones inside your control.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a new issue is detected and how quickly it is tied to the projects that use it.
Where Safeguard fits
Safeguard includes zero-day discovery and continuous monitoring so new advisories are checked against stored inventories without a rebuild. A free scan gives you a baseline to start from.
Quick check
Which clock do teams most often overlook?
Matching. If a scanner only runs on builds, a new advisory waits for the next build before a finding exists.
Can I trust one advisory source?
Sources differ in timing and completeness, so it helps to know which ones your scanner reads and how often it syncs.
Sources
Last reviewed: 19 October 2026.
