Do Son 
Altering Commit Timestamps (zsec.uk)
A method for concealing change history has been uncovered in Git, capable of misleading even seasoned digital forensics experts. This is not a newly discovered vulnerability, but rather a built-in functionality which, if misused, can become a powerful instrument of manipulation—a technique now known as Commit Stomping. It enables the alteration of commit timestamps within a repository, effectively obscuring or distorting the true sequence of events, thus complicating audits, incident investigations, or code reviews.
By design, Git is decentralized and inherently trusts the user. Each commit contains two timestamps: GIT_AUTHOR_DATE, indicating when the code was written, and GIT_COMMITTER_DATE, marking when the commit was recorded. These values can be manually overridden via environment variables, thereby opening the door to chronological tampering.
For instance, an attacker could insert malicious code and retroactively “embed” it into an earlier release by assigning it a timestamp that aligns with the historical development timeline. This would cause the malicious code to appear as a legitimate part of an older version, complicating vulnerability attribution and concealing the true point of injection.
Git operations such as rebase and commit --amend inherently rewrite history and update GIT_COMMITTER_DATE in the process. However, a greater risk arises from the deliberate, manual specification of timestamps or mass history rewrites using tools like git filter-branch or git filter-repo. These allow not only individual commits to be backdated but also entire sequences of actions to be disguised within a fabricated timeframe.
Indicators that a repository may be subject to Commit Stomping include identical timestamps across multiple commits, significant discrepancies between author and committer dates, the appearance of retroactively dated commits, or inconsistencies between commit metadata and CI/CD logs. If the perpetrator exercises restraint and uses only subtle temporal offsets, such tampering becomes exceedingly difficult to detect without external sources of verification.
This technique is particularly alarming in the context of software supply chains, where repositories are public and consumed by a broad ecosystem. A barely noticeable commit alteration could silently make its way into production builds, while any investigative efforts may be misled by a falsified timeline.
To mitigate such risks, the following practices are recommended:
- Enforce commit signature verification via GPG or SSH;
- Maintain external logging of incoming commits within CI/CD pipelines or on the Git server;
- Mirror repositories in immutable storage systems;
- Prohibit force-pushes on protected branches;
- Monitor for chronological anomalies in commits, especially during code audits and release preparations.
Commit Stomping is neither a bug, nor an exploit, nor a CVE. It is a natural byproduct of Git’s architecture—an architecture founded on flexibility and developer trust. But in an era where source code management forms part of the security perimeter, trust alone is no longer sufficient. Without additional layers of safeguarding, the version history ceases to be a source of truth and becomes a potential vector of deception.
Given the rise in supply chain attacks and incidents of sabotage in open-source projects, the ability to obscure or falsify commit history should be treated as a genuine security concern—especially in scenarios involving impersonation within teams, concealment of insider activity, or the emulation of sophisticated adversaries. Git tells the story of a project’s evolution. Commit Stomping allows that story to be rewritten, altering crucial facts—and in doing so, concealing the path to the truth.
Donate