Secret Scanning mit Open Source 2026: Gitleaks, TruffleHog und vier Alternativen auf einem präparierten Repository getestet

Welche Open-Source-Secret-Scanner werden 2026 noch gepflegt?

Von elf Open-Source-Secret-Scannern, die wir am 29. Oktober 2026 geprüft haben, haben Betterleaks, Gitleaks, TruffleHog, Kingfisher, Titus und secretlint 2026 jeweils ein Release veröffentlicht. Nosey Parker ist archiviert, detect-secrets und git-secrets sind seit mehr als zwei Jahren ohne Release. Die Tabelle zeigt, was die GitHub-API und das README jedes Projekts an diesem Tag hergaben: die Lizenz, das letzte Release, ob das Tool ein Secret bei seinem Anbieter prüfen kann und ob es SARIF schreibt. Sterne messen Aufmerksamkeit, nicht Pflege, deshalb fehlen sie hier.

Zwei Zeilen stellen den üblichen Rat auf den Kopf. Gitleaks funktioniert weiterhin, und sein Repository bekommt weiterhin Commits, doch seit dem 21. Mai 2026 bezeichnet das README von Gitleaks das Tool als „feature complete“ und kündigt an, künftige Releases würden nur noch Sicherheitspatches enthalten. Sein ursprünglicher Autor ist zu Betterleaks gewechselt, einem neuen MIT-Projekt, das die Leute hinter Gitleaks im Februar 2026 angelegt haben und dessen Entwicklung Aikido Security unterstützt. Und Nosey Parker, das in vielen Listen noch auftaucht, wurde von Praetorian archiviert und durch Titus ersetzt, einen in Go geschriebenen Scanner, dessen 487 Regeln aus Nosey Parker und Kingfisher stammen.

Auch wer hinter einem Tool steht, zählt. Kingfisher gehört MongoDB, detect-secrets kommt von Yelp, git-secrets von AWS Labs und Talisman von Thoughtworks. TruffleHog ist der Open-Source-Scanner von Truffle Security und steht seit Version 3.0 unter AGPL-3.0. Whispers von Skyscanner, das manche Listen noch führen, ist archiviert; sein letztes Release war 1.5.3 im August 2021.

Was fanden die sechs Scanner in einem präparierten Repository?

In unserem Test vom 29. Oktober 2026 liefen sechs Open-Source-Secret-Scanner gegen ein Repository mit 12 gefälschten Credentials: Betterleaks fand 12, Titus 11, Gitleaks und Kingfisher je 10, TruffleHog und detect-secrets je 9. Übersehen wurden Passwörter und ein JWT-Signing-Secret ohne Anbieterpräfix, ein Schlüssel, der nur in der Git-Historie existierte, und bei Titus ein Stripe-Live-Key. Titus und detect-secrets meldeten je einen Köder.

Am 29. Oktober 2026 haben wir ein kleines Repository gebaut, das wie die API eines Webshops aussieht, mit TypeScript, Python, einer Django-Settings-Datei, einer Docker-Compose-Datei und einem Deploy-Skript in Shell, verteilt auf drei Commits. Die 12 gefälschten Credentials haben wir dort platziert, wo solche Werte in der Praxis gern landen:

• ein AWS-Access-Key-Paar in einer TypeScript-Konfiguration;
• ein GitHub Personal Access Token in einem curl-Header;
• ein Stripe-Live-Key in .env;
• ein Slack-Bot-Token in YAML;
• ein OpenAI-Key und ein Anthropic-Key in SDK-Aufrufen;
• ein Google-API-Key in einem HTML-Script-Tag;
• ein Passwort in einem Postgres-Connection-String;
• ein JWT-Signing-Secret in Node.js;
• ein Django-Datenbankpasswort;
• ein privater RSA-Schlüssel;
• ein SendGrid-Key in einer Datei .env.production, die ein späterer Commit gelöscht hat.

Jeder Wert war zufällig erzeugt und im Format des jeweiligen Anbieters gebaut, keiner war ein echter Schlüssel. Zwei Köder lagen im README: der Beispielschlüssel aus der AWS-Dokumentation, AKIAIOSFODNN7EXAMPLE, und ein Stripe-Platzhalter aus lauter x. Jedes Tool lief mit seinen Standardregeln, im Git-Historien-Modus, sofern es einen hat, auf einem Mac mit den Versionen, die Homebrew an diesem Tag auslieferte. Die Live-Prüfungen waren abgeschaltet, denn ein gefälschter Schlüssel lässt sich nicht verifizieren:

