Join our Newsletter — 33% off our NHI Course

GitHub comments leak secrets: what should repository teams do?

 

(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 16521
Topic starter  

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.

Editorial analysis by NHI Mgmt Group, based on content published by Truffle Security: “Think Twice Before Commenting: Thousands of GitHub Comments Leak Live API Keys”.

By the numbers:

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.

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.

Q: How should security teams handle secrets that may still be recoverable after a repository, branch, or comment is deleted or edited?

A: Security teams should assume deletion, editing, or privacy changes do not guarantee removal of exposed secrets.

Practitioner guidance

  • 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.

Bottom line: Public collaboration tools can leak live API credentials even when no code is committed.

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

👉 Read Truffle Security's analysis of live API keys exposed in GitHub comments →

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 5 months ago
Posts: 17012
 

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.

A few things that frame the scale:

  • 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.

A question worth separating out:

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.

👉 Read our full editorial: GitHub comments expose live API keys beyond committed code



   
ReplyQuote
Share:

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.