Betterleaks Secrets Scanner: Architektur und Schlüssel
Die Erkennung von Geheimnissen in Repositories hat sich in den letzten Jahren erheblich verändert. Früher genügte es, im Code nach verdächtigen Zeichenketten oder Schlüsseln mit hoher Entropie zu suchen. Heute sieht die Situation anders aus: größere Repositories, schnellere CI/CD-Pipelines und vor allem eine zunehmende Menge an Code, der von automatisierten Tools oder KI-Modellen generiert wird.
Dies hat eine praktische Konsequenz: Es geht nicht mehr nur darum, Geheimnisse aufzudecken, sondern auch darum, wirklich Gefährliches von scheinbar Gefährlichem zu unterscheiden. Viele Teams stellen fest, dass die eigentlichen Kosten dieser Scanner nicht in der Durchführung der Analyse liegen, sondern in der Überprüfung hunderter Fehlalarme.
Erkennungsarchitektur: Was ändert sich mit Betterleaks?
Betterleaks erscheint genau in diesem Kontext. Es versucht nicht, das Scannen geheimer Inhalte völlig neu zu erfinden, sondern stellt eine weit verbreitete Annahme in Frage: dass das Erkennen von Mustern ausreicht.
In vielen modernen Repositories ist das nicht der Fall.
Das von Zach Rice entwickelte und von Aikido unterstützte Projekt verfolgt einen etwas anderen Ansatz. Anstatt sich ausschließlich auf die Erkennung von Übereinstimmungen zu konzentrieren, prüft es zunächst, ob der Befund plausibel ist, bevor er als Warnmeldung weitergeleitet wird.
Dies mag wie ein unbedeutendes Detail erscheinen, verändert aber die Dynamik in großen Teams erheblich. Wenn ein Scansystem zu viele irrelevante Warnmeldungen generiert, ist die natürliche Reaktion des Teams, diese zu ignorieren. Und im Bereich der IT-Sicherheit kann eine ignorierte Warnmeldung schlimmer sein als gar keine.
Um dieses Problem anzugehen, führt Betterleaks zwei interessante technische Elemente ein: die Validierung mittels CEL (Common Expression Language) und eine Metrik namens „Token Efficiency“, die auf der BPE-Tokenisierung basiert.
Die Idee dahinter ist, dass nicht alles, was geheim erscheint, es auch tatsächlich ist. Manche Zeichenketten mit hoher Entropie sind lediglich Hashwerte, Kennungen oder automatisch generierte Fragmente. Das System hat zum Ziel, dieses Rauschen zu reduzieren.
Die Projektdokumentation erwähnt einen Vergleich, in dem die BPE-Tokenisierung eine Trefferquote von 98,6 % erreicht, verglichen mit den 70,4 %, die mit Entropie im CredData-Datensatz erzielt wurden. Wie bei jedem Benchmark sind diese Zahlen nur Richtwerte. Sie dienen als guter Referenzpunkt, ersetzen aber keine Tests in realen Repositories.
Quelle: GitHub
Komponenten, die den Unterschied ausmachen
Eine Überprüfung der Projektmerkmale offenbart eine klare Richtung: die Implementierung in realen Umgebungen zu erleichtern, ohne dabei zu viel technische Komplexität hinzuzufügen.
Zu den wichtigsten Elementen gehören:
- Regeldefinierte Validierung mittels CEL (Common Expression Language)
- Token-Effizienz-Scanning basierend auf BPE-Tokenisierung anstelle von Entropie, wodurch eine Trefferquote von 98,6 % gegenüber 70,4 % mit Entropie auf dem CredData-Datensatz erreicht wird.
- Reine Go-Implementierung (ohne Abhängigkeit von CGO oder Hyperscan)
- Automatische Verarbeitung doppelt/dreifach kodierter Geheimnisse
- Erweitertes Regelwerk für mehr Anbieter
- Parallelisiertes Git-Scannen für eine schnellere Repository-Analyse
Auch wenn diese Liste auf den ersten Blick nur eine Zusammenstellung technischer Verbesserungen zu sein scheint, ist interessant, wie sie sich auf den Alltag auswirken.
Eine vollständige Go-Implementierung ohne native Abhängigkeiten vereinfacht beispielsweise die Integration in CI/CD-Pipelines erheblich. In vielen Teams entscheiden solche Details darüber, ob ein Tool letztendlich genutzt wird oder im Repository in Vergessenheit gerät.
Die BPE-Tokenisierung verfolgt ebenfalls einen anderen Ansatz. Anstatt lediglich die Zufälligkeit einer Kette zu messen, analysiert sie Tokenmuster, die die tatsächliche Struktur moderner Anmeldeinformationen genauer widerspiegeln.
Was passiert, wenn der Scanner etwas findet?
Wenn Betterleaks ein potenzielles Geheimnis entdeckt, ist der Prozess damit noch nicht beendet.
Zunächst wird der Kontext anhand von in CEL definierten Regeln ausgewertet. Dies ermöglicht das Hinzufügen weiterer Bedingungen: beispielsweise die Überprüfung, ob das Format dem erwarteten Anbieter entspricht, oder das Verwerfen von Mustern, die häufig in Beispielen oder fiktiven Daten vorkommen.
Dieser Schritt mag trivial erscheinen, hat aber erhebliche praktische Auswirkungen. Fehlalarme verschwenden nicht nur Zeit, sondern mindern auch das Vertrauen des Teams in das Warnsystem.
Ein weiterer interessanter Aspekt ist die automatische Verarbeitung mehrfach kodierter Geheimnisse. In manchen Repositories werden Zugangsdaten mithilfe von Base64 oder anderen Kodierungsverfahren transformiert, was ihre Erkennung erschwert.
Dennoch sollte man etwas bedenken, das oft übersehen wird: Kein Scanner kann die menschliche Überprüfung vollständig ersetzen. Das Aufdecken eines Geheimnisses ist nur der Anfang; die Entscheidung, wie damit umzugehen ist (widerrufen, rotieren, ignorieren oder untersuchen), hängt vom jeweiligen Kontext ab.
Governance und nutzerzentrierter Ansatz/KI
Betterleaks wird unter der MIT-Lizenz veröffentlicht und enthält externe Beiträge von Organisationen wie der Royal Bank of Canada, Red Hat und Amazon.
Das Projekt versucht außerdem, sich einer Realität anzupassen, die in modernen Repositories immer deutlicher sichtbar wird: der Mischung aus von Entwicklern geschriebenem Code und Code, der von automatisierten Tools generiert wird.
In diesem Kontext soll das Tool sowohl in manuell bedienten Arbeitsabläufen als auch in automatisierten Systemen, die ganze Repositories überprüfen, gut funktionieren. Dies entspricht dem zunehmenden Einsatz von Automatisierung und Werkzeuge die Code analysieren oder automatische Überprüfungen generieren.
Der Fahrplan enthält auch interessante Ideen: Integration mit Datenquellen jenseits von GitUnterstützung durch Sprachmodelle zur Klassifizierung von Befunden und automatische Widerrufsmechanismen über Anbieter-APIs.
Dies eröffnet eine interessante Debatte. Die Automatisierung des Entzugs von Zugangsdaten kann die Reaktionszeit auf einen Vorfall verkürzen, setzt aber auch voraus, dass das Klassifizierungssystem korrekt ist.
Wenn eine automatische Widerrufung fehlschlägt oder irrtümlich ausgelöst wird, können die betrieblichen Auswirkungen erheblich sein.
Praktische Implikationen und Grenzen
Aus operativer Sicht ist Betterleaks attraktiv für Teams, die Fehlalarme reduzieren und die Bereitstellung vereinfachen möchten.
Es ist aber auch wichtig, einige Grenzen zu beachten:
- Die Recall-Metriken hängen vom verwendeten Datensatz ab und können zwischen verschiedenen Repositorien erheblich variieren.
- Die Automatisierung von Aktionen wie dem Entzug von Schlüsseln erfordert zusätzliche Kontrollen und Prüfprotokolle.
- Geheime Scanner stellen nur eine Verteidigungsebene innerhalb einer umfassenderen Strategie dar.
In vielen Fällen hängt die Entscheidung für ein solches Tool weniger von seiner theoretischen Genauigkeit ab als von etwas Einfacherem: davon, ob es sich gut in den Arbeitsablauf des Teams integrieren lässt.
Ein hochpräziser Scanner, der zu viel Reibung erzeugt, wird in der Regel nicht mehr verwendet. Ein ausreichend genauer Scanner, der sich leicht integrieren lässt, wird hingegen meist beibehalten.
In diesem Sinne versucht Betterleaks, ein Gleichgewicht herzustellen. Es verspricht nicht, alle Fehlalarme zu eliminieren oder bestehende Sicherheitsprozesse zu ersetzen, sondern zielt darauf ab, Störungen zu reduzieren und die Integration in moderne Pipelines zu erleichtern.
Das Projekt ist auf GitHub verfügbar. und wird als Weiterentwicklung des von Gitleaks verwendeten Ansatzes präsentiert, mit der Absicht, sich an Repositories anzupassen, in denen Automatisierung, Analyseagenten und von Sprachmodellen generierter Code ein regelmäßiger Bestandteil des Entwicklungsprozesses sind.
