What breaks when a Composer package tag is rewritten after release?

Why a rewritten Composer tag breaks trust in the release

A Composer tag is supposed to be an immutable pointer: package consumers expect a version string to resolve to one commit, one artifact, and one release history. When that tag is rewritten after publication, the package name still looks familiar, but the trust relationship changes underneath it. The break is not just technical, it is evidentiary, because version-based trust can no longer be assumed.

That matters because dependency tooling, release management, and security review often treat the tag as a stable reference. If the reference moves, the same version can mean different code at different times, which undermines reproducibility and weakens any assurance built on the original release.

Composer itself is only the delivery path here, but the real issue is release integrity. A tag rewrite creates a mismatch between human-readable versioning and source-of-truth code state, so the question is not “what version is installed?” but “what commit does that version resolve to right now?”

What fails in lockfiles, updates, and audit trails

Lockfiles rely on a stable resolution event. If a tag is rewritten after a lockfile was generated, the lockfile may still name the same package version while future installs or refreshes resolve to different content. That can create drift between build output, local development, and CI pipelines even when everyone believes they are using the same dependency set.

Update pipelines are affected in a similar way. Automated dependency refreshes, rebuilds, and validation jobs may ingest the rewritten tag and produce a new binary or package graph without any visible version bump. That is especially dangerous when the pipeline assumes semantic versioning is enough to distinguish trusted from changed code.

Audit trails are also weakened. A version tag that changes after release makes historical records less reliable because an investigation may point to a trusted name while the underlying source has already shifted. For supply chain review, provenance evidence must therefore bind to the resolved commit, not just to the package label.

For release integrity and source verification, the relevant control objective is the same: SLSA focuses attention on build provenance, while NIST Cybersecurity Framework 2.0 helps teams treat software supply chain integrity as a governed security outcome rather than a tooling detail.

How to tell whether a tag rewrite has become a supply-chain problem

The practical warning sign is any process that trusts a version identifier more than the resolved source. If your controls only record “package x at version y” without pinning the commit hash, you do not actually have immutable provenance. That gap can let a rewritten tag pass through as a normal update, even though the code behind it has changed.

This is most serious when downstream systems cache or promote dependencies automatically. A rewritten tag can silently invalidate prior testing, because the package that passed review is no longer the same package a later build resolves. The control failure is not merely hash mismatch, it is trust in a mutable release reference.

Source authenticity and dependency visibility are central here. OpenSSF is useful for teams building supply-chain hygiene around provenance and dependency trust, and NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces why configuration, integrity, and audit controls need to cover the actual artifact source, not only the package label.

Practitioner Guidance

What to verify: Treat the resolved commit, archive digest, or signed provenance record as the authoritative object, and verify that it still matches the tag you originally approved. If your workflow cannot prove that a tag has remained anchored to the same source, do not rely on the tag alone for release trust.

Decision rule: If a package version can be re-resolved to different code, freeze consumption to a known commit or immutable artifact and require a fresh review before promotion. If the release process depends on mutable tags, the process is the weak point, not the package manager.

Common mistake: Teams often treat a green dependency update as proof of safety when it only confirms that the current tag resolves cleanly. The real control is provenance continuity, not successful retrieval.

Practitioner takeaway: A rewritten tag turns versioning from a stable reference into a moving target, so the durable control is to validate source identity and artifact integrity at resolution time, not to trust the version string by itself.

Related resources from NHI Mgmt Group

• What breaks when a dependency tag can be rewritten after publication?
• What breaks when a Composer package uses eager autoloaded files and a tag is force-pushed to a malicious commit?
• What breaks when configuration profiles are not refreshed after an Apple release?
• What breaks when medical device security is only checked after release?