GitHub’s Modell zur Geheimniserkennung: Mehr Geheimnisse mit weniger Rauschen finden

höhere Akzeptanz

Owner-gewichtete Alarmgenauigkeit

niedrigere mediane Scan-Ausführungszeit

Post-Push-Scanning

niedrigere Serving-Kosten

Kompaktes Modell vs. remote LLM-Aufrufe

Secret Scanning funktioniert am besten, wenn Entwickler den Ergebnissen vertrauen. Wird zu wenig erkannt, können echte Zugangsdaten in einem Repository verbleiben. Wird zu oft alarmiert, verbringen Entwickler möglicherweise Zeit mit der Untersuchung von Zeichenketten, die keine Geheimnisse sind.

Generische Geheimnisse machen diese Balance besonders schwierig. Dieselbe Zeichenkette könnte echte Zugangsdaten oder ein Dokumentations-Platzhalter sein, daher erfordert die Erkennung ein Verständnis des umgebenden Codes und Texts.

Um diese Herausforderung zu bewältigen, haben wir einen Secret Classifier speziell für die Produktanforderungen von GitHub trainiert: echte Zugangsdaten von deren_doublegängern zu unterscheiden und gleichzeitig die Geschwindigkeits- und Effizienzanforderungen des Scanvorgangs im großen Maßstab zu erfüllen.

In unserem Begleitbeitrag, Secret protection must scale with software, haben wir erklärt, warum der Schutz von Geheimnissen mit der KI-beschleunigten Entwicklung Schritt halten muss. Hier werfen wir einen Blick hinter die Kulissen des kontextbasierten Klassifikators, der diese Bemühungen antreibt: wie wir ihn entworfen, trainiert und evaluiert haben, um mehr echte Geheimnisse mit weniger Rauschen zu finden.

Was wir aktiviert haben

GitHub secret scanning arbeitet zu zwei entscheidenden Zeitpunkten:

• Push protection hilft zu verhindern, dass Geheimnisse in ein Repository gelangen, indem Änderungen gescannt werden, bevor ein Push akzeptiert wird, wodurch Entwickler die Möglichkeit erhalten, den Befund zu beheben.
• Post-push scanning funktioniert, nachdem Code committet wurde, scannt kontinuierlich den Repository-Inhalt und erstellt Warnungen, wenn potenzielle Geheimnisse erkannt werden, damit Entwickler und Sicherheitsteams sie untersuchen und beheben können.

Wir haben einen schnellen Klassifikator entwickelt, der die mediane Ausführungszeit des Post-Push-Scans um 86% im Vergleich zur vorherigen LLM-basierten Pipeline reduzierte. Diese Effizienz machte es praktikabel, die Erkennung generischer Geheimnisse auf Push Protection auszuweiten, sodass Ergebnisse zurückgegeben werden, bevor Entwickler Änderungen pushen – nicht erst, nachdem der Code committet wurde.

Warum Geheimnisse schwer zu erkennen sind

Strukturierte Zugangsdaten enthalten oft ein markantes Präfix, eine bestimmte Länge, ein Alphabet oder eine Prüfsumme. Generische Geheimnisse mögen das nicht. Ihre Syntax überschneidet sich mit Build-Identifikatoren, Prüfsummen, Asset-Hashes, Beispielwerten und anderen nicht-sensiblen Zeichenketten. Der Kontext ist das entscheidende Signal.

Diese Fälle sind schwierige Negative: Zeichenketten, die einem Credential-Muster entsprechen, aber keine verwendbaren Credentials sind. Weitere Regeln hinzuzufügen kann einige davon unterdrücken, doch jede Ausnahme birgt das Risiko, ein echtes Geheimnis zu verbergen. Ein gelernter Klassifikator kann stattdessen Signale wie Dateipfad, Secret-Typ, Variablennamen und umgebenden Code oder Text nutzen.

Deshalb haben wir einen neuen Scanner mit einer zweistufigen Pipeline ausgeliefert:

