For production, yes. Kubernetes documents that a digest is a hash of an image's content and is immutable, while a tag can be moved to a different image. Using a digest in Helm values means the cluster runs exactly what you scanned. Pair it with a readable tag in the same reference so humans can follow along.
Tag versus digest
The Kubernetes documentation explains that tags identify different versions of a series of images, and that digests are a unique identifier for a specific version. Tags can be moved to point to different images, but digests are fixed. If you give no tag, Kubernetes assumes latest, and the docs advise avoiding the latest tag in production because it is harder to track which version runs and harder to roll back.
If a reference has both a tag and a digest, only the digest is used for pulling. The documentation's example shows the tag and digest together in one reference. That gives you a label for people and a lock for machines.
Why this matters for Helm users
Most charts expose image settings in values, usually a repository and a tag. The default tag is often a version the chart author tested. Three things can go wrong with tags:
- The publisher re-pushes the tag, either by mistake or on purpose.
- A mirror updates a tag at a different time than the original.
- Your scan result applies to the image as of the scan, while the node pulls whatever the tag resolves to later.
A digest closes all three. The scan, the review and the running pod refer to the same bytes.
How pull policy interacts
The imagePullPolicy and the tag together decide when the kubelet fetches an image. With IfNotPresent, a node that already has an image under that name will not check again. With Always, the runtime resolves the tag to a digest each time a container starts and pulls any missing layers. Two nodes can therefore run different images under the same tag if the tag moved between pulls. With a digest, they cannot.
Putting digests into values
A values schema can require them. See can values.schema.json stop risky Helm settings. A simple layout uses separate fields for repository, tag and digest, and the chart template composes them, using the digest when present. If the chart you consume does not support a digest field, many allow overriding the full image string, or you can use a post-renderer or overlay to set it. Review whichever route you choose against the rendered output.
A workflow that stays readable
- Build and scan the image in CI.
- Record the digest that passed.
- Update values with the tag and digest together, through a pull request.
- Let reviewers see the tag, the digest and the scan result in one place.
- Promote the same digest through environments, rather than rebuilding.
- Re-scan on a schedule, because new vulnerabilities appear after a build.
Promoting one digest from staging to production means the thing you tested is the thing you ship, which also helps incident response, because you can search for a digest across clusters.
What a digest does not solve
A digest does not mean an image is safe. It only means it is stable. An image with a known vulnerability stays vulnerable at the same digest. You still need scanning and a plan for updating when a fixed base image appears. If you use a multi-architecture image, check whether your digest points to the index or a single platform image, because the two differ.
Where a scanner fits
Safeguard's container scanning and SBOM generation attach findings to a specific image, and continuous monitoring can flag new vulnerabilities in images you already run. Policy gates can block a pull request that deploys an unscanned reference. Free scan: gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice that results belong to one image version, which is the reason to deploy that exact version by digest.
Quick check
What happens if I give both a tag and a digest?
Kubernetes uses only the digest for pulling, according to its documentation. The tag stays as a human readable label.
Is latest acceptable in production?
The Kubernetes documentation advises avoiding the latest tag in production. Use a meaningful version tag and, ideally, a digest.
Sources
Last reviewed: 19 October 2026.
