TL;DR: Truffle Security’s analysis shows that force-pushed GitHub history still leaves dangling commits accessible, with tens of millions of hidden commits and 3.68 unique dangling commits found per zero-commit force push in a 1,500-repository survey. History rewriting does not equal secret removal, so detection and preventative controls have to move upstream into commit hygiene and CI enforcement.
At a glance
What this is: This is an analysis of how force-pushed GitHub history can still expose dangling commits and secrets long after developers think they have been deleted.
Why it matters: It matters because identity teams, platform engineers, and security leads cannot treat Git history rewrites as secret remediation without controls that prevent and detect credential exposure in source control.
By the numbers:
- Truffle Security surveyed 1,500 repositories and found 3.68 unique dangling commits per zero-commit force push.
- The dataset the article cites includes 26Tb of public GitHub event data from 2015 to today.
- Truffle Security says it has seen 15 million zero-commit force push events in the dataset.
👉 Read Truffle Security’s analysis of force-pushed Git history and secret exposure
Context
Force-pushed Git history is a secret exposure problem, not just a version-control habit. When a branch pointer moves back, commits that disappear from the visible branch can still remain reachable as dangling objects, which means credentials and other sensitive material may persist outside normal review paths.
The article connects this to NHI governance because source control often stores the secrets that authenticate workloads, automation, and cloud access. The governance gap is that deletion in Git is not the same as revocation of the underlying secret, so the organisation can lose sight of exposure without actually removing access.
Truffle Security’s analysis treats this as a scale problem as much as a workflow problem. The evidence suggests that many repositories have a hidden historical attack surface that conventional secret scanning may miss if it only inspects current branches.
Key questions
Q: What should teams do first when a secret has already been committed to Git history?
A: Revoke or rotate the secret immediately and treat the credential as compromised, even if the bad commit has been removed from the latest branch. Repository cleanup is only containment. The owning identity still needs to be disabled or reissued before any history rewrite can be considered complete.
Q: Why do force-pushed commits still matter after developers think they deleted them?
A: Because a force push moves the branch pointer, but it does not guarantee that the old objects are gone. Dangling commits can remain recoverable for a period of time, so secrets in those commits may still be exposed even though the branch looks clean.
Q: How should security teams reduce the risk of exposed hardcoded secrets in source repositories?
A: Security teams should combine automated secret scanning, repository visibility monitoring, and enforced code review controls. That means detecting hardcoded credentials early, alerting on public repository changes, and requiring CODEOWNERS or equivalent review gates before risky code reaches production. The goal is to shrink the window between exposure and remediation, because once a secret is in git history, the blast radius is hard to contain.
Q: What is the difference between deleting a branch and revoking a leaked secret?
A: Deleting a branch removes one pointer to the data, but revoking a leaked secret invalidates the credential everywhere it exists. A deleted branch may still leave recoverable commits, pull request refs, or API-accessible history behind. Revocation is the actual security control because it cuts off use of the exposed secret even if copies remain discoverable.
Technical breakdown
How dangling Git commits persist after a force push
A force push rewrites branch history by moving the branch ref to a new commit, but it does not necessarily erase the old objects from the repository. Commits that are no longer reachable from a branch or tag become dangling commits, and if someone knows the commit hash they may still be retrievable from GitHub’s object storage for some period of time. That creates a second, hidden history layer that ordinary branch-based scanning misses. For security teams, the technical problem is not just mutable history but object persistence beyond the visible branch tip.
Practical implication: scan commit objects, not just current branch heads, when assessing secret exposure.
Why zero-commit force pushes are a useful exposure signal
A zero-commit force push is a PushEvent where the commits array is empty because the branch moved but no new commits were added. In the article’s workflow, that event becomes a strong signal that the previous tip may now be dangling and worth scanning. The key architectural point is that event metadata can reveal which historical objects are likely still recoverable, which is far more efficient than brute-forcing commit hashes. This turns Git activity logs into a discovery mechanism for historical secret exposure.
Practical implication: use force-push event history to prioritise high-risk repository scans.
Why secret scanning must extend to historical repository state
Secret scanners often focus on the live repository state, pull requests, or recent commits, but that misses deleted or rewritten content. The article’s approach combines Git history reconstruction with secret scanning so that inherited history, not just present state, is assessed for leaked credentials. That matters because a secret can remain exploitable even after the visible evidence of the commit has been removed. In NHI terms, the credential lifecycle is incomplete if revocation never happened, even when the source line disappeared.
Practical implication: include dangling commit scanning in secret detection and response workflows.
Threat narrative
Attacker objective: The attacker wants to recover an apparently deleted secret and use it to access the protected service or repository-linked environment.
- Entry occurs through a leaked secret that was committed to Git history before a force push rewrote the visible branch.
- The exposed commit remains recoverable as a dangling object if the commit hash or event metadata can be used to locate it.
- An attacker who finds the secret can reuse the credential against the connected service or cloud environment.
- Impact comes from credential abuse after developers assumed the secret had been deleted.
Breaches seen in the wild
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Hidden Git history is now part of the NHI attack surface: The problem is no longer whether a secret was removed from the visible branch, but whether the underlying credential ever ceased to exist in accessible history. Force pushes can hide evidence without revoking the secret itself, which means the real control boundary is secret lifecycle management, not branch hygiene. Practitioners should treat repository history as a live credential exposure surface, not an archive.
Secret deletion without revocation is a broken governance assumption: The article shows that teams often assume removing a commit removes the risk. That assumption fails because dangling commits can persist after a force push and may still contain usable credentials. The implication is that access governance must account for historical persistence, not just current code state.
Runtime discovery has to reach beyond the current repository tip: Conventional secret scanning is strongest when it inspects live branches, but force-pushed objects exist outside that view. The named concept here is hidden commit exposure: sensitive material that is no longer visible in the branch but remains technically recoverable. Security teams should treat that hidden layer as a first-class discovery target.
Prevention matters more than after-the-fact cleanup: If secrets can be committed, rewritten, and still recovered, the control problem starts before the push. Git history rewriting is only a partial containment step unless organizations also stop secrets from entering the repository in the first place. The practical conclusion is to move controls left into commit-time prevention and repository governance.
Historical secret exposure is a lifecycle failure, not just a scanning gap: The article’s scale data shows this is not an edge case. Tens of millions of dangling commits mean many organizations have unknowable exposure in old history, which invalidates any process that treats repository cleanup as a one-time remediation event. Practitioners need a lifecycle model that spans creation, exposure, rewrite, and revocation.
From our research library:
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to the State of Secrets Sprawl 2026.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Hidden commit exposure: Organisations need to treat repository history as a governed part of the credential estate, because historical Git objects can preserve secrets after the branch view changes. The operational signal is simple: if your scanning only covers current code, you are missing a class of recoverable exposure that lives outside normal developer workflows.
Force-push activity should trigger repository-level secret review, but the bigger programme issue is prevention at commit time. Security teams that rely on cleanup alone will keep rediscovering the same risk in new histories, which is why pre-commit enforcement and CI blocking should sit alongside detection and revocation.
For practitioners
- Scan dangling commits, not only live branches Extend secret scanning to commit objects that are no longer reachable from current branch heads, especially after force pushes and history rewrites.
- Treat secrets in Git as revocation failures When a secret is discovered in history, rotate or revoke the underlying credential rather than assuming a rewrite removed the exposure.
- Gate force pushes on protected repositories Restrict force pushes on shared and release branches, and require review or approval when history rewriting is unavoidable.
- Add commit-time secret prevention controls Use pre-commit hooks and CI checks to block credentials before they enter repository history, since cleanup after the fact leaves hidden exposure behind.
Key takeaways
- Force-pushed Git history can still contain usable secrets, so deleted code is not the same thing as removed exposure.
- The scale signal is material: the article says thousands of repositories and millions of force-push events expose dangling commits that remain worth scanning.
- The practical control point is upstream prevention combined with historical scanning, because cleanup after rewrite leaves hidden data behind.
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article is about secrets persisting in accessible Git history after force pushes. |
| NHI-07 — Long-Lived Secrets | Dangling commits extend secret lifetime beyond the visible branch lifecycle. | |
| Recommendation — Scan historical repository objects for leaked secrets and revoke any exposed credentials immediately. Shorten secret lifetime by preventing credentials from entering source control and removing any that do. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Authenticator lifecycle control applies when leaked repository secrets may still authenticate. |
| Recommendation — Apply IA-5 to rotate and revoke credentials found in repository history. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The exposed history is valuable because it can yield working credentials to an attacker. |
| Recommendation — Map exposed commit secrets to TA0006 and prioritise monitoring for credential theft and reuse. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Repository secrets represent access entitlements that must be governed across their lifecycle. |
| Recommendation — Use PR.AA-05 to govern who can create, store, and retain secrets in source control. | ||
Key terms
- Dangling Commit: A dangling commit is a Git object that still exists in the repository database but is no longer referenced by a branch or tag. It may be invisible in normal history views, yet still recoverable until garbage collection removes it or a hosting platform discards it.
- Force-Push: A force-push rewrites branch history by replacing existing commits with new ones on the remote repository. It is a legitimate Git operation, but in an attack it can hide malicious changes inside preserved commit metadata, making tampering harder to detect through ordinary pull request review or feed monitoring.
- Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
- Credential Lifecycle: Credential lifecycle is the process of issuing, rotating, expiring, and revoking secrets, certificates, and tokens across their usable life. For non-human identities, lifecycle discipline is the core control that separates temporary access from persistent exposure.
What's in the full article
Truffle Security’s full post covers the operational detail this analysis intentionally leaves for the source:
- The Force Push Scanner workflow for turning GH Archive push events into a scanable commit set
- The exact Git commands used to identify dangling commits and walk parent history
- The SQLite and BigQuery access options for the pre-built dataset
- The command-line scanning flow for dangling commit ranges in TruffleHog
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on October 15, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org