gitleaks git . --report-format json --report-path gitleaks.json
betterleaks git . --report-format json --report-path betterleaks.json
trufflehog git file://. --no-verification --json > trufflehog.jsonl
kingfisher scan . --no-validate --format json --output kingfisher.json
titus scan --git . --format json --output :memory: > titus.json
detect-secrets scan --all-files > detect-secrets.json

Alle sechs fanden den AWS-Key, das GitHub-Token, das Slack-Token, den Anthropic-Key und den privaten Schlüssel. Die größten Lücken rissen die Secrets ohne Präfix: Gitleaks, Kingfisher und TruffleHog übersahen das Django-Datenbankpasswort, Kingfisher und TruffleHog zusätzlich das JWT-Signing-Secret. Doch auch Anbieter-Keys wurden nicht durchweg erkannt: TruffleHog und detect-secrets übersahen den Google-API-Key, detect-secrets außerdem den OpenAI-Key und Titus den Stripe-Live-Key. Ein Wert, der JWT_SECRET zugewiesen wird, ist eine zufällige Zeichenkette ohne Format, auf das eine Regel passen könnte. Erkannt wird er nur von Regeln, die den Variablennamen oder die Entropie der Zeichenkette auswerten.

Den SendGrid-Key gab es nur in einem Commit, den der nächste Commit wieder gelöscht hat. Jedes Tool, das die Git-Historie liest, hat ihn gefunden. detect-secrets nicht, und sein README erklärt auch, warum: Das Tool verzichtet bewusst darauf, sich durch die gesamte Git-Historie zu graben, scannt die aktuellen Dateien und arbeitet mit einer Baseline bekannter Befunde.

Die beiden Köder haben unterschiedliche Tools hereingelegt. Gitleaks und Betterleaks ignorieren AWS-Keys, die auf EXAMPLE enden, weil ihre Standardregel für AWS genau diese Ausnahme enthält; der Schlüssel aus der Dokumentation blieb also stumm. detect-secrets dagegen meldete ihn. Titus meldete den Platzhalter aus lauter x als Stripe-Key und übersah den echten Stripe-Key in .env. Nosey Parker 0.24.0, das wir ebenfalls laufen ließen, verhielt sich exakt genauso, was zu Regeln passt, die aus Nosey Parker übernommen wurden.

Die Zahl der Befunde liegt über der Zahl der Credentials. Titus meldete 16 Befunde für 11 Credentials und detect-secrets 15 für 9, weil mehrere Regeln auf denselben Wert anschlugen: ein GitHub-Token, das sowohl als Token als auch als curl-Header erkannt wurde, ein OpenAI-Key, der ein zweites Mal als generischer Schlüssel auftauchte. Jedes Duplikat ist eine weitere Zeile, die jemand triagieren muss.

Gitleaks vs. TruffleHog vs. Betterleaks: Welcher Scanner passt zu Ihnen?

Für ein neues Setup starten Sie mit Betterleaks. Behalten Sie Gitleaks, wenn es bereits in Ihren Hooks steckt und einfach weiterlaufen soll, und ergänzen Sie TruffleHog oder Kingfisher, sobald die Frage, ob ein Schlüssel aktiv ist, wichtiger ist, als jedes Passwort zu erwischen. Die Tools unterscheiden sich in ihren Regeln, ihrer Pflege und dem, was sie nach einem Treffer tun.

Gitleaks (MIT, v8.30.1) erledigt seine Aufgabe weiterhin: In unserem Test schlug es kein einziges Mal falsch an und übersah zwei Passwörter. Neue Regeln wird es nicht mehr bekommen. Der Umstieg ist leicht, denn Betterleaks liest eine .gitleaks.toml und respektiert gitleaks:allow-Kommentare.

Betterleaks (MIT) hat in unserem Test alles gefunden. Version 1.9.0 ist das stabile Release, die Validierung schalten Sie mit dem Flag --validation ein. Version 2 steckt im Release-Candidate-Stadium, und laut Migrationsleitfaden wurden die Reporter für CSV, JUnit, SARIF und Templates entfernt. Wenn Ihre Pipeline SARIF liest, bleiben Sie vorerst bei 1.x.

