A tag force-push rewrites a Git tag to point to a different commit after the tag already existed. In software supply chains, this can silently swap trusted release content for malicious code while leaving lightweight monitoring blind. Defenders should alert on tag mutation, not just new tag creation or deletion.
Expanded Definition
A tag force-push is a post-creation change to a Git tag reference, redirecting the tag from one commit to another. In release engineering, that matters because tags often serve as human-readable anchors for signed builds, provenance checks, and downstream automation. When a tag is rewritten, the visible name may stay the same while the referenced content changes, which can undermine trust in software delivery and artifact verification.
This term sits at the intersection of source control governance and software supply chain security, where integrity depends on stable references as much as on code review. Under the NIST Cybersecurity Framework 2.0, the practical concern is asset integrity and change control, even though Git itself does not impose a universal prevention model for tag mutation. Usage in the industry is still evolving because some teams allow tag retargeting for exceptional release fixes, while others treat any tag rewrite as a policy violation.
The most common misapplication is assuming that a tag name is immutable once published, which occurs when teams monitor new tag creation but do not detect tag updates or force-push events.
Examples and Use Cases
Implementing tag immutability rigorously often introduces release-management friction, requiring organisations to weigh fast hotfix workflows against the integrity of published version references.
- A build pipeline consumes release tags to fetch source for packaging, and a force-push silently points the same tag at a different commit.
- A security team verifies that a signed release corresponds to tag
v1.4.2
, but a later tag rewrite breaks the link between the signature review and the code that is actually deployed.
- An attacker compromises a maintainer account and retargets a stable tag to a malicious commit, relying on downstream consumers that trust tag names more than commit hashes.
- A repository policy allows tag updates only for a documented emergency fix, with audit logging and reviewer approval, reducing the chance of hidden replacement.
- Monitoring detects a tag mutation event and triggers a software supply chain investigation before the altered artifact is promoted to production.
For teams that formalise release integrity, tag handling should be treated as a control point rather than a convenience. The SLSA framework and related provenance practices reinforce the value of stable references, even when the implementation details differ across platforms.
Why It Matters for Security Teams
Tag force-pushes are dangerous because they can invalidate assumptions used by CI/CD, artifact signing, incident response, and audit trails. If defenders only alert on branch rebases or deleted references, a tag rewrite can slip through as a low-noise change while the published release identity remains unchanged. That creates a gap between what users think they installed and what the repository now presents as trusted history.
Security teams should treat tag mutation as a supply chain integrity event, not just a version-control preference. In practice, that means monitoring reference updates, restricting who can move release tags, and preserving evidence of the original commit tied to each published version. Where identity is involved, the question is also who had authority to retarget the release marker, which makes privileged access review part of the control story. Guidance from NIST SP 800-53 and OWASP software assurance guidance is useful when mapping integrity checks and change control to operational controls.
Organisations typically encounter the consequences only after a release mismatch, dependency compromise, or incident review exposes that the tag no longer points to the code that was originally approved, at which point tag force-push detection becomes operationally unavoidable to address.
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 surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST AI RMF set the technical controls, and EU Cyber Resilience Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS | Tag mutation impacts data and software integrity within the CSF protect function. |
| NIST SP 800-53 Rev 5 | CM-3 | Configuration change control applies when published release references are rewritten. |
| OWASP Non-Human Identity Top 10 | Tag rewrites can affect non-human release identities and their trust relationships. | |
| NIST AI RMF | GOV | AI systems that depend on tagged model or package versions need governance over reference integrity. |
| EU Cyber Resilience Act | The CRA emphasizes secure software lifecycle practices relevant to release reference integrity. |
Define ownership for tag integrity in AI supply chains and escalate unexpected reference changes.
Related resources from NHI Mgmt Group
- What breaks when a GitHub Action is hijacked through a tag force-push in CI/CD workflows?
- What breaks when a Composer package uses eager autoloaded files and a tag is force-pushed to a malicious commit?
- What is the difference between password spraying and brute-force attacks?
- What is the difference between credential stuffing and brute force attacks?
