Committer date is the timestamp recorded when a commit is applied to a repository, separate from the original author date. Large gaps between the two can indicate rebasing or history rewriting. In compromise investigations, that mismatch is a useful signal that the visible commit may not reflect the real change time.
Expanded Definition
Committer date is the recorded time when a change is added to a repository history, while author date reflects when the change was originally created. The distinction matters because repository metadata can show a later commit time even when the underlying work was written earlier, especially after rebasing, cherry-picking, squash merges, or deliberate history rewriting. In software supply chain reviews, this timestamp difference is often used as a signal rather than proof, because the date alone does not establish trustworthiness or malicious intent.
For security and integrity analysis, committer date is most useful when compared with branch protection settings, pull request records, CI logs, and repository audit trails. It can help investigators understand whether history was rebuilt during normal engineering work or altered to hide the true sequence of events. This is especially relevant in environments that map repository governance to NIST Cybersecurity Framework 2.0 practices for logging, change control, and incident response. Definitions vary slightly across platforms, but the underlying concept is consistent: committer date represents when the repository accepted the commit object, not when the code was first authored. The most common misapplication is treating committer date as definitive evidence of malicious activity, which occurs when analysts ignore normal development workflows such as rebasing or automated merge operations.
Examples and Use Cases
Implementing committer date analysis rigorously often introduces an investigation overhead, requiring teams to balance fast triage against the need to validate repository history and surrounding evidence.
- A security analyst sees a commit with an old author date but a very recent committer date, then checks whether the change was rebased during a release process or inserted during an incident.
- A repository maintainer reviews unusually large gaps between author and committer dates alongside branch protection and pull request approvals to confirm whether the history was rewritten legitimately.
- An incident responder compares committer dates with CI pipeline logs to determine whether code was merged after a suspicious credential event or during a routine deployment window.
- A supply chain reviewer uses repository metadata together with guidance from the Git commit signing guidance to distinguish signed, traceable changes from rewritten history.
- A forensic examiner correlates committer date anomalies with audit logs and access records to identify whether the repository was altered from an unexpected account or automation identity.
Why It Matters for Security Teams
Committer date matters because repository history is frequently treated as evidence, yet timestamps can be altered by legitimate workflow choices or by an attacker trying to disguise when a change was introduced. For security teams, the key risk is not the timestamp itself but the false confidence created when committer date is read in isolation. A mismatch between author and committer dates can support an integrity review, but it must be interpreted with branch protection status, identity controls, and signing evidence. That is where broader control thinking from OWASP software supply chain guidance and NIST supply chain controls becomes useful, because commit metadata is only one layer in provenance validation. For NHI-aware operations, the same principle applies to automation accounts and build identities: a commit may be signed and still arrive through a compromised pipeline. Organisations typically encounter the real impact only after a suspicious change is discovered in production, at which point committer date becomes operationally unavoidable to reconstruct the timeline.
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 and risk surface, while NIST CSF 2.0, NIST AI RMF, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC, PR.DS | CSF addresses governance and data integrity relevant to repository history trust. |
| NIST AI RMF | AIRMF supports traceability and accountability concepts that parallel commit provenance. | |
| OWASP Non-Human Identity Top 10 | NHI guidance covers automation identities that may create or apply commits. | |
| NIST SP 800-63 | AAL2 | Identity assurance helps validate who acted in repository workflows behind the commit. |
| NIST Zero Trust (SP 800-207) | Zero trust emphasizes continuous verification of actions and identities across systems. |
Use committer date as one signal within governance and integrity reviews, not as standalone proof.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
