Betterleaks: Der Secrets-Scanner vom Gitleaks-Autor mit Expr-Filterung und neuen Quellen
Scannen Sie die Welt (nach Geheimnissen). | Neue Quellen | Unterstützung für Quellen wie GitHub, GitLab, Hugging Face, S3 und mehr.
Auf einen Blick
- Was ist das?
- Was Betterleaks laut README kann: Scans über Git, GitHub, GitLab und S3, Expr-basierte Filter gegen Fehlalarme, Treffervalidierung, und wo die Grenzen liegen.
- Für wen ist es gedacht?
- Betterleaks passt zu Teams, die über Git-Repositories hinaus auch GitHub-Organisationen, GitLab-Gruppen oder S3-Buckets auf geleakte Schlüssel prüfen wollen und bereit sind, eine eigene betterleaks.toml zu pflegen. Wer nur ein Rezept für einfache Git-Scans braucht, fährt mit Gitleaks des selben Autors möglicherweise leichter.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Go, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Warum der Gitleaks-Autor Betterleaks gebaut hat
Das konkrete Problem, das Betterleaks angeht, sind Fehlalarme bei der Suche nach geleakten Zugangsdaten. Ein Scanner, der Muster für API-Schlüssel über Code historisch laufen lässt, meldet erfahrungsgemäß viel Rauschen: Beispieldaten, Build-Artefakte, Schlüssel in Archiveinblendungen. Gitleaks, das frühere Werk desselben Autors, bot dafür das [[allowlist]]-Konstrukt, doch dessen Ausdruckskraft stieß an Grenzen, wenn Kontext wie der Git-Autor oder der Dateipfad in die Entscheidung einfließen sollte.
Betterleaks ist die Antwort des Gitleaks-Teams, das auch den ursprünglichen Autor einschließt, auf genau diese Situation. Das README beschreibt das Tool als konfigurierbar, schnell und gründlich. Die Entwicklung wird von Aikido Security unterstützt, einer Sicherheitsfirma, die das Projekt als Scanner in ihrer Plattform einsetzt. Stand der Analyse: Version v1.8.1 vom 18. August 2026, 1805 Sterne, 131 Forks, Lizenz MIT. Wer wissen will, wie die Erkennungsmaschine gedacht ist, findet im README eine Blogserie mit Titeln wie Regex is all you need und Rare Not Random.
Scan-Quellen: betterleaks git, dir, github und gitlab
Die Benutzeroberfläche besteht aus Unterbefehlen, einer pro Datenquelle. betterleaks git /path/to/repo -v --source-workers=16 durchsucht ein Git-Repository mit sechzehn Worker-Prozessen, betterleaks dir richtet dieselbe Maschine auf beliebige Dateisystempfade. Damit ist der Scanner nicht auf Repositories beschränkt, sondern frisst sich durch Backups, Exporte oder CI-Arbeitsverzeichnisse.
Interessanter wird es bei den Plattformquellen. betterleaks github https://github.com/cooluser123456789 --include issues,prs,actions,releases,gists prüft einen Nutzer nicht nur im Code, sondern auch in Issues, Pull Requests, Actions-Logs, Releases und Gists. Mit betterleaks github https://github.com/betterleaks/betterleaks/pull/113 lässt sich eine einzelne Ressource scannen, etwa nur die Kommentare eines Pull Requests. betterleaks gitlab https://gitlab.com/mygroup deckt GitLab-Gruppen ab. Das README nennt darüber liegend Hugging Face und S3 als unterstützte Quellen, nähere Details dazu verweist es an docs/scanning.md. Der Datenfluss bleibt bei allen Quellen derselbe: Fragment erzeugen, Attribute anreichern, Regex-Matching, Filter, gegebenenfalls Validierung.
Prefilter und filter in der betterleaks.toml
Die Stärke liegt laut README in der Konfiguration, und die ist konsequent zweistufig gebaut. Ein globaler prefilter läuft vor jedem Regex-Matching und sieht nur die attributes-Map, also Metadaten des Fragments wie den Dateipfad oder git.author_name. Im README-Beispiel wirft er Bilder, PDFs, node_modules und vendor per Pfad-Regex raus und überspringt Commits des Bots renovate[bot]. Das spart die teuren Regex-Aufrufe, bevor sie überhaupt starten.
Der globale filter greift dagegen nach jedem Treffer und kann auf die Kandidatendaten zugreifen, etwa finding["secret"] oder finding["match"]. Das Beispiel filtert Strings wie EXAMPLE oder CHANGEME aus. Einzelne Regeln leben in [[rules]]-Tabellen mit id, description, regex und keywords; mehrteilige Muster lesen Nachbarkomponenten über Ausdrücke wie components["rule-id"]?.secret ?? "". Bemerkenswert: Früher lief diese Logik über CEL, bestehende CEL-Konfigurationen werden weiter akzeptiert, neue sollten Expr nutzen. Wer Regeln ausprobieren will, nutzt den Betterleaks Playground auf betterleaks.com/playground.
Treffervalidierung per validate-Feld und BPE-Tokenisierung
Zwei Mechanismen im Regelwerk gehen über reines Mustererkennen hinaus. Das validate-Feld einer Regel definiert einen Expr-Ausdruck, der asynchrone HTTP-Anfragen direkt aus der Regeldefinition heraus stellt. Das README zeigt das am Beispiel eines GitHub Fine-Grained PAT: Der Scanner fragt beim Anbieter nach und bekommt Gültigkeit, Nutzernamen und OAuth-Scopes zurück. Praktisch bedeutet das, dass erkannte Geheimnisse während des Scans an den jeweiligen Anbieterdienst übertragen werden; das README nennt zu Ratenlimits oder Fehlerbehandlung dabei keine Angaben.
Der zweite Mechanismus richtet sich gegen die klassische Fehlerquelle natürliche Sprache. Die Token Efficiency filtering nutzt BPE-Tokenisierung, um zu messen, wie selten oder unmenschlich eine Zeichenkette ist. Ein echter API-Schlüssel zerfällt in ungewöhnliche Tokenfolgen, ein прозaischer Satz nicht. Das README beschreibt das Prinzip, nennt aber keine Schwellenwerte und keine Zahlen zur Genauigkeit dieses Filters. Wie stark er das Rauschen in der Praxis senkt, lässt sich aus dem Material nicht ablesen.
Installation per brew install betterleaks und Build aus dem Quellcode
Das README listet vier Installationswege auf. Auf macOS läuft brew install betterleaks, alternativ brew install betterleaks/tap/betterleaks über einen eigenen Tap. Fedora-Nutzer nehmen sudo dnf install betterleaks. Für Container-Umgebungen gibt es docker pull ghcr.io/betterleaks/betterleaks:latest, was sich direkt in CI-Pipelines einhängen lässt. Go-Entwickler können go install github.com/betterleaks/betterleaks@latest nutzen, und wer am Quellcode arbeiten will, klont das Repository und ruft make build auf.
Zur Portabilität heißt es im README, die kleine Binärdatei laufe auf jedem modernen OS und auf jeder Architektur und lasse sich in beliebige Systeme integrieren. Eine Mindest-Go-Version oder eine Liste unterstützter Plattformen fehlt im Material ebenso wie Angaben zur Binärgröße. Wer Versionen in der Hand behalten will, findet unter github.com/betterleaks/betterleaks/releases die Tags; zwischen v1.8.0 und v1.8.1 lagen im August 2026 lediglich zwei Tage.
Grenzen von Betterleaks v1.8.1 nach dem Material
Das schnellste Argument gegen blinde Übernahme: Die Behauptung schnell steht im README, Messwerte fehlen. Es gibt keine Benchmarks, keine Aussagen zu Durchsatz pro Worker und kein Beispiel, wie sich --source-workers dimensionieren lässt. Wer Performance-Hoffnungen hat, muss sie gegen die eigene Codebasis messen.
Zweite Grenze: Der Ausdrucksspielraum der Konfiguration ist eine Verpflichtung. Das README empfiehlt ausdrücklich, in der Produktion eine eigene Konfiguration zu pflegen, statt die Upstream-Datei config/betterleaks.toml direkt zu erweitern, damit Upstream-Regeländerungen bei Upgrades nicht ungeprüft ins eigene Regelwerk rutschen. Drittens zeigen 86 offene Issues, dass das Projekt aktiv und damit auch in Bewegung ist. Zu Supportkanälen, Sicherheitsrichtlinien oder einem Disclosure-Prozess sagt das Material nichts. Die Dokumentation verteilt sich auf README, docs/scanning.md und docs/config.md, wer Tiefe sucht, muss in alle drei schauen.
Gegenüberstellung mit Gitleaks und dem allowlist-Ansatz
Die naheliegende Alternative ist Gitleaks, und die Unterschiede sind im Material klar benannt. Beide stammen aus derselben Werkstatt, beide suchen nach Mustern für Geheimnisse. Gitleaks löst Kontextfälle über das [[allowlist]]-Konstrukt, Betterleaks ersetzt genau das durch Expr-Ausdrücke mit Zugriff auf Attribute und Trefferdaten und ergänzt Validierung sowie Quellen jenseits von Git.
Als Faustregel aus dem Material: Wer bestehende Gitleaks-Konfigurationen hat und nur Repositories scannt, hat wenig Grund zu wechseln, zumal die CEL-Kompatibilität zeigt, dass das Team Umstiegskosten kennt. Wer dagegen GitHub-Organisationen, Gists, Actions-Logs oder Cloud-Buckets abdecken und aktive Schlüssel automatisiert prüfen will, findet in Betterleaks die Erweiterung genau dieser drei Dimensionen. Ein Abgleich bestehender Regeln gegen config/betterleaks.toml zeigt schnell, welche der eigenen Ausnahmeregelungen sich als Expr ausdrücken lassen.
Redaktionelles Fazit
Betterleaks passt zu Teams, die über Git-Repositories hinaus auch GitHub-Organisationen, GitLab-Gruppen oder S3-Buckets auf geleakte Schlüssel prüfen wollen und bereit sind, eine eigene betterleaks.toml zu pflegen. Wer nur ein Rezept für einfache Git-Scans braucht, fährt mit Gitleaks des selben Autors möglicherweise leichter. Vor der Einführung eigene Regeln im Betterleaks Playground testen, die Beispielkonfiguration config/betterleaks.toml lesen und mit betterleaks git auf einer Kopie eines Repos mit bekannten Treffern das Verhalten prüfen.
Community-Notizen