Secrets : Ein praktischer Leitfaden zum Aufspüren und Verhindern von gestohlenen Zugangsdaten

‍Secrets – API-Schlüssel, Passwörter, Zertifikate – sind das digitale Äquivalent zu Flüstern auf dem Spielplatz: Sie sind für einen vertrauenswürdigen Empfänger bestimmt, nicht für die Öffentlichkeit. In moderner Software secrets programmgesteuert verwendet, wodurch sie sowohl allgegenwärtig als auch anfällig sind. Unkontrolliert sind sie häufig der Ausgangspunkt für schwerwiegende Sicherheitsverletzungen. Dieser Leitfaden erklärt, wo secrets , warum ihre Erkennung schwieriger ist, als es scheint, was eine gute Erkennung tatsächlich bewirkt und wie Sie sie einsetzen können, um versehentliche Verluste zu verhindern, bevor sie zu Vorfällen werden.

Was gilt in der Softwarebranche als „Geheimnis“?

Ein Geheimnis ist jede Art von Zugangsdaten, die Zugriff auf Systeme oder Dienste gewähren: API-Schlüssel, Datenbankpasswörter, OAuth-Token, SSH-Schlüssel, TLS-Zertifikate und Ähnliches. Da secrets programmgesteuert verwendet secrets , durchlaufen sie Quellcode, CI-Pipelines, Entwicklerrechner und Backups – wodurch eine große Angriffsfläche entsteht.

Wie secrets durchgesickert werden

Einer der häufigsten Vektoren für Datenlecks ist die Versionskontrollhistorie. Das typische Szenario:

1. Ein Entwickler erstellt einen Feature-Zweig und codiert eine Anmeldeinformation fest, um etwas schnell zu testen.
2. Nach der Überprüfung ersetzen sie die Anmeldeinformationen durch eine Umgebungsvariable oder einen Vault-Aufruf und senden die Änderungen zur Überprüfung.
3. Bei der Codeüberprüfung wird nur der aktuelle Diff betrachtet; das temporäre Geheimnis bleibt im Branch oder Commit-Verlauf verborgen.

Sofern Sie die Git-Historie nicht überschreiben (was störend und riskant ist), bleibt dieses Geheimnis bestehen. Wenn ein Angreifer Zugriff auf Ihr Repository erhält – selbst auf ein privates –, kann er die Historie scannen und Zugangsdaten sammeln, um sich Zugang zu höherwertigen Zielen zu verschaffen.

Wie weit verbreitet ist das Problem?

Öffentliche Untersuchungen zeigen, dass dies keineswegs selten ist. Groß angelegte Scans von GitHub haben Millionen offengelegter secrets eine überraschend hohe Prävalenz selbst in privaten Repositorys aufgedeckt. Tatsächliche Sicherheitsverletzungen belegen das Risiko: Durchgesickerte Quellcode-Dumps haben Tausende von Anmeldedaten offenbart, darunter Cloud-Token und Zahlungsschlüssel.

Warum SAST nicht ausreicht

Statische Anwendungssicherheitstests SAST) eignen sich hervorragend, um Dinge wie SQL-Injection oder Pfadüberquerung in der aktuellen Codebasis zu finden, aber sie scannen in der Regel den letzten Snapshot und nicht die gesamte Commit-Historie. Secrets anders: Ein Geheimnis in einem Commit, Branch oder Tag ist ein Kompromittierungsrisiko. Das bedeutet, dass die Erkennung die gesamte Historie und mehrere Repositorys, in denen diese Historie gespeichert ist, berücksichtigen muss.

Warum secrets schwieriger ist als „nur reguläre Ausdrücke“

Auf den ersten Blick könnte man meinen: Schreibe eine reguläre Ausdrucksfolge für „API_KEY=“ und fertig. In Wirklichkeit muss secrets ein Gleichgewicht zwischen Präzision und Wiederauffindbarkeit finden, damit Entwickler nicht in einer Flut von Informationen untergehen:

• Strings mit hoher Entropie (zufällig aussehende Werte) sind oft secrets aber nicht immer. Viele nicht geheime Artefakte weisen ebenfalls eine hohe Entropie auf.
• Platzhalter und Beispiele sind in Codebasen weit verbreitet. Das naive Markieren aller ähnlich aussehenden Schlüssel führt zu Fehlalarmen, die Arbeitsabläufe unterbrechen.
• Die Muster der Anbieter variieren. Einige Dienste (Stripe, AWS, Twilio) verwenden identifizierbare Präfixe oder Formate, andere nicht.

Wie secrets gute secrets aussieht

Eine effektive Lösung secrets nutzt mehrere Signale, um Fehlalarme zu reduzieren und echte Lecks aufzudecken:

