GitHub secret scanning checks the full git history on all branches, plus issues, pull request titles, descriptions and comments, discussions, wikis, and secret gists. Its overview page does not list workflow run logs. So logs, other CI systems, artifacts, and chat tools remain your job to cover with other controls.
What it scans
GitHub's overview says secret scanning covers the entire Git history on all branches of a repository for hardcoded credentials, and rescans periodically as new secret types are added. It also covers non-code content: issue descriptions and comments including historical issues, pull request titles, descriptions, and comments, GitHub Discussions, wikis, and secret gists.
When a partner pattern is detected, GitHub notifies the provider so it can act, for example by revoking the credential. Partner secrets are reported directly to the provider and are not displayed in your repository alerts. That helps when a provider supports it, but it is not a substitute for knowing about your own leaks.
Availability
| Repository type | Availability, per GitHub's page |
|---|---|
| Public | Runs automatically for free |
| Organization owned private and internal | Available with GitHub Secret Protection on GitHub Team or Enterprise Cloud |
| User owned | Available on Enterprise Cloud with Enterprise Managed Users, or Enterprise Server with Secret Protection |
Other features the page lists include validity checks, custom and generic patterns, and AI detected secrets. Check what your plan actually includes before depending on any of these.
What the page does not mention
The overview does not mention workflow run logs, and it does not describe push protection. Do not assume either is covered based on this page. Check the dedicated documentation for your plan before you rely on them.
That matters because CI logs are where secrets often leak in practice. GitHub's secure use guidance says redaction happens on the runner and only applies to secrets used in that job, so you should not assume every exposure is masked. Error output from tools can print credentials.
Gaps and how to cover them
| Where secrets leak | Cover it with |
|---|---|
| Workflow logs and artifacts | Manual and scheduled log review, short retention, and a rule to delete the log and rotate on any hit |
| Other CI systems | That system's masking and scanning features plus periodic review |
| Chat and tickets | Policy, plus a response runbook for pasted secrets |
| Container images and build outputs | Scan images and artifacts before publishing |
| Developer machines | Pre-commit checks and training |
Steps to build a layered setup
- Turn on secret scanning wherever your plan offers it, and route alerts to a named owner.
- Treat every alert as a live credential until proven otherwise: revoke or rotate first.
- GitHub recommends rotating exposed credentials right away, since rewriting history is time intensive and often unnecessary once the credential is revoked.
- Add a check of CI logs after test runs, especially for error output.
- Scan build artifacts and images for credentials before they are published.
- Use short lived credentials, so a missed leak expires on its own.
- Track time from detection to rotation as a metric.
Quick check
If secret scanning is on, can I stop worrying about logs?
No. The overview page does not list workflow logs among scanned locations. Review logs separately and keep credentials short lived.
Should I rewrite git history after a leak?
Rotate first. GitHub's guidance says rewriting is often unnecessary once the credential is revoked.
Safeguard asset discovery and SBOM and dependency scanning help you see what is in your repositories and builds, and you can run a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
