Pin the scanner version so results are repeatable and upgrades are deliberate. Do not freeze the vulnerability database the same way, because a stale database hides new advisories. Pin the tool, refresh the data, and record both versions in every result.
The two things that change
A scanner has code and data. The code is the binary or container that parses artifacts and applies rules. The data is the advisory database it matches against. They change at different speeds and for different reasons, so they need different policies.
Code changes can alter behaviour: new parsers, new rules, changed output formats. A surprise change in a CI pipeline can break parsing of reports or cause a gate to flip. Data changes alter results in the way you want, as new advisories arrive.
What each choice gives you
| Choice | Benefit | Cost |
|---|---|---|
| Float the scanner (latest) | Newest detections | Surprise behaviour changes, hard to reproduce a past scan |
| Pin the scanner | Repeatable runs, planned upgrades | You must schedule upgrades or fall behind |
| Float the database | Fresh coverage | Same code can give different results on different days |
| Pin the database | Exact reproduction | Missed advisories while pinned |
For most teams the sensible mix is a pinned scanner and a database refreshed on a schedule through an internal mirror, with the database build recorded in each result.
Why not pin the database
Pinning the database is useful for one purpose: reproducing a past scan, for example during an audit or an incident review. For that, store the database build identifier rather than freezing production scans. If you need to reproduce, fetch that build.
Steps
- Pin the scanner by version or image digest in one shared place, not in hundreds of pipelines. A moving tag defeats the pin, so use a digest where you can.
- Schedule a regular review of new scanner releases, with the staged rollout described in our post on scanner upgrades.
- Refresh the database through a mirror on a fixed cadence, and alert when its age passes your threshold.
- Write scanner version, rule set version and database build into each result record.
- Keep the previous scanner version available for rollback.
Note that some scanners have a database schema tied to the scanner version. Trivy's documentation, for example, says that without an explicit tag the database image defaults to the schema number, not a latest tag. That is a reminder that scanner and data versions are linked, so test combinations rather than assuming any mix works.
Common failure
A team pins the scanner to a version from two years ago because "it works", and never upgrades. The tool then lacks support for newer package formats and quietly reports fewer components. Pinning without a review schedule is just a slower way to fall behind.
Try it yourself
Click through it at your own pace, or open it full screen. Check how many components are found, since a stale scanner can undercount this.
Safeguard is hosted, so scanner and data updates are handled for you. The CLI is available through the curl and PowerShell installers if you want it in a pipeline, and you can try the free scan at https://gold.safeguard.sh/scan.
Quick check
Is pinning by tag enough?
Not if the tag can move. Pin by digest for container images, or by exact version for binaries.
How do I reproduce an old scan?
Use the scanner version and database build recorded in that result, and fetch both.
Sources
Last reviewed: 19 October 2026.
