Fix live credentials with the widest access first, then live credentials in public places, then dead credentials you only need to confirm, and last the test data. Validity decides urgency, reach decides order within it, and exposure location breaks ties. Everything else is cleanup.
Why order matters
A scanner can return hundreds of alerts. Treating them equally means the production database password waits behind a sample token in a README. A short, written order avoids that.
The three questions
- Is it live? GitHub's secret scanning documentation describes validity checks that verify whether a detected secret is still active, to help prioritise remediation. Without such a check, test it with the provider or ask the owner.
- What can it reach? A read only key to a sandbox differs from an admin credential to production data.
- Who could have seen it? A public repository, a public package or a wide chat channel is a bigger audience than a private repository with five people.
Triage table
| Priority | Condition | Action |
|---|---|---|
| 1 | Live, broad access, public exposure | Revoke now, review logs |
| 2 | Live, broad access, private exposure | Revoke today, review logs |
| 3 | Live, narrow access | Revoke this week |
| 4 | Revoked or expired, unconfirmed | Confirm with the provider, close |
| 5 | Test or example value | Label with a reason, close |
Steps for each alert
- Identify the credential type and the issuing system.
- Find the owner. Use commit author, repository owner or the team that holds the account.
- Check validity.
- Revoke and rotate if live. Create the replacement first when downtime matters.
- Review activity for the exposure window. See how to check whether a key was used.
- Close the alert with a reason: revoked, false positive, used in tests.
- Record anything the process should change, such as a missing push block.
GitHub's guidance says to close the alert as revoked and document the incident and lessons learned.
Keep the queue healthy
- Set a service level per priority and report misses.
- Review closed as false positive items monthly. A pattern of false positives suggests a rule to tune.
- Track how many alerts were live when found. If it is rising, prevention is failing.
Quick check
Should I wait for validity checks before revoking?
No, if the exposure is public or the access is broad. Revoking an already dead key costs nothing.
What if nobody owns the credential?
Treat that as a finding. Revoke if you can safely, otherwise escalate to the account owner. Orphaned credentials are a risk by themselves.
Safeguard groups scan findings and supports policies that block risky changes, and you can try a free scan.
Sources
Last reviewed: 19 October 2026.
