Das Erste, was die meisten Leute tun, wenn sie ein Secrets detection Tool ausprobieren, ist Folgendes:
AWS_SECRET_KEY = "FAKEAWSSECRETKEY123456"
PASSWORD = "password123"Sie führen den Scan aus, nichts wird markiert, und die unmittelbare Reaktion ist so etwas wie:
“Was für ein nutzloses Tool. Das hätte mein Hund auch gefunden.”
Es scheint so offensichtlich. Das Finden von Secrets ist doch der einfachste Teil der Sicherheit, oder? Suchen Sie einfach nach password=, fügen Sie ein paar Regexes hinzu und fertig. Wie schwer kann das sein?
Und in gewisser Weise haben Sie Recht. Strings zu finden, die wie Secrets aussehen, ist einfach. Echte Secrets zu finden, ohne in Fehlalarmen zu versinken, ist der schwierige Teil.
Lassen Sie uns durchgehen, warum Tests schwieriger sind, als es scheint, warum die schlechtesten Lösungen oft wie die besten aussehen und wie Sie diese Tools tatsächlich bewerten sollten.
Wie Secrets Detection funktioniert
Es gibt zwei Hauptansätze zur Erkennung von Secrets: regelbasiertes Musterabgleich und Entropie-Statistiken.
Regelbasierte Erkennung stützt sich auf reguläre Ausdrücke, um Secrets mit einer definierten Struktur zu identifizieren. AWS-Schlüssel sind ein klassisches Beispiel. Sie beginnen immer mit demselben Präfix und haben eine feste Länge, sodass ein Regex wie dieser sie erfassen wird:
AKIA[0-9A-Z]{16}
Es fühlt sich mächtig an, wenn man sieht, wie es einen Schlüssel im Code markiert. Bis man merkt, dass es auch jeden Platzhalter markiert, der so aussieht.
AWS_ACCESS_KEY_ID="AKIA1234567890123456"
Nicht so schlimm für einen Schlüssel, aber führt man Tausende von Regeln ein, wird es schnell sehr unübersichtlich. Regex ist nützlich, kann aber echte Schlüssel nicht von Dummy-Schlüsseln trennen, und man landet in einem fragilen, unübersichtlichen Chaos.
Filtern mit Secret Validation
Eine der besten Methoden, um Fehlalarme zu reduzieren, ist die Validierung von Secrets nach der Erkennung. Dies bedeutet in der Regel, einen sicheren API-Aufruf zu tätigen. Zum Beispiel kann ein AWS-Schlüssel getestet werden mit:
aws sts get-caller-identity --access-key <KEY> --secret-key <SECRET>
Ist der Aufruf erfolgreich, haben Sie einen aktiven Schlüssel. Schlägt er fehl, können Sie den Alarm sicher herabstufen.
Das ist großartig, denn Sie können ein sehr weites Netz auswerfen und es später eingrenzen. Aber hier liegt der Knackpunkt: Wenn Sie ein Tool testen, pushen Sie keine echten AWS-Schlüssel auf GitHub. Sie verwenden gefälschte. Ein Tool, das Schlüssel validiert, wird diese als ungültig verwerfen und Ihnen null Ergebnisse anzeigen. Währenddessen sieht das weniger anspruchsvolle Tool, das alles markiert, so aus, als würde es besser funktionieren.
Filtern mit Entropie-Statistiken
Ich denke, hier müssen wir schnell erklären, was Entropie bedeutet. Strings mit hoher Entropie beziehen sich auf Strings mit einem hohen Maß an Zufälligkeit; mehr Zufälligkeit = mehr Entropie.
Die meisten Secrets können nicht validiert werden, daher verlassen sich Tools auf andere Methoden, um Rauschen zu reduzieren. Entropie-Statistiken sind eine der effektivsten.
Die Idee ist einfach: Echte Secrets sehen zufällig aus. Platzhalter nicht. Betrachten Sie diesen gefälschten Stripe-Schlüssel:
StripeKey = "SK_123456789"
Er entspricht dem Regex, ist aber nicht zufällig genug, um echt zu sein. Ein echter Schlüssel hat eine viel höhere Entropie, etwas, das Menschen sehr schlecht fälschen können.
Die Filterung nach englischen Wörtern hilft ebenfalls. Echte API-Schlüssel enthalten fast nie lesbare Wörter. Wenn Sie so etwas sehen wie:
TEST823hufb934
können Sie ziemlich sicher sein, dass es sich um einen Platzhalter oder ein Test-Credential handelt. Gute Tools stufen Strings herab oder ignorieren sie, die hohe Entropie mit offensichtlichen Wörterbuchwörtern wie TEST, PASSWORD oder DEMO mischen. Dies führt oft zu Problemen beim Testen, da es für Menschen tatsächlich sehr schwierig ist, Entropie zu fälschen; wir folgen beim Tippen natürlich Mustern, auch wenn wir uns dessen nicht bewusst sind.
Leider ist dies auch nicht immer so einfach, während API-Schlüssel Strings mit hoher Entropie sind. UUIDs, Hashes und Dateinamen sind ebenfalls Strings mit hoher Entropie und keine Secrets. Es ist dann wichtig, auch Kontext um das Secret einzuführen. Die besten Lösungen kombinieren Entropie, Kontext und Wortfilterung. Dies führt jedoch zu Problemen beim Testen, denn wenn Sie gefälschte Credentials hinzufügen, die nicht zum Inhalt passen, in dem sie sich befinden, werden sie ebenfalls ignoriert.
Warum die schlechtesten Tools die besten aussehen
Das ist das Paradoxon. Die schlechtesten Lösungen, die bei jedem verdächtig aussehenden String Alarm schlagen, glänzen in schnellen Tests. Sie fangen Ihre Dummy-Schlüssel und Passwörter bereitwillig ab. Die intelligenteren Tools wirken fehlerhaft, weil sie Ihre Fälschungen stillschweigend ignorieren.
Wenn Sie nicht mit realistischen Daten testen, loben Sie am Ende das laute Tool und verwerfen dasjenige, das in der Produktion tatsächlich helfen würde.
So testen Sie Secrets detection richtig
Wenn Sie eine faire Bewertung wünschen, benötigen Sie bessere Testdaten.
Eine Option sind Honey Tokens. Dienste wie CanaryTokens ermöglichen es Ihnen, harmlose, aber realistische Credentials zu generieren. Ein gutes Tool sollte diese sofort erkennen.
Ein weiterer Ansatz ist es, echte Schlüssel ohne Berechtigungen zu erstellen, Ihre Tests durchzuführen und sie danach zu widerrufen. Dies liefert Ihnen sichere, aber gültige Eingaben, die die Validierungslogik auslösen.
Die beste Methode ist jedoch, das Tool auf realen Codebasen auszuführen. Secrets sind in Repositories weit verbreitet, insbesondere tief in der Commit-Historie. Das Scannen tatsächlicher Projekte zeigt, wie sich ein Tool unter realistischen Bedingungen verhält, und liefert einen vertrauenswürdigen Benchmark.
Was ein gutes Tool zur Secrets detection ausmacht
Ein leistungsstarkes Tool zur Secrets detection sollte all das Folgende leisten:
- Secrets wo möglich validieren
Echte Secrets mit sicheren API-Aufrufen bestätigen, wenn Anbieter dies zulassen. - Spezifische Secret-Muster unterstützen
Strukturierte Schlüssel wie AWS, Stripe und Twilio mithilfe von Regex- oder Musterregeln erkennen. - Generische Secrets mit Entropie und Kontext behandeln
Zufälligkeitsbewertung plus umgebende Codeanalyse nutzen, um Secrets ohne feste Muster zu erkennen. - Gefälschte oder Test-Anmeldeinformationen herausfiltern
Schlüssel, die offensichtliche Wörterbuchwörter wie TEST oder PASSWORD enthalten, herabstufen. - Eine breite Palette von Secret-Typen abdecken
Über API-Schlüssel hinaus auch Zertifikate, SSH-Schlüssel, Datenbankpasswörter und mehr einschließen. - Lecks verhindern, bevor sie entstehen
Pre-Commit-Hooks oder IDE-Integrationen bereitstellen, um zu verhindern, dass Secrets jemals in die Versionskontrolle gelangen. - Skalierung über Repositories und Pipelines hinweg
Effektiv in CI/CD, über Historien hinweg und im Unternehmensmaßstab arbeiten.
Zusammenfassung
Secrets detection sieht einfach aus, aber das Testen ist alles andere als das. Die rauschenden Tools, die jedes gefälschte Secret markieren, können beeindruckend wirken, während die intelligenteren Tools, die validieren und filtern, den Anschein erwecken, weniger zu tun.
Wenn Sie richtig testen möchten, verwenden Sie Honey Tokens, Schlüssel mit eingeschränktem Zugriff oder echte Repositories. Achten Sie bei der Evaluierung auf die Eigenschaften, die in der Produktion zählen: Validierung, Mustererkennung, Entropieanalyse, Wörterbuchfilterung, breite Abdeckung und vor allem Prävention vor dem Commit.
Denn der gefälschte AWS-Schlüssel, den Sie für Testzwecke platziert haben, ist nicht gefährlich. Der echte, der sich offensichtlich versteckt, ist es.
