iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Not by itself. A Docker image tag is a mutable registry label, so the same tag can point to different image bytes later. A digest pins the exact content you reviewed, while signature verification provides evidence about who signed that content. Reliable deployments use all three deliberately: keep a tag for human context, deploy the recorded digest, and require a signature from an identity your policy explicitly trusts.
What a tag, digest, and signature actually tell you
These three references answer different security and operations questions. Confusing them is why a deployment can be repeatable yet still come from an unexpected publisher, or appear to come from a trusted publisher while running content that changed after review.
| Control | Question it answers | What it establishes | What it does not establish |
|---|---|---|---|
| Tag | Which human-readable release label should I use? | A convenient registry name such as latest or a version-looking label. |
That the label will continue to identify the same bytes, or that the publisher is trustworthy. |
| Digest | Which exact content should I retrieve? | A content-addressed image reference that selects one specific image manifest and its referenced content. | Who produced the image, whether it is benign, or whether it includes the newest security fixes. |
| Signature | Does this artifact verify under my signer and identity policy? | Evidence that a signer attested to a digest, when the signature, identity, issuer or key, and policy all validate. | That an untrusted signer is acceptable, or that the image is safe merely because a signature exists. |
Docker’s Compose guidance states the operational risk plainly: “Tags are mutable, meaning anyone with push access to a registry can overwrite a tag silently, so a reference you reviewed last week may point to different content today.” That applies to familiar release labels as well as latest; a tag that looks like a version is still a name that can be repointed.
Why Docker tags are mutable
A tag is a pointer maintained by a registry. When an authorized publisher pushes another manifest under the same tag, the pointer can move without changing the text in your Compose file, deployment manifest, or shell history. A later pull therefore may retrieve different layers, configuration, or software versions than an earlier pull.
#1 Best Overall
Common ways a tag changes
- A publisher rebuilds a release to include a dependency or operating-system security fix and pushes it under the existing release tag.
- An automated build promotes a new image to a channel tag such as
stableorlatest. - A registry administrator or compromised account overwrites the tag with an unrelated image.
- A mirror or replication process updates its tag pointer at a different time from the source registry.
None of these events requires a consumer to edit the tag in a deployment file. If your production system resolves the tag at deployment time, the result can change between runs. A review performed last week is therefore not proof of what the same tag will deliver today.
Why a version-looking tag is not an immutable version
Labels such as 2.4.1, 2026-09, or release-candidate are easier for people to read than digests, but they have no built-in immutability guarantee. Whether a registry prevents overwrites is a separate registry policy, and a consumer should not assume that policy exists or is enforced everywhere. Treat every tag as mutable unless you have verified an explicit, enforceable immutability policy and still record the resolved digest.
What an image digest pins
A digest reference uses the repository name, an @ separator, and a content digest, for example ubuntu@sha256:<digest>. Docker describes this as pinning an image to a specific version in time. The registry resolves that content-addressed reference to the manifest identified by the digest rather than resolving a moving tag.
Recommended Free Tools
Benefits of digest pinning
- Repeatability: the same digest reference selects the same image content whenever that digest remains available in the registry.
- Change detection: a code review shows an explicit digest change instead of hiding a content change behind an unchanged tag.
- Auditability: incident records and deployment logs can identify the exact artifact that ran.
- Safer promotion: development, staging, and production can all deploy the same reviewed digest while retaining different environment configuration.
What pinning does not do
Pinning is not an update mechanism. Docker’s pull guidance warns that a digest-pinned reference needs a deliberate update to move to newer content. If the publisher releases a vulnerability fix under a new digest, a workload pinned to the old digest will continue running the old image until someone reviews and changes the reference.
A digest also says nothing about publisher identity or image behavior. An attacker can publish a malicious image and give you its digest; that digest will still identify the malicious bytes consistently. Content identity and publisher authenticity are separate properties.
Rank #2
Why signatures add a different security check
A signature can bind an attestation to an image digest and a signer identity, key, or certificate chain. Verification asks whether the signature is valid for the exact digest you are about to deploy and whether the signer satisfies your trust policy. This is stronger than checking that a tag exists, but it is not a substitute for deciding which identities are allowed.
Digest binding matters
Container-signing systems include the image digest in the signed payload. Sigstore’s Cosign documentation says digest matching is checked by default. If a signature was made for one digest and the registry reference resolves to another, verification should fail rather than silently accepting the changed content.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesIdentity constraints matter just as much
A mathematically valid signature from an unexpected account, workflow, or issuer is not a reason to run an image. Your policy should name the expected publisher identity and the OpenID Connect issuer or trusted key. Avoid wildcard identity constraints in production unless your organization has deliberately evaluated their scope; accepting any identity can turn signature presence into a false sense of security.
How to verify an image with Cosign
The exact identity and issuer values must come from the image publisher’s documented signing policy. The command form below illustrates the checks rather than supplying a universal trust policy.
- Choose the exact image reference. Resolve the tag you intend to review and record the resulting digest. Keep the human-readable tag in release metadata, but use the digest as the deployment reference.
- Identify the expected signer. Obtain the publisher’s documented certificate identity, workflow identity, issuer, or public key. A repository name alone is not an identity policy.
- Run verification with identity and issuer constraints.
cosign verify <image-uri> --certificate-identity=<expected-workflow-or-publisher-identity> --certificate-oidc-issuer=<expected-oidc-issuer> - Inspect the result. Require a successful signature check, a digest that matches the image you will deploy, and an identity and issuer that match your approved policy. Treat any mismatch, missing signature, or unexpected certificate as a deployment failure.
- Record the evidence. Store the image name, tag used for discovery, immutable digest, verification output, signer identity, issuer or key reference, and verification time with the release record.
Cosign also documents key-based verification. Key-based and identity-based approaches can both be valid; the choice depends on how the publisher provisions, rotates, revokes, and audits keys or workload identities, and on where your deployment platform enforces the policy.
Rank #3
- Made in USA - Proudly produced in Ohio by a Veteran-owned business
- Comprehensive Coverage: This BookFactory log book includes essential fields such as post/shift, time of change, date, weather conditions, and a designated space for detailed notes. This ensures that all relevant information is captured and easily accessible.
- Sturdy Cover: The trans-lux cover protects the log book from wear and tear, ensuring its longevity and maintaining the integrity of your recorded data.
- Essential Security Tool: This log book is an indispensable tool for any organization that values security and accountability. It helps to prevent misunderstandings, improve communication, and ensure a smooth transition between shifts.
- Wire-O with Trans-lux cover, 100 Pages, Dimensions 8.5" x 11" - (Security-Pass-Down) Reorder SKU: LOG-100-7CW-PP(Security-Pass-Down)
Do not verify only the tag
Verifying a signature against a tag without recording the resolved digest leaves a race between review and deployment. Resolve the tag, verify the digest that was resolved, and deploy that digest. If the tag moves afterward, the production reference remains unchanged.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteDocker Content Trust and the Notary v1 retirement
Docker Content Trust (DCT) associates trust metadata with tags and is disabled by default in the Docker client. Docker documents enabling it with the DOCKER_CONTENT_TRUST=1 environment variable. That legacy workflow is time-limited: Docker says the Notary v1 service at notary.docker.io is scheduled to shut down on December 8, 2026.
The retirement date means a command that works today is not a durable assurance that the service will remain available for the life of your deployment. Docker’s official material points users toward Sigstore and Notation as migration alternatives. Before standardizing a migration, confirm the current Docker documentation, your registry’s support for signatures, and the enforcement capabilities of your deployment platform.
What the DCT caveat changes for operators
- Do not claim that a tag is signed merely because it exists or because it resembles a signed release label.
- Do not design a new long-lived policy around Notary v1 without an explicit migration plan.
- Do not assume that switching from a tag to a digest automatically preserves publisher authentication; digest pinning and signature verification remain separate controls.
- Test how your registry stores, serves, and garbage-collects signatures before changing production enforcement.
A deployment workflow that combines all three controls
The most practical pattern is to use a tag for discovery and a digest plus signature for release authorization.
- Discover: select a publisher’s documented release tag, such as a channel or version label.
- Resolve: obtain the manifest digest associated with that tag at the time of review.
- Review: inspect the image provenance, build context, dependency changes, and vulnerability findings required by your organization.
- Verify: check the signature against the exact digest and require the expected signer identity, issuer, or key.
- Record: commit the digest and verification metadata to the deployment change. Preserve the tag only as human-readable context.
- Enforce: make CI, an admission controller, or another deployment gate reject unsigned images, unexpected identities, or tag-only references where policy requires digests.
- Monitor: track new publisher releases and security advisories separately from running production content.
This separation gives operators a readable release name without allowing the name to silently select new bytes. It also makes an emergency rollback precise: restore the previously approved digest, then investigate the newer release independently.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
How to update a pinned image safely
Digest pinning creates an explicit update decision rather than eliminating updates. Use a repeatable review path:
- Watch the publisher’s release and security channels for a new version or urgent fix.
- Resolve the candidate tag to its current digest and compare it with the digest currently deployed.
- Verify the candidate digest’s signature using the approved identity and issuer or key policy.
- Review image changes, provenance, vulnerability results, and compatibility in a non-production environment.
- Update the deployment manifest to the new digest, retain the tag and review date in release metadata, and obtain the required approval.
- Deploy through the normal gate and confirm that the runtime reports the expected digest.
Do not “refresh” a digest-pinned workload by pulling the same reference and assuming it has changed. A digest reference is intentionally stable; a new image requires a new digest and a reviewed change.
Choosing a signing and verification workflow
Cosign and Notation are named by Docker as migration alternatives, but the available evidence does not establish a feature-by-feature winner. Select a workflow by testing the controls that affect your environment.
| Decision area | Questions to answer |
|---|---|
| Identity and trust policy | Can verification constrain the expected publisher, build workflow, certificate issuer, or public key? Can policy reject every other identity? |
| Digest binding | Does verification prove that the signature covers the exact image digest that deployment will retrieve? |
| Enforcement point | Will checks run as a manual review, CI gate, admission or deployment control, or runtime policy? |
| Registry and signature storage | Can your registries store and retrieve signatures through the OCI workflows and replication paths you actually use? |
| Key and identity lifecycle | How are credentials provisioned, rotated, revoked, and audited, and who responds when a key or workflow identity is compromised? |
| Update process | Who reviews a new digest, how are fixes adopted, and how is the change linked to the release record? |
A tool is only one part of the control. A signature that no deployment system checks, or a policy that accepts every identity, does not provide meaningful release authorization.
Failure modes and practical fixes
The tag changed after approval
Symptom: the digest resolved in production differs from the digest reviewed in the change request. Fix: stop relying on the tag at deployment time; commit and deploy the approved digest, then investigate who moved the tag and whether registry access was abused.
Best Value
The digest is stable but contains a known vulnerability
Symptom: scanners identify a fix released after the pinned image was approved. Fix: resolve the publisher’s newer release, verify its signature, test it, and make an explicit digest update. Stability does not equal freshness.
Signature verification succeeds for the wrong signer
Symptom: the cryptographic check passes, but the certificate identity, issuer, or key is not the one your organization expects. Fix: fail the deployment and tighten the identity or key constraint. Signature validity alone is insufficient.
Verification cannot find a signature
Symptom: the image pulls successfully but the signature lookup fails. Fix: check that the publisher signs the exact digest, that your registry preserves signature artifacts, and that network or mirror policies permit retrieval. Do not bypass the check by accepting an unverified tag.
A legacy DCT command stops working
Symptom: a workflow depending on Notary v1 fails during or after the planned service retirement. Fix: move to a supported signing and verification workflow, validate it in the registry and deployment controls you use, and document the migration before the December 8, 2026 shutdown date.
What to put in a production release record
- Repository and human-readable tag used for discovery.
- Resolved image digest and the registry from which it was obtained.
- Signature verification result for that digest.
- Expected signer identity and certificate issuer or trusted key.
- Verification timestamp and the software or policy version used.
- Review approvals, test evidence, and the reason for any digest update or rollback.
Keeping both the tag and digest preserves readability without treating the tag as an authority. During an incident, the digest tells responders exactly which content ran; the signer evidence helps them determine whether it came from the expected build path.
Bottom line for teams deciding what to trust
Trust a Docker image through layered checks, not through a label. Tags are useful pointers but can move silently. Digests make the selected content repeatable but do not identify its publisher or guarantee security updates. Signatures connect a digest to a signer, yet only an explicit identity, issuer, or key policy makes that evidence meaningful. For new systems, require digest references, verify signatures against the exact digest, enforce the accepted signer policy in CI or deployment controls, and treat Docker Content Trust’s Notary v1 shutdown on December 8, 2026 as a migration deadline rather than a permanent solution.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →
