Gitleaks im Wartungsmodus: Was das Tool leistet und wo die Grenze liegt

Welches Problem Gitleaks adressiert und für wen es gedacht ist

Der Kern des Problems ist nicht der aktuelle Commit, sondern die Historie. Ein API-Key, der vor zwei Jahren versehentlich eingecheckt und später entfernt wurde, bleibt in den Objekten des Repositories erhalten und ist über jeden Klon abrufbar. Gitleaks durchsucht genau das: Commits, Branches und Dateien, die bereits im Repository liegen. Die README beschreibt das Ziel als Erkennung von Passwörtern, API-Keys und Tokens in Git-Repos, Dateien und beliebigen Eingaben über stdin. Der Anwendungsfall ist damit ein DLP- und DevSecOps-Thema, nicht ein Linter für den nächsten Commit.

Die Zielgruppe sind Entwicklerteams, die eine Prüfung in ihre Pipeline oder in einen Pre-Commit-Hook einbinden wollen, sowie Sicherheitsteams, die eine bestehende Codebasis nachträglich auf Altlasten prüfen. Auch für die Prüfung von Dateien außerhalb eines Repositories ist das Werkzeug gedacht, weil der dir-Befehl und der stdin-Modus nicht auf Git angewiesen sind. Wer nur einen einzelnen Commit vor dem Push prüfen will, braucht dagegen deutlich weniger Werkzeug als das gesamte Repository-Scanning.

Wie die Erkennung technisch abläuft

Die Erkennung basiert nach Angaben des Projekts im Wesentlichen auf regulären Ausdrücken. Der verlinkte Blogbeitrag heißt "Regex is (almost) all you need", was die Grenze bereits im Titel trägt: Mustererkennung mit einem Entropiewert als Zusatzkriterium, nicht semantische Analyse. Die Beispielausgabe der README zeigt die Felder, die ein Treffer mitbringt: Finding, Secret, RuleID, Entropy, File, Line, Commit, Author, Email, Date und Fingerprint. Der Fingerprint setzt sich aus Commit-Hash, Dateipfad, Regel-ID und Zeilennummer zusammen, zum Beispiel cd5226711335c68be1e720b318b7bc3135a30eb2:cmd/generate/config/rules/sidekiq.go:sidekiq-secret:23. Diese Kombination ist der Mechanismus, mit dem einzelne Funde dauerhaft adressierbar werden.

Der Entropiewert im Beispiel liegt bei 2.609850 für den Wert cafebabe:deadbeef. Das ist ein Hinweis darauf, dass Regeln nicht nur ein Muster treffen, sondern die Zufälligkeit des Treffers bewerten. Das reduziert Fehlalarme bei Platzhaltern, beseitigt sie aber nicht. Die Konfiguration der Regeln liegt in TOML-Dateien, und die README verweist auf cmd/generate/config/rules/sidekiq.go, also auf Go-Quellen, aus denen die Regeln erzeugt werden. Wer eigene Regeln ergänzen will, arbeitet daher entweder an der Konfiguration oder am Generator, nicht an einer lose verteilten Regelsammlung.

Installation und erste Ausführung

Für macOS nennt die README brew install gitleaks. Für Docker gibt es zwei Quellen: docker pull zricethezav/gitleaks:latest und docker pull ghcr.io/gitleaks/gitleaks:latest. Der Aufruf bindet ein Host-Verzeichnis ein und übergibt Befehl, Optionen und Pfad: docker run -v ${path_to_host_folder_to_scan}:/path zricethezav/gitleaks:latest [COMMAND] [OPTIONS] [SOURCE_PATH]. Aus dem Quellcode geht der Weg über git clone https://github.com/gitleaks/gitleaks.git, cd gitleaks und make build. Zusätzlich liegen auf der Releases-Seite Binärdateien für verbreitete Plattformen.

Für einen ersten Lauf auf einem Repository nennt die README gitleaks git -v. Die Befehlsübersicht zeigt daneben dir für Verzeichnisse und Dateien, stdin für Eingaben aus der Pipe sowie completion und version. Die wichtigsten Flags für den Betrieb sind -b beziehungsweise --baseline-path für eine Liste bekannter, zu ignorierender Funde, -c beziehungsweise --config für die Konfigurationsdatei, --exit-code für den Rückgabewert bei Funden (Standard 1), --redact zum Schwärzen der Ausgabe und -f beziehungsweise --report-format mit json, csv, junit, sarif und template. Die Reihenfolge der Konfigurationsauflösung ist explizit dokumentiert: zuerst --config/-c, dann die Umgebungsvariable GITLEAKS_CONFIG, dann GITLEAKS_CONFIG_TOML mit dem Dateiinhalt, dann (target path)/.gitleaks.toml, andernfalls die Standardkonfiguration.

