TL;DR: Truffle Security finds thousands of live API keys and passwords exposed in public GitHub comments, showing that secret leakage extends beyond committed code into editable discussion threads. Comment history, not deletion, often preserves the credential, so revocation has to happen at exposure time, not after cleanup.
At a glance
What this is: Truffle Security reports that public GitHub comments, issue threads, and pull requests contain thousands of live API keys and passwords, with comment history creating an ongoing exposure path.
Why it matters: IAM and NHI teams need to treat collaboration surfaces as credential-bearing systems, because revocation, masking, and monitoring must extend beyond source code repositories.
By the numbers:
- Truffle Security found 721 live API keys and passwords in a sampled subset of public GitHub pull request and issue comments.
- Human users authored 97% of comments containing leaked secrets in the dataset.
- Truffle Security sees 1800 new secrets leaked in GitHub git pushes every day.
👉 Read Truffle Security's analysis of live API keys exposed in GitHub comments
Context
Secret exposure is not limited to code commits. Public collaboration surfaces such as issue comments, pull request discussions, and edit history can become durable repositories for live credentials, which makes secret governance a broader collaboration-control problem rather than a narrow developer mistake.
That matters for API key management because the lifecycle of a key now includes every place a user can paste text, not just the repository itself. When comments can be indexed, archived, or edited without fully removing prior content, offboarding and revocation controls have to assume exposure has already happened.
The article's core finding is typical of modern secret sprawl: leakage happens in ordinary workflow tools, often by people who are trying to solve a support or integration problem rather than bypass security controls.
Key questions
Q: What should teams do first when a live API key is posted in a public comment?
A: Rotate or revoke the exposed credential immediately. Deleting the comment is not enough because the key may already be copied, archived, or preserved in edit history. Containment has to start with invalidating the secret, then move to searching for reuse, reviewing where it appeared, and checking whether any automation or support workflow is repeatedly exposing the same class of credential.
Q: Why are public issue and pull request comments risky for secret exposure?
A: They are persistent, searchable collaboration surfaces where users can paste live credentials into plain text. Unlike private tickets or controlled secret stores, comments can be seen by the public, retained in history, and copied into archives. That combination makes them a real credential-disclosure surface, not just a communication feature, and it demands the same governance attention as source code and deployment logs.
A: Security teams should assume deletion, editing, or privacy changes do not guarantee removal of exposed secrets. The safer approach is to search for residual copies, revoke or rotate any credential that may have been exposed, and scan the surrounding systems where the secret could persist. Git history, forks, comments, and cached copies can all preserve data longer than teams expect.
Q: What is the difference between secret leakage in code and secret leakage in comments?
A: Code leakage usually happens inside the development artifact, while comment leakage happens in a communication layer that many teams do not monitor as closely. Both can expose live credentials, but comment leakage is often driven by support or collaboration behaviour rather than build mistakes. That means secret detection must cover non-code text fields, and response playbooks must assume the secret may already be public even if the repository itself is clean.
Technical breakdown
Why comment history turns text boxes into secret storage
GitHub issue and pull request comments are not just ephemeral chat. They are persisted, versioned text fields that can be rendered publicly and, in many cases, remain discoverable after a user edits the original content. That means a secret can exist in the current view, the edit history, or external archives at the same time. For governance purposes, this turns a support comment into a secret-bearing artifact with its own retention and exposure characteristics. A scanner must therefore look at both current text and historical revisions, because deletion in the interface does not equal removal from the wider data surface. Read Guide to the Secret Sprawl Challenge.
Practical implication: Scan comment history and revision trails, not just live repository files.
Why plain text comments are a higher-risk leakage path than code blocks
The research notes that most leaked secrets were typed directly into plain text rather than wrapped in code blocks. That matters because security tooling and human reviewers often pay closest attention to code snippets, while plain prose appears harmless. In practice, this is a human-factor failure mode: users treat a comment box like an internal ticket, not a public data surface. The result is that a secret can bypass developer expectations, scanning heuristics, and code-focused review habits. The key technical issue is not markdown syntax, but that the credential is exposed in a universally readable field with no containment boundary. See the API Key Management Guide.
Practical implication: Treat freeform comment fields as secret-exposure surfaces in scanning rules and review workflows.
Why exposed credentials still require immediate revocation after deletion
Deleting or editing a comment does not reliably invalidate the credential that was exposed. The article points out that an attacker may already have copied the key, and external archives may retain the original text even after the visible comment changes. In other words, the security event is the disclosure itself, not the continued visibility of the text. Once a live API key has been posted, the only reliable containment step is to revoke or rotate it. This is the same logic that applies to NHI secrets generally: exposure creates an access window that cannot be closed by content cleanup alone. Read the Ultimate Guide to NHIs: What are Non-Human Identities.
Practical implication: Rotate any exposed key immediately and treat comment deletion as only a housekeeping step.
Threat narrative
Attacker objective: Obtain and reuse valid API credentials that can be replayed against the affected service or environment.
- Entry occurs when a user pastes a live API key or password into a public GitHub issue or pull request comment instead of into a controlled secret store.
- Credential exposure persists because the comment, its edit history, and external archives can all retain the secret after the user attempts to clean it up.
- Impact follows when an attacker or scraper copies the exposed credential and uses it before the owner rotates it.
Breaches seen in the wild
- 12,000 secrets in LLM training data: Truffle Security found 11,908 live API keys and passwords hard-coded in web pages captured by Common Crawl, a dataset used to train LLMs.
- 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.
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 leakage has moved out of the codebase and into the collaboration layer. The important governance shift in this article is that public issue and pull request comments are now part of the credential attack surface, not just a communication channel. That widens the control boundary for NHI programmes because secrets governance has to cover text entry fields, comment history, and disclosure response as one workflow. The practitioner implication is to expand secret detection to every user-generated field that can persist or be replayed.
Comment history is a standing exposure window, not a removable mistake. Once a live credential enters a public comment, the organisation no longer controls every copy of it. That failure mode is structurally different from a committed secret because the leak can survive edits, deletion, and user intent to correct it. The control gap is the assumption that removing the visible post removes the risk. Practitioners should treat exposure as irreversible until the secret is revoked.
Support interactions are now a common NHI leakage path. The article shows that people leak credentials while asking for help, not only while coding. That is why identity governance has to account for support desks, vendor repositories, and community threads as part of the credential lifecycle. The broader lesson is that machine identity governance fails when it stops at source control and ignores the rest of the operational conversation. Practitioners should fold support channels into their secret-discovery model and key challenges and risks assessments.
Live secrets create a stronger governance problem than expired ones. The article's focus on verified live credentials is the right one, because only active secrets represent an immediate access path. That distinction matters for NHI governance: expired material can distort prioritisation, while live credentials define real exposure and remediation urgency. The practitioner conclusion is to prioritise revocation workflows around verified live secrets, not generic hygiene metrics.
From our research library:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Secret discovery must move upstream into collaboration workflows. The next maturity step for NHI governance is not better cleanup, but broader detection across issue trackers, comment histories, and support channels where users paste live credentials. If the control boundary stops at code, the organisation will keep missing the places where people actually expose secrets.
Comment history creates a persistence problem that policy alone does not solve. A deleted post can still leave an accessible trail in version history or external archives, so response models must assume disclosure persists after the user thinks it is fixed. That is why revocation speed matters more than remediation optics.
Live-secret exposure is the signal that matters. Verified active credentials should drive prioritisation because they create a real replay path, while expired material mostly creates noise. Teams that cannot separate live from dead secrets will misallocate effort and understate the operational risk of public collaboration tools.
For practitioners
- Expand scanning to comments and edit history Include GitHub issue comments, pull request comments, and prior comment versions in secret-detection coverage so exposed credentials are found where users actually paste them.
- Rotate exposed keys before cleanup is considered complete If a live secret appears in a public comment, revoke or rotate the credential immediately and treat deletion of the comment as a secondary housekeeping task.
- Mask automated bot output in public threads Review any automation that comments on pull requests or issues and ensure its output never reveals tokens, credentials, or other sensitive values in plain text.
- Add support-channel checks for customer-shared secrets Build a workflow for SaaS support and community repositories that flags customer-submitted credentials and routes them through secure intake and remediation.
- Audit your own historical comments Search older issue and pull request comments for pasted credentials, because edited text and version history can preserve the original secret even when the current view looks clean.
Key takeaways
- Public collaboration tools can leak live API credentials even when no code is committed.
- Comment edits and deletions do not reliably remove the original exposure path.
- Revocation is the control that matters, because cleanup alone does not invalidate a leaked key.
Related NHI Mgmt Group resources: Guide to the Secret Sprawl Challenge · API Key Management Guide · Ultimate Guide to NHIs
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 CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Public comments and edit history expose live NHI secrets outside the intended control boundary. |
| NHI-07 — Long-Lived Secrets | The article shows live API keys persisting in comments long enough to remain exploitable. | |
| Recommendation — Scan collaboration surfaces for exposed secrets and revoke any leaked credentials immediately. Replace long-lived API keys with shorter-lived or more tightly scoped credentials where possible. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle management is the direct control area for leaked API keys and their revocation. |
| Recommendation — Apply authenticator management to rotate or revoke exposed keys as soon as they are detected. | ||
| CIS Controls v8 | CIS-5 — Account Management | The leak shows accounts and tokens need lifecycle control beyond the code repository boundary. |
| Recommendation — Inventory and remove stale or exposed access paths across developer and support workflows. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The article is about acquiring valid credentials that can be reused by an attacker. |
| Recommendation — Map public credential exposure to credential-access techniques and prioritise detection of active secrets. | ||
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.
- Comment History Exposure: Comment history exposure occurs when an edited or deleted message still leaves earlier content available in version history or external archives. This matters because the visible text may look clean while the original credential remains discoverable and potentially usable by an attacker.
- Credential Revocation: Credential revocation is the process of disabling a secret, token, or key so it can no longer authenticate or authorize action. It is the operational half of detection, because exposed credentials remain dangerous until they are invalidated and replaced across every dependent system.
What's in the full report
Truffle Security's full post covers the operational detail this post intentionally leaves for the source:
- The sampling method used to inspect public GitHub pull request and issue comments across a large historical dataset
- Examples of how users exposed secrets in plain text comments and how edit history preserved the original values
- The TruffleHog scan flags used to inspect issue and pull request comments directly
- Practical disclosure examples showing how the researchers contacted affected parties after finding live credentials
👉 See Truffle Security's details on scanning GitHub comments and rotating exposed keys
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.
Published by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org