GitHub found 20,000 secrets across 15,000 repositories when it piloted its own Secret Scanning tool. Nine months later, it reached zero open alerts. This post is the internal playbook of how that happened.
The real number that mattered was not 20,000. Five repositories alone held roughly 18,000 alerts, all inactive: test fixtures, deactivated credentials, and fake-but-valid tokens used to test the scanner itself. That left around 2,000 live-risk alerts requiring triage, rotation decisions, and remediation across source code, support tickets, bug bounty reports, and wiki pages. The team had to answer hard operational questions: edit an issue body and lose revision history, or preserve the audit trail and leave the secret visible? Rewrite git history and break open pull requests, or revoke the credential and leave the artifact in place? The post walks through each of these decisions with the actual reasoning used.
The three-phase approach was: enable push protection org-wide first to stop accumulation, triage by repository and secret type to separate noise from real risk, then validate liveness by building custom validity checks before Secret Scanning had that feature natively. The sample curl against GET /user for GitHub tokens is included. If your organization is sitting on an unquantified secret backlog, this is the operational detail you will not find in a vendor whitepaper.
[READ ORIGINAL →]