GitHubs Strategie: Wie Secret Scanning Inbox Zero ermöglichte

GitHubs Sicherheitsabteilung startete vor Jahren ein Projekt, um die Geheimhaltungspraktiken zu optimieren und Risiken zu minimieren. Im Rahmen dieser Initiative wurde die damals noch in Entwicklung befindliche Funktion Secret Scanning getestet – mit überraschenden Erkenntnissen. Statt der erwarteten wenigen Hundert wurden über 20.000 geheime Zugangsdaten in mehr als 15.000 Repositories entdeckt. Die Herausforderung bestand nicht nur in der schieren Menge, sondern darin, echte Sicherheitsrisiken von harmlosen Testdaten zu unterscheiden und systematisch zu beheben. Nach neun Monaten harter Arbeit gelang es GitHub, die letzte offene Warnung zu schließen – ein Meilenstein für die interne Sicherheitspolitik.

Warum die Warnanzahl trügerisch sein kann

Die anfängliche Zahl von 20.000 Warnungen entpuppte sich schnell als irreführend. Eine detaillierte Analyse zeigte, dass fünf Repositories allein für 18.000 dieser Warnungen verantwortlich waren – und alle dort gefundenen Zugangsdaten waren inaktiv. Es handelte sich um Testumgebungen, deaktivierte Anmeldedaten oder scheinbar echte, jedoch absichtlich gefälschte Schlüssel für Testzwecke. GitHub entwickelt schließlich selbst Secret-Scanning-Tools und sammelt in Testrepositories bewusst solche Muster.

Übrig blieben rund 2.000 Warnungen, die tatsächlich Aufmerksamkeit erforderten: potenziell aktive Anmeldedaten und komplexe Entscheidungen zu Risikobewertung, Rotation und Behebung. Die Erfahrung zeigte, dass die bloße Anzahl der Warnungen kein zuverlässiger Indikator für tatsächliche Sicherheitslücken ist. Vielmehr kommt es auf die Kontextualisierung an – wo genau die Zugangsdaten liegen, wie alt sie sind und ob sie jemals genutzt wurden.

Geheimnisse verstecken sich überall – nicht nur im Code

Nicht alle sensiblen Daten finden sich in Quellcode-Repositories. GitHub entdeckte geheime Zugangsdaten auch in:

• Support-Tickets, in denen Kunden versehentlich Tokens einreichten
• Bug-Bounty-Berichten, in denen Sicherheitsforscher ihre Funde mit vollständigen API-Anfragen inklusive Tokens dokumentierten
• Incident-Notes, die während Sicherheitsvorfällen erstellt wurden
• Wiki-Seiten, auf denen technische Details oder Konfigurationen geteilt wurden

Um diese verstreuten Risiken zu kontrollieren, arbeitete GitHub eng mit den Teams für Kundensupport, Incident-Response und Bug-Bounty-Programm zusammen. Gemeinsam wurden standardisierte Abläufe entwickelt, um sicherzustellen, dass bei der Behebung dieser Daten keine neuen Sicherheitslücken entstanden – etwa durch das versehentliche Veröffentlichen von Tokens in neuen Commits oder Issues.

Der strukturierte Weg zur Geheimnisbereinigung

Die Bereinigung von 20.000 Warnungen war keine Aufgabe, die ein kleines Team von Sicherheitsingenieuren in kurzer Zeit hätte bewältigen können. Stattdessen setzte GitHub auf einen dreiphasigen, operationalen Ansatz, der auf Skalierbarkeit, Wiederholbarkeit und Messbarkeit ausgelegt war – ähnlich der Behandlung technischer Schulden in der Softwareentwicklung.

Phase 1: Neue Risiken verhindern

Bevor bestehende geheime Daten bereinigt wurden, galt es zunächst, die Ansammlung neuer Risiken zu stoppen. Dies gelang durch die flächendeckende Aktivierung von Secret Scanning und Push Protection in allen Unternehmens- und Organisationsbereichen. Dank der unternehmensweiten Einstellungen in GitHub Advanced Security musste nicht jedes der 15.000 Repositories einzeln konfiguriert werden. Stattdessen wurden die Schutzmaßnahmen verpflichtend gesetzt, sodass Teams nicht mehr eigenständig darauf verzichten konnten.

Push Protection verhinderte, dass neue geheime Daten überhaupt in die Repositories gelangten. Dadurch wurde sichergestellt, dass der „Schuldenberg“ nicht schneller wuchs, als er abgebaut werden konnte. Diese Maßnahme legte den Grundstein für nachhaltige Geheimnisverwaltung.

Phase 2: Priorisierung und Klassifizierung

