Secrets leak in issues and pull requests too, not just code

Credentials leak outside source files all the time: in issue descriptions, pull request comments, discussions and wikis. GitHub's secret scanning covers the full Git history on all branches and also those surfaces. When a token turns up in any of them, rotate it first, then delete the text.

What GitHub says it scans

GitHub's documentation lists these surfaces:

• the entire Git history of a repository, on all branches
• issue descriptions and comments, including open and closed historical issues
• pull request titles, descriptions and comments
• GitHub Discussions, wikis and secret gists

GitHub also periodically rescans repositories when new secret types are added, so an old leak can surface later.

Why the non-code places matter

Support threads get pasted into issues, with logs that include tokens. Reviewers paste commands that contain a key. A debug session ends up in a comment. These are easy to miss because nobody reviews old issues.

Deleting a comment does not recall a token that someone already copied or that a notification email carried.

Partner patterns and alerts

For partner patterns, GitHub validates detected secrets with the service provider and notifies it so it can act, for example by revoking the credential. Those do not appear as alerts in your repository. For alerts that do appear, GitHub advises rotating the credential immediately. You can add custom patterns and validity checks, and some detection options are described as AI assisted.

Who gets it

Secret scanning runs automatically for public repositories at no cost. For organization owned private and internal repositories, it needs GitHub Secret Protection on a Team or Enterprise Cloud plan. Confirm your own plan's coverage on GitHub's pricing and docs pages, as they change.

A response routine

1. Treat the credential as exposed and rotate it.
2. Check logs for use of the old credential since the post time.
3. Edit or delete the comment so it does not keep teaching the habit.
4. Add a line to your issue template asking people to redact tokens.
5. If it was in code, follow the leaked secret response order.

Prevent it

Ask support staff and contributors to redact logs, give your issue template a redaction reminder, and use push protection so code never carries the key. See stopping secrets before they reach Git.

Think about the human side too. People paste tokens into issues because they are stuck and want help fast, not because they are careless. A friendly template and a clear way to ask for help privately make leaks less likely than a stern warning does. When a leak does happen, thank the person, rotate the key, and avoid naming them in public threads, so the next person speaks up quickly instead of deleting the evidence.

Quick check

Safeguard compliance and evidence automation can record your rotation steps as evidence, and the free scan at gold.safeguard.sh/scan covers dependency risk.

Sources

• About secret scanning, GitHub Docs

Last reviewed: 19 October 2026.