What breaks when a dependency tag can be rewritten after publication?

Why This Matters for Security Teams

A dependency tag that can be rewritten after publication breaks the core trust model behind software supply chains: a name no longer guarantees a stable artifact. That creates a gap between review and runtime, where a package that passed approval can later resolve to different code. The risk is especially acute for build systems, automation, and NHI-backed CI/CD pipelines that assume dependency references are immutable once accepted.

NHI Management Group has repeatedly shown how often identity and secret assumptions fail in practice, including the Ultimate Guide to NHIs, which notes that 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage. Mutable tags create a similar failure mode for supply-chain trust: the reference is visible, but the resolved content can change underneath it. The result is unreviewed code entering production without a new change record, a new approval, or a new security scan.

For security teams, this is not just a packaging issue. It affects provenance, change control, artifact integrity, and incident response. The moment a tag can be repointed, ordinary dependency updates stop being deterministic, and rollback procedures become unreliable unless the original commit SHA and artifact hash are preserved. In practice, many security teams discover this only after a trusted dependency has already been republished and consumed by automated pipelines.

How It Works in Practice

The practical control is to treat tags as human-friendly labels and immutable digests as the security boundary. A secure pipeline should pin dependencies to commit SHAs, signed release hashes, or immutable artifact references, then verify those references at fetch time and again before deployment. This is the same general principle behind NIST Cybersecurity Framework 2.0: identify what is trusted, protect it, detect changes, and respond when integrity cannot be proven.

Operationally, teams should maintain three checks:

• Reference control: reject mutable tags in production manifests unless the tag is resolved to an approved immutable digest.
• Artifact verification: compare downloaded package hashes against a trusted lockfile or provenance attestation.
• Change detection: alert when a published tag now points to a different commit than the one originally approved.

This is especially important for package registries, container images, and build dependencies consumed by CI/CD, where automation can pull updates faster than reviewers can notice drift. The LiteLLM PyPI package breach is a good example of how packaging trust can be undermined when release mechanics and dependency consumption are not tightly controlled. A mutable tag is not inherently malicious, but it becomes unsafe the moment the organisation treats it as a permanent identity for code. These controls tend to break down when build pipelines auto-refresh dependencies from public registries because there is no enforced digest pinning at ingestion time.

Common Variations and Edge Cases

Tighter pinning often increases operational overhead, requiring organisations to balance reproducibility against release agility. That tradeoff is real, especially for teams shipping frequently or consuming fast-moving open-source libraries. Best practice is evolving, but current guidance suggests that mutable tags can exist for developer convenience while production systems rely on immutable references and explicit promotion workflows.

There are a few common edge cases. Pre-release tags may be intentionally reused in test environments, but they should never be treated as production-grade trust anchors. Some ecosystems expose both version tags and content digests, and the digest should win whenever integrity matters. Internal mirrors and artifact repositories also help, but only if they preserve provenance and do not silently overwrite stored artifacts. The key distinction is simple: a tag tells you what something was called, while a digest tells you what it actually is. When that distinction is ignored, dependency drift can look like a routine update instead of a supply-chain compromise.

For broader NHI governance, the same integrity problem shows up whenever automation depends on weakly controlled secrets or service identities. The Ultimate Guide to NHIs is useful here because it frames identity trust, rotation, and visibility as lifecycle controls, not one-time setup tasks. In mature environments, dependency integrity is treated as part of the same control plane as secret rotation and provenance enforcement.

Related resources from NHI Mgmt Group

• What breaks when a malicious dependency is resolved during npm install?
• What breaks when legacy APIs are left online after they are no longer needed?
• What breaks when a dependency uses build scripts to read private source trees?
• Should organisations prioritise secret rotation or dependency review after a package compromise?