Pin by digest if you also automate the updates. A digest guarantees the same image bytes every build, even if a publisher moves a tag, but it freezes you on that image until something raises a pull request to change it.
Tag versus digest in plain terms
A tag such as 3.21 is a label that a publisher can move to a new image. A digest is a content hash of one specific image. Docker's build best practices say that pinning to a digest means you always use the same image version, even if a publisher replaces the tag with a new image. They also note that unpinned tags leave you without an audit trail of the exact versions you used.
The same guidance names the cost. Looking up digests by hand is tedious, and pinning means opting out of automatic security fixes unless you add a process to refresh the pin.
Decision table
| Approach | Repeatable builds | Gets fixes automatically | Audit trail |
|---|---|---|---|
| Floating tag (latest) | No | Yes, but unreviewed | Weak |
| Version tag (3.21) | Mostly | Within that tag, unreviewed | Moderate |
| Tag plus digest | Yes | No, until a PR updates it | Strong |
| Tag plus digest plus update PRs | Yes | Yes, reviewed | Strong |
The last row is the target for a golden path.
How to set it up in a template
- Put the base image in the template Dockerfile as a tag plus digest.
- Add an update tool configuration to the template so pull requests arrive on a schedule. Docker's documentation recommends Dependabot with package-ecosystem set to docker, which raises pull requests to update base image tags and digests.
- Run an image scan in CI on every build, so a pinned image with a newly published vulnerability is caught even when nothing changed in your code.
- Publish approved base images from the platform team, so most services pick from a short list instead of the public internet.
Step 3 is easy to forget. A pin protects you from surprise changes, not from a known flaw in the image you pinned. Digests do not age well without rescans.
Who owns the base image
The platform team usually owns the approved list and its update cadence. App teams own the choice to move to a newer one. See who owns base image vulnerabilities for how to split that cleanly.
A rollout that works
Start with one language runtime image and one update cadence. Tell teams how long a base image update takes to reach their service, and measure it. If a critical fix needs to move faster than the schedule, have a documented fast lane that raises the pull request immediately and still runs the same checks.
Avoid rebuilding without a change on a floating tag as a substitute for this. It gives you fixes but not repeatability, and a bad upstream release lands in production before anyone reviews it.
Where Safeguard fits
Safeguard scans container images and the dependencies inside them, applies policies in pull requests, and can open fix PRs (off by default, every category on Manual). You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Run the image scan and look at which findings come from the base layer rather than your own code.
Click through it at your own pace, or open it full screen.
Quick check
Does pinning a digest make an image safe?
No. It makes the image repeatable. The image can still contain known vulnerabilities, so keep scanning it.
Is the latest tag ever acceptable in a template?
It makes builds unrepeatable and unreviewed, so most platform teams avoid it in templates and use a version tag with a digest.
Sources
Last reviewed: 19 October 2026.