Der Wartungsstatus ist die wichtigste Randbedingung

Die README trägt ganz oben eine Warnung des Autors. Gitleaks sei funktionsvollständig, neue Features würden nicht mehr zusammengeführt, künftige Releases seien ausschließlich Sicherheitspatches, und der Fokus verschiebe sich auf Betterleaks. Das ist keine Randnotiz, sondern die zentrale Information für jede Adoptionsentscheidung. Die letzten Releases in den vorliegenden Daten sind v8.30.1 vom 21. März 2026, v8.30.0 vom 26. November 2025 und v8.29.1 vom 19. November 2025. Wer aus diesen Zeitstempeln eine Aussage über die künftige Entwicklung ableiten will, sollte vorsichtig sein: Sicherheitspatches können unregelmäßig erscheinen, und die README verspricht keine Feature-Roadmap mehr.

Praktisch bedeutet das: Regeln, die neue Secret-Typen abdecken, kommen aus der Community oder aus eigenen Ergänzungen, nicht mehr aus dem Hauptprojekt. Für Teams mit eigenen internen Token-Formaten ist das ohnehin der Normalfall. Für Teams, die auf eine gepflegte Regelsammlung für fremde Dienste setzen, ist es ein Risiko. Der Verweis auf Betterleaks in derselben Warnung macht die Wahl zu einer Migrationsfrage, nicht nur zu einer Werkzeugfrage, und diese Frage sollte vor dem Rollout geklärt werden, nicht danach.

Pre-Commit, GitHub Action und die Grenzen der Durchsetzung

Für die lokale Absicherung nennt die README eine .pre-commit-config.yaml mit dem Repository https://github.com/gitleaks/gitleaks, einer rev-Angabe (im Beispiel v8.24.2) und dem Hook id: gitleaks. Alternativ existiert der Hook gitleaks-docker für die offiziellen Images. Nach pre-commit install bricht ein Commit mit einem Secret ab, was die README mit der Zeile Detect hardcoded secrets.................................................Failed zeigt. Der Hook lässt sich umgehen, und die README dokumentiert die Umgehung selbst: SKIP=gitleaks vor dem Commit-Befehl überspringt die Prüfung.

Das ist die entscheidende Einschränkung. Ein Pre-Commit-Hook ist eine Bequemlichkeit für den Entwickler, keine Kontrolle. Wer die Prüfung verbindlich machen will, braucht sie serverseitig, etwa über die separate gitleaks-action in der Pipeline. Auch dort bleibt ein Restrisiko: Die Erkennung arbeitet mit Mustern, und ein Secret, das nicht dem Muster einer Regel entspricht, wird nicht gefunden. Der Modus --max-decode-depth steht standardmäßig auf 0, es findet also keine rekursive Dekodierung statt. Ebenso steht --max-archive-depth standardmäßig auf 0, verschachtelte Archive werden ohne explizite Angabe nicht durchsucht. Wer Base64-kodierte oder in Archiven versteckte Secrets erwartet, muss diese Werte bewusst setzen und die Laufzeitkosten tragen.

Betriebskosten, Ausgabeformate und Lizenz

Die Ausgabeformate json, csv, junit, sarif und template bedienen unterschiedliche Abnehmer: sarif für Code-Scanning-Oberflächen, junit für Testberichte, json für eigene Auswertungen. Das ist der Teil, der den Betrieb günstig macht, weil keine eigene Nachbearbeitung nötig ist. Teurer ist die Pflege der Baseline. Jeder bestätigte Fehlalarm oder akzeptierte Altfund muss über --baseline-path beziehungsweise -b gepflegt werden, sonst schlägt der Lauf dauerhaft mit Exit-Code 1 fehl und die Pipeline wird ignoriert. Das ist ein wiederkehrender Aufwand, der mit der Größe der Historie wächst.

Zwei weitere Stellschrauben kosten Zeit oder Speicher: --max-target-megabytes überspringt große Dateien, und --diagnostics mit cpu, mem, trace oder http erzeugt Profiling-Ausgaben, die über --diagnostics-dir abgelegt werden. Auf großen Repositories sind das die Hebel, mit denen sich die Laufzeit begrenzen lässt. Zur Lizenz: Das Projekt steht unter MIT, was die kommerzielle Nutzung und Weitergabe erlaubt, solange der Lizenztext erhalten bleibt. Das ist eine Einordnung, keine Rechtsberatung; wer das Werkzeug in ein Produkt einbettet, sollte die Bedingungen selbst prüfen.

