To test freshness, ask where the data comes from, when it last synced, how often your inventory is re-matched, and what happens to corrected records. A scanner that can answer each with a source and a timestamp is easier to trust than one that says "up to date".
The checklist
Use these in a tool evaluation or as a quarterly self check.
- Which advisory sources do you read? Expect a named list, such as ecosystem databases, NVD and the KEV catalog.
- When was each source last synced? Expect a visible timestamp, not a promise.
- Do you alert on reviewed records only, or raw ones too? Either is valid. The answer explains your delays. GitHub, for instance, alerts only on reviewed advisories.
- Is matching triggered by new data or by my scan schedule? New data triggering a re-match shortens lag.
- Is my inventory stored between scans? A stored list allows re-matching without a rebuild.
- How do you handle records with no package mapping? NVD says CVEs outside its priority set may not be enriched promptly, so this matters.
- What happens when an advisory is withdrawn or corrected? Findings should update or close, with a visible history.
- Do you ingest exploitation signals? KEV and EPSS give different information. EPSS is updated daily.
- How do you report scan time versus data time? Both should appear on a result.
- Can you show a worked example from publication to alert? Timestamps, please.
Scoring your answers
| Answers with sources and timestamps | Result |
|---|---|
| 8 to 10 | Strong freshness posture |
| 5 to 7 | Gaps to close, ask for roadmap dates |
| 0 to 4 | Treat results as indicative only |
The bands are a rule of thumb for your own comparison, not a standard.
Run a live test
Questions are easy to answer well. A test is harder to fake.
- Pick a recently published advisory for a package you use.
- Note its publication time from the source record.
- Check when your scanner first showed it.
- Repeat for two or three advisories and look at the spread.
The spread matters more than the average, because the slowest case is the one that hurts.
Fix what you find
If the lag comes from one source, add another. If it comes from your own schedule, change the trigger. If it comes from a stale inventory, start storing SBOMs per release. Our post on continuous dependency monitoring setup covers the mechanics.
Where Safeguard fits
Safeguard's SBOM and dependency scanning stores your inventory, and its policies act on current results. Try a free scan and apply the checklist to what you see.
Quick check
Is a bigger vulnerability database always fresher?
No. Size is not speed. Freshness depends on sync cadence, review queues and matching triggers.
How often should I rerun this test?
Quarterly is a sensible start, and after any tooling change.
Sources
Last reviewed: 19 October 2026.