TruffleHog (AGPL-3.0) gibt über 800 Secret-Typen an und über 700 Detektoren, die Credentials gegen die APIs ihrer Anbieter testen, und es führt diese Tests standardmäßig aus. Für AWS ruft es laut README GetCallerIdentity auf. --results=verified behält nur bestätigte, aktive Secrets, und in unserem Test, bei abgeschalteter Verifizierung, meldete es zugleich die wenigsten Befunde. Übersehen hat es den Google-API-Key, das JWT-Signing-Secret und das Django-Passwort. Es steht unter AGPL-3.0: Lesen Sie die Lizenz also gemeinsam mit Ihrer Rechtsabteilung, bevor Sie das Tool einbetten oder weitergeben.

Kingfisher (Apache-2.0, Rust) validiert Befunde standardmäßig und kann einige davon sogar widerrufen. Seit Version 2.0.0 vom 23. August 2026 stammen seine Regeln aus dem Katalog von Betterleaks: 462 seiner 488 Regeln, dazu 26 aus Veles von Google. Getestet haben wir 2.14.0; 2.15.0 war am Vortag erschienen.

Titus (Apache-2.0, Go) ist die naheliegende Anlaufstelle für bisherige Nutzer von Nosey Parker. Es validiert mit --validate und schreibt SARIF.

Sollte ein Secret Scanner prüfen, ob ein Schlüssel noch gültig ist?

Ja, für die Triage, solange Sie kontrollieren, wo die Prüfung läuft. Eine Live-Prüfung schickt das gefundene Credential an die API seines Anbieters und zeigt Ihnen, welche Befunde ein echter Vorfall sind und welche nur tote Schlüssel. TruffleHog und Kingfisher tun das standardmäßig, Betterleaks und Titus nur mit einem Flag, Gitleaks nie.

Die Prüfung ist eine echte Anfrage mit dem echten Secret. Führen Sie sie dort aus, wo Ihre Netzwerkrichtlinie Aufrufe zu diesen Anbietern erlaubt, und halten Sie die Ergebnisse aus öffentlichen CI-Logs heraus. Das Secret Scanning von GitHub bietet dieselbe Idee als optionale „Validity Checks“ an.

Nicht verifiziert heißt nicht ungefährlich. Ein Passwort für eine Datenbank in Ihrem privaten Netz lässt sich von einem CI-Runner außerhalb dieses Netzes nicht testen. Ein verifizierendes Tool meldet es deshalb als nicht verifiziert, und ein Filter auf verifizierte Ergebnisse lässt es stillschweigend fallen.

Wo sollte Secret Scanning laufen: Pre-Commit, CI oder im Agenten?

An drei Stellen: als Pre-Commit-Hook auf jedem Laptop, als Scan in der CI bei jedem Push, den ein Entwickler nicht überspringen kann, und einmal als Scan der kompletten Historie, wenn Sie das Tool einführen. Ein Pre-Commit-Hook allein reicht nicht, denn git commit --no-verify umgeht laut Git-Dokumentation die Hooks pre-commit und commit-msg.

Auf GitHub blockiert Push Protection jeden Push, der ein erkanntes Secret enthält. Secret Scanning läuft auf öffentlichen Repositories kostenlos; für private und interne Repositories im Besitz einer Organisation braucht es GitHub Secret Protection auf GitHub Team oder GitHub Enterprise Cloud, abgerechnet pro aktivem Committer.

Coding-Agenten schieben vor den Commit noch einen Schritt. Claude Code, Cursor oder Codex können eine .env-Datei lesen, wenn nichts es ihnen verbietet, wie wir in unserer Analyse dazu, was Claude Code an Anthropic schickt und wie Sie die .env außer Reichweite halten gezeigt haben. Und ein Wert, den ein Agent gelesen hat, kann in einer Datei landen, die er schreibt.

Genau an diesem Schritt arbeitet CybeDefend: Die Guards von VibeDefend verweigern einem Agenten in Claude Code, Cursor und Codex das Lesen der .env und verweisen ihn auf die Umgebungsvariable, und der Diff-Scan von VibeDefend prüft die vom Agenten geänderten Dateien auf Secrets, SAST- und IaC-Probleme, bevor sie committet werden. Beides sehen Sie auf der Seite So funktioniert VibeDefend.

Der Pull Request bleibt die letzte Schranke, und die Sicherheitsprüfungen für den Pull Request eines KI-Agenten enthalten einen eigenen Durchgang für Secrets.

