A lesser-known feature of Git, Dubbed “Commit Stomping,” this technique allows users to manipulate commit timestamps, potentially disguising malicious or unauthorized changes in a repository’s history.
While not a bug or vulnerability, Commit Stomping exploits Git’s flexibility to rewrite the timeline of code changes, posing significant risks to software supply chain security, incident response, and code audits.
What is Commit Stomping?
Inspired by “timestomping,” a tactic used in offensive cyber operations to alter file metadata, Commit Stomping involves falsifying the timestamps of Git commits to mislead observers about when changes were made.
Git tracks two timestamps for each commit: the GIT_AUTHOR_DATE, which marks when the content was written, and the GIT_COMMITTER_DATE, which records when the commit was finalized.
By manipulating these, bad actors can backdate or postdate commits, making it harder to establish an accurate timeline during investigations.
“This isn’t a flaw in Git—it’s a feature,” explains cybersecurity researcher, who previously explored the technique while developing RepoMan, a tool for AI-influenced code commits. “Git’s design trusts users to set timestamps, which is great for flexibility but can be abused to hide malicious activity.”
Git’s commit history is often treated as a source of truth in software development, relied upon for:
- Incident response: Pinpointing when malicious code was introduced.
- Code audits: Ensuring compliance with regulations.
- Team attribution: Tracking contributions in collaborative or open-source projects.
When timestamps are falsified, these processes break down. “Imagine trying to trace a backdoor in your codebase, only to find the commit appears to be from two years ago,”. “Commit Stomping can throw off forensic timelines and obscure the origin of changes.”
How It Works
Git’s flexibility makes Commit Stomping straightforward. Users can set arbitrary timestamps during a commit using environment variables:
bash
GIT_AUTHOR_DATE="2025-01-01T10:00:00" \
GIT_COMMITTER_DATE="2025-01-01T10:00:00" \
git commit -m "Backdated change"
This creates a commit that appears to have occurred on January 1, 2025, regardless of the actual date. For existing commits, tools like git rebase or git filter-branch allow users to rewrite timestamps after the fact. For example, an interactive rebase can modify a single commit’s metadata:
bash
git rebase -i HEAD~3
# Change 'pick' to 'edit' for the target commit
GIT_COMMITTER_DATE="2025-01-01T10:00:00" \
git commit --amend --no-edit --date "2025-01-01T10:00:00"
git rebase --continue
For large-scale manipulation, git filter-branch or the more modern git filter-repo can alter timestamps across entire histories, even randomizing them to create noisy, hard-to-analyze timelines.
Commit Stomping’s implications are far-reaching. In software supply chain attacks, attackers could use it to bury malicious code in older commits, making it appear as part of a trusted release.
Insider threats could leverage it to cover their tracks, while open-source projects might struggle to verify contributor activity. “In high-trust environments, like regulated industries, this could undermine compliance efforts,” researcher said..
Detecting Commit Stomping is challenging. Red flags include:
- Identical timestamps: Multiple commits with the same GIT_AUTHOR_DATE and GIT_COMMITTER_DATE suggest automation.
- Chronological inconsistencies: Commits with earlier timestamps appearing after newer ones.
- External log mismatches: Discrepancies between commit dates and CI/CD or webhook logs.
- Unusual backdating: Sudden bursts of commits with old timestamps.
Defending Against Commit Stomping
Since Git’s design prioritizes flexibility, defending against Commit Stomping requires external controls:
- Require signed commits: GPG or SSH signatures verify committer identity, adding accountability.
- Log commit ingestion: Capture metadata in CI/CD pipelines or Git servers to create an independent timeline.
- Use immutable mirrors: Maintain read-only repository copies to detect history rewrites.
- Restrict force pushes: Prevent unauthorized history changes on protected branches.
- Monitor anomalies: Use analytics to flag suspicious timestamp patterns.
“Git is a distributed system it’s not going to enforce timestamp integrity for you,” according to the technical writeup. “You need to build trust around it with logging, signatures, and monitoring.”
A Feature, Not a Bug
Commit Stomping isn’t a traditional security flaw there’s no patch coming. It’s a byproduct of Git’s trust-based design, which allows legitimate use cases like preserving historical dates when importing code. But in the wrong hands, it’s a powerful tool for deception.
As software becomes a critical part of the security perimeter, treating Git’s commit history as immutable is no longer safe.
Organizations must assume version history can be manipulated and surround it with validation mechanisms. “If you’re not looking for Commit Stomping, you won’t see it,”. “And if you’re not defending against it, you’re leaving a gap in your forensic trail.”
In a world where code tells a story, Commit Stomping lets bad actors rewrite the plot. Awareness and proactive defenses are key to ensuring that story stays true.
How to Discover Vulnerable External Assets Associated with a Domain or an IP? -> Try Cyber Asset Finder for Free
