How GitHub Tackled 20,000 Secrets to Reach Inbox Zero

How GitHub Tackled 20,000 Secrets to Reach Inbox Zero

Imagine waking up one day to find 20,000 secrets scattered across your organization’s repositories. That’s exactly what happened to GitHub a few years ago when they piloted their Secret Scanning tool. But here’s the kicker: nine months later, they reached inbox zero. How did they pull it off? Buckle up, because this story is a masterclass in scaling security and automating the boring stuff.

The Challenge: 20,000 Secrets, 15,000 Repositories

GitHub’s journey started with a daunting number: 20,000 secrets. These weren’t just in code—they were hiding in support tickets, bug bounty reports, incident notes, and even wiki pages. The problem was clear: secrets management had evolved over time, but legacy practices left gaps. And with GitHub’s scale, those gaps added up quickly.

The first step was to cut through the noise. Out of the 20,000 alerts, 18,000 were in just five repositories, and most of those were inactive (test fixtures, deactivated credentials, etc.). That left around 2,000 alerts that needed real attention. But how do you tackle such a massive backlog without burning out your team?

The Phased Approach

GitHub broke the problem into manageable phases. Here’s how they did it:

1. Stop the Bleeding: Before cleaning up existing secrets, they enabled secret scanning and push protection across all repositories. This prevented new secrets from piling up and ensured the backlog wouldn’t grow faster than they could handle it.

2. Triage and Validate: Not all secrets are created equal. GitHub developed criteria to bulk-close low-risk alerts and focused on validating live credentials. They even built a custom validity-checking tool to determine whether a secret was still active.

3. Ownership and Accountability: One of the biggest challenges was figuring out who owned each secret. GitHub partnered with teams across the organization to develop playbooks and ensure secrets were routed to the right owners for remediation.

4. Automate the Workflow: To make the process scalable, GitHub automated notifications, routed alerts into their vulnerability management platform, and documented playbooks for different secret types. They also tied secret remediation to their Engineering Fundamentals program, making it a shared responsibility.

The Hard Questions

Along the way, GitHub had to make some tough decisions. Should they rewrite git history to remove secrets? (Spoiler: usually no, because it can break pull requests and invalidate commit SHAs.) Should they delete repositories that were no longer in use? (Again, no, because deleting a repository takes its audit trail with it.)

The key was to rotate or revoke the exposed secret first and then decide whether rewriting git history was worth the risk. These decisions aren’t one-size-fits-all, but GitHub’s approach offers a framework for thinking through the trade-offs.

Lessons Learned

GitHub’s journey to inbox zero wasn’t just about cleaning up secrets—it was about building a system that could handle secrets management at scale. Here are some of their key takeaways:

• Don’t panic at the number: The raw count of alerts is almost never the real scope of work.
• Enable and enforce everywhere: Partial rollouts create blind spots.
• Validate before you escalate: Not every detected secret is live.
• Metadata saves hours: Surfacing metadata (like who created a token and what scopes it has) can cut down on detective work.
• You can’t remediate without ownership: Invest in durable ownership infrastructure early.
• Make it everyone’s problem: Security teams can’t do it alone. Tie secret hygiene to broader engineering standards.

What This Means for You

The good news is that you don’t have to reinvent the wheel. Many of GitHub’s manual workarounds—like validity checking and bulk triage—are now native features in GitHub Secret Scanning. If you’re just getting started, here’s what you can do:

1. Enable secret scanning and push protection everywhere. No exceptions.
2. Triage the backlog by repository and secret type. Bulk-close what you can prove is noise.
3. Validate what’s live before escalating.
4. Route alerts to owners and track remediation like any other engineering work.

GitHub’s story is a reminder that secrets management isn’t just a technical problem—it’s an operational one. By combining automation, cross-team collaboration, and a relentless focus on ownership, they turned a mountain of alerts into a manageable workflow. And if they can do it, so can you.