A tag is a human-readable label attached to an artifact, often used to describe a version, release, or purpose such as latest or v1.1. Tags are convenient for users and pipelines, but they are mutable references, so they do not guarantee that the underlying artifact has not changed.
How Tags Work in Practice
Tags are intended to make artifact references easy for humans and automation to read. They are commonly used to mark releases, rolling labels such as latest, or purpose-based pointers, but the label itself is only a reference, not proof of immutability.
That distinction matters because a tag can be moved to a different artifact without changing the tag name. In delivery pipelines, registries, and release processes, tags are useful for convenience and workflow clarity, but they should never be treated as evidence that a specific build or image is the same one that was previously approved.
Tags Versus Immutable References
The security value of a tag is limited by its mutability. A tag tells you what an artifact is called today, not necessarily what it pointed to yesterday. That is why tags are often paired with immutable digests, commit hashes, versioned release identifiers, or signed provenance records when reproducibility and traceability matter.
This separation helps explain why teams may allow tags for consumption but rely on immutable references for enforcement. A deployment that says “use v1.1” is operationally convenient, while a deployment that pins an exact digest is materially stronger for auditability, rollback confidence, and supply-chain integrity.
SLSA is a useful companion reference because it emphasizes build provenance and integrity verification, which are the controls that tags alone cannot provide.
Security Implications of Mutable Tags
Mutable tags can create ambiguity across the software supply chain. If a tag is retargeted after review, the artifact that reaches production may differ from the one that was tested, scanned, or approved. That opens the door to integrity drift, undeclared changes, and confusing rollback behaviour.
Tags are also relevant to dependency trust. A pipeline that trusts only a tag name may miss the difference between a stable release pointer and a moving label. When that happens, security teams lose assurance that the deployed object matches the expected content, even if the tag itself looks familiar.
For artifact integrity, the stronger control is to verify the object behind the tag, not the tag name itself. Supply-chain controls, provenance checks, and cryptographic verification are the mechanisms that make tag-based workflows safer.
Common Uses and Misuses
In practice, tags are useful for human navigation, release management, and broad lifecycle labels. They are less suitable as a security boundary or a long-term trust anchor. Teams often use them correctly for convenience, then overstate their reliability when a workflow needs reproducibility.
A common misuse is assuming that “tagged” means “fixed”. Another is promoting a tag from a convenience label into a release guarantee without also introducing digest pinning, signature verification, or provenance validation. The result is a workflow that is easy to operate but weakly bound to the actual artifact.
OWASP API Security Top 10 is relevant where tags are exposed through APIs or automation, because broken authorization and weak object handling can turn convenient labels into unintended access paths.
Risk and Threat Considerations
Mutable tags can create integrity and trust risk when teams assume the label is stable while the referenced artifact is not. In a delivery pipeline, that can lead to a mismatch between what was reviewed, what was scanned, and what is actually deployed.
Failure mechanism: An attacker or insider with write access to a registry, repository, or release channel can retarget a trusted tag to a different artifact, or a benign process can overwrite the tag and silently change what downstream systems consume.
Impact: The organisation may deploy unreviewed code, lose rollback certainty, or inherit a compromised artifact under a familiar name, which undermines supply-chain integrity and incident response confidence.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI 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 | Tags affect software release integrity and trusted delivery workflows. |
| Recommendation — Pin release artifacts by immutable identifiers and verify content before deployment. | ||
| NIST CSF 2.0 | PR.DS — Data Security | Mutable tags can break integrity expectations for released artifacts and build outputs. |
| PR.IP — Information Protection Processes and Procedures | Tag-based workflows need release procedures that distinguish convenience labels from approved artifacts. | |
| Recommendation — Protect artifact integrity by validating the exact object, not only its label. Document release handling so approval ties to immutable references and provenance checks. | ||
| OWASP Agentic AI Top 10 | UNKNOWN — Supply Chain and Dependency Integrity | Mutable labels can mislead automated delivery and tool-driven consumption of artifacts. |
| Recommendation — Have automated systems consume immutable artifact references and verify provenance before use. | ||
