Sign and verify the digest because a tag is a movable label, while a digest is a hash of the exact content. A signature tied to a tag name proves little once the tag points somewhere else. A signature tied to a digest stays attached to those exact bytes.
Tag versus digest
Docker's documentation on digests puts it plainly: tags can be reused or changed, while a digest is a SHA-256 hash of the image content, so any change to the image produces a different digest. That is the property a signature needs.
| Tag | Digest | |
|---|---|---|
| Example form | name:1.4 | name@sha256 followed by the hash |
| Can it point to new content later? | Yes | No |
| Safe as a trust anchor? | No | Yes |
| Good for humans to read? | Yes | No |
Multi platform images add a detail. A tag usually points to a manifest list, which references a separate digest for each platform. The manifest list digest identifies the whole multi platform image. To pin one platform, use that platform's digest.
What cosign does with the digest
The cosign documentation says signature payloads include the image digest and that, by default, cosign checks that the digest matches the container during verification. Its container signing examples set the image variable to a digest reference. Signatures are stored in the registry using the OCI 1.1 referrer specification, and the cosign tree command shows what is attached to an image.
The docs I reviewed did not include an explicit warning about signing by tag, so treat this as good practice backed by how digests work rather than a quoted rule.
A safe routine
- In CI, build and push, then capture the digest from the push result.
- Sign the digest reference, not the tag.
- Record the digest in your deployment manifest.
- At deploy time, verify the signature and the expected identity against that same digest.
- Reject manifests that reference a bare tag in production.
A short example of the shape, in a shell:
IMAGE=registry.example.com/app@sha256:<digest>
cosign sign "$IMAGE"
cosign verify "$IMAGE" \
--certificate-identity=name@example.com \
--certificate-oidc-issuer=https://accounts.example.com
The failure this prevents
Imagine you verify a tag at 9am and deploy at 10am. If the tag moved in between, you deployed something you never checked. Verifying and deploying the same digest closes that gap, because both steps refer to bytes rather than a name.
Where Safeguard fits
Safeguard can scan container images for vulnerabilities, and policy gates can stop a release that fails your rules. Try the demo below or run the free scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Scan an image in the demo and notice that findings attach to a specific image build, which is the same idea as pinning a digest.
Quick check
Is it enough to verify a signature on latest?
No. The tag can move after you check it. Resolve to a digest, verify that, and deploy that same digest.
Do I need a digest per platform?
If you must pin one platform, yes. The manifest list digest identifies the full multi platform image, and each platform has its own digest.
Sources
Last reviewed: 19 October 2026.
