Pin the base image to a digest, then schedule a regular, reviewed update of that digest. Pinning gives repeatable builds, but it also freezes any flaws in that image, so the update loop is what keeps a pinned image from going stale.
Why pin at all
Docker's build guidance explains that image tags are mutable. A tag such as a minor version might point at one patch release today and a different one three months later, so rebuilding the same Dockerfile can give a different result and you have no audit trail of the exact image used. Pinning to a digest means you keep the same image even if the publisher moves the tag. The guidance shows the form, a tag followed by an at sign and a sha256 value.
FROM alpine:3.21@sha256:<digest-you-recorded>
Keep the tag in the line as a human-readable note. The digest is what the build actually uses.
The trade you are making
| Floating tag | Digest pin | |
|---|---|---|
| Gets upstream patches automatically | Yes, on next rebuild | No, until you change it |
| Same input on every build | No | Yes |
| Audit trail of what shipped | Weak | Clear |
| Risk | Surprise changes | Stale, unpatched image |
Neither is free. A digest pin swaps surprise breakage for a chore you must own.
A review loop that fits a small team
- Pick a cadence. Weekly or fortnightly works for most teams, plus an immediate update when a serious flaw is published in your base image.
- Resolve the new digest. Pull the same tag and note its new digest.
- Open one change per image. The pull request changes just the digest line. Small diffs are easy to review.
- Scan before and after. Compare findings in the old and new image so the reviewer can see whether the update fixed things or introduced something.
- Run your tests and a smoke deploy. A base image update can change a system library.
- Merge and record. The merged digest is your audit trail.
Tools exist that propose these pull requests automatically, and you can use one, but the review step should stay human or gated by tests.
Do not forget the packages inside
Docker's guidance also says to combine the package index update and install in a single instruction. If your Dockerfile installs packages at build time, the installed versions can still move even though the base image is pinned. That is a second drift source to decide on, either by pinning versions or by accepting the movement and rebuilding on a schedule.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how findings are tied to a specific image. That is the comparison your digest update pull request should include.
Where Safeguard fits
Safeguard scans container images and can open fix pull requests, which is off by default with every category on Manual, so a human still approves each change. Free scan: gold.safeguard.sh/scan.
Quick check
Does a digest pin make the image secure?
No. It makes the image repeatable. If the image has known flaws, they stay until you update.
Should I drop the tag when I use a digest?
Keep it. The digest controls what runs, and the tag tells reviewers what you intended.
Sources
Last reviewed: 19 October 2026.