Wie führt man Secret-Scanner-Ergebnisse mit anderen Scannern zusammen?

Lassen Sie jeden Scanner SARIF 2.1.0 schreiben, das Format, das Code-Hoster und Tools für Schwachstellenmanagement lesen, und führen Sie die Dateien zusammen. Fünf der sechs getesteten Tools schreiben es, und jeder Befehl unten hat auf unserem Test-Repository eine gültige SARIF-2.1.0-Datei erzeugt. Zwei Fallen: Betterleaks v2 entfernt seinen SARIF-Reporter, und die Hilfe von Kingfisher nennt die eigene SARIF-Ausgabe weiterhin experimentell.

gitleaks git . --report-format sarif --report-path gitleaks.sarif
betterleaks git . --report-format sarif --report-path betterleaks.sarif   # 1.x only
trufflehog git file://. --sarif > trufflehog.sarif
kingfisher scan . --format sarif --output kingfisher.sarif
titus scan --git . --format sarif --output :memory: > titus.sarif

Pre-Commit- und CI-ScansJe eine SARIF-DateiZusammenführen und deduplizierenTriage und Historie führen

Eine zusammengeführte Datei ist noch keine triagierte Liste. Derselbe Schlüssel kommt von zwei Tools unter zwei Regelnamen zurück, ein False Positive, den Sie verworfen haben, taucht im nächsten Lauf wieder auf, und nichts führt den Nachweis, den ein Auditor verlangt. Es ist dasselbe Sortierproblem, das wir in unserem Beitrag dazu beschreiben, warum die meisten SAST-Befunde Rauschen sind.

CybeDefend Open Source ist für genau diesen Schritt gebaut. Es lässt die Scanner laufen, die Sie auswählen, also jedes Tool, das SARIF schreibt, und führt ihre Befunde in einer deduplizierten Queue zusammen, kostenlos und auf Ihren Servern. Der Start steht kurz bevor, und die Warteliste für CybeDefend Open Source ist offen.

Welche kostenlosen Secret Scanner sind nicht vollständig Open Source oder lokal?

GitHub Secret Scanning und ggshield von GitGuardian kosten für den Einstieg nichts, doch keines von beiden läuft vollständig auf Ihrem Rechner und unter einer Open-Source-Lizenz. GitHub scannt öffentliche Repositories kostenlos und verlangt für private einen kostenpflichtigen Secret-Protection-Plan. Die CLI von ggshield steht unter MIT, der Scan läuft aber über die API von GitGuardian und setzt ein Konto voraus.

Das Scanning von GitHub ist eine gehostete Funktion: Es liest die gesamte Historie eines Repositorys auf GitHub, auf jedem Branch, und seine Push Protection greift auf dem Server. Als Auffangnetz taugt es deshalb gut, für Code, der woanders liegt, passt es schlecht. Was es in einem Copilot-Workflow erkennt und was ihm entgeht, behandelt unser Leitfaden zu den Sicherheitsrisiken von GitHub Copilot.

Laut README von ggshield müssen Sie sich für die Nutzung gegenüber den Servern von GitGuardian authentifizieren, mit einem Konto oder einem API-Key; dort steht auch, dass Ihre Dateien und Secrets nicht gespeichert werden. Für viele Teams ist das ein vernünftiger Tausch, nur eben ein anderer, als Betterleaks auf dem eigenen Runner laufen zu lassen.

Was tun, wenn ein Scanner ein echtes Secret findet?

Widerrufen oder rotieren Sie es zuerst und entscheiden Sie danach, ob die Historie umgeschrieben werden muss. Die Anleitung von GitHub zum Entfernen sensibler Daten nennt als ersten Schritt für ein Passwort, ein Token oder ein Credential, es zu widerrufen und/oder zu rotieren. Ein widerrufenes Secret gewährt keinen Zugriff mehr, und das kann allein schon genügen.

1. Widerrufen oder rotieren Sie das Credential beim Anbieter. Kingfisher und Betterleaks ab Version 2 können einige Credential-Typen selbst widerrufen.
2. Prüfen Sie in den Zugriffslogs des Anbieters, wie es genutzt wurde, solange es offenlag.
3. Holen Sie es aus dem Code heraus, in einen Secrets-Manager oder in eine Umgebungsvariable, die der Code liest.
4. Schreiben Sie die Historie nur um, wenn es sein muss; die Anleitung von GitHub beschreibt die Schritte.
5. Halten Sie die False Positives fest, damit sie nicht wiederkommen: mit einem Kommentar gitleaks:allow oder betterleaks:allow, einem Eintrag in der Ignore-Datei des Tools oder einer Baseline von detect-secrets.

