GitHub says secret scanning cleared 20,000 internal credential alerts in nine months

GitHub has published a rare inside look at how its own security team cleared a large backlog of exposed credentials, saying it found more than 20,000 secret-scanning alerts across more than 15,000 internal repositories before reducing the open-alert count to zero over nine months.

The July 2 post is not a new product launch, but it is a useful operational case study for security teams adopting automated secret detection at scale. GitHub says the first lesson was that a scary alert total did not equal the same number of active risks. Five repositories accounted for roughly 18,000 alerts, and those were inactive test fixtures, deactivated credentials, or deliberately realistic-looking test values. After developing criteria for bulk closure, the team says it was able to resolve that low-risk group in days and focus on the remaining alerts that could represent live access.

Why it matters

Secret scanning tools are now common in source-control and DevSecOps programs, but the hard part is often the workflow around them: deciding which alerts are real, finding the owner of an exposed token, rotating credentials without breaking production systems, and preserving enough audit history for incident response. GitHub's account emphasizes that remediation reached beyond code into support tickets, bug bounty reports, incident notes, and wiki pages where tokens may also appear.

The company says it enabled secret scanning and push protection broadly across its enterprises and organizations so new exposures would be blocked while the historical backlog was triaged. For live-credential validation, GitHub initially built narrow checks that asked only whether a credential still worked and who might own it, while treating ambiguous responses as inconclusive. GitHub says native validity checking is now built into its secret scanning product, which helped accelerate the later stages of the cleanup.

Lessons for security teams

• Alert volume should be grouped by repository, secret type, age, and likely validity before teams assign manual review work.
• Bulk closure can be appropriate for known test repositories and inactive fixtures, but only with documented criteria.
• Revoking or rotating a credential usually comes before debating whether to rewrite repository history.
• Deleted repositories can remove forensic context, so archiving and preserving audit trails may be safer than erasing old projects.

For organizations drowning in scanner output, the message is pragmatic: secret hygiene is less about one heroic cleanup sprint than about stopping new leaks, separating noise from risk, and building repeatable ownership paths for whatever remains.

Sources

• github.blog

Cover image: FutUndBeidl, source, licensed under BY.