Secrets — API-Schlüssel, Passwörter, Zertifikate — sind das digitale Äquivalent von Flüstern auf dem Spielplatz: Sie sind für einen vertrauenswürdigen Empfänger bestimmt, nicht für die Öffentlichkeit. In moderner Software werden Secrets programmatisch verwendet, was sie sowohl allgegenwärtig als auch fragil macht. Bleiben sie unkontrolliert, sind sie häufig der Ausgangspunkt für größere Sicherheitsverletzungen. Dieser Leitfaden erklärt, wo Secrets lecken, warum ihre Erkennung schwieriger ist, als es scheint, was eine gute Erkennung tatsächlich leistet und wie man sie implementiert, um versehentliche Lecks zu stoppen, bevor sie zu Incidents werden.
Was gilt in Software als „Secret“?
Ein Secret ist jede Anmeldeinformation, die Zugriff auf Systeme oder Dienste gewährt: API-Schlüssel, Datenbankpasswörter, OAuth-Tokens, SSH-Schlüssel, TLS-Zertifikate und Ähnliches. Da Secrets programmatisch genutzt werden, durchlaufen sie Quellcode, CI-Pipelines, Entwickler-Maschinen und Backups – wodurch eine große Angriffsfläche entsteht.
Wie Secrets typischerweise lecken
Einer der häufigsten Leak-Vektoren ist die Versionskontrollhistorie. Das typische Szenario:
- Ein Entwickelnder erstellt einen Feature-Branch und hardcodiert eine Anmeldeinformation, um schnell etwas zu testen.
- Sobald dies verifiziert ist, ersetzen sie die Anmeldeinformation durch eine Umgebungsvariable oder einen Vault-Aufruf und pushen die Änderungen zur Überprüfung.
- Die Code-Review betrachtet nur den aktuellen Diff; das temporäre Secret bleibt in der Branch- oder Commit-Historie verborgen.
Sofern Sie die Git-Historie nicht umschreiben (was störend und riskant ist), bleibt dieses Secret bestehen. Erlangt ein Angreifer Zugriff auf Ihr Repository — selbst ein privates — kann er die Historie scannen und Anmeldeinformationen (Creds) sammeln, um sich zu höherwertigen Zielen vorzuarbeiten.
Wie verbreitet ist das Problem?
Öffentliche Studien zeigen, dass dies keineswegs selten ist. Groß angelegte Scans von GitHub offenbaren Millionen exponierter Secrets und eine überraschend hohe Prävalenz selbst in privaten Repositories. Tatsächliche Sicherheitsverletzungen belegen das Risiko: Geleakte Quellcode-Dumps haben Tausende von Anmeldeinformationen zutage gefördert, darunter Cloud-Tokens und Zahlungsschlüssel.
Warum SAST allein nicht ausreicht
Statische Anwendungssicherheitstests (SAST) eignen sich hervorragend, um Dinge wie SQL-Injection oder Path Traversal in der aktuellen Codebasis zu finden, aber sie scannen typischerweise den neuesten Snapshot, nicht die gesamte Commit-Historie. Secrets sind anders: Ein Secret in jedem Commit, Branch oder Tag stellt ein Kompromittierungsrisiko dar. Das bedeutet, dass die Erkennung die gesamte Historie und mehrere Repositories, in denen diese Historie existiert, berücksichtigen muss.
Warum Secrets Detection schwieriger ist als „nur Regex“
Auf den ersten Blick könnte man denken: Eine Regex für „API_KEY=“ schreiben und fertig. In Wirklichkeit muss Secrets detection Präzision und Recall ausbalancieren, um Entwickelnde nicht in Rauschen zu ertränken:
- High-Entropy-Strings (zufällig aussehende Werte) sind oft Secrets – aber nicht immer. Viele nicht-geheime Artefakte weisen ebenfalls eine hohe Entropie auf.
- Platzhalter und Beispiele durchziehen Codebasen. Ein naives Kennzeichnen jedes schlüsselähnlichen Elements führt zu Fehlalarmen, die Workflows stören.
- Provider-Muster variieren. Einige Dienste (Stripe, AWS, Twilio) verwenden identifizierbare Präfixe oder Formate; andere nicht.
Wie eine gute Secrets detection aussieht
Eine effektive Secrets detection-Lösung nutzt mehrere Signale, um Fehlalarme zu reduzieren und echte Leaks zu erkennen:
- Musterabgleich für bekannte Anbieter. Identifizieren Sie Schlüssel, die anbieterspezifischen Formaten folgen (z. B. Stripe-Präfixe, AWS-Token-Formate).
- Validierung, wo möglich. Versuchen Sie eine nicht-destruktive Validierung (existiert dieser AWS-Schlüssel? Ist er aktiv?), um zu bestätigen, ob ein Fund echt ist.
- Entropie + Kontext. Nutzen Sie Entropiemaße, um Strings mit hoher Zufälligkeit zu finden, und prüfen Sie dann den umgebenden Code (Dateipfad, Variablennamen, Kommentare), um zu entscheiden, ob es sich um ein Secret handelt.
- Anti-Dictionary-Checks. Filtern Sie Strings heraus, die englische Wörter oder offensichtliche Platzhalter enthalten, um das Rauschen zu reduzieren.
- History-aware Scanning. Scannen Sie die gesamte Git-Historie über Branches, Tags und Mirrors hinweg – nicht nur den aktuellen Stand des Main-Branches.
- Entwickelnden-zentrierte Bereitstellung. Führen Sie die Erkennung sowohl remote (zentrale Repos) als auch lokal (Pre-Commit-Hooks, IDE-Plugins) aus, um Leaks früher im Workflow zu stoppen.
Testen eines Secrets detection Tools (und die häufige Falle)
Bei der Evaluierung von Tools führen Teams oft einen einfachen Test durch: Sie hardcodieren offensichtliche Secret-ähnliche Strings und erwarten, dass der Scanner sie erkennt. Ironischerweise kann ein Tool, das jedes offensichtliche gefälschte Secret kennzeichnet, von geringer Qualität sein – es sind die rauschenden Tools, die in naiven Tests am besten aussehen.
Gute Tools ignorieren absichtlich triviale, nicht-reale Muster und Platzhalterwerte. Sie priorisieren die Validierung verdächtiger Funde, anstatt bei jedem zufälligen String Alarm zu schlagen.
Wie man richtig testet:
- Verwenden Sie Honeytokens / Canary Tokens – echte, risikoarme API-Schlüssel, die Sie kontrollieren – die Sie sicher veröffentlichen können, um die Erkennung und Alarmierung zu testen.
- Führen Sie das Tool gegen historische Branches und vergessene Commits aus, nicht nur gegen frische gefälschte Schlüssel in aktuellen Dateien.
- Messen Sie False-Positive-Rate und Validierungserfolg: Kann das Tool das Rauschen reduzieren und dabei immer noch echte, umsetzbare Secrets aufdecken?
Wo Secrets detection bereitgestellt werden sollte
Die Erkennung sollte auf mehreren Ebenen erfolgen:
- Remote Git-Repositories (obligatorisch). Ihr zentrales Git-Hosting ist die kanonische Quelle der Wahrheit: Scannen Sie alle Repositories und die gesamte Historie. Jedes hier vorhandene Secret sollte als kompromittiert betrachtet werden.
- Lokale Umgebung der Entwickelnden (dringend empfohlen). Nutzen Sie Pre-Commit-Hooks und IDE- oder Editor-Erweiterungen, um Secrets abzufangen, bevor sie jemals einen Push erreichen. Lokales Feedback vermeidet unnötigen Aufwand und gibt Entwickelnden Kontrolle.
- CI/CD-Pipelines. Fügen Sie Prüfungen hinzu, um Merges oder Deployments zu blockieren, wenn ein validiertes Secret gefunden wird, wobei sichergestellt wird, dass Regeln Fehlalarme minimieren, die die Entwicklung behindern.
“Wenn ein Secret in [Ihr Remote-Repository] gelangt, müssen Sie es als kompromittiert betrachten.”
Schnelle Checkliste zur Behebung, wenn Sie ein geleaktes Secret finden
- Rotieren Sie das Secret sofort (Anmeldeinformationen rotieren, Tokens widerrufen).
- Umfang bewerten: Welche Systeme waren mit dem Schlüssel zugänglich?
- Entfernen Sie das Secret aus allen Commits und Branches — erwägen Sie das Umschreiben der Historie nur, wenn dies für Ihren Workflow notwendig und akzeptabel ist.
- Prüfen Sie auf ähnliche Leaks in anderen Repositories oder Backups.
- Verbessern Sie die Workflows der Entwickelnden und die Tools, um ein Wiederauftreten zu verhindern (IDE-Plugins, Pre-Commit-Hooks, Einführung von Vaults).
Zusammenfassung: Das Wesentliche
- Secrets sind in der modernen Entwicklung allgegenwärtig und befinden sich oft in der Git-Historie.
- SAST-Tools, die nur die Spitze des Baumes scannen, reichen für die Secrets detection nicht aus.
- Eine gute Erkennung kombiniert Anbieter-Muster, Validierung, Entropie-/Kontextanalyse und Anti-Wörterbuch-Filter, um Rauschen zu reduzieren.
- Setzen Sie die Erkennung sowohl zentral (Remote-Repositories) als auch lokal (IDE/Hooks) ein, um Leaks frühzeitig zu erkennen und ein Katz-und-Maus-Spiel zu vermeiden.
- Testen Sie Scanner verantwortungsvoll mithilfe von Honeytokens und historischen Scans anstatt trivialer gefälschter Schlüssel.
Die Erkennung von Secrets ist ein kontinuierliches, Developer-First-Problem. Mit der richtigen Mischung aus Signalen und Platzierung können Sie das Risiko drastisch reduzieren, ohne Entwickelnde in Fehlalarmen zu ertränken. Beginnen Sie mit dem Scannen Ihrer Git-Historie, fügen Sie lokale Schutzmaßnahmen hinzu und machen Sie die Validierung zu einem Kernmerkmal jeder Secrets detection-Lösung, die Sie wählen. Testen Sie Aikido Security noch heute!