1. Kandidatengenerierung: Regex-Filter durchsuchen Inhalte mit hoher Trefferquote nach potenziellen Geheimnissen. Diese Stufe ist darauf optimiert, breite Familien von credential-ähnlichen Mustern schnell und deterministisch zu erkennen.
2. Kontextbewusste Klassifizierung: Ein feinabgestimmter ModernBERT-Klassifikator bewertet jeden Kandidaten zusammen mit seinem umgebenden Kontext. Er wurde darauf trainiert, die Signale zu erkennen, die echte Geheimnisse von Fehlalarmen unterscheiden, darunter Platzhalterwerte, Beispiele, Dokumentationsausschnitte, generierte Inhalte und nicht sensible Kennungen. Da das Modell klein ist und auf unserer Inferenz-Infrastruktur effizient läuft, ist der Betrieb deutlich kostengünstiger und die Skalierung einfacher als bei einer LLM-basierten Pipeline.

Auswirkung:

• 11.5% Verbesserung der Nutzerakzeptanz, wodurch Fehlalarme reduziert werden.
• 86% schnellere Ausführungszeit der Geheimniserkennung nach dem Push.
• Mehr als 98% Kostenersparnis im Vergleich zur LLM-basierten Pipeline.

Wie unsere Pipeline funktioniert

Während der Inhalt gescannt wird, spannen Regex-Muster ein weites Netz und markieren alles, was nach einem Credential aussieht, damit echte Geheimnisse am Anfang nicht übersehen werden. Jeder Kandidat wird anschließend an einen feinabgestimmten ModernBERT-Klassifikator weitergeleitet, der den Wert zusammen mit seinem Dateipfad, Variablennamen und umgebenden Code liest. Der Klassifikator schätzt, wie wahrscheinlich es sich um ein echtes Geheimnis handelt. Befunde mit hoher Konfidenz werden zu Warnungen, und ähnlich aussehende Treffer wie Platzhalter, Test-Fixtures und Prüfsummen werden herausgefiltert, bevor sie die Entwickler erreichen.

SCHRITT 1

Scannen

Repository-Inhalte, Commits, Pull Requests und andere gescannte Oberflächen.

SCHRITT 2

Kandidaten generieren

Regex-Muster identifizieren mögliche Tokens, Schlüssel und credential-ähnliche Zeichenketten.

SCHRITT 3

Klassifizieren

Der feinabgestimmte ModernBERT bewertet Kandidat + Kontext und weist die Wahrscheinlichkeit eines echten Geheimnisses zu.

SCHRITT 4

Warnen oder unterdrücken

Befunde mit hoher Konfidenz werden weitergeleitet; wahrscheinliche Fehlalarme werden gefiltert.

Die wichtige Designentscheidung besteht darin, dass das Modell das deterministische Scannen nicht ersetzt. Stattdessen ergänzt es dieses. Regexes bleiben das richtige Werkzeug, um Kandidaten-Zeichenketten schnell zu finden. Der Klassifikator wird dort eingesetzt, wo maschinelles Lernen den größten Nutzen bietet: bei der Unterscheidung zwischen „sieht aus wie ein Geheimnis“ und „ist wahrscheinlich ein echtes Geheimnis“.

Ein Problem mit harten Negativen: Geheimnisse, die fast echt aussehen

Die meisten Fehlalarme sind nicht zufällig. Es sind harte Negative: Zeichenketten, die einem Credential-Muster entsprechen, aber keine verwendbaren Credentials sind. Beispiele sind Dokumentationsplatzhalter, spielerische Beispiele in Tests, geschwärzte Werte, nicht sensible IDs und generierte Fixtures. Diese Fälle matcht ein Regex leicht, während es für ein rein regelbasiertes System schwer ist, sie zu unterdrücken, ohne versehentlich echte Geheimnisse zu verlieren.

