Mirror the vulnerability database once inside your network, have workers pull from that mirror into a local cache, and refresh on a schedule. Track the database age as a metric so a silent refresh failure shows up before it causes missed findings.
Why this matters at scale
Many scanners download an advisory database at the start of a run. With one developer machine that is fine. With hundreds of ephemeral CI runners or short-lived containers, every run downloads it again. That adds seconds to every scan, costs bandwidth, and can trip the upstream source's limits.
Trivy is a useful public example. Its documentation says the vulnerability database is stored in the cache directory and is downloaded as an OCI artifact from registries, with default locations including ghcr.io and a mirror, and it lets you set your own repository locations. It also provides flags to skip the update step and an option to only update the database without scanning. That pattern, download once and reuse, applies to most scanners even if the details differ.
Three caching approaches
| Approach | Good for | Watch out for |
|---|---|---|
| Internal mirror, workers pull each run | Ephemeral runners | Mirror becomes critical, needs monitoring |
| Shared volume with periodic refresh job | Long-lived workers | Concurrent refresh can corrupt files, use atomic swap |
| Baked into the worker image, rebuilt often | Air-gapped or locked-down networks | Image age equals database age |
Steps
- Run one refresh job on a schedule that pulls the database from upstream into your mirror or object store.
- Point workers at the mirror through the scanner's database location setting.
- Tell workers to skip the upstream update step so they never reach the internet during a scan.
- Write the refresh atomically: download to a new path, verify, then switch a pointer, so a worker never reads a half-written file.
- Record the database build time and expose it as a metric.
- Alert if the age exceeds your threshold, since a stuck refresh is quiet and dangerous.
How fresh is fresh enough
There is no single answer. OSV.dev states a data freshness objective that its sources are no more than 15 minutes stale 99.5 percent of the time, which shows the upstream data itself changes quickly. A mirror refreshed once a day will lag by up to a day plus whatever delay your scanner's database build adds. Decide what lag you accept for each lane: pull request checks can tolerate a few hours, while reactive rescans after a major advisory may justify forcing an immediate refresh.
Build a manual "refresh now" action for those days. It should update the mirror, then trigger the reactive lane.
Pitfalls
Two databases drifting apart. If some workers use the mirror and others fetch upstream, the same code can scan differently. Force all workers through one path.
Schema changes. A scanner upgrade may need a newer database schema. Trivy notes that without a tag it defaults to the database schema number, which hints at why you should test mirror and scanner versions together.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how quickly newly disclosed issues surface, and think about how old your own database would have to be to miss them.
Safeguard is a hosted platform with zero-day discovery, so customers using it do not operate a database mirror for the platform itself. Try the free scan at https://gold.safeguard.sh/scan.
Quick check
Can workers just use a shared network drive?
Yes, if refreshes are atomic and read-only for workers. Concurrent writes to a live database file risk corruption.
What is the one metric to alert on?
Database age. A scan that completes against a three week old database looks identical to a good scan unless you track it.
Sources
Last reviewed: 19 October 2026.