Wo Gitleaks das falsche Werkzeug ist und was stattdessen passt

Gitleaks ist das falsche Werkzeug, wenn ein Team aktive Weiterentwicklung der Erkennungslogik erwartet. Der Autor hat das ausdrücklich ausgeschlossen. Es ist ebenfalls schwach, wenn Secrets nicht als Text in Commits oder Dateien auftauchen, sondern zur Laufzeit erzeugt werden, etwa kurzlebige Tokens in einem Secret-Manager. Dort gibt es nichts zu scannen, weil nichts im Repository landet.

Die naheliegende Alternative nennt die README selbst: Betterleaks unter https://github.com/betterleaks/betterleaks, das Projekt, auf das der Autor seinen Fokus verlagert. Der Unterschied im Ansatz liegt nicht in der Erkennungstechnik, sondern in der Projektführung: Gitleaks ist auf Sicherheitspatches eingefroren, Betterleaks ist das Ziel der weiteren Arbeit. Wer heute neu einsteigt und neue Regeln oder Funktionen braucht, sollte deshalb prüfen, ob Betterleaks den eigenen Anwendungsfall bereits abdeckt, statt in ein Projekt zu investieren, das per Ankündigung keine Features mehr erhält. Wer dagegen eine stabile, dokumentierte Basis mit MIT-Lizenz sucht und eigene Regeln selbst pflegt, kann mit Gitleaks weiterarbeiten. Ein weiterer Unterschied zu beachten: Ein reiner Git-History-Scanner wie Gitleaks prüft nichts zur Laufzeit. Wer Secrets in Umgebungsvariablen oder in einem Container-Image kontrollieren will, braucht dafür andere Werkzeuge, weil Gitleaks dort keine Angriffsfläche hat.

Wer adoptieren sollte, wer nicht, und was zuerst zu prüfen ist

Für Teams, die eine bestehende Repository-Historie einmalig auf Altlasten prüfen wollen, ist Gitleaks weiterhin brauchbar: brew install gitleaks, dann gitleaks git -v auf einem Klon, danach die Treffer sichten und die akzeptierten über --baseline-path ausblenden. Auch als Pre-Commit-Hook mit der dokumentierten .pre-commit-config.yaml funktioniert es, solange allen Beteiligten klar ist, dass SKIP=gitleaks die Prüfung umgeht und die verbindliche Kontrolle in die Pipeline gehört. Wer dagegen neue Erkennungsregeln aus dem Projekt erwartet oder einen aktiven Maintainer für Feature-Anfragen braucht, sollte nicht adoptieren, sondern Betterleaks prüfen.

Vor dem Rollout sind drei Dinge konkret zu verifizieren. Erstens ein Lauf mit gitleaks git -v gegen einen vollständigen Klon der echten Historie, nicht gegen einen flachen Checkout, weil die Tiefe des Klons darüber entscheidet, was überhaupt gefunden werden kann. Zweitens die Frage, ob die Ausgabe mit -f sarif oder -f junit in die vorhandene Pipeline passt oder ob eine eigene Nachbearbeitung nötig wird. Drittens, ob die eigene Konfiguration in .gitleaks.toml ausreicht oder ob eigene Regeln ergänzt werden müssen, was angesichts des eingefrorenen Feature-Stands dauerhaft in eigener Verantwortung bleibt.

Redaktionelles Fazit

Wer heute ein Secret-Scanning-Werkzeug einführt, sollte Gitleaks nur dann wählen, wenn ein stabiler, funktionsvollständiger Stand ohne neue Features ausreicht und der Wechsel zu Betterleaks noch nicht ansteht. Für Teams, die neue Erkennungsregeln oder aktive Feature-Entwicklung erwarten, ist es die falsche Wahl. Vor der Einführung im eigenen Repository zu prüfen: die Ausgabe von gitleaks git -v auf einem Klon der echten Historie, ob die Treffer in der eigenen Codebasis über die Baseline steuerbar sind, und ob die Konfigurationsdatei .gitleaks.toml mit eigenen Regeln auskommt. Erst danach lohnt die Entscheidung.

Offizielle Quellen

1. gitleaks/gitleaks on GitHub
2. License: MIT
3. Project website
4. README
5. Releases