Secrets in KI-gestütztem Code: Entscheidend ist, wie lange sie gültig bleiben

KI-gestützter Code hat 2025 im Jahresmittel ungefähr doppelt so oft Secrets geleakt wie der Durchschnitt aller öffentlichen GitHub-Commits, so steht es im Report „State of Secrets Sprawl 2026“ von GitGuardian. Schulungen zum Cybersecurity Awareness Month setzen vor dem Commit an. Wie groß der Schaden nach einem Leak wird, hängt aber davon ab, wie lange das Secret gültig bleibt, und dazu enthält derselbe Report die deutlichere Zahl: Fast zwei Drittel der gültigen Secrets, die 2022 geleakt wurden, sind 2026 noch nicht widerrufen. Die Absicherung, die nach einem Leak greift, gehört deshalb in Architektur und Pipeline, besonders in Microservice-Landschaften, in denen Coding-Agenten mitschreiben.

Was der Report über KI-gestützten Code sagt

GitGuardian hat für den am 17. März 2026 veröffentlichten Report öffentliche GitHub-Commits aus dem Jahr 2025 ausgewertet und rund 29 Millionen Secrets gefunden, 34 Prozent mehr neu geleakte Secrets als im Vorjahr. Zum KI-Anteil schreibt GitGuardian: „Secret leak rates in AI-assisted code were, on average across the year, roughly double the GitHub-wide baseline.“ Für Commits mit Claude Code nennt der Report eine Quote von 3,2 Prozent gegenüber 1,5 Prozent über alle öffentlichen Commits.

Zwei Einschränkungen gehören zu diesen Zahlen. Die Vergleichsbasis ist der Durchschnitt aller öffentlichen Commits, in dem KI-gestützter Code bereits enthalten ist, also kein Vergleich mit rein menschlich geschriebenem Code. Und die KI-Werte stammen aus öffentlichen Repositories, für interne Repositories nennt der Report keine entsprechende Quote.

Warum ein Leak mit dem Löschen nicht erledigt ist

Ein Secret, das einmal committet wurde, verschwindet nicht, wenn jemand es im nächsten Commit entfernt. Es bleibt erhalten:

• in der Git-Historie, auch wenn ein späterer Commit die Datei bereinigt
• in Forks und Klonen, die diesen Stand enthalten
• in CI-Caches und Build-Artefakten aus den Läufen dazwischen
• in Container-Images, wenn die Datei beim Build ins Image kopiert wurde

Solange das Secret beim ausstellenden System gültig ist, kann es jeder benutzen, der Zugriff auf eine dieser Kopien hat. Das betrifft nicht nur öffentlichen Code: Interne Repositories enthalten laut GitGuardian rund sechsmal wahrscheinlicher hartcodierte Secrets als öffentliche.

GitGuardian beschreibt, woran der Widerruf scheitert: „64% of valid secrets from 2022 are still not revoked in 2026, most often because security teams lack the governance needed to achieve a viable, repeatable remediation path for any leaked secret.“

Was sich mit Microservices und Coding-Agenten ändert

In einem Monolithen gibt es eine überschaubare Zahl von Zugangsdaten. In einer Microservice-Architektur braucht jeder Service eigene Credentials für seine Datenbank, den Message Broker, externe APIs und oft für die Nachbarservices. Mit jedem Service kommen damit neue Stellen dazu, an denen ein Secret landen kann:

• Konfigurationsdateien und Helm Values, die es pro Service gibt und die oft mit im Repository liegen
• Pipeline-Variablen, die für jeden Service gepflegt und bei jeder Rotation einzeln aktualisiert werden müssen
• lokale .env-Dateien, die Coding-Agenten als Kontext lesen und deren Werte so in generierten Code, Testfixtures oder Beispielkonfigurationen wandern können
• MCP-Konfigurationen (Model Context Protocol), über die Agenten an Werkzeuge angebunden werden

Bei den MCP-Konfigurationen beginnt das Problem laut GitGuardian schon in der Dokumentation, denn viele MCP-Server empfehlen dort, Zugangsdaten direkt in die Datei einzutragen. In den untersuchten Konfigurationen fanden sich 24.008 eindeutige Secrets. Auch die Zugangsdaten zu KI-Diensten selbst tauchen häufiger in Leaks auf, laut Report 81 Prozent mehr als im Vorjahr, insgesamt 1.275.105.

