Trufflehog regelmäßig in Pre-Commit-, CI/CD- und Repository-Scan-Prozesse integrieren und gefundene Secrets rotieren.
Bewertung v1.2, deterministisch berechnet. Bedrohungswert und Konfidenz sind getrennte Größen.Methodik
trufflehog — Find, verify, and analyze leaked credentials
Find, verify, and analyze leaked credentials · Sprache: Go · Topics: credentials, devsecops, dynamic-analysis, precommit, scanning, secret · ⭐ 26.061 Stars
SecBoard-Einordnung
Geleakte Zugangsdaten in Repositories können unbefugten Zugriff auf Systeme oder Dienste ermöglichen.
Realistisch schlimmster Fall: Nicht erkannte Zugangsdaten in Code können zur Kompromittierung der zugehörigen Konten oder Dienste führen; dies ist ein realistisches Risiko aus den Artikelfakten.
Betroffen
Entwickler und Organisationen, die Codebasen auf geleakte Zugangsdaten prüfen wollen.
Prüfen
3- ▸Defensiver Check 1: Testen, ob Pre-Commit- oder CI/CD-Prüfungen bekannte Dummy-Secrets erkennen und Builds blockieren.
- ▸Defensiver Check 2: Prüfen, ob gefundene Zugangsdaten zeitnah widerrufen oder rotiert werden.
▸ 1 weitere▾ weniger
- ▸Defensiver Check 3: Repository-Historie auf versehentlich eingecheckte Zugangsdaten prüfen.
Offene Punkte
3▸ anzeigen▾ ausblenden
- ▸Konkrete Secret-Typen sind nicht im Artikel angegeben.
- ▸Betroffene Repositories oder Organisationen sind nicht im Artikel angegeben.
- ▸IOCs und konkrete Vorfälle sind nicht im Artikel angegeben.
Erwähnte Akteure & Werkzeuge
Abgleich mit dem MITRE-ATT&CK-Katalog
MITRE ATT&CK(1)
Techniken aus allen Quellen zusammengeführt — nach Stärke des Belegs sortiert.
„Der Artikel beschreibt die Erkennung, Überprüfung und Analyse geleakter Zugangsdaten in Codebasen.“
Mehrere Herkünfte bei derselben Technik heißt: mehrere unabhängige Wege führen dorthin.
Quellen & Belege· 1 Quelle
Nutzer-/popularitaetsgetriebene Sammlung, Zuverlaessigkeit je Beitrag verschieden.
- Nur eine Quelle — der Sachverhalt ist an keiner zweiten Stelle gegengelesen.