Häufige Fragen

Welcher Open-Source-Secret-Scanner ist 2026 der beste?

In unserem Test vom 29. Oktober 2026 fand Betterleaks 1.9.0 alle 12 Credentials, die wir in einem kleinen Repository platziert hatten, und schlug bei keinem der Köder an. TruffleHog ist die bessere Wahl, wenn Sie wissen müssen, ob ein Schlüssel aktiv ist, weil es standardmäßig verifiziert. Gitleaks funktioniert weiterhin, und sein README beschränkt künftige Releases auf Sicherheitspatches.

Wird Gitleaks noch gepflegt?

Gitleaks wird noch gepflegt, aber nur noch mit Sicherheitspatches. Seit dem 21. Mai 2026 bezeichnet sein README Gitleaks als „feature complete“, neue Features werden nicht mehr gemergt; das letzte Release ist v8.30.1 vom 21. März 2026. Sein ursprünglicher Autor arbeitet inzwischen an Betterleaks, das Konfigurationsdateien und Allow-Kommentare von Gitleaks liest.

Was ist die beste Gitleaks-Alternative?

Betterleaks, wenn der Wechsel ohne Umbau gelingen soll: Es stammt von den Leuten hinter Gitleaks, liest eine .gitleaks.toml, respektiert gitleaks:allow-Kommentare und fand in unserem Test alle 12 Credentials. Wenn Sie zusätzlich wissen müssen, ob ein Schlüssel aktiv ist, ergänzen Sie TruffleHog oder Kingfisher, die beide standardmäßig verifizieren.

Reicht Gitleaks als Pre-Commit-Hook?

Allein nicht. git commit --no-verify umgeht laut Git-Dokumentation die Hooks pre-commit und commit-msg. Lassen Sie Gitleaks oder Betterleaks deshalb zusätzlich in der CI bei jedem Push laufen, wo ein Entwickler den Scan nicht überspringen kann, und scannen Sie bei der Einführung einmal die komplette Git-Historie.

Was ist Betterleaks?

Betterleaks ist ein Secret Scanner unter MIT-Lizenz, im Februar 2026 von den Leuten hinter Gitleaks angelegt, darunter dessen ursprünglicher Autor, mit einer Entwicklung, die Aikido Security unterstützt. Version 1.9.0 ist das stabile Release. Version 2 steckt im Release-Candidate-Stadium, lässt die Live-Validierung standardmäßig aus und entfernt den SARIF-Reporter.

Ist TruffleHog kostenlos und Open Source?

Ja. TruffleHog auf GitHub ist seit Version 3.0 Open Source unter AGPL-3.0 und kostenlos nutzbar. Es gibt über 800 Secret-Typen an, verifiziert Credentials standardmäßig bei ihren Anbietern und schreibt seit Version 3.97.0, erschienen im August 2026, SARIF.

Scannt detect-secrets auch die Git-Historie?

Nein, und das ist Absicht. detect-secrets scannt die Dateien in Ihrem Arbeitsverzeichnis, standardmäßig die von Git verfolgten, und führt eine Baseline bekannter Befunde, sodass nur neue Secrets einen Commit blockieren. In unserem Test übersah es einen Schlüssel, der nur in der Historie einer gelöschten Datei existierte. Sein letztes Release, 1.5.0, stammt vom Mai 2024.

Wie findet man hartcodierte API-Keys im Quellcode?

Lassen Sie einen musterbasierten Scanner wie Betterleaks oder Gitleaks einmal über den Code und seine komplette Git-Historie laufen, danach bei jedem Commit und jedem Push. Anbieter-Keys von AWS, GitHub oder Stripe werden über Präfix und Format erkannt. Generische Secrets wie Passwörter brauchen Regeln, die Variablennamen und Entropie auswerten, und genau dort unterscheiden sich die Tools am stärksten.

Ist GitHub Secret Scanning kostenlos?

Für öffentliche Repositories ja: Secret Scanning läuft dort automatisch und kostenlos. Für private und interne Repositories im Besitz einer Organisation braucht es GitHub Secret Protection auf GitHub Team oder GitHub Enterprise Cloud, abgerechnet pro aktivem Committer.