Why do mutable tags create supply chain risk for signed artifacts?

Why mutable tags break artifact integrity

Mutable tags create a trust gap between what the pipeline thinks it is signing and what is actually stored in the registry. A tag can be reassigned after review but before signing, so the label no longer proves content. That is why digest-pinned references are the safer boundary for signed artifacts, they preserve content identity instead of relying on a changeable pointer.

In a supply chain, the danger is not limited to accidental drift. A tag that once pointed to a clean build can later point to a tampered image, package, or bundle, while the human-readable name stays unchanged. That makes tag-based approvals fragile in any workflow where fetch, verify, and sign are not atomically bound to the exact bytes being released.

Artifact integrity depends on a stable identifier that survives registry writes, cache refreshes, and rebuilds. Digest-based references do that because the hash is derived from the content itself. For signed release workflows, the practical rule is simple: if the reference can be changed without changing the object you intended to trust, it is not a safe basis for attestation or signing.

Where the supply chain failure happens

The failure window usually appears between selection and signing. A build system, release bot, or approver may resolve a tag to an image or package, inspect it, and then sign what it believes is the same object later in the pipeline. If the tag moved in between, the signature can end up endorsing a different artifact than the one that was reviewed, tested, or promoted.

That risk becomes more serious when tags are reused for release channels such as SLSA style provenance workflows, because provenance only helps if the artifact reference is immutable at verification time. The same logic is why secure software delivery guidance emphasizes pinned inputs and verifiable build outputs, not moving labels. NIST SSDF (SP 800-218) and OpenSSF both reinforce that release integrity depends on traceable, reproducible, and verifiable artifacts.

Mutable tags also weaken incident response. When a bad release is found, responders need to know exactly which bytes were signed, distributed, and deployed. If the registry label has shifted over time, you lose forensic clarity and may misidentify the compromised object, which complicates rollback, blast-radius assessment, and re-signing.

How teams should structure signing and verification

The cleanest control is to resolve tags only for convenience, then convert to immutable digests before any trust decision. Signing, verification, promotion, and deployment should all operate on the digest or another content-derived identifier. If a platform or policy forces tag use, treat that as a weaker state and require an additional check that binds the tag to a recorded digest at the moment of approval.

For practitioners, the key question is whether the signing step can be bypassed by a later registry change. If yes, the control is not strong enough. If no, because the pipeline records and enforces the exact digest, then the signature meaningfully attests to the artifact rather than to its label. That is the distinction that prevents tag hijack from becoming a release compromise.

One useful operational habit is to retain the resolved digest in build metadata, provenance records, and deployment manifests. That gives release engineering, security review, and incident response the same stable reference. It also makes drift obvious when a tag and its recorded digest no longer match, which is often the earliest sign that the pipeline trusted the wrong object.

Risk and Threat Considerations

Mutable tags create a classic substitution risk: the trusted name stays stable while the underlying artifact changes. An attacker who can rewrite a tag, compromise a registry entry, or influence an upstream publishing step can redirect the pipeline toward a malicious payload without needing to change the visible release name.

Failure mechanism: The pipeline signs or promotes the artifact after resolving a tag, but before the exact content is bound into the trust decision. If the tag is moved during that window, the signature can apply to an unintended object and the registry label will continue to look legitimate.

Impact: Released artifacts may carry a valid-looking signature on attacker-controlled content, which undermines provenance, rollback confidence, and downstream trust in deployment and verification controls.

Practitioner Guidance

What to verify: Confirm that every signing and verification path records and checks the immutable digest, not just the tag string. If a release record cannot prove which bytes were signed, treat it as insufficient for production promotion.

Decision rule: If the artifact reference is mutable at any point between review and signing, require digest pinning or a comparable content-bound control before release. If you cannot enforce that, assume the pipeline is signing a label, not an artifact.

Practitioner takeaway: The control objective is to make the signed object impossible to confuse with a later replacement, because once trust is attached to a mutable label, the release process can be redirected without visibly changing the name.

Related resources from NHI Mgmt Group

• Why do mutable action tags create such a high supply chain risk in CI/CD?
• Why do mutable GitHub Action tags create so much risk in a supply chain attack?
• Why do mismanaged tags create supply chain risk in DevOps and application security?
• Why do supply-chain attacks create such a large IAM and NHI risk?