Am 5. September 2025 entdeckte GitGuardian eine Angriffskampagne namens GhostAction: Angreifer hatten in 817 GitHub-Repositories manipulierte Workflows platziert und innerhalb kurzer Zeit 3.325 Geheimnisse abgegriffen, darunter PyPI-, npm- und DockerHub-Tokens sowie AWS-Zugangsdaten. Der Fall zeigt ein Muster, das 2026 längst zum Normalzustand geworden ist: Entwickler committen Zugangsdaten versehentlich in Git-Repositories, und Angreifer warten nicht lange, bis sie diese finden und missbrauchen.
Drei Werkzeuge dominieren den Markt für Secrets-Scanning: GitGuardian, TruffleHog und Gitleaks. Alle drei suchen nach API-Schlüsseln, Passwörtern und Zertifikaten im Quellcode, unterscheiden sich aber fundamental in Preismodell, Erkennungsmethode und Zielgruppe. Während Gitleaks und TruffleHog als Open-Source-Kommandozeilen-Tools direkt von Entwicklern eingesetzt werden, tritt GitGuardian als kommerzielle Plattform für ganze Sicherheitsabteilungen an.
Dieser Vergleich stützt sich auf aktuelle Benchmarks, offizielle Herstellerangaben und reale Vorfälle aus den Jahren 2025 und 2026, um zu klären, welches Tool für welches Team tatsächlich die richtige Wahl ist. Dabei geht es nicht nur um Feature-Listen, sondern um die Frage, die in jedem Sicherheitsteam irgendwann auf den Tisch kommt: Reicht ein kostenloses CLI-Tool, oder braucht es eine Plattform mit Dashboard, Audit-Trail und Vertragsgarantie?
Warum geleakte Zugangsdaten 2026 zum größten Risikofaktor wurden
Der Verizon Data Breach Investigations Report 2025 wertete 22.052 Sicherheitsvorfälle und 12.195 bestätigte Datenpannen aus. Gestohlene Zugangsdaten waren dabei mit 22 Prozent aller Fälle der häufigste initiale Angriffsvektor, noch vor Schwachstellen-Ausnutzung mit 20 Prozent und Phishing mit 15 Prozent. Bei sogenannten Basic-Web-Application-Angriffen waren sogar 88 Prozent der Fälle auf gestohlene Credentials zurückzuführen. Über das vergangene Jahrzehnt tauchten gestohlene Zugangsdaten laut Verizon in 31 Prozent aller analysierten Datenpannen auf. Scanner, die öffentliche Code-Plattformen überwachen, fanden laut der gleichen Auswertung 441.780 Geheimnisse auf öffentlich zugänglichen GitHub- und GitLab-Instanzen.
GitGuardian liefert mit dem State of Secrets Sprawl Report 2026 vom 17. März 2026 die bislang höchste gemessene Zahl: 28,65 Millionen neue fest codierte Geheimnisse wurden 2025 in öffentlichen GitHub-Commits gefunden, ein Plus von 34 Prozent gegenüber dem Vorjahr und der größte Einzeljahressprung, den der Anbieter je gemessen hat. 2024 waren es noch 23,77 Millionen gewesen, ein Anstieg von 25 Prozent im Jahresvergleich. Besonders stark wuchs eine neue Kategorie: KI-Dienst-Zugangsdaten. 1.275.105 solcher Secrets wurden 2025 offengelegt, ein Plus von 81 Prozent. Allein 113.000 DeepSeek-API-Schlüssel tauchten in öffentlichen Repositories auf, zusätzlich fanden sich 24.008 einzigartige Geheimnisse in MCP-Konfigurationsdateien, die zur Anbindung von KI-Agenten an externe Dienste verwendet werden.
Noch gravierender: Laut Verizon dauert es im Median 94 Tage, bis ein auf GitHub geleakter Schlüssel bereinigt wird. In diesem Zeitraum bleibt ein Angreifer, der den Fund vor dem eigenen Sicherheitsteam macht, praktisch unbemerkt im System. 43 Prozent der entdeckten Cloud-Secrets in öffentlichen Repositories waren Google-Cloud-API-Schlüssel, ein Hinweis darauf, dass die Verbreitung geleakter Zugangsdaten eng mit der jeweiligen Marktdurchdringung des Cloud-Anbieters zusammenhängt. Und ein beträchtlicher Teil dieser Lecks bleibt über Jahre aktiv: Eine GitGuardian-Analyse aus dem Jahr 2026 fand, dass 64 Prozent der bereits 2022 geleakten Geheimnisse auch vier Jahre später noch gültig waren. 68 Prozent der untersuchten Sicherheitsvorfälle gehen laut dem gleichen Report nach wie vor auf Code zurück, der über klassische Versionsverwaltung wie Git läuft, nicht über exotischere Angriffswege. Wer KI-Pipelines gegen API-Key-Diebstahl absichert, kennt das Problem bereits aus erster Hand, denn gerade generative Tools verleiten Entwickler dazu, Testschlüssel schnell im Code zu belassen.
Ein Treiber dieses Anstiegs sind KI-Coding-Assistenten selbst. Laut dem GitGuardian-Report 2026 enthielten Commits, die mit Unterstützung von Claude erstellt wurden, doppelt so häufig Geheimnisse wie der Durchschnitt aller untersuchten Commits. Entwickler kopieren Beispielcode aus Chatverläufen, in denen zuvor echte Zugangsdaten zu Testzwecken eingefügt wurden, oder lassen einen Assistenten eine funktionierende Konfigurationsdatei generieren, ohne den eingebetteten Schlüssel vor dem Commit zu entfernen. Schnellere Entwicklungszyklen bedeuten damit nicht automatisch sicherere Zyklen, eher im Gegenteil: Governance-Mechanismen hinken dem Tempo oft hinterher, mit dem neuer Code entsteht.
GitGuardian, TruffleHog und Gitleaks: die drei Werkzeuge im Kurzporträt
Gitleaks ist ein schlankes, in Go geschriebenes Kommandozeilen-Tool unter MIT-Lizenz. Es durchsucht Git-Diffs und komplette Commit-Historien nach Mustern, die auf Geheimnisse hindeuten, und läuft typischerweise in unter einer Sekunde durch einen Pre-Commit-Hook. Das Projekt lebt vollständig von seiner Community, es gibt keinen Konzern im Hintergrund, der Support-Verträge verkauft. Eine Validierung der gefundenen Treffer gegen echte Provider-APIs führt Gitleaks nicht durch, dafür ist es kostenlos, schnell und binnen Minuten in bestehende Pipelines integrierbar.
TruffleHog verfolgt einen anderen Ansatz und stammt vom Unternehmen Truffle Security. Neben der reinen Mustererkennung ruft das Tool für einen großen Teil der unterstützten Secret-Typen aktiv die zugehörige Provider-API auf und prüft, ob ein gefundener Schlüssel tatsächlich noch funktioniert. Laut offizieller TruffleHog-Dokumentation deckt das Tool mittlerweile mehr als 800 Secret-Detektoren ab, sowohl in der freien Open-Source-Version unter AGPLv3 als auch in der kostenpflichtigen Enterprise-Variante. Truffle Security positioniert das Produkt explizit als forensisches Werkzeug, das nicht nur meldet, sondern beweist, ob ein Fund ein echtes Risiko darstellt.
GitGuardian positioniert sich als Plattform für ganze Sicherheitsteams statt als reines Entwickler-Tool. Neben der Erkennung von Geheimnissen im eigenen Code überwacht GitGuardian kontinuierlich öffentliche GitHub-Repositories weltweit, legt für jeden Fund ein Incident-Ticket an, verfolgt den Rotationsstatus und bietet Governance-Funktionen für sogenannte Non-Human Identities wie Service-Accounts und API-Schlüssel. Das französische Unternehmen hat sich in den vergangenen Jahren vom reinen Scanner zu einer umfassenderen Plattform für das Management maschineller Identitäten entwickelt und verlangt dafür ein individuelles Angebot statt einer öffentlichen Preisliste.
Alle drei Tools lassen sich grob in die größere Kategorie der Application-Security-Werkzeuge einordnen, zu der auch Scanner für Abhängigkeiten und Container-Images gehören. Secrets-Scanning deckt dabei eine eigene Nische ab, die weder klassische Schwachstellen-Scanner noch Software-Bill-of-Materials-Tools abbilden: Ein Paket kann vollkommen aktuell und ungefährlich sein und trotzdem einen fest codierten Produktionsschlüssel enthalten. Genau diese Lücke zwischen Code-Qualität und Code-Hygiene haben GitGuardian, TruffleHog und Gitleaks in den vergangenen Jahren zu einem eigenständigen Marktsegment ausgebaut.
Technische Daten im direkten Vergleich
| Kriterium | GitGuardian | TruffleHog | Gitleaks |
|---|---|---|---|
| Lizenzmodell | Kommerziell (SaaS/Self-Hosted) | Open Source (AGPLv3) + Enterprise | Open Source (MIT) |
| GitHub Stars (Stand 1. Okt. 2026) | kein offenes Kernprodukt-Repo | 28.221 | 29.592 |
| Forks auf GitHub | – | 2.615 | 2.262 |
| Anzahl Secret-Detektoren | konfigurierbare Custom Detectors, keine öffentliche Gesamtzahl | 800+ laut Hersteller-Doku | keine offizielle Gesamtzahl veröffentlicht |
| Live-Verifizierung von Credentials | Ja, im Rahmen des Incident-Workflows | Ja, als Kernfunktion gegen Provider-APIs | Nein |
| Pre-Commit-Hook | Ja (ggshield) | Ja | Ja (gitleaks protect) |
| CI/CD-Integration | GitHub, GitLab, Jenkins, CI-Logs | GitHub Actions, GitLab CI, Docker, S3, GCS | GitHub Actions, vorkonfigurierte Action |
| Scan-Modus | Öffentliches Monitoring + interne Repos + CI-Logs | Git-Historie, Dateisysteme, S3, Docker, GCS | Git-Diffs und vollständige Commit-Historie |
| Self-Hosted-Option | Ja, in Enterprise-Tarif | Ja, in Enterprise-Tarif | Ja, da reines CLI-Tool |
| Zentrales Incident-Dashboard | Ja | Nein (CLI-fokussiert) | Nein |
| SecretBench Recall (NC State University) | nicht separat ausgewiesen | 52 Prozent | 88 Prozent |
| SecretBench Precision | nicht separat ausgewiesen | mittlerer Bereich laut Studie | 46 Prozent |
| Primärer Einsatzzweck | Unternehmensweites Secrets-Management & Compliance | Verifizierte Historien-Scans | Schnelle Pre-Commit- und CI-Diffs |
Auffällig: Gitleaks und TruffleHog liegen bei den GitHub-Stars nah beieinander, 29.592 gegenüber 28.221, was für eine ähnlich große Entwickler-Community spricht. GitGuardian lässt sich auf dieser Ebene nicht vergleichen, weil das Kernprodukt eine geschlossene SaaS-Plattform ist. Lediglich das zugehörige CLI-Tool ggshield ist offen zugänglich und wird in der SecretBench-Studie als Referenzpunkt für die Erkennungslogik des Anbieters genutzt.
Bei den CI/CD-Integrationen zeigt sich ein weiterer Unterschied: TruffleHog deckt mit Docker-, S3- und GCS-Scanning auch Infrastrukturebenen ab, die über reinen Quellcode hinausgehen, während Gitleaks sich bewusst auf Git-native Workflows beschränkt. GitGuardian wiederum kann direkt CI-Logs einlesen, also genau jene Stelle, an der laut dem tj-actions/changed-files-Vorfall Geheimnisse im Klartext landen können, wenn eine Pipeline kompromittiert wird.
Technisch unterscheiden sich die drei Tools auch in der Erkennungsmethode selbst. Gitleaks arbeitet primär mit regulären Ausdrücken und Entropie-Berechnung, es misst also, wie zufällig eine Zeichenkette wirkt, um zwischen einem echten Schlüssel und einem gewöhnlichen Wort zu unterscheiden. TruffleHog kombiniert dieselbe Grundtechnik mit einer nachgeschalteten Verifizierungsschicht, die den gefundenen String testweise gegen die echte API schickt. GitGuardian setzt zusätzlich auf maschinelles Lernen, um Kontextinformationen aus dem umgebenden Code einzubeziehen, etwa ob eine Variable “api_key” oder “example_token” heißt, was die Fehlalarmquote nach Herstellerangaben weiter senken soll.
Erkennungsleistung: Was die Benchmarks wirklich zeigen
Die belastbarste akademische Quelle für einen direkten Vergleich ist SecretBench, eine Studie der North Carolina State University mit 97.479 gelabelten Instanzen aus 818 Repositories. Das Ergebnis überrascht auf den ersten Blick: Gitleaks erreichte in diesem Test einen Recall von 88 Prozent bei einer Precision von 46 Prozent. TruffleHog kam auf einen Recall von 52 Prozent bei einer mittleren Precision. Recall beschreibt, wie viele der tatsächlich vorhandenen Geheimnisse ein Tool findet, Precision beschreibt, wie viele der gemeldeten Treffer tatsächlich echte Geheimnisse sind statt Fehlalarme.
Das Bild ist also nicht so eindeutig, wie Marketingmaterial oft suggeriert. Gitleaks findet in diesem Test mehr potenzielle Geheimnisse, produziert aber auch mehr Fehlalarme. TruffleHog findet weniger, dafür verifiziert es einen großen Teil der Treffer live gegen die jeweilige Provider-API, was die Zahl der tatsächlich relevanten Funde in der Praxis oft wichtiger macht als der reine Recall-Wert. Die Studie maß zudem die Überschneidung zwischen den Tools: Zwischen GitGuardians CLI ggshield und TruffleHog lag die Übereinstimmung bei echten Treffern bei 76 Prozent, zwischen ggshield und Gitleaks dagegen nur bei 18 Prozent. Das deutet darauf hin, dass die Erkennungslogiken der drei Tools sich spürbar unterscheiden und sich in der Praxis eher ergänzen als vollständig überschneiden.
Eine zweite Datenquelle liefert die Praxis in großem Maßstab: Der GitGuardian-Report 2026 wertet selbst Milliarden öffentlicher Commits aus und versendete 2025 rund 2,5 Millionen E-Mail-Benachrichtigungen an betroffene Entwickler, ein Anstieg von 47 Prozent gegenüber 2024. Diese Zahl ist kein Benchmark im klassischen Sinn, zeigt aber die Größenordnung, in der automatisierte Erkennung heute arbeitet. Eine dritte, unabhängige Einordnung liefern Fachportale wie devsecops.ae und safeguard.sh, die TruffleHog und Gitleaks übereinstimmend als die beiden führenden Open-Source-Scanner einstufen, TruffleHog wegen der Verifizierung, Gitleaks wegen der Geschwindigkeit bei Pre-Commit-Prüfungen.
| Quelle | Methodik | Kernaussage |
|---|---|---|
| SecretBench (NC State University) | 97.479 gelabelte Instanzen aus 818 Repositories | Gitleaks: 88 % Recall / 46 % Precision, TruffleHog: 52 % Recall |
| GitGuardian State of Secrets Sprawl 2026 | Scan öffentlicher GitHub-Commits in Milliardenumfang | 28,65 Mio. neue Secrets 2025, 2,5 Mio. Alerts versendet |
| Verizon DBIR 2025 | 22.052 analysierte Sicherheitsvorfälle | 441.780 Secrets auf öffentlichen Plattformen entdeckt |
| Branchenvergleiche (devsecops.ae, safeguard.sh) | Qualitative Einordnung durch Sicherheitspraktiker | TruffleHog führt bei Verifizierung, Gitleaks bei Geschwindigkeit |
Die vier Quellen zeigen übereinstimmend, dass keines der drei Tools in jeder Disziplin führt. Wer sich ausschließlich auf einen einzelnen Recall-Wert verlässt, trifft eine unvollständige Entscheidung. Erst die Kombination aus Erkennungsrate, Fehlalarmquote und operativer Weiterverarbeitung ergibt ein realistisches Bild.
Preismodelle: kostenlos, Open Source oder Unternehmenslizenz?
| Tool | Kostenlose Version | Kommerzielle Version | Besonderheit |
|---|---|---|---|
| Gitleaks | Vollständig kostenlos, MIT-Lizenz, keine Einschränkungen | Kein kommerzieller Tarif bekannt | Reine Community-Pflege, kein Hersteller-Support |
| TruffleHog | Open Source unter AGPLv3, 800+ Detektoren inklusive | Enterprise: Preis nur auf Anfrage | Live-Verifizierung bereits in der kostenlosen Version enthalten |
| GitGuardian | Keine vollständig kostenlose Version öffentlich dokumentiert | Gestaffelte Tarife (u. a. Growth, Business, Enterprise), individuelles Angebot | Unbegrenztes Monitoring öffentlicher Repositories ab höherer Stufe |
Die offizielle GitGuardian-Preisseite listet Funktionen wie unbegrenztes Monitoring öffentlicher Secrets, Governance für Non-Human Identities, Developer-Endpoint-Schutz und Self-Hosted-Deployment, nennt dafür aber keine öffentlichen Euro- oder Dollarbeträge. Interessenten müssen den Vertrieb kontaktieren, was in der Praxis bedeutet, dass der Preis stark von Repository-Anzahl, Teamgröße und gewünschten Zusatzmodulen abhängt. Für Budgetplanungen ist das unbequem, aber in der Enterprise-Security-Branche eher die Regel als die Ausnahme.
Bei TruffleHog ist die Situation ähnlich gelagert, allerdings mit einem wichtigen Unterschied: Die Open-Source-Variante ist laut offizieller Preisseite komplett kostenlos und deckt bereits mehr als 800 Detektoren ab, inklusive der Live-Verifizierung, die bei anderen Anbietern oft erst in Bezahltarifen freigeschaltet wird. Die Enterprise-Variante mit GitHub-, S3-, Directory-, GCS- und Docker-Scanning wird dagegen nur auf Anfrage angeboten und richtet sich an Organisationen, die zentrale Verwaltung über viele Repositories hinweg benötigen. Gitleaks bleibt der einzige der drei Kandidaten ohne jede kommerzielle Schiene, was das Tool besonders für Einzelentwickler und kleine Teams attraktiv macht, die kein Budget für Secrets-Management haben, aber trotzdem nicht auf Schutz verzichten wollen.
Beim Kosten-Nutzen-Verhältnis lohnt sich ein Blick auf die Folgekosten eines tatsächlichen Vorfalls statt nur auf die Lizenzgebühr. Der GhostAction-Vorfall betraf 817 Repositories gleichzeitig, die Bereinigung von 3.325 gestohlenen Geheimnissen inklusive Rotation aller betroffenen Zugangsdaten bindet in einem mittelgroßen Unternehmen schnell mehrere Personenwochen an Arbeitszeit. Gemessen an diesem Aufwand relativiert sich ein individuelles GitGuardian-Angebot für Teams, die ohnehin regelmäßig mit solchen Vorfällen rechnen müssen, deutlich schneller als es die reine Preisliste zunächst vermuten lässt.
GitGuardian im Detail
GitGuardians größter Mehrwert liegt nicht in der reinen Erkennung, sondern im Umgang mit dem Fund danach. Wird ein Geheimnis entdeckt, legt die Plattform automatisch ein Incident-Ticket an, weist es dem verantwortlichen Entwickler zu und verfolgt, ob der Schlüssel rotiert oder widerrufen wurde. Für Sicherheitsteams, die Dutzende oder Hunderte Repositories im Blick behalten müssen, ersetzt das mühsame manuelle Nachverfolgung in Tabellenblättern und macht den gesamten Remediation-Prozess für Auditoren nachvollziehbar.
Ein konkretes Beispiel für die Reichweite der Plattform: GitGuardian testete 4.802 aus mehr als 500.000 öffentlich gefundenen RSA-Schlüsseln für GitHub-Apps und stellte fest, dass 474 davon, also knapp 10 Prozent, noch funktionierten und Administratorzugriff auf 440 Organisationen ermöglichten. Im August 2026 fand das Team zudem 4.576 einzigartige n8n-API-Tokens in öffentlichen GitHub-Commits, verknüpft mit mehr als 1.200 Hostnamen. 896 der zugehörigen Instanzen waren erreichbar, 321 davon noch aktiv zugänglich. Solche Funde zeigen, warum ein zentrales Monitoring öffentlicher Repositories für größere Organisationen einen echten Unterschied macht, den reine CLI-Tools so nicht leisten können, weil sie nur das eigene Repository im Blick haben und nicht das gesamte öffentliche Internet.
Der Nachteil liegt im Preis und in der fehlenden Transparenz. Ohne öffentliche Preisliste müssen Teams einen Sales-Prozess durchlaufen, bevor sie wissen, ob sich die Investition lohnt. Für kleine Teams mit ohnehin schlankem Workflow ist das oft unverhältnismäßig, insbesondere wenn die gleichen Funktionen in Grundform bereits durch eine Kombination aus Gitleaks und TruffleHog abgedeckt werden könnten.
Für Entwickler im Alltag bringt GitGuardian zusätzlich das CLI-Tool ggshield mit, das sich wie Gitleaks als Pre-Commit-Hook einsetzen lässt und so die Lücke zwischen Entwickler-Workflow und zentralem Dashboard schließt. Ein Fund wird lokal blockiert, bevor er überhaupt committet wird, erscheint aber gleichzeitig im zentralen Incident-System, sobald er die Prüfung umgangen hat oder nachträglich über das öffentliche Monitoring auftaucht. Diese doppelte Absicherung, lokal und zentral, ist einer der Gründe, warum größere Organisationen GitGuardian trotz des höheren Preises gegenüber reinen CLI-Tools bevorzugen.
TruffleHog im Detail: Live-Verifizierung als Unterscheidungsmerkmal
TruffleHogs zentrales Versprechen lautet: nicht jeder String, der wie ein API-Schlüssel aussieht, ist auch ein aktiver API-Schlüssel. Für einen Großteil der über 800 unterstützten Secret-Typen führt das Tool deshalb einen schreibgeschützten Testaufruf gegen die jeweilige Provider-API durch und meldet nur, ob ein Fund tatsächlich noch funktioniert. Das reduziert die Zahl der Fehlalarme in der Praxis erheblich, auch wenn der SecretBench-Benchmark beim reinen Recall-Wert niedriger abschneidet als Gitleaks.
Dieser Verifizierungsansatz erklärt auch, warum TruffleHog bei forensischen Nachforschungen beliebt ist. Nach dem tj-actions/changed-files-Vorfall im März 2025, bei dem ein gestohlenes Bot-Zugangstoken genutzt wurde, um Tags der populären GitHub Action auf manipulierten Code umzubiegen (CVE-2025-30066), setzen viele Sicherheitsteams historische Scans ein, um herauszufinden, welche der über die Logs exfiltrierten Zugangsdaten noch aktiv sind. Genau für dieses Szenario, vollständige Git-Historien nach noch gültigen Credentials zu durchsuchen, ist TruffleHog konzipiert. Ein Scan, der zehntausend Commits zurückreicht, liefert wenig Nutzen, wenn am Ende niemand weiß, welche der gefundenen Strings überhaupt noch ein Risiko darstellen, und genau diese Lücke schließt die Verifizierung.
Die Kehrseite: TruffleHog bleibt im Kern ein Kommandozeilen-Werkzeug. Ohne die Enterprise-Variante fehlt ein zentrales Dashboard, Teams müssen eigene Prozesse für Remediation und Nachverfolgung bauen, etwa über dedizierte Secrets-Management-Systeme, die Zugangsdaten von vornherein außerhalb des Codes verwalten. Zudem bedeutet die Live-Verifizierung, dass TruffleHog während eines Scans aktiv Netzwerkanfragen an Drittanbieter-APIs stellt, was in stark abgeschotteten Netzwerkumgebungen zusätzliche Konfiguration erfordert.
Bei der Bereitstellung zeigt sich TruffleHog flexibel: Das Tool lässt sich als eigenständige Binärdatei, als Docker-Image oder über Homebrew installieren und unterstützt neben GitHub auch GitLab, Bitbucket sowie lokale Dateisysteme als Scan-Ziel. Diese Breite macht TruffleHog zur praktischen Wahl für Organisationen, die nicht ausschließlich auf GitHub setzen, sondern eine heterogene Toolchain mit mehreren Code-Hosting-Plattformen betreiben, wie es in gewachsenen deutschen Mittelstandsunternehmen häufig der Fall ist.
Gitleaks im Detail: schnell, schlank, kostenlos
Gitleaks ist bewusst minimalistisch gehalten. Das Tool läuft als einzelne Binärdatei, benötigt keine externen Abhängigkeiten und ist in der Lage, typische Pre-Commit-Prüfungen in deutlich unter einer Sekunde abzuschließen. Für Teams, die Secrets-Scanning direkt in den Git-Workflow einbauen wollen, ohne spürbare Verzögerung beim Commit, ist das ein echter Vorteil gegenüber den schwereren Alternativen. Die Konfiguration erfolgt über eine einzelne TOML-Datei, in der eigene Regeln ergänzt oder Standardregeln deaktiviert werden können.
Der SecretBench-Benchmark bestätigt diesen Fokus: Mit 88 Prozent Recall erkennt Gitleaks mehr potenzielle Geheimnisse als TruffleHog, allerdings bei einer Precision von nur 46 Prozent. In der Praxis bedeutet das mehr Fehlalarme, die Entwickler manuell prüfen müssen, etwa Beispielwerte in Dokumentationen oder Testdateien, die zufällig wie echte Schlüssel aussehen. Weil Gitleaks keine Live-Verifizierung durchführt, lässt sich aus einem Treffer allein nicht ablesen, ob der gefundene String tatsächlich noch ein aktives Risiko darstellt oder längst abgelaufen ist.
Für Open-Source-Projekte, Einzelentwickler und Teams mit begrenztem Budget bleibt Gitleaks trotzdem die naheliegende Wahl: MIT-lizenziert, 29.592 GitHub-Stars, aktiv gepflegt und ohne jede Preisschwelle einsetzbar. Die vorkonfigurierte GitHub Action macht die Integration in bestehende Pipelines zur Sache weniger Minuten, und weil das Tool als statische Binärdatei ausgeliefert wird, lässt es sich auch in air-gapped Umgebungen ohne Internetzugang betreiben, ein Bereich, in dem TruffleHogs API-Verifizierung naturgemäß an Grenzen stößt.
Das Projekt wird von einer breiten Community aus Contributors weiterentwickelt und veröffentlicht neue Versionen in kurzen Abständen, meist um neue Regeln für zusätzliche Secret-Typen zu ergänzen oder Fehlalarme bei bestehenden Regeln zu reduzieren. Wer eigene, unternehmensspezifische Muster erkennen will, etwa interne API-Formate, kann diese über die Konfigurationsdatei ergänzen, ohne den Quellcode selbst anfassen zu müssen. Dieser niedrigschwellige Anpassungsaufwand ist einer der Gründe, warum Gitleaks in vielen Open-Source-Projekten zum De-facto-Standard geworden ist.
Reale Vorfälle: Wenn ein vergessener API-Key zum Sicherheitsvorfall wird
Die Zahlen aus den Sprawl-Reports wären abstrakt ohne konkrete Fälle. Hier sind sieben dokumentierte Vorfälle aus 2025 und 2026, die zeigen, wie aus einem einzelnen geleakten Secret ein ernsthafter Sicherheitsvorfall oder sogar ein Supply-Chain-Angriff wird.
Bemerkenswert an den folgenden Fällen ist, wie unterschiedlich die Angriffswege im Detail aussehen, obwohl die Grundursache fast immer dieselbe bleibt: ein Zugangstoken, das irgendwo im Code oder in einer Log-Datei landete, wo es nicht hingehörte. Mal war es ein kompromittierter Bot-Account, mal ein unbedacht gepushter Container, mal eine automatisierte Workflow-Datei, die niemand mehr genau geprüft hatte. Für Verteidiger bedeutet das: Die Angriffsfläche liegt nicht nur im eigenen Quellcode, sondern erstreckt sich über CI/CD-Konfigurationen, Container-Registries und sogar über Automatisierungsplattformen wie n8n, die zunehmend sensible Zugangsdaten verwalten.
- tj-actions/changed-files, März 2025 (CVE-2025-30066): Ein gestohlenes persönliches Zugangstoken erlaubte es Angreifern, die Tags der weitverbreiteten GitHub Action auf manipulierten Code umzuleiten. Der Code druckte anschließend CI/CD-Geheimnisse direkt in die Workflow-Logs, betroffen waren Tausende Pipelines weltweit.
- GhostAction-Kampagne, 5. September 2025: Von GitGuardian entdeckt, betraf 327 GitHub-Nutzer und 817 Repositories. Angreifer injizierten bösartige Workflows, die 3.325 Geheimnisse abgriffen, darunter PyPI-, npm- und DockerHub-Tokens, GitHub-PATs, AWS-Schlüssel, Datenbank-Credentials und Cloudflare-API-Tokens.
- GitHub-App-Private-Keys, 2026: GitGuardian testete 4.802 der mehr als 500.000 öffentlich gefundenen RSA-Schlüssel und stellte fest, dass 474 davon, rund 10 Prozent, noch gültig waren und Administratorzugriff auf 440 Organisationen boten.
- n8n-Token-Leck, August 2026: GitGuardian fand 4.576 einzigartige n8n-Automatisierungs-Tokens in öffentlichen Commits, verknüpft mit über 1.200 Hostnamen. 896 Instanzen waren erreichbar, 321 davon weiterhin aktiv zugänglich.
- Docker-Hub-Geheimnisse, Ende 2025: Sicherheitsforscher von Flare fanden mehr als 10.000 öffentliche Docker-Hub-Container-Images, die produktive API-Schlüssel, Cloud-Tokens, CI/CD-Zugangsdaten und sogar KI-Modell-Zugriffstokens offenlegten.
- DeepSeek-API-Schlüssel, 2025: GitGuardian zählte 113.000 öffentlich auffindbare DeepSeek-API-Schlüssel, ein Ausmaß, das die rasante und oft unvorsichtige Integration neuer KI-Dienste in bestehende Codebasen verdeutlicht.
- Shai-Hulud-2-Kampagne, 2026: Die Angriffswelle fand 294.842 Secret-Vorkommen über 6.943 kompromittierte Maschinen verteilt, wobei 59 Prozent davon auf CI/CD-Runner entfielen, also genau jene Systeme, die Build-Pipelines mit privilegiertem Zugriff ausführen.
Mehr Details zur GhostAction-Kampagne liefert der Originalbericht von GitGuardian, eine laufend aktualisierte Übersicht weiterer Vorfälle rund um Non-Human Identities führt die Non-Human Identity Management Group. Wer sich mit Software-Signierung gegen manipulierte Supply Chains beschäftigt, trifft regelmäßig auf dieselben Angriffsmuster: gestohlene Tokens als Einstiegspunkt, gefolgt von lateraler Bewegung über CI/CD-Systeme in nachgelagerte Infrastruktur.
Pro und Contra im Überblick
GitGuardian
- Plus: zentrales Incident-Dashboard mit Remediation-Tracking
- Plus: kontinuierliches Monitoring öffentlicher Repositories weltweit
- Plus: Governance-Funktionen für Non-Human Identities
- Plus: direkte Integration von CI-Logs als zusätzliche Scan-Quelle
- Minus: keine öffentliche Preisliste, Sales-Kontakt notwendig
- Minus: kein vollständig kostenloser Vollzugang dokumentiert
TruffleHog
- Plus: Live-Verifizierung reduziert Fehlalarme spürbar
- Plus: über 800 Detektoren bereits in der kostenlosen Version
- Plus: aktive Community mit 28.221 GitHub-Stars
- Plus: breite Scan-Ziele über Docker, S3 und GCS hinaus
- Minus: niedrigerer Recall im SecretBench-Benchmark (52 Prozent)
- Minus: ohne Enterprise-Tarif kein zentrales Dashboard
Gitleaks
- Plus: vollständig kostenlos, MIT-lizenziert, keine Hintertür-Kosten
- Plus: höchster Recall im SecretBench-Test (88 Prozent)
- Plus: extrem schnell bei Pre-Commit-Prüfungen
- Plus: funktioniert auch offline bzw. in abgeschotteten Netzwerken
- Minus: keine Live-Verifizierung, dadurch mehr Fehlalarme (46 Prozent Precision)
- Minus: kein Hersteller-Support, reine Community-Pflege
Welches Tool passt zu welchem Team? Fünf Einsatzszenarien
Einzelentwickler und kleine Open-Source-Projekte fahren mit Gitleaks als Pre-Commit-Hook am besten. Die Integration kostet wenige Minuten, es fallen keine Kosten an, und die Geschwindigkeit stört den Entwicklungsfluss nicht. Für ein privates Side-Project oder ein kleines npm-Paket ist das völlig ausreichend, insbesondere wenn der Maintainer ohnehin jeden gemeldeten Fund manuell prüft.
DevSecOps-Teams mit regelmäßigen Historien-Audits sollten auf TruffleHog setzen. Wer prüfen will, welche der vor Monaten oder Jahren geleakten Zugangsdaten heute noch aktiv sind, profitiert direkt von der Live-Verifizierung gegen Provider-APIs, statt Hunderte potenzielle Treffer manuell durchzugehen, von denen die meisten längst abgelaufen sind.
Regulierte Unternehmen mit Compliance-Pflichten, etwa im Rahmen von NIS2 oder branchenspezifischen Audits, benötigen das zentrale Dashboard und die Remediation-Nachverfolgung von GitGuardian. Ohne dokumentierten Workflow lässt sich gegenüber Prüfern kaum belegen, dass ein gefundenes Geheimnis tatsächlich rotiert wurde, und genau diese Nachweispflicht wird in Audits regelmäßig zum Streitpunkt.
Teams mit intensivem CI/CD-Einsatz, etwa viele parallele GitHub-Actions-Workflows, sollten eine Kombination fahren: Gitleaks als schneller Pre-Commit-Filter, TruffleHog als geplanter Scan direkt gegen die CI-Logs, da genau dort laut Vorfällen wie tj-actions/changed-files die größten Risiken entstehen. Die Shai-Hulud-2-Zahlen, bei denen 59 Prozent der betroffenen Maschinen CI/CD-Runner waren, bestätigen, dass dieser Bereich besondere Aufmerksamkeit verdient.
Teams, die verstärkt KI-Coding-Assistenten einsetzen, sollten dem Thema Verifizierung besonderes Gewicht geben. Angesichts des 81-prozentigen Anstiegs bei geleakten KI-Dienst-Zugangsdaten im Jahr 2025 reicht reine Mustererkennung oft nicht mehr aus, um zwischen Platzhaltern in generiertem Beispielcode und echten, aktiven Schlüsseln zu unterscheiden, die ein Assistent versehentlich aus einer vorherigen Konversation übernommen hat.
Die Wahl hängt am Ende weniger von der Teamgröße allein ab als vom Reifegrad der bestehenden Sicherheitsprozesse. Ein zehnköpfiges Startup ohne dedizierte Sicherheitsabteilung braucht kein Governance-Dashboard, sondern zuverlässigen Basisschutz zum Nulltarif. Ein regulierter Konzern mit mehreren hundert Repositories und externen Auditoren braucht dagegen genau die Nachvollziehbarkeit, die reine CLI-Tools nicht liefern können. Zwischen diesen beiden Polen bewegen sich die meisten Teams, und die realistischste Antwort ist fast immer eine schrittweise Eskalation statt einer einmaligen Grundsatzentscheidung.
Migrationsleitfaden: vom ungeschützten Repository zur Scanning-Pipeline
Wer heute noch ganz ohne Secrets-Scanning arbeitet, sollte nicht direkt mit der teuersten Lösung starten, sondern schrittweise vorgehen. Der folgende Ablauf hat sich in der Praxis bei Teams unterschiedlicher Größe bewährt und lässt sich ohne größere Vorlaufkosten umsetzen.
Ein häufiger Fehler beim Einstieg: Teams aktivieren direkt einen harten CI/CD-Stopp bei jedem Fund, noch bevor die bestehende Codebasis bereinigt wurde. Das Ergebnis sind blockierte Pipelines wegen Dutzender Altfunde, die niemand kurzfristig beheben kann, was die Akzeptanz des gesamten Vorhabens im Team untergräbt. Besser ist es, zunächst im reinen Beobachtungsmodus zu scannen, die Historie zu bereinigen, und erst danach harte Gates einzuführen, die nur noch neue Commits betreffen.
- Schritt 1 – Bestandsaufnahme: Gitleaks einmalig gegen die komplette Commit-Historie aller aktiven Repositories laufen lassen, um das aktuelle Ausmaß des Problems zu sehen, ohne Kosten oder Vertragsverhandlungen.
- Schritt 2 – Verifizierung der Funde: Die Ergebnisliste mit TruffleHog gegenprüfen, um Fehlalarme auszusortieren und herauszufinden, welche gefundenen Schlüssel tatsächlich noch aktiv sind. Erst dieser Schritt liefert eine priorisierte, handhabbare Liste statt eines unübersichtlichen Datenbergs.
- Schritt 3 – Sofortige Rotation: Alle als aktiv verifizierten Zugangsdaten umgehend widerrufen und neu ausstellen, bevor irgendeine weitere Integration erfolgt. Dieser Schritt hat höchste Priorität und sollte nicht auf eine spätere Projektphase verschoben werden.
- Schritt 4 – Pre-Commit-Hook einführen: Gitleaks als Git-Hook bei allen Entwicklern installieren, damit neue Geheimnisse gar nicht erst committet werden. Eine kurze Schulung hilft, die Akzeptanz im Team zu sichern.
- Schritt 5 – CI/CD-Gate einbauen: Einen Scan-Schritt in die Pipeline einfügen, der Builds bei neu gefundenen Secrets blockiert, idealerweise kombiniert mit einer TruffleHog-Verifizierung gegen die CI-Logs selbst.
- Schritt 6 – Governance aufbauen: Sobald mehrere Teams und Repositories involviert sind, auf eine zentrale Plattform wie GitGuardian umsteigen, um Zuständigkeiten, Fristen und Rotationsstatus nachvollziehbar zu dokumentieren.
- Schritt 7 – Regelmäßige Re-Audits: Historische Scans mindestens vierteljährlich wiederholen, da laut GitGuardian ein erheblicher Teil älterer Leaks über Jahre hinweg aktiv bleibt und neue Mitarbeiter immer wieder neue Risiken einbringen.
Dieser stufenweise Ansatz kombiniert bewusst alle drei Tools, statt sich früh auf eines festzulegen. Für Projekte, die parallel auch Abhängigkeiten gegen bekannte Schwachstellen prüfen müssen, lohnt sich ein Blick auf Werkzeuge für Paket- und Abhängigkeitssicherheit, da Secrets-Leaks und anfällige Pakete oft über dieselben CI/CD-Pfade in Produktionssysteme gelangen und sich in Audits gegenseitig bedingen.
DACH-Perspektive: NIS2, KRITIS und der Compliance-Druck
Für Unternehmen in Deutschland, Österreich und der Schweiz ist Secrets-Scanning längst keine rein technische Frage mehr. Mit der Umsetzung von NIS2 in deutsches Recht müssen betroffene Betreiber wesentlicher und wichtiger Einrichtungen Risikomanagementmaßnahmen nachweisen, wozu auch der kontrollierte Umgang mit Zugangsdaten und Schlüsseln in der Softwareentwicklung zählt. Wer im Audit nicht belegen kann, wann ein geleaktes Secret entdeckt und wann es rotiert wurde, gerät schnell in Erklärungsnot, unabhängig davon, wie gut die technische Erkennung im Hintergrund tatsächlich funktioniert hat.
Gerade hier zeigt sich der Unterschied zwischen den drei Tools am deutlichsten. Reine CLI-Werkzeuge wie Gitleaks und die Open-Source-Version von TruffleHog liefern Funde, aber keine Dokumentation darüber, wer wann reagiert hat. Für ein Audit reicht das selten aus, ohne dass Teams eigene Prozesse drumherum bauen, etwa über separate Ticketsysteme, die den Fund mit der Behebung verknüpfen. GitGuardians Incident-Tracking liefert genau diese Dokumentation von Haus aus, was die höheren Kosten für regulierte Branchen wie Finanzdienstleister, Energieversorger oder Gesundheitswesen relativiert.
Ein weiterer Aspekt betrifft die Datenschutz-Grundverordnung: Geleakte Zugangsdaten führen in vielen Fällen direkt zu unbefugtem Zugriff auf personenbezogene Daten, etwa wenn ein kompromittierter Datenbank-Schlüssel Kundendatensätze offenlegt. Meldepflichten gegenüber Aufsichtsbehörden greifen dann unabhängig davon, ob der ursprüngliche Fehler ein einzelner vergessener Commit war. Unternehmen, die zusätzlich zentrale Schlüsselverwaltung statt reiner Erkennung benötigen, vergleichen an dieser Stelle häufig auch dedizierte Secrets-Management-Plattformen, die Zugangsdaten gar nicht erst in Konfigurationsdateien landen lassen, sondern zur Laufzeit dynamisch ausliefern.
In der Schweiz verlangt das revidierte Datenschutzgesetz vergleichbare Nachweispflichten, während österreichische Unternehmen über das Netz- und Informationssystemsicherheitsgesetz ähnliche Anforderungen an Betreiber kritischer Infrastrukturen stellen. Für international tätige Konzerne mit Standorten in allen drei Ländern bedeutet das, dass ein einheitlicher Scanning- und Dokumentationsprozess über Landesgrenzen hinweg sinnvoller ist als länderspezifische Insellösungen. Gerade hier zahlt sich eine zentrale Plattform aus, die sich über mehrere Rechtsräume hinweg einheitlich konfigurieren lässt, statt für jedes Land ein eigenes CLI-Setup zu pflegen.
Das Urteil: Welches Tool gewinnt den Vergleich?
Es gibt keinen einzelnen Gewinner, die Daten sprechen für eine Kombination. Gitleaks gewinnt beim Recall im SecretBench-Benchmark mit 88 Prozent gegenüber 52 Prozent bei TruffleHog und ist dabei komplett kostenlos, das macht es zur besten Wahl für den ersten Verteidigungsring direkt am Commit. TruffleHog gewinnt bei der Präzision der tatsächlich verwertbaren Funde durch Live-Verifizierung gegen über 800 Provider-APIs und eignet sich am besten für geplante, tiefere Scans der Commit-Historie. GitGuardian gewinnt dort, wo Governance, Dokumentation und Skalierung über viele Teams hinweg zählen, auch wenn der Preis dafür nicht öffentlich einsehbar ist und individuell verhandelt werden muss.
Die geringe Überschneidung von nur 18 Prozent zwischen Gitleaks und GitGuardians ggshield im SecretBench-Test untermauert diesen Schluss: Die drei Werkzeuge erkennen teilweise unterschiedliche Dinge, selbst wenn sie auf denselben Code angesetzt werden. Angesichts von 28,65 Millionen neuen Leaks allein 2025 und einer mittleren Bereinigungszeit von 94 Tagen ist der Verzicht auf jede Form von Scanning das eigentliche Risiko, nicht die Wahl zwischen den drei vorgestellten Tools. Für die meisten Teams führt der pragmatischste Weg über eine Kombination aus Gitleaks für das Tagesgeschäft und TruffleHog für periodische Tiefenprüfungen, ergänzt um GitGuardian, sobald Compliance-Anforderungen eine lückenlose Dokumentation verlangen.
Wichtig bleibt dabei die Erwartungshaltung: Kein Scanner verhindert, dass Entwickler versehentlich Zugangsdaten committen. Jedes der drei Tools wirkt erst, nachdem der Fehler passiert ist, verkürzt aber das Zeitfenster zwischen Leck und Entdeckung von potenziell Monaten auf Minuten oder Stunden. Angesichts der 94 Tage medianer Bereinigungszeit aus dem Verizon-Report ist genau diese Verkürzung der eigentliche Wert, den Secrets-Scanning 2026 für jedes Entwicklungsteam liefert, unabhängig davon, für welches der drei vorgestellten Werkzeuge es sich am Ende entscheidet.
Häufig gestellte Fragen
Was ist der grundlegende Unterschied zwischen GitGuardian, TruffleHog und Gitleaks?
Gitleaks und TruffleHog sind in erster Linie Kommandozeilen-Werkzeuge für Entwickler, GitGuardian ist eine kommerzielle Plattform mit zentralem Dashboard, Incident-Tracking und Governance-Funktionen für ganze Sicherheitsteams.
Ist Gitleaks wirklich komplett kostenlos?
Ja. Gitleaks steht unter MIT-Lizenz, es gibt keinen bekannten kommerziellen Tarif, und das Tool lässt sich uneingeschränkt in privaten wie öffentlichen Repositories einsetzen.
Was bedeutet Live-Verifizierung bei TruffleHog genau?
TruffleHog ruft für gefundene Zugangsdaten die zugehörige Provider-API auf und prüft, ob der Schlüssel aktuell noch funktioniert, statt nur ein Muster im Text zu erkennen. Das reduziert Fehlalarme, erfordert aber Netzwerkzugriff während des Scans.
Welches Tool erkennt laut Benchmark die meisten Geheimnisse?
Im SecretBench-Test der North Carolina State University erzielte Gitleaks mit 88 Prozent den höchsten Recall, allerdings bei nur 46 Prozent Precision. TruffleHog lag bei 52 Prozent Recall mit mittlerer Precision.
Kann ich mehrere dieser Tools gleichzeitig einsetzen?
Ja, und laut der geringen Funde-Überschneidung von teils nur 18 Prozent zwischen den Tools ist das sogar sinnvoll. Viele Teams kombinieren Gitleaks als schnellen Pre-Commit-Filter mit TruffleHog für verifizierte Historien-Scans.
Wie lange dauert es im Schnitt, bis ein auf GitHub geleakter Schlüssel entfernt wird?
Laut Verizon DBIR 2025 liegt die mediane Zeit bis zur Bereinigung bei 94 Tagen, in dieser Zeit bleibt der Schlüssel in der Regel aktiv nutzbar.
Sind geleakte Secrets wirklich eine Ursache für Supply-Chain-Angriffe?
Ja, der Vorfall rund um tj-actions/changed-files im März 2025 (CVE-2025-30066) zeigt das direkt: Ein gestohlenes Zugangstoken ermöglichte es Angreifern, eine weitverbreitete GitHub Action zu manipulieren und Secrets aus Tausenden Pipelines abzugreifen.
Welches Tool passt zu einem kleinen deutschen Unternehmen mit begrenztem Budget?
Die Kombination aus Gitleaks als Pre-Commit-Hook und der kostenlosen Open-Source-Version von TruffleHog für geplante Scans deckt den Großteil der Risiken ab, ohne dass ein individuelles Preisangebot eingeholt werden muss. Sobald Compliance-Nachweise gegenüber Behörden oder Kunden notwendig werden, lohnt sich der Wechsel zu einer dokumentierten Plattform wie GitGuardian.
Finden diese Tools auch Geheimnisse in privaten, nicht öffentlichen Repositories?
Ja, Gitleaks und TruffleHog scannen jedes Repository, auf das sie lokalen oder API-Zugriff erhalten, unabhängig von dessen Sichtbarkeit. GitGuardians kontinuierliches Monitoring öffentlicher Repositories ist dabei eine Zusatzfunktion und ersetzt nicht das Scannen der eigenen internen Projekte, das alle drei Tools ebenfalls unterstützen.
