Pin the base image to a digest so every build uses exactly the same bytes, then let an update bot open pull requests when a newer image appears. Docker's guidance says a digest guarantees the same image even if a publisher replaces the tag, at the cost of opting out of automatic security fixes.
Tag versus digest
A tag such as a CUDA or PyTorch version label is a movable pointer. A publisher can push a new image under the same tag. A digest is a content hash of the image, so it only ever means one thing.
| Tag | Digest | |
|---|---|---|
| Readable | Yes | No |
| Same bytes next month | Not guaranteed | Guaranteed |
| Gets fixes automatically | Yes, on rebuild | No |
| Protects against a swapped tag | No | Yes |
Docker's best practices page frames it this way: to secure supply chain integrity you can pin the image version to a specific digest, and you are then guaranteed the same version even if the publisher replaces the tag. It names the trade-off plainly: you opt out of automated security fixes.
Why ML teams feel this more
ML base images are large, slow to pull, and tied to a specific driver and framework combination. When a rebuild changes the base image underneath you, results can shift and bugs can appear that nobody can reproduce. Pinning protects reproducibility as much as security. It also gives you one thing to point to when you record which image trained which model.
How to pin
Write the tag for humans and the digest for machines:
FROM python:3.12-slim@sha256:REPLACE_WITH_REAL_DIGEST
Find the digest by pulling the image once and reading it from your registry or runtime, then paste it. Never invent or guess one. Keep the tag beside it as a comment so readers know what it was meant to be.
Keep patches flowing
The docs suggest using Dependabot with the docker package ecosystem, which opens pull requests to update tags and digests. That keeps you in control. Each pull request is a small change to review, scan, and test with a short training run before merge.
A workable cadence:
- Let the bot open update pull requests weekly.
- Scan the new image for known vulnerabilities.
- Run a smoke training job on a small dataset.
- Merge, and record the new digest with the next model you ship.
- For a serious vulnerability, do not wait for the weekly run.
Common mistakes
- Pinning once and never updating, which turns a supply chain control into stale software.
- Pinning the final image but not the build stage image.
- Copying a digest from a blog post rather than from your own pull.
See also how to enable GPUs in Docker safely and how to scan a GPU inference container image.
Try it yourself
Click through it at your own pace, or open it full screen. Look at what a scan reports for the packages inside an image.
Safeguard scans container images and dependencies, and a free scan is at gold.safeguard.sh/scan.
Quick check
Does a digest prove the image is safe?
No. It proves the image is the same one you reviewed. You still need to scan and review it.
Should every FROM line be pinned?
Pin every image that ends up in a build you rely on, including build stages.
Sources
Last reviewed: 19 October 2026.
