Show three things: when the alert was raised, when the credential was rotated or revoked, and what you checked for misuse. GitHub's documentation advises rotating an exposed credential immediately and notes that scrubbing Git history is time-intensive and often unnecessary once the credential is revoked.
What secret scanning covers
GitHub documents that secret scanning checks your entire Git history on all branches for hardcoded credentials such as API keys, passwords and tokens. It also scans issue and pull request titles, descriptions and comments, discussions, wikis and secret gists, and rescans when new secret types are added. For some partner secrets, GitHub notifies the provider so they can act, such as revoking the credential.
An alert appears on the repository's security tab with details about the exposure.
What "handled properly" looks like on paper
| Step | Evidence to keep |
|---|---|
| Detection | Alert creation time and secret type |
| Containment | Rotation or revocation time in the secret manager or provider console |
| Impact check | Notes or log queries on use of the key since exposure |
| Closure | Alert state with a resolution reason |
| Prevention | A change that makes the repeat less likely, such as push protection |
The gap between the first row and the second is your response time. That is the number an auditor or customer will care about.
Steps
- When an alert fires, open a ticket and link the alert.
- Rotate the credential first. Do not wait to rewrite history.
- Check the provider logs for use of the old credential during the exposure window and write down what you found, including "no unusual use seen".
- Resolve the alert with the appropriate reason and a comment that names the ticket.
- Ask what let the secret in. If it was a local file, add a pre-commit check. If it was a test fixture, change how fixtures are made.
- Record the lesson in one sentence on the ticket.
Setting a response target
Pick a number and write it in your incident or vulnerability policy: for example, rotate within one business day of an alert for a live credential. Then measure it. Each alert has a creation time and each rotation has a timestamp in your secret manager or the provider console, so the gap is easy to compute. If you miss the target, note why. Repeated misses tell you the process needs an owner on call, not a better dashboard.
Common mistakes
Closing the alert as "used in tests" without checking whether the value was real is a frequent one. Another is deleting the commit and calling it done. The credential was already visible, so the exposure happened.
Also remember that GitHub's scanning only recognises patterns it knows. A clean alert list is not a statement that no secret is present. For a deeper look, read adopting secret scanning on an old repository.
Where Safeguard fits
Safeguard offers compliance and evidence automation and policies and gates that can block risky changes before merge. A free scan looks at your dependencies.
Quick check
Is rewriting Git history required after a leak?
GitHub's documentation says it is time-intensive and often unnecessary if the credential has already been revoked. Rotate first.
Does an empty alert list prove there are no secrets?
No. Scanning finds known patterns only. Treat it as one control among several.
Sources
Last reviewed: 19 October 2026.
