Refresh the vulnerability database as often as your tool allows, ideally on every scan or at least daily, because new advisories appear continuously. Update the scanner engine on a planned cadence, such as monthly, with pinned versions and a test run first. Data and engine are separate decisions.
Two clocks
The database answers "which versions are vulnerable". It changes daily. EPSS, for example, recalculates scores daily, according to FIRST, and the CISA KEV catalog gains entries over time.
The engine parses lockfiles, matches packages and applies policy. It changes with releases, and a new release can change results through new parsers or matching rules.
Mixing these up causes two opposite mistakes: running a stale database because the engine is pinned, or letting the engine float and surprising everyone with new results.
Recommended pattern
| Item | Cadence | Reason |
|---|---|---|
| Vulnerability data | Every scan, or daily | Advisories arrive constantly |
| Exploitation feeds such as KEV and EPSS | Daily | Both change on a daily rhythm |
| Scanner engine | Planned, for example monthly | Controlled change |
| Policy and rule files | On change, through review | Auditable |
| Scanner health check | Yearly | Continuity |
Steps to set it up
- Pin the engine version in CI by exact number.
- Separate data refresh from engine upgrade, so you can update one without the other.
- Cache the data per pipeline run to avoid hammering the source, but expire the cache daily. Our guide on caching a vulnerability database across scan workers covers this.
- Before an engine upgrade, run old and new versions on three repositories and diff the results.
- Read release notes for parser, matching and severity source changes.
- Roll the upgrade out in waves, starting with a low risk repository.
- Record the version and data date in every scan report, so any result can be reproduced.
What to watch for
- A data download that fails quietly. Alert on it, because a scan against old data looks like a clean scan.
- Rate limits and access changes at data sources. NVD, for instance, has changed its feeds and API over time, as its news page records, so scripts that call it directly need maintenance.
- Engine upgrades that change the finding count sharply. Investigate before gating.
For managed platforms
You should not have to manage either clock, but you should still ask: how fresh is the data, can you see its age, and are engine changes announced before they alter results? Put the answers in your vendor review.
Safeguard offers continuous monitoring so data refresh and monitoring are handled in the service, and you can see results with a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how monitoring re-evaluates the same components when new data arrives.
Quick check
Should I always use the latest scanner version?
Use a deliberate, tested upgrade cadence with pinned versions rather than floating on latest.
Is a clean scan with stale data safe?
No. It only says nothing was known at the data's date.
Sources
Last reviewed: 19 October 2026.
