What breaks when teams sign container images or packages using registry tags instead of digests?

When teams sign by tag, the signature can end up attached to the wrong artifact if the tag changes after build but before signing. That breaks the trust chain because verification may still succeed on a malicious image that now carries a valid signature. The failure is not in cryptography, but in referencing a mutable object instead of immutable content.

Why tag-based signatures break trust in content-addressed systems

Tags are pointers, not immutable content. If a team signs “the thing behind the tag,” the object being verified can change between build, promotion, signing, and deployment. That means the signature may still be cryptographically valid while no longer describing the artifact that was actually built or reviewed. The practical failure is a broken binding between policy and content.

This is why digest-pinned workflows are the safer default in container and package supply chains. A digest identifies a specific byte sequence, so the signature is attached to the exact artifact that was produced. A tag can be reassigned, rebuilt, or repointed, which makes it unsuitable as the stable reference for attestations, approvals, or provenance checks.

That distinction matters for release automation as much as for security. If a tag is reused, a registry syncs late, or a signing job runs after a rebuild, verification can quietly confirm a different image than the one intended. The system appears healthy because the signature verifies, but the trust chain has shifted to a new artifact.

For container and package ecosystems, the principle is the same: sign immutable content, not mutable labels. This is especially important where registries, mirrors, build pipelines, and deployment controllers all resolve references at different times. The more handoffs there are, the more opportunity there is for a tag to drift away from the artifact that was actually assessed.

When the question is how to preserve provenance, the answer is to make the digest the security boundary and treat the tag as human-friendly metadata only. That keeps verification deterministic and avoids false assurance caused by mutable references.

What failure modes show up in real release pipelines

Teams usually see this bug as a mismatch between intent and evidence, not as a broken cryptographic primitive. The build may sign one image, but the registry tag later points to another image after a retag, rebuild, or overwrite. Verification still passes because it checks the signed reference, while the runtime pulls the newer content behind that reference.

That creates three common failure modes. First, provenance can be attached to the wrong artifact. Second, policy engines can approve a release that no longer matches the reviewed build. Third, incident responders may trust a signed artifact that has actually been replaced in the registry, slowing triage and increasing the chance of missed malicious content.

The safer pattern is to resolve the artifact by digest at build time, sign that digest, and deploy by digest wherever the platform allows it. If a tag is still needed for usability, it should be derived from the same immutable artifact, not used as the trust anchor. For container-focused guidance, NIST SP 800-190 Container Security is the clearest external reference for treating image, registry, and runtime boundaries as separate trust points.

Packages follow the same logic. A package name or version label can be republished, replaced, or mirrored, but the signed content identifier is what preserves integrity. In supply chain terms, the goal is not simply to know that “something” was signed, but to know exactly which bytes were signed and later verified.

Risk and Threat Considerations

Mutable references are attractive to attackers because they create a timing gap. If an adversary can influence the registry entry, retag process, or downstream resolver after signing, they may be able to swap in different content while preserving a valid-looking approval path. The cryptography remains intact, but the control is applied to the wrong object.

Failure mechanism: The signing workflow binds trust to a label that can be reassigned, so verification succeeds against a later artifact rather than the reviewed one.

Impact: A malicious image or package can inherit a trusted signature, bypass provenance checks, and reach deployment or execution with the appearance of legitimacy.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS 16 — Application Software Security	Signed artifacts are a software supply chain integrity control.
Recommendation — Enforce artifact integrity checks on immutable digests before release and deployment.
NIST CSF 2.0	PR.DS — Data Security	Digest-based signing preserves integrity of the released artifact and its provenance.
	PR.AC — Identity Management, Authentication and Access Control	Verification must bind authorization to the exact artifact, not a mutable reference.
	GV.SC — Cyber Supply Chain Risk Management	Tag drift is a supply-chain trust failure across build, registry and deployment stages.
Recommendation — Protect release artifacts by validating immutable content identifiers at each trust boundary. Require deployment controls to authorize the specific signed digest rather than the tag. Govern supply-chain trust by pinning signatures and approvals to immutable artifacts.
OWASP Non-Human Identity Top 10	NHI-01 — Secrets and Credential Management	The same trust-chain failure class applies when mutable references protect identity-bearing material.
	NHI-04 — Trust and Authorization Boundaries	Signing the wrong reference breaks the boundary between reviewed content and trusted content.
	NHI-09 — Supply Chain and Third-Party Risk	Registry tags can drift between creation and deployment, creating supply-chain exposure.
Recommendation — Treat any identity-bearing artifact as immutable before signing or approval. Bind trust decisions to immutable artifact references across registries and pipelines. Pin supply-chain controls to digests so downstream consumers verify the intended artifact.

Practitioner Guidance

What to verify: Confirm that every signing, admission, and verification step uses the immutable digest, not a tag-derived lookup. If any tool resolves tags implicitly, treat that as a release-control defect rather than a convenience feature.

Common mistake: Teams often fix signing and still leave deployment, scanning, or policy enforcement pointed at tags. That leaves the pipeline consistent enough to pass tests, but inconsistent enough to approve the wrong artifact.

Practitioner takeaway: The control objective is referential integrity, not just signature validity, so the trusted object must be the exact content that will run, not a mutable name that can be repointed later.