ModernBERT hilft, weil es den Kandidaten zusammen mit umliegendem Code und Text lesen kann und dadurch ein kontextuelles Verständnis bietet, das mit einem LLM vergleichbar ist, ohne die Latenz- und Rechenaufwände der Generierung natürlichsprachiger Ausgaben. So kann ein Kandidat, der von Wörtern wie „example“, „dummy“, „fake“ oder „replace-me“ umgeben ist, ein geringeres Risiko aufweisen als ein Kandidat, der einer Umgebungsvariablen in einer Deployment-Datei zugewiesen ist. Der Klassifikator lernt diese kontextuellen Unterschiede aus bespielten Beispielen, anstatt dass Ingenieure jede Ausnahme als weitere Regel kodieren müssen.

Wir haben ModernBERT gewählt, weil es eine starke Passung für diese Arbeitslast bietet: Es ist kompakt, effizient und gut für Klassifizierung über code-nahen Text geeignet. Für das Geheimnis-Scannen muss das Modell eine kalibrierte Entscheidung über kurze Kandidatenfenster mit hohem Durchsatz und geringer Latenz treffen.

Das macht einen feinabgestimmten Encoder-Klassifikator für diese Stufe der Pipeline zu einer besseren Serving-Form als ein Allzweck-LLM. Das Modell kann direkt auf unserer Entscheidungsgrenze trainiert und mit denselben Recall- und Precision-Metriken evaluiert werden, die für die Qualität des Geheimnis-Scannens entscheidend sind.

Wie wir trainiert haben

Die Herausforderung bestand darin, repräsentative Daten für Fälle zu finden, in denen die Syntax allein irreführend ist. Die Trainings- und Evaluierungsstrategie kombiniert drei Quellen:

• Produktabgeleitete Beispiele aus GitHub-Repositories unter Verwendung von Feedback aus der Geheimniserkennungserfahrung und zusätzlicher menschlicher Validierung.
• Regex-Kandidaten mit hohem Recall aus GitHub-Repository-Daten, einschließlich menschlich annotierter Beispiele und schwacher Labels zur Erweiterung der Abdeckung.
• Synthetische Beispiele, gezielt für seltene und schwierige Fälle, wie Dokumentationsgeheimnisse, Test-Fixtures, öffentliche Schlüssel, Prüfsummen, strukturierte Lookalikes und Fast-Treffer-Paare.

Synthetische Zeilen bestehen eine deterministische Validierung und eine modellbasierte Qualitätsprüfung, bevor sie aufgenommen werden. Das Training legt den Schwerpunkt auf echte Geheimnisse, realistische Fehlalarme und schwierige Negativbeispiele, die rein regex-basierte Ansätze häufig verwirren. Jede Modelleingabe umfasst den Kandidatenwert, den Dateipfad, den Secret-Typ und eine begrenzte Menge an umgebendem Kontext. Wir wählen Schwellenwerte durch Offline-Evaluierung aus und validieren das Verhalten anschließend an produktionsähnlichem Traffic, bevor wir breiter ausrollen.

Bevor wir die Daten aufteilten, gruppierten wir Zeilen, die ein Repository, einen Kandidatenwert oder ein Beispiel teilen, damit nahezu doppelte Einträge nicht sowohl im Training als auch in der Auswertung erscheinen konnten.

Das Training konzentrierte sich auf die Fälle, die für die Alarmqualität am wichtigsten sind: echte Secrets, realistische False Positives und harte Negative, auf die Regexes häufig zutreffen. Die Eingabedarstellung umfasst die Kandidaten-Secret-Zeichenkette, den Dateipfad, den Typ und eine begrenzte Menge umgebenden Kontexts. Die Ausgabe ist ein Klassifikationsscore, den der Scanner verwendet, um zu entscheiden, ob der Kandidat weiterverarbeitet werden soll.

Wir optimierten für den Produkttrade-off: Recall erhalten oder verbessern, während False Positives und Servicing-Kosten reduziert werden. In der Praxis bedeutet das, dass der Klassifikator-Schwellenwert mittels Offline-Evaluierung ausgewählt und dann vor dem Rollout gegen produktionsähnlichen Traffic validiert wird.

Das wichtigste Trainingsprinzip bestand darin, das Modell die verwirrenden Beispiele sehen zu lassen. Wir nahmen Kandidaten auf, die syntaktisch echten Secrets ähneln, aber semantisch unterschiedlich sind, damit das Modell nicht nur lernt, wie ein Secret aussieht, sondern auch, wie ein False Positive im Kontext aussieht.

