GitHub scrubbed 20,000 secrets in 9 months: here's how

GitHub’s own secret scanner turned up 20,000+ secrets across 15,000+ repositories — but five repos alone accounted for 18,000 alerts, every one of them inactive test fixtures. Real risk was closer to 2,000 alerts.

Nine months later, they hit inbox zero. Here’s the playbook, straight from the team that built the tool.

90% of alerts were noise; the hard part was the rest

GitHub Security launched an internal hygiene initiative years ago, piloting the secret scanning product they were developing. First discovery: raw alert count is nearly useless. 18,000 alerts lived in dedicated test repositories — fake credentials, deactivated tokens, valid-looking but harmless test patterns. Bulk-closing those took days.

That left 2,000 alerts requiring human judgment: potential live credentials, secrets buried in support tickets, bug bounty reports, incident notes, and wiki pages. Secrets don’t stay in code. Partnering with customer support, incident response, and the bug bounty program was necessary to build shared playbooks for redaction and routing — without creating new leaks by opening issues or pushing commits containing the secrets.

Stop the leak, then validate what’s live

Phase one: enable secret scanning and push protection at the enterprise level, enforced so no repo could opt out. No new secrets in, backlog stops growing. Phase two: triage by repository, secret type, and age.

Phase three was the hard technical bit. At the time, GitHub’s secret scanning lacked native validity checking, so they built their own narrow check: for a GitHub token, a single authenticated GET /user request. No follow-on probes into repos or orgs. Privacy and legal teams were involved to ensure even “read-only” checks were acceptable. That manual work later fed into the product — validity checking is now native in secret scanning.

Ownership is the bottleneck, not detection

Even after validation, they still didn’t know who could rotate each credential. GitHub tokens came with metadata (creator, scopes, creation date), but third-party secrets required detective work. The pain exposed a deeper problem: not all 15,000+ repos had clear owners. GitHub’s Engineering Fundamentals program enforced ownership on services, but many repos didn’t map cleanly. That drove a company-wide initiative using Custom Properties to assign durable owners — because you cannot rotate what you cannot find.

Make hygiene everyone’s KPI

Final phase: systematize. Document playbooks per secret type. Route alerts into the internal vulnerability management platform. Automate notifications based on repo ownership. And the killer move — tie secret remediation to Engineering Fundamentals, making it a mandatory metric. When leadership watches the dashboards, teams find time to fix things.

GitHub’s own product now bakes in validity checking, ownership hints, and workflow automation. Today, you can start by enabling secret scanning and push protection everywhere, bulk-close noise, validate live credentials, and route to owners. The next piece is durable repository ownership — the foundation everything else depends on.

Source: How GitHub used secret scanning to reach inbox zero
Domain: github.blog