No. Kubernetes documents that tags can be moved to point to different images, while a digest is a hash of the content and cannot change. Some registries offer tag immutability as a setting, but unless you know it is on for that repository, treat a tag as a moving label and pin the digest.
What drift looks like
Tag drift is when the same name returns different content on different days. It happens in ordinary ways:
- A maintainer rebuilds a tag to pick up a patched base layer.
- A publisher pushes a new build to a version tag to fix a mistake.
- A latest or major-version alias moves to a new release.
None of these is an attack. All of them change what you run without any change in your repository, which makes failures hard to explain and scans hard to compare.
Official images show the legitimate version of this. The official-images repository says tags in the library file are rebuilt when the file is updated or when the base image is updated. So a listed tag is expected to be rebuilt, and its digest changes.
Can the publisher lock a tag?
Docker Hub documents an immutable tags setting. In repository settings, under tag mutability, the modes are: all tags mutable (the default), all tags immutable (including latest), or specific tags immutable chosen with regular expressions. With immutability on, you cannot push a new image under an existing tag name, so each new version needs a new tag.
Two things follow for a consumer. The default is mutable, so a repository does not have this protection unless its owner turned it on. And you generally cannot see from outside whether it is on, so you cannot count on it.
What to do as a consumer
- Pin by digest in Dockerfiles, Compose files and manifests. Kubernetes states that when both a tag and a digest are given, only the digest is used for pulling.
- Keep a human-readable tag next to the digest as a comment, so people know what version it means.
- Update the digest on purpose. Pull the new tag, scan it, test it, then change the digest in a reviewed pull request.
- Record the digest you scanned, so a later audit can tie a finding to exact content.
- If you publish images yourself, turn on tag immutability where your registry supports it, and use a new tag per release.
The trade-off
Pinning digests gives repeatability and removes surprise, at the price of doing updates yourself. That price is the point: updates become a visible change with a scan attached, rather than something that happens overnight. Tools that open update pull requests make the cost small.
Quick check
Is an exact version tag like 1.2.3 safe to trust as fixed?
Not unless the registry enforces immutability for it. A version tag can still be rebuilt, so pin the digest.
What if a tag and digest are both written?
Kubernetes documents that only the digest is used for pulling.
Safeguard records an SBOM for each image you scan, so you can tie findings to the exact digest rather than a moving tag. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
