Warum ich einen KI-basierten Secrets-Detektor statt Regex entwickelte

Die meisten Tools zur Erkennung von Secrets in Code arbeiten nach demselben Prinzip: Sie durchsuchen den Quelltext nach vordefinierten Mustern wie AWS-Zugangsschlüsseln, GitHub-Tokens oder privaten Schlüsseln. Doch dieses Verfahren hat zwei fatale Schwachstellen – und genau dort entstehen die meisten Sicherheitslücken.

Ich habe einen maschinellen Detektor für Secrets entwickelt, der diese Lücken schließt. Warum die Kombination aus Regex und KI mehr Sicherheit bietet als jede Methode allein.

Die Grenzen klassischer Secrets-Scanner

Bevor ich eine eigene Lösung baute, analysierte ich die Schwächen etablierter Tools wie TruffleHog, detect-secrets und Gitleaks. Alle drei nutzen Regex, um bekannte Secret-Formate zu erkennen – doch sie scheitern aus zwei Gründen.

Problem 1: Die Regex-Lücke – Unbekannte Secrets bleiben unsichtbar

Regex-Scanner finden nur Secrets, die einem bekannten Muster entsprechen. Doch was passiert mit intern generierten Passwörtern oder API-Keys, die keine öffentliche Struktur haben?

Ein menschlicher Entwickler könnte etwa diese Zeilen schreiben:

DB_PASSWORD = "Tr0ub4dor&3"
INTERNAL_API_KEY = "prod-backend-service-key-2019"
SMTP_PASSWORD = "companyname_mail_2018!"

Kein Regex erfasst diese Strings zuverlässig. Studien zeigen, dass ein Großteil der in echten Sicherheitsvorfällen exponierten Zugangsdaten genau dieser Kategorie angehören: zufällig gewählte Passwörter oder interne Tokens, die nicht für die Erkennung durch Regex entworfen wurden.

Problem 2: Hohe Entropie führt zu False Positives

Manche Tools kompensieren die Regex-Lücke, indem sie nach hochgradig zufälligen Zeichenfolgen suchen – unter der Annahme, dass Secrets immer zufällig sein müssen. Doch diese Logik scheitert in der Praxis.

In jedem Code-Projekt finden sich hochgradig zufällige Strings, die keine Secrets sind:

• UUIDs wie 550e8400-e29b-41d4-a716-446655440000
• SHA-256-Hashes wie d8e8fca2dc0f896fd7cb4cb0031ba249
• Base64-kodierte Bilddaten wie iVBORw0KGgoAAAANSUhEUgAAAAEAA...
• Integritäts-Hashes aus package-lock.json-Dateien

In einem Node.js-Projekt kann ein reiner Entropie-Scanner tausende False Positives erzeugen – allein durch Hash-Werte aus Abhängigkeiten. Entwickler gewöhnen sich schnell daran, alle Warnungen zu ignorieren.

KI erkennt Secrets durch Kontext – nicht nur durch Muster

Der entscheidende Unterschied zwischen Regex-Scannern und einer KI-basierten Lösung liegt im Verständnis von Kontext. Ein menschlicher Sicherheitsingenieur kann sofort erkennen, ob ein String ein Secret ist – nicht durch das Muster allein, sondern durch die Umgebung, in der es steht.

Kann eine Maschine diese menschliche Fähigkeit nachahmen? Die Antwort lautet: Ja – mit einem Random-Forest-Klassifikator, der 26 Merkmale kombiniert, um zu entscheiden, ob ein String ein Secret ist.

Wie die KI den Kontext nutzt

Die KI analysiert nicht nur den Wert selbst, sondern auch:

• Die Entropie des Strings (wie zufällig ist er?)
• Die Zeichenverteilung (enthält er Sonderzeichen?)
• Den Variablennamen (ist es password, token oder hash?)

Besonders der Variablenname erwies sich als entscheidendes Merkmal. Ein String wie d8e8fca2dc0f896fd7cb4cb0031ba249 kann je nach Kontext entweder ein harmloser Hash oder ein Secret sein:

checksum = "d8e8fca2dc0f896fd7cb4cb0031ba249"  # Wahrscheinlich kein Secret
password = "d8e8fca2dc0f896fd7cb4cb0031ba249"  # Wahrscheinlich ein Secret

Die KI lernt, solche Unterschiede automatisch zu erkennen. Selbst ein zufällig gewähltes Passwort wie Tr0ub4dor&3 wird erkannt, weil der Name DB_PASSWORD auf ein Secret hindeutet.

Warum ein Random Forest – und keine neuronale KI?

Für die Klassifizierung von Secrets benötigte ich ein Modell, das:

• Schnell arbeitet (für Echtzeit-Analysen)
• Erklärbar ist (Entwickler sollen nachvollziehen können, warum etwas als Secret markiert wurde)
• Robust gegen Overfitting ist (da die Trainingsdaten begrenzt sind)

Ein Random Forest erfüllt diese Anforderungen besser als ein neuronales Netzwerk. Das Modell erreicht eine Genauigkeit von über 90 % und benötigt weniger Rechenleistung als ein Deep-Learning-Ansatz.

Die wichtigsten Merkmale im Überblick

Nach dem Training des Modells zeigte sich, dass einige Merkmale besonders wichtig sind:

• Variablenname-Risiko (0,28 von 1,0): Namen wie password, secret oder api_key sind starke Indikatoren.
• Entropie (0,22): Zu hohe Zufälligkeit deutet auf Secrets hin – aber nicht immer.
• Sonderzeichen (0,15): Secrets enthalten oft Sonderzeichen wie !, @ oder #.
• Länge (0,10): Lange, unstrukturierte Strings sind verdächtiger als kurze.

Diese Kombination ermöglicht es der KI, Secrets zu erkennen, die weder Regex noch reine Entropie-Analyse finden würden.

Die optimale Lösung: Regex + KI in Kombination

Mein Detektor nutzt kein entweder-oder-Prinzip, sondern eine zweistufige Erkennung:

1. Stufe 1 – Regex-Scanning: Bekannte Secret-Formate (AWS-Keys, GitHub-Tokens, JWTs) werden sofort erkannt.
2. Stufe 2 – KI-Klassifikation: Unbekannte Strings werden durch den Random Forest analysiert. Hier kommen die Kontextmerkmale wie Variablennamen und Entropie ins Spiel.

Diese Kombination reduziert False Positives deutlich und erhöht die Erkennungsrate für bisher übersehene Secrets.

Fazit: Die Zukunft der Secrets-Erkennung

Regex-Scanner bleiben ein mächtiges Werkzeug für bekannte Secret-Formate – doch sie können nicht alles abdecken. Eine KI-basierte Lösung füllt diese Lücken und erkennt auch intern generierte Passwörter, die keine klare Struktur aufweisen.

Die nächste Generation von Secrets-Detektoren wird wahrscheinlich eine Hybridlösung sein: ein Mix aus Regex, Entropie-Analyse und maschinellem Lernen. Entwickler sollten solche Tools nicht nur als Sicherheitsfeature, sondern als integralen Bestandteil ihrer CI/CD-Pipelines betrachten.

Denn eines ist sicher: Wo Regex endet, beginnt oft der gefährlichste Teil der Secrets-Exposition.