Topic starter
15/10/2026 10:09 am
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.
Editorial analysis by NHI Mgmt Group, based on content published by Truffle Security: “7 Spooky Places Your Secrets Leak Online”.
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.
A: Encoded or transformed secrets still create risk because they preserve the underlying credential while bypassing simple pattern matching.
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.
Practitioner guidance
- 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.
Bottom line: Deleted forks, edited comments, and branch history can preserve secrets long after teams think they have removed them.
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
👉 Read Truffle Security's analysis of seven places secrets leak online →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
15/10/2026 10:12 am
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.
A question worth separating out:
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.
👉 Read our full editorial: Secrets leak through deleted forks and encoded text online