A Docker tag is a movable label, so FROM alpine:3.21 can resolve to different content over time. A digest identifies exact image content and never changes. Pin the digest to get repeatable builds, then automate updates so pinned images do not rot.
Do Docker images have a lockfile?
Not in the way npm or Cargo do. There is no single file that records exact resolved versions of every layer. The closest equivalent is writing a digest next to the tag in your Dockerfile. Docker's build best practices say pinning base images by digest guarantees you always use the same image version, even if a publisher replaces the tag with a new image.
Docker also spells out how loose a tag is. Writing alpine:3.21 resolves to the latest patch version for 3.21. That is convenient and also means two builds a week apart can differ.
What does a digest look like?
A digest is a sha256 value over the image manifest. In a Dockerfile you keep the human tag and add the digest, so the line reads as the image name, the tag, an at sign, then sha256 and the value. Docker documents this form, and the tag stays as a readable hint while the digest decides what is pulled.
Why does this matter for security?
Consider a constructed incident. A team builds from a popular base image tag. A publisher account is compromised and a malicious image is pushed under the same tag. Every new build pulls it. Had the Dockerfile carried a digest, builds would keep fetching the earlier content and fail loudly if it were gone.
The same reasoning covers an honest mistake. A maintainer rebuilds a tag with a different default and your build changes behavior with no commit on your side. Pinning turns that into a diff you can review.
What is the catch?
Pinning freezes bugs and security fixes too. An old digest keeps old vulnerable packages. The goal is to move on purpose, not never.
Another catch: a digest names one platform manifest or a multi-platform index. Check which one you pinned if you build for several architectures.
How do digests work with multi-stage builds?
Every FROM line is a separate dependency. A multi-stage Dockerfile might use one image to compile and another to run, and each deserves its own pin. Teams often pin the final runtime stage and forget the builder stage, even though the builder is the one executing your build scripts and holding your source. Review all of them, including images referenced by copy-from instructions and by CI service definitions.
How to check or apply this
- Find every FROM line in your repositories and note which use bare tags or latest.
- Resolve each to a digest from your registry and add it after the tag.
- Use the same digest in CI and in production deployment manifests, not just in the Dockerfile.
- Set up automated update proposals so a newer digest arrives as a reviewable change.
- Scan the image at each update and fail the pipeline on findings your policy blocks.
- Pin the digest of images you pull at runtime too, such as sidecars and Kubernetes manifests.
- Record the digests in your SBOM so you can answer which builds used which base.
Safeguard's policy gates can block a build on scan findings, and its SBOM and dependency scanning covers what ends up inside an image.
Quick check
If I pin a digest, do I still need the tag?
Keeping it helps people read the file, and Docker documents the combined form. The digest is what determines the content pulled.
Does pinning mean my base image never gets security patches?
It does until you update the digest. Automate update proposals so patches arrive on purpose and are reviewed.
Sources
Last reviewed: 18 October 2026.
