The deliberate alteration of Git history to make malicious changes appear older, cleaner or less suspicious than they are. It is a forensic evasion technique because it manipulates the evidence trail that teams rely on when reconstructing a compromise.
What History Rewriting Is
History rewriting is the intentional modification of a repository’s commit lineage, messages, timestamps, or ordering so later analysis sees a cleaner story than what actually happened. In practice, it is used to obscure when malicious code was introduced, who touched it, or how visible the change would be during an incident review.
Why It Matters in Git Forensics
Git history is not just a convenience feature, it is part of the evidence trail teams use to understand change, ownership, and sequence. When that trail is rewritten, investigators can lose important context about the first appearance of a backdoor, the real timing of a compromise, or the relationship between a suspicious commit and later deployment activity. That makes history integrity a security property, not merely a repository housekeeping concern.
History rewriting can affect commit graphs, tag references, and blame-style workflows, and it can also make a malicious change appear to have been authored by a different identity or at a different point in time. If a team relies on the repository as an audit source, the evidentiary value of the repository depends on whether the history has been protected from post-hoc alteration.
Common Forms and Indicators
Typical forms include force-pushing a branch after amending commits, rebasing to rearrange or squash changes, editing author or committer metadata, and replacing a visible change with a cleaner-looking follow-up commit. Each of these can be legitimate during development, which is why the issue is not the presence of rewriting itself, but whether the rewrite is expected, authorized, and traceable.
Signals that deserve attention include sudden disappearance of commits, unexpected divergence between local and remote branch history, rewritten timestamps, or a commit chain that no longer aligns with ticketing, review, or release records. When those clues appear together, the question is often not “was Git used?” but “has the evidence trail itself been manipulated?”
For broader context on preserving repository trust, compare the evidence problem with SLSA, which focuses on build provenance and integrity, and the operational controls in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially audit and configuration-related safeguards.
How Teams Reduce Exposure
Teams reduce exposure by treating history as something to govern, not just edit. That means limiting who can rewrite protected branches, preserving authoritative audit sources outside the working tree, and making it easy to distinguish a normal development rewrite from an unauthorized attempt to hide activity.
History-integrity controls work best when paired with strong review and provenance practices. A repository that permits rewriting on feature branches may still remain defensible if protected branches, release tags, CI records, and signed artifacts provide an independent record of what was actually built and deployed. For a control-based view of that discipline, NIST Cybersecurity Framework 2.0 frames the need to govern, detect, and respond to integrity issues, while OWASP SAMM helps teams embed provenance and review practices into the software delivery process.
Risk and Threat Considerations
History rewriting creates a forensic blind spot because it can separate the visible repository narrative from the actual sequence of malicious activity. That matters most when a compromise is being investigated, because the attacker may be trying to delay discovery, confuse attribution, or make a harmful change look like a routine cleanup.
Failure mechanism: An attacker or insider alters commit history after the fact, then relies on rewritten metadata, squashed commits, or forced updates to hide the original sequence of events and weaken later reconstruction.
Impact: Security teams may misjudge dwell time, miss the first malicious change, or trust a misleading audit trail, which can slow containment and reduce confidence in post-incident findings.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, NIST CSF 2.0, NIST SP 800-53 Rev 5 and OWASP SAMM set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain provenance | History rewriting can obscure artifact provenance and change lineage. |
| Recommendation — Preserve build provenance so rewritten repository history cannot mask what was actually built. | ||
| NIST CSF 2.0 | GV.SC-01 — Supply Chain Risk Management | Repository history integrity is part of software supply-chain trust and governance. |
| Recommendation — Govern repository trust assumptions and require independent provenance for delivered code. | ||
| NIST SP 800-53 Rev 5 | AU-9 — Protection of Audit Information | Rewritten history weakens the trustworthiness of audit evidence and change records. |
| Recommendation — Protect audit records with separate immutable logging so source history alone is not authoritative. | ||
| OWASP SAMM | D-SD-1 — Security Requirements | Secure development maturity includes preserving trustworthy change evidence across delivery. |
| Recommendation — Embed provenance and review checkpoints into delivery so history changes remain accountable. | ||
Practitioner Guidance
What to watch for: Treat history rewriting as a governance question as much as a source-control feature. If your workflow permits rebases or force pushes, define where they are allowed, what must be preserved elsewhere, and which histories are considered authoritative for incident review.
Common misunderstanding: Teams often assume that “Git has history” means the evidence is durable. In reality, durability comes from branch protection, separate audit logging, release provenance, and disciplined access to rewrite operations, not from the mere presence of a commit graph.