Store, Scanning und kurze Gültigkeit

Secrets kommen aus einem Store, nicht aus dem Repository

Liegen Zugangsdaten in einem Secret Store, gibt es in Kubernetes zwei verbreitete Wege, sie an die Anwendung zu bringen.

Weg 1, External Secrets Operator: Die Anwendung liest ihre Zugangsdaten wie bisher aus Umgebungsvariablen, am Code ändert sich nichts. Dafür liegt eine Kopie in etcd, der Datenbank von Kubernetes, und die ist nur geschützt, wenn die etcd-Verschlüsselung eingeschaltet ist.

Weg 2, Secrets Store CSI Driver: Die Werte kommen als Dateien direkt in den Pod, standardmäßig ohne Kopie in etcd. Dafür muss die Anwendung Dateien lesen, was je nach Anwendung eine Code-Anpassung bedeutet.

Für Coding-Agenten gilt dasselbe, mit einer Ergänzung: Weil ein Agent die Umgebungsvariablen seines Prozesses lesen kann, bekommt er in der Entwicklung eigene Schlüssel mit eng begrenzten Rechten und keine Produktionswerte.

Scanning vor dem Push und vor dem Merge

Secret-Scanning wirkt in mehreren Stufen, von denen jede eine Lücke der vorigen schließt.

1. Pre-Commit-Hook: meldet Funde, bevor ein Commit entsteht. Er lässt sich aber mit --no-verify überspringen und läuft nur dort, wo er installiert ist.
2. Push Protection: lehnt den Push serverseitig ab, bevor das Secret im Remote liegt. Sie erkennt aber nur Secret-Muster, die der Plattform bekannt sind, und lässt sich je nach Plattform beim Push umgehen.
3. Merge-Gate in der CI/CD-Pipeline: prüft mit eigenen Regeln auch Muster, die die Push Protection nicht kennt, und fängt umgangene Pushes ab, bevor sie in den Hauptbranch gelangen. Ein Treffer hier muss trotzdem widerrufen werden, denn mit dem Push liegt das Secret schon auf dem Server.

Einmal muss außerdem die gesamte Historie gescannt werden, weil jedes neu eingeführte Gate nur neue Commits prüft.

Gültigkeit kurz halten

Weil kein Scanner jedes Leak abfängt, bestimmt die Gültigkeitsdauer, wie groß der Schaden wird. Ein Secret Store mit dynamischen Credentials, etwa Vault oder OpenBao, erzeugt bei jeder Anfrage eigene Datenbankzugänge und entzieht sie nach Ablauf der Lease. Anmelden kann sich der Service am Store mit einem explizit projizierten Service-Account-Token, das zeitlich begrenzt und an Pod und Audience gebunden ist, sodass kein statisches Token gespeichert werden muss. Die automatisch gemounteten Standard-Tokens taugen dafür weniger, weil der API-Server ihre Laufzeit aus Kompatibilitätsgründen verlängern kann.

Bleiben statische Schlüssel, etwa für externe APIs, muss die Rotation automatisiert laufen. Eine Rotation, die jemand von Hand anstoßen muss, skaliert nicht mit der Zahl der Services. Ein Teil dessen, was GitGuardian als fehlende Governance beschreibt, ist in Landschaften mit vielen Services genau dieser fehlende automatisierte Ablauf.

Fazit

KI-gestützter Code leakt laut GitGuardian häufiger Secrets, und Schulungen wirken vor dem Commit. Wie groß der Schaden nach einem Leak wird, entscheidet aber die Gültigkeitsdauer des Secrets, und die legen Architektur und Pipeline fest: Secrets aus einem Store statt aus dem Repository, Scanning vor Push und Merge, Zugangsdaten, die ablaufen oder automatisch rotiert werden. Prüfen Sie deshalb, wie lange es heute dauert, ein Secret zu widerrufen und überall zu ersetzen, wo es verwendet wird. Dauert das Tage, stellen Sie zuerst die Datenbankzugänge um. Vault und OpenBao bringen dafür eine Database Secrets Engine mit Plugins für gängige Datenbanken wie PostgreSQL und MySQL mit, die Zugänge pro Anfrage erzeugt und nach Ablauf der Lease wieder entzieht.