Der nächste Schritt bestand darin, die 20.000+ Warnungen nach Repositories, Geheimnistyp und Alter zu sortieren, um zwischen „Rauschen“ und echten Risiken zu unterscheiden. Dabei zeigte sich erneut, dass der Großteil der Warnungen auf Testumgebungen und veraltete, inaktive Zugangsdaten entfiel.

Für Warnungen mit hohem Volumen, aber geringem Risiko wurden klare Kriterien für die Massenbereinigung definiert. Beispielsweise konnten geheime Daten in dedizierten Testrepositories, die nie aktiv genutzt wurden und bekannten Testmustern entsprachen, sicher als bereinigt markiert werden. Innerhalb weniger Tage wurden so rund 18.000 Warnungen geschlossen – ein entscheidender Fortschritt.

Doch nicht alle Entscheidungen waren einfach. Die Sicherheitsverantwortlichen standen vor komplexen Fragen:

• Soll ein geheimes Token in einem Issue bearbeitet werden? Eine Bearbeitung könnte die Versionshistorie löschen und damit wichtige Audit-Daten verlieren.
• Darf ein Repository gelöscht werden, wenn es nicht mehr genutzt wird? Die Antwort war meist nein, da gelöschte Repositories auch ihre Forensikhistorie mitnehmen. Ohne diese könnte ein einst kompromittiertes Repository im Ernstfall nicht mehr untersucht werden.
• Ist ein Rewrite der Git-History sinnvoll? Ein solcher Eingriff kann Pull Requests unterbrechen, Commit-Hashes ungültig machen und Entwicklerteams massiv behindern.

Die Regel lautete: Zuerst das Token rotieren oder widerrufen, dann entscheiden, ob eine Historienbereinigung notwendig ist. Oft reichte es aus, den Zugriff zu sperren, ohne die Historie zu verändern.

Phase 3: Validierung aktiver Zugangsdaten

Der kritischste Schritt bestand darin, zu überprüfen, ob die gefundenen geheime Daten tatsächlich noch aktiv waren. Ein Credential, das vor Jahren rotiert wurde, stellt ein geringeres Risiko dar als eines, das noch immer Zugriff auf Produktionssysteme ermöglicht. Doch zu diesem Zeitpunkt verfügte Secret Scanning nicht über eine native Funktion zur Gültigkeitsprüfung, sodass GitHub eine eigene Lösung entwickeln musste.

Das Ziel war klar: Ermitteln, ob ein Credential noch funktioniert – ohne unnötige Tests, die die Sicherheit gefährden könnten. Diese Validierung war entscheidend, um Prioritäten zu setzen und die begrenzten Ressourcen der Sicherheits-Teams effizient einzusetzen.

Lessons Learned: Systematische Sicherheit statt Ad-hoc-Lösungen

GitHubs Erfahrung zeigt, dass die Bereinigung sensibler Daten kein einmaliger Prozess, sondern eine kontinuierliche Sicherheitsdisziplin sein muss. Die wichtigsten Erkenntnisse aus dem Projekt lassen sich wie folgt zusammenfassen:

• Automatisierung ist unverzichtbar: Manuelle Prüfungen skalieren nicht bei Tausenden Repositories. Tools wie Secret Scanning und Push Protection müssen verpflichtend und zentral gesteuert werden.
• Kontextualisierung ist entscheidend: Nicht jede Warnung ist ein kritisches Risiko. Eine klare Klassifizierung nach Risikostufen spart Zeit und Ressourcen.
• Kollaboration über Abteilungsgrenzen: Geheimnisse verstecken sich überall – in Tickets, Wikis oder Incident-Reports. Standardisierte Abläufe mit Support, Incident-Response und Bug-Bounty-Teams sind unerlässlich.
• Entscheidungen erfordern Trade-offs: Die Balance zwischen Sicherheit, Compliance und Entwicklerproduktivität ist komplex. Historienbereinigungen oder Repository-Löschungen haben oft weitreichende Folgen.

Für Unternehmen, die ähnliche Herausforderungen meistern wollen, bietet GitHubs Ansatz eine blaupauseartige Anleitung – von der Verhinderung neuer Risiken über die systematische Aufräumarbeit bis hin zur validierten Risikobewertung. Die größten Sicherheitslücken entstehen oft dort, wo niemand sie vermutet – doch mit der richtigen Strategie lassen sie sich entschärfen.

Die Reise zu Inbox Zero für geheime Daten war beschwerlich, aber lehrreich. Sie zeigt: Sicherheit ist kein Ziel, sondern ein Prozess – und Tools allein reichen nicht aus. Erst durch klare Prozesse, kontinuierliche Prüfung und interdisziplinäre Zusammenarbeit lässt sich das Risiko langfristig minimieren.