What are the signs that a repository has been manipulated after compromise?

What signs suggest the repository history has been tampered with?

Look for changes that do not fit the normal development pattern: rewritten commit history, unexpected force pushes, altered timestamps, reflog gaps, and files that appear ordinary but now contain appended code, hidden loaders, or suspicious execution paths. The key question is whether the repository still reflects an authentic evolution of work, or whether an intruder has tried to reshape evidence after gaining access.

History tampering often shows up as a mismatch between the visible branch tip and the repository’s internal evidence trail. If the commit graph looks neat but the audit trail is broken, or if files were updated in ways that do not match the surrounding change cadence, treat that as a compromise indicator rather than a harmless cleanup.

Git metadata matters here because attackers who already have write access may not just alter source content, they may also try to erase or reorder signs of their activity. MITRE ATT&CK Enterprise Matrix is useful for mapping those post-compromise behaviours to credential access, persistence and defense evasion patterns.

Which repository artifacts deserve the closest scrutiny?

Start with commits, refs, and branch movement. Amended commits, rewritten hashes, non-linear history where none is expected, and force-push events after suspicious access are all worth examining. In a healthy repository, the change history should explain itself, not require guesswork to reconcile with the working tree.

Then inspect the repository’s bookkeeping structures. Reflog inconsistencies, missing or truncated references, and timestamp anomalies can indicate that someone tried to create the appearance of a normal development flow while suppressing the real sequence of actions. If the object database, refs, and logs no longer agree, the repository deserves incident-level review.

Finally, inspect files that are easy to trust by habit: task runners, build scripts, CI definitions, deployment configs, and package metadata. Attackers commonly hide malicious commands in places that still look functionally plausible. A build file that suddenly shells out, fetches a remote payload, or invokes an unfamiliar loader is often more meaningful than a cosmetic source-code edit.

Repository integrity is also a supply-chain issue when the repo feeds builds or releases. SLSA is relevant because it frames provenance and integrity checks that help detect when a repository’s history or artifacts no longer reflect trusted source state.

How should practitioners confirm whether the change is malicious?

Use a consistency check, not a single symptom. Compare the visible branch state against reflogs, remote push history, CI outputs, signed commit evidence, and any independent clone or mirror you trust. If one view says the change is ordinary but another says the history was rewritten, assume the repository has been manipulated until proven otherwise.

Prioritise evidence that ties content to sequence. A malicious actor may leave files that look legitimate at a glance, but the surrounding execution path reveals the real intent. That means the strongest confirmation usually comes from combining history inspection with file-level diff review, dependency review, and build or runtime traces, rather than from any one indicator alone.

For teams that rely on branch protection, signed commits, or controlled promotion paths, the question is not only whether the code looks bad, but whether the repository still preserves trustworthy provenance. NIST SP 800-53 Rev 5 Security and Privacy Controls supports that judgement through controls for access control, audit logging, configuration management, and system integrity.

Practitioner Guidance: Treat any post-compromise repository change as both an integrity problem and a possible persistence mechanism. The first decision is whether you can still trust the history enough to continue normal development; if not, freeze promotion, preserve evidence, and validate from a clean reference clone before accepting any subsequent commits.

What to verify: Verify whether the commit history, reflog, remote refs, and CI or release artifacts tell the same story. If they do not, the discrepancy itself is the finding, even before you identify the payload.

Decision rule: If a repository change alters history as well as content, treat it as higher risk than a normal bad commit because the attacker is no longer only changing code, they are also tampering with the record of how that code arrived.

Practitioner takeaway: The most important signal is not just suspicious code, but evidence that the repository’s timeline has been edited to make that code look legitimate.

Related resources from NHI Mgmt Group

• How do attackers turn a supply-chain incident into wider NHI compromise?
• What did Shai Hulud 2.0 actually compromise?
• Why do still-valid secrets matter after public disclosure?
• How do attackers turn stolen npm secrets into broader compromise?