TL;DR: Truffle Security says secrets can still surface in deleted forks, private forks, edited comments, deleted branches, Postman workspaces, and base64-encoded GitHub content, showing that deletion and visibility controls do not reliably remove exposed credentials. The governance gap is assuming a secret is gone when it is only harder to find.
At a glance
What this is: This is a secret-leak analysis showing that common collaboration platforms can preserve API keys and passwords in places teams may wrongly assume are removed or hidden.
Why it matters: It matters because IAM and NHI programmes need to account for secret persistence across repositories, workspaces, and comment histories, not just live systems and obvious exposures.
👉 Read Truffle Security's analysis of seven places secrets leak online
Context
Secrets often persist after teams believe they have been deleted, hidden, or made private. In this case, the problem is not a single platform flaw but a broader governance assumption that one cleanup action removes all access paths to a credential or snippet.
For IAM and NHI teams, the important question is how long exposed secrets remain retrievable across forks, branches, comments, and encoded content. That changes how organisations think about offboarding secrets, scanning coverage, and the lifecycle of credentials that move through developer tooling.
Key questions
Q: What breaks when teams assume deleted secrets are gone?
A: The main failure is that deletion often removes the visible copy, not the retrievable history. Forks, branches, edited comments, and encoded blobs can still expose the original credential, so the control gap is incomplete removal rather than lack of intent. Teams need to verify recoverability, not just user-facing visibility.
A: Encoded or transformed secrets still create risk because they preserve the underlying credential while bypassing simple pattern matching. If a scanner only looks for obvious plain text values, a secret hidden in base64 or another encoding can slip through and remain usable. Effective detection must decode, normalize, and inspect content before assuming the data is safe.
Q: What are the signs that secret detection is missing important exposures?
A: A weak secret detection programme usually shows the same patterns repeatedly: secrets only discovered after they are committed, findings that are not validated quickly, and credentials that remain usable after exposure. Another warning sign is limited coverage for nonstandard formats. If teams cannot scan for custom patterns, hard-coded secrets will continue to slip through.
Q: Should teams prioritise revocation or cleanup first after finding an exposed secret?
A: Revocation or rotation should come first when the credential is still usable, because cleanup does not remove existing access. Once access is cut off, teams should remove the exposed material, hunt for related copies, and confirm that any forks, branches, or edited content no longer reveal the same secret.
Technical breakdown
Why deleted Git history can still expose secrets
Git-based workflows do not behave like a simple file delete. Deleted forks, deleted branches, and edited comments can still retain prior object versions, cached references, or retrievable history depending on how the platform stores and serves content. That means a secret removed from the visible surface may still exist in underlying structures that scanners or attackers can recover. Base64 encoding adds another layer of concealment, but it does not remove the credential from the data plane. For identity teams, this is a content persistence problem, not just a repository hygiene issue.
Practical implication: scan for retrievable history and encoded variants, not only current repository content.
How public and private forks create secret exposure paths
Forking can create unexpected inheritance of content that teams believe is isolated or private. If a repository or fork is made public later, previously committed data can become visible without a fresh action by the developer who created it. Private forks of public repositories can also expose commits in ways that break assumptions about containment. The technical issue is that repository visibility does not always equal data invisibility, especially when upstream content has already been indexed into a fork lineage. This is a lifecycle issue for code-adjacent secrets, not just a platform setting.
Practical implication: treat fork lineage as part of secret inventory and review exposure before changing visibility.
Why content scanning must understand encoded and alternate forms
Secret detection that only looks for plain-text patterns will miss a meaningful share of exposed credentials. Truffle Security notes that Base64-encoded text can evade default protections while still being decoded by scanning tools. That illustrates a wider detection lesson: secret controls need content normalisation, decoding, and pattern expansion before evaluation. Without those steps, the control only sees the obvious form of leakage, not the form an attacker can actually recover. For NHI governance, the failure is incomplete inspection of where secrets may be hidden, not merely weak secret rotation.
Practical implication: normalise, decode, and rescan content before declaring a repository or workspace clean.
Threat narrative
Attacker objective: The attacker’s objective is to recover reusable credentials from overlooked content paths and use them to access downstream systems or data.
- Entry occurs when a secret is committed into a repository, comment, workspace, or encoded blob that later appears deleted or hidden but remains retrievable.
- Credential exposure follows when the secret persists in fork history, edited content, deleted branches, or base64-encoded form that bypasses simple detection.
- Impact occurs when an attacker or unauthorised user recovers the credential and uses it to access connected systems, data stores, or developer tooling.
Breaches seen in the wild
- iOS apps leaking hard-coded secrets: Cybernews found 71% of 156,080 iOS apps leak hard-coded secrets, with open cloud storage and Firebase databases exposing user data.
- 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
Secret persistence is the real control failure: this article shows that teams often treat removal as a binary event when platforms preserve retrievable history, alternate encodings, and fork lineage. That breaks the assumption that a secret stops being reachable once it is deleted from the visible interface. Practitioners should read this as a lifecycle problem for secrets, not a one-time cleanup problem.
Secret visibility and secret recoverability are not the same thing: a repository can look private, edited, or cleaned up while the underlying object history still exposes credentials. That distinction matters for governance because approval, access review, and remediation decisions are often based on current state only. The implication is that exposure assessment must include historic and transformed content, not just live files.
Encoded-secret blind spots create a false sense of coverage: plain-text-only scanning misses a class of secrets that are still fully usable once decoded. This is a control-design issue, not a tool-tuning issue. Organisations that rely on default pattern matching are underestimating their residual credential exposure.
Fork lineage is part of the NHI attack surface: when code and secrets move through forks, branches, and workspaces, the identity governance problem extends beyond vaults and into collaboration history. That makes secret handling an NHI lifecycle issue across the software development path. Teams should govern where secrets have ever lived, not just where they live now.
Runtime trust assumptions break in collaboration systems: deleted or edited content does not reliably mean revoked access. The practical lesson is that the NHI governance model must assume persistence until content is positively invalidated, re-scanned, and revoked if necessary. Anything less leaves recoverable credentials in circulation.
What this signals
Secret leakage is a lifecycle problem, not a file-cleanup problem: organisations need to govern where secrets were stored, copied, forked, or edited, because those paths can outlive the visible object. The practical shift is from surface remediation to exposure lineage management.
Recovery-aware scanning has become the baseline: plain-text detection is no longer enough when comments, forks, and encoded blobs can all preserve usable credentials. Teams should assume secret content may be recoverable in more than one form and design controls accordingly.
For practitioners
- Expand secret scans beyond live code Scan deleted forks, deleted branches, edited comments, and workspace history for retrievable credentials, not just current files.
- Decode before you decide content is clean Normalize and inspect Base64-encoded or otherwise transformed content before declaring a repository or workspace free of secrets.
- Review visibility changes as exposure changes Check whether moving a fork, workspace, or repository from private to public would reveal earlier commits or upstream content that already contains secrets.
- Treat comment history as a secret-bearing surface Assume edited comments may retain the original text and include them in credential discovery, revocation, and incident review workflows.
Key takeaways
- Deleted forks, edited comments, and branch history can preserve secrets long after teams think they have removed them.
- Base64 and other transformations can hide credentials from simple pattern matching while still leaving them recoverable.
- The control that matters is not just deletion but verification of recoverability, visibility, and revocation across the full content lifecycle.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 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 primarily about secrets persisting in exposed or recoverable places. |
| NHI-07 — Long-Lived Secrets | The article shows secrets remaining usable long after teams think they removed them. | |
| Recommendation — Scan for leaked secrets across forks, comments, and workspaces, then revoke exposed credentials immediately. Shorten secret lifetime and remove any credential that can still be recovered from history. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle management is central because the exposed items are reusable authenticators. |
| Recommendation — Apply IA-5 to govern secret issuance, rotation, revocation, and replacement across development tooling. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article’s exposure paths require disciplined account and credential lifecycle control. |
| Recommendation — Use account management controls to remove stale access and eliminate recoverable credential paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Visibility changes and hidden history affect who can still reach secret material. |
| Recommendation — Review entitlements and authorizations that keep historic content reachable after deletion or visibility changes. | ||
Key terms
- Secrets Leakage: Secrets leakage is the exposure of credentials such as API keys, tokens, or certificates in places where they can be discovered and reused. The risk is not just disclosure, but unauthorized authentication that turns a coding or pipeline mistake into active access.
- Recoverable History: Recoverable history is retained content that is no longer obvious in the current interface but can still be retrieved from version history, deleted objects, or platform lineage. For identity teams, it means exposure assessment must include past states, not only the present view.
- Encoded Secret Bundle: A packaged secret object that combines multiple credential values into one transferable string, often for configuration or registration. It is convenient operationally but increases governance risk because one leaked bundle can expose both identity material and environment context.
- Fork lineage: Fork lineage is the chain of source inheritance that shows where a deployed binary originated and what upstream code it still contains. In security programmes, it matters because a fix in the original project does not automatically protect derivative builds, repackaged distributions, or long-lived forks.
What's in the full article
Truffle Security's full article covers the operational detail this post intentionally leaves for the source:
- Platform-by-platform examples of where deleted or edited content remains recoverable
- The exact Base64 secret pattern Truffle Security used to show why default blocking is insufficient
- Specific guidance on where secret scanning misses history, forks, and transformed text
- Additional examples from Postman and GitHub showing how visibility changes affect exposure
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 responsible for identity security strategy or NHI governance in your organisation, 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