GitHub secret scanning runs automatically and free on public repositories. For private repositories owned by an organization, it needs GitHub Secret Protection on a Team or Enterprise Cloud plan. When any secret leaks, the rule is the same: rotate the credential first, and treat rewriting history as optional.
What it scans
GitHub's documentation says secret scanning checks a repository's full Git history on all branches. It also covers issue and pull request text, discussions, wikis and secret gists. A finding creates an alert in the security tab.
Some secrets are detected by partner programs and reported to the service provider, who may revoke them. Those do not show up in your own alerts.
Where it is available
- Public repositories: automatic and at no cost.
- Organization owned private and internal repositories: available with GitHub Secret Protection on GitHub Team or Enterprise Cloud.
- User owned repositories: only on certain enterprise setups, per the same page.
A small startup with private repositories under a free organization plan should check what is actually enabled rather than assume coverage.
GitHub also offers a free assessment of an organization's code for leaked secrets from the Assessments page, which is a cheap way to learn how big the problem is.
What to do when a secret leaks
GitHub's advice is to rotate the affected credential immediately, and notes that rewriting Git history is often unnecessary once the credential is revoked. Follow this order:
- Revoke or rotate the secret at the provider.
- Check the provider's logs for use of the key during the exposure window.
- Replace the secret in your deployment config.
- Close the alert with a note on what was done.
- Find out how it got there, and add a prevention step.
Prevent the next one
Keep secrets out of code by using a secrets manager or environment injection. Add a pre commit or CI check so that leaks are blocked before they reach the shared repository. Do not rely on one control. Local env files, CI logs and chat messages all leak credentials too.
Beyond repositories
Safeguard scans for secrets alongside dependency and code findings, and you can run a free scan at gold.safeguard.sh/scan to see what turns up.
Common pitfalls
A few more habits help. Use separate credentials for development and production, so a leaked development key has limited reach. Give keys the narrowest permissions and shortest lifetime the provider allows. Keep a list of where each secret is used, since the hardest part of rotating a leaked key is often finding every place that depends on it. And review the alert list in your weekly security hour so that open alerts do not age.
Also remember that a secret in a public repository is likely to be found by automated scrapers quickly, so treat exposure of a live key in public as an incident from the first minute, even if the commit was removed seconds later.
Quick check
Do we have to scrub the Git history?
Per GitHub, rewriting history is often unnecessary once the credential is revoked. Rotation is what removes the risk.
Sources
Last reviewed: 19 October 2026.
