How GitHub eliminated secret alerts with phased cleanup and automation

GitHub’s security team faced an unexpected challenge when they discovered over 20,000 exposed secrets scattered across more than 15,000 repositories during a routine hygiene assessment. The sheer volume of alerts—far exceeding initial projections—highlighted a critical gap in their secrets management strategy. Nine months later, they achieved their goal of "inbox zero" for secret scanning alerts, proving that even large-scale systems can be systematically cleaned up with the right approach.

This initiative wasn’t just about reducing noise—it was about establishing sustainable practices to prevent future accumulation and prioritize genuine risks. Like many long-running software companies, GitHub’s secrets management evolved organically over time, long before modern tools like centralized vaults, automated scanners, and dedicated secrets-management platforms became industry standards. Their journey offers valuable lessons for organizations grappling with similar security challenges.

The real risk wasn’t the sheer number of alerts

The initial count of 20,000 alerts painted an alarming picture, but further investigation revealed that most were non-critical. Nearly 18,000 of these alerts originated from just five repositories, all of which contained inactive secrets—test fixtures, expired credentials, or placeholder values used in development environments. Given GitHub’s role in building secret scanning tools, it’s no surprise their own repositories contained a high concentration of synthetic secrets designed to test detection capabilities.

This discovery underscored a critical insight: alert volume alone doesn’t reflect actual risk. Many organizations struggle with this distinction, prioritizing cleanup based on sheer numbers rather than contextual relevance. GitHub’s approach shifted focus toward identifying live credentials and high-risk exposures, drastically narrowing the scope of their remediation effort.

Secrets hide in more than just source code

One of the most surprising revelations was the diversity of locations where secrets were found. Beyond repositories, exposed credentials appeared in:

• Customer support tickets, where users occasionally included tokens in their inquiries
• Bug bounty reports, where researchers documented vulnerabilities with full API requests
• Incident response notes and internal wiki pages

Addressing this required collaboration across multiple teams, including security incident response, customer support, and the bug bounty program. A unified playbook ensured consistency in handling these cases without introducing new risks—such as inadvertently exposing secrets during cleanup or altering audit trails.

A three-phase strategy to eliminate secret backlogs

GitHub’s cleanup effort followed a structured, three-phase approach designed to stop new issues while systematically reducing existing ones. This mirrored their standard operational backlog management, emphasizing repeatability, measurability, and scalability.

Phase 1: Prevent new secrets from entering the system

Before tackling the existing backlog, GitHub prioritized stopping the flow of new secrets. They enabled secret scanning and push protection across all enterprise and organizational accounts using GitHub Advanced Security’s organization-level settings. This centralized enforcement prevented individual repositories or teams from opting out, ensuring consistent protection without the need for repository-by-repository manual configuration.

Push protection blocked new secrets at the source, effectively capping the backlog growth while they worked to reduce existing alerts. This proactive measure was critical to maintaining momentum and preventing the problem from worsening.

Phase 2: Triage alerts to separate noise from real risks

With alerts continuing to pour in, GitHub needed a way to prioritize effectively. They categorized alerts by repository, secret type, and age, which helped them distinguish between high-risk exposures and low-impact test data.

For low-risk alerts—such as secrets in dedicated test repositories or those matching known test patterns—they established bulk-closure criteria. This allowed them to confidently resolve thousands of alerts in days, reducing the backlog by roughly 18,000 entries.

However, this phase also required addressing complex questions about remediation methods. For example:

• Should a secret in an issue be edited, potentially altering revision history?
• Is rewriting Git history acceptable when a credential appears in a commit?
• Should an unused repository be deleted to remove exposure, or preserved for forensic purposes?

GitHub’s stance was clear: deleted repositories erase audit trails, which are essential for incident response. Instead, they focused on rotating or revoking exposed secrets first, reserving more invasive actions like Git history rewrites for cases where residual risk justified the disruption.

Phase 3: Verify which secrets remain active

A credential sitting dormant in a repository might no longer grant access—or it could still pose a threat. Without native validity-checking tools at the time, GitHub developed their own approach to determine whether a secret still worked. This step was crucial for prioritizing remediation efforts, as it allowed them to focus on credentials that posed an immediate risk rather than those already rotated or expired.

Lessons for organizations tackling secrets management

GitHub’s experience demonstrates that secrets cleanup isn’t just a technical challenge—it’s an operational one. The most effective strategies combine preventative measures, intelligent triage, and collaborative workflows. For organizations considering similar initiatives, key takeaways include:

• Centralize enforcement to prevent inconsistent adoption across teams.
• Automate where possible to reduce manual effort and human error.
• Prioritize based on risk, not volume, to maximize impact.
• Preserve audit trails unless absolutely necessary to alter them.

As secrets management tools continue to evolve, GitHub’s approach serves as a blueprint for balancing security with operational efficiency. The goal isn’t just to reach inbox zero—it’s to build systems that sustain that state without constant intervention.