To test advisory freshness in a proof of concept, choose several advisories published in the last few weeks, note when each appeared in a public database, then record when the scanner first reported each one on a seeded package. The gap, in hours or days, is the lag you are buying.
Why freshness matters
A scanner is only as current as its data. A new advisory for a package you use is useless to you until your tool knows about it. Detection logic can be perfect and still miss today's issue.
Vulnerability data comes from many sources: language ecosystem advisories, project maintainers, the National Vulnerability Database and aggregators. OSV describes itself as an aggregator of vulnerability databases that have adopted the OpenSSF vulnerability format, and says it provides infrastructure to keep affected versions accurate. Different sources publish at different speeds, so a scanner's lag depends on which it ingests and how often.
The freshness test
- Pick five to ten advisories published in the past two to four weeks, in ecosystems you use. Use public sources to confirm the publication dates.
- For each, find a package and version that is affected. Add it to a throwaway branch.
- Record, per advisory, the public publication time you observed.
- Scan. For advisories the scanner does not report yet, rescan daily and log the day it first appears.
- Compute the lag per advisory.
A simple log works:
| Advisory | Public date | Package seeded | First seen in scanner | Lag |
|---|---|---|---|---|
| Your entry | Date | name@version | Date | Days |
Because the PoC runs two weeks, newly published advisories keep arriving. You can add rows as new ones land, which gives a live sample.
What lag is acceptable?
That depends on your risk. A team that patches monthly may accept a day or two. A team exposed to internet facing services may want same day. Decide before the test. Write the tolerance in the success criteria.
Also ask the vendor, in writing, what sources feed the data and how often they refresh. Compare the written answer with what you measured.
Coverage versus speed
Fast but narrow is a trap. A tool that picks up one source instantly but ignores ecosystem advisories may report some issues early and miss others entirely. Track two numbers: the lag for advisories found, and the count not found after a fixed window, say seven days.
Related checks
Freshness is not only about new advisories. Records get corrected. A version range may be widened or narrowed after the first report. Pick two advisories that were updated after publication and see whether the scanner reflects the current record or a stale copy. And see our post on continuous monitoring versus point in time scans for what happens after the first scan.
Try it yourself
Open the demo to see how a new advisory can change the status of a repo that was clean yesterday, which is exactly what your freshness log is measuring.
Click through it at your own pace, or open it full screen.
Quick check
Can we trust the vendor's stated update frequency?
Treat it as a claim to verify. Your own lag log is the evidence.
What if the scanner never reports a seeded advisory?
Count it as a miss, record the ecosystem, and ask the vendor whether that source is supported.
Sources
Safeguard offers SBOM and dependency scanning with reachability analysis, and you can try a free scan at gold.safeguard.sh/scan before you plan a longer test. The CLI, desktop app and IDE extensions are listed on safeguard.sh/download.
Last reviewed: 19 October 2026.