• Musterabgleich für bekannte Anbieter. Identifizieren Sie Schlüssel, die anbieterspezifischen Formaten entsprechen (z. B. Stripe-Präfixe, AWS-Token-Formate).
• Validierung, wo möglich. Versuchen Sie eine zerstörungsfreie Validierung (existiert dieser AWS-Schlüssel? Ist er aktiv?), um zu bestätigen, ob ein Befund echt ist.
• Entropie + Kontext. Verwenden Sie Entropiemessungen, um Zeichenfolgen mit hoher Zufälligkeit zu finden, und überprüfen Sie dann den umgebenden Code (Dateipfad, Variablennamen, Kommentare), um zu entscheiden, ob es sich um ein Geheimnis handelt.
• Anti-Wörterbuch-Prüfungen. Filtern Sie Zeichenfolgen heraus, die englische Wörter oder offensichtliche Platzhalter enthalten, um Störsignale zu reduzieren.
• Geschichtsbewusstes Scannen. Scannen Sie die gesamte Git-Historie über Branches, Tags und Mirrors hinweg – nicht nur die Spitze von main.
• Entwickelnde Bereitstellung. Führen Sie Erkennungen sowohl remote (zentrale Repositorys) als auch lokal (Pre-Commit-Hooks, IDE-Plugins) durch, um Lecks früher im Workflow zu stoppen.

Testen eines Tools secrets (und der üblichen Fallstricke)

Bei der Bewertung von Tools führen Teams oft einen einfachen Test durch: Sie programmieren offensichtliche, geheimnisvoll aussehende Zeichenfolgen fest ein und erwarten, dass der Scanner diese erkennt. Ironischerweise kann ein Tool, das jedes offensichtliche falsche Geheimnis markiert, von geringer Qualität sein – es sind die lautstarken Tools, die in naiven Tests am besten abschneiden.

Gute Tools ignorieren absichtlich triviale, nicht reale Muster und Platzhalterwerte. Sie priorisieren die Validierung verdächtiger Ergebnisse, anstatt bei jeder zufälligen Zeichenfolge Alarm zu schlagen.

So testen Sie richtig:

1. 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.
2. Führen Sie das Tool nicht nur für neue gefälschte Schlüssel in aktuellen Dateien aus, sondern auch für historische Zweige und vergessene Commits.
3. Messung der Falsch-Positiv-Rate und des Validierungserfolgs: Kann das Tool Störsignale reduzieren und gleichzeitig echte, verwertbare secrets aufdecken?

Wo soll secrets eingesetzt werden?

Die Erkennung erfolgt auf mehreren Ebenen:

• Remote-Git-Repositorys (obligatorisch). Ihr zentrales Git-Hosting ist die kanonische Quelle der Wahrheit: Scannen Sie alle Repositorys und die gesamte Historie. Alle hier vorhandenen Geheimnisse sollten als kompromittiert behandelt werden.

• Entwickelnde Umgebung (dringend empfohlen). Verwenden Sie Pre-Commit-Hooks und IDE- oder Editor-Erweiterungen, um secrets abzufangen, secrets sie überhaupt einen Push erreichen. Lokales Feedback vermeidet Unruhe und gibt Entwicklern die Kontrolle.
• CI/CD-Pipelines. Fügen Sie Prüfungen hinzu, um Merges oder Bereitstellungen zu blockieren, wenn ein validiertes Geheimnis gefunden wird, und stellen Sie gleichzeitig sicher, dass die Regeln Fehlalarme minimieren, die die Entwicklung blockieren.

„Wenn ein Geheimnis seinen Weg in [Ihr Remote-Repository] findet, müssen Sie davon ausgehen, dass es kompromittiert ist.“

Checkliste für schnelle Abhilfe, wenn Sie ein durchgesickertes Geheimnis entdecken

1. Drehen Sie das Geheimnis sofort (drehen Sie Anmeldedaten, widerrufen Sie Tokens).
2. Umfang bewerten: Auf welche Systeme konnte mit dem Schlüssel zugegriffen werden?
3. Entfernen Sie das Geheimnis aus allen Commits und Branches – erwägen Sie, die Historie nur dann zu überschreiben, wenn dies für Ihren Workflow notwendig und akzeptabel ist.
4. Überprüfen Sie andere Repositorys oder Backups auf ähnliche Lecks.
5. Verbessern Sie die Arbeitsabläufe und Tools für Entwickler, um Wiederholungen zu vermeiden (IDE-Plugins, Pre-Commit-Hooks, Einführung von Vault).

Zusammenfassung: Das Wesentliche

• Secrets in der modernen Entwicklung allgegenwärtig und finden sich oft in der Git-Historie.
• SAST , die nur die Spitze des Baums scannen, reichen für secrets nicht aus.
• Eine gute Erkennung kombiniert Anbieter-Muster, Validierung, Entropie-/Kontextanalyse und Anti-Wörterbuch-Filter, um Störsignale zu reduzieren.
• Setzen Sie die Erkennung sowohl zentral (Remote-Repositorys) als auch lokal (IDE/Hooks) ein, um Lecks frühzeitig zu erkennen und ein Katz-und-Maus-Spiel zu vermeiden.
• Testen Sie Scanner verantwortungsbewusst mit Honeytokens und historischen Scans anstelle von trivialen gefälschten Schlüsseln.

Das Aufspüren secrets ein fortwährendes Problem, bei dem Entwickler an erster Stelle stehen. Mit der richtigen Mischung aus Signalen und Platzierung können Sie das Risiko drastisch reduzieren, ohne Entwickler mit Fehlalarmen zu überhäufen. Beginnen Sie damit, Ihren Git-Verlauf zu scannen, fügen Sie lokale Schutzmaßnahmen hinzu und machen Sie die Validierung zu einer Kernfunktion jeder von Ihnen gewählten Lösung secrets . Probieren Sie Aikido noch heute aus!