Das trainierte Modell wird im ONNX-Format mit 8-Bit-Quantisierung exportiert, was schnelle Inferenz ermöglicht.

Ergebnisse der Evaluierung

Wir bewerteten die Auswirkung der neuen Pipeline in der Produktion in zwei Stufen: zunächst gegen die Produktionsbasislinie auf demselben öffentlichen Traffic und anschließend in einem Kunden-A/B-Experiment.

• Offline-Evaluierung: Beim Post-Push-Scanning erzielte die neue Pipeline 13% höhere Präzision und 19% höheren Recall als die bisherige LLM-Pipeline, ausgewertet auf demselben öffentlichen Traffic. 
• Online-Evaluierung: Anschließend validierten wir in einem A/B-Experiment gegen die bisherige LLM-Pipeline, ob sich diese Qualitätsverbesserungen in Kundenergebnissen niederschlagen. Die repositoryeigentümer-gewichtete Akzeptanz stieg um 11.5%. Wir gewichten die Akzeptanz nach Repositoryeigentümer, um den Einfluss von Kunden zu verringern, die große Mengen an Alarmen in einem Zug massenweise abschließen, was ansonsten einen einfachen Durchschnitt verzerren kann. 

Zum Mitnehmen

Das beste Sicherheitstool ist das, dem Entwickler genug vertrauen, um es zu nutzen. Höhere Präzision bedeutet weniger ablenkende Alarme. Höherer Recall bedeutet, dass mehr echte Secrets erfasst werden. Niedrigere Kosten bedeuten, dass wir die Abdeckung weiter verbessern können, ohne das Scanning prohibitiv teuer zu machen.

Für Entwickler und Sicherheitsteams sollte sich das in weniger False Positives und schnelleres Feedback genau dort übersetzen, wo Secrets am wahrscheinlichsten eingeführt werden: in Commits, Pull Requests und alltäglichen Entwicklungs-Workflows.

Hybride Systeme sind leistungsstark. Regex gibt uns Geschwindigkeit, Transparenz und breite Kandidatenabdeckung. ModernBERT gibt uns gelerntes Kontextverständnis und Reduzierung von False Positives. Die Kombination übertrifft für diese Produktbeschränkung jeden der beiden Ansätze, für sich allein verwendet.

Wir haben auch gelernt, dass Modellgröße nicht dasselbe wie Modellnützlichkeit ist. Ein kleinerer feinabgestimmter Klassifikator kann die richtige Antwort sein, wenn die Aufgabe eng gefasst ist, die Entscheidungsgrenze messbar ist und die Effizienz im Betrieb entscheidend ist.

Dies ist ein Schritt dazu, die Geheimnisserkennung (Secret Scanning) genauer, skalierbarer und benutzerfreundlicher zu machen. Für die Zukunft konzentrieren wir uns auf zwei Bereiche:

• Aufbau eines kontinuierlichen Verbesserungskreislaufs. Wir werden Produktions-Feedbackschleifen nutzen, um neue False Negatives und False Positives zu identifizieren und so Signale aus der Praxis in Trainings- und Evaluationsdaten höherer Qualität umzuwandeln.
• Erkundung neuer Modellarchitekturen. Wir untersuchen Ansätze, die die Erkennung und Extraktion von Geheimnissen in einem einzigen Schritt durchführen können, wodurch die Komplexität der Pipeline reduziert wird, während Genauigkeit und Skalierung erhalten bleiben.

Danksagungen

Großen Dank an die Engineering-, Wissenschafts- und Produktteams bei GitHub und Microsoft, die beim Aufbau der Trainingsdaten, der Evaluationssuite, des Serving-Stacks und des Rollout-Plans für diesen neuen Geheimnis-Scanner geholfen haben.

Der Beitrag GitHubs Modell zur Erkennung von Geheimnissen: Mehr Geheimnisse mit weniger Störmeldungen finden erschien zuerst auf The GitHub Blog.