BrassCoders entdeckte hartcodierte Geheimnisse in zwei der fünfzehn untersuchten KI-generierten Python-Skripte, was ein konkretes Risiko für Entwickler darstellt, die Code direkt aus den Ausgaben großer Sprachmodelle kopieren und einfügen. Die Ergebnisse zeigen, dass ein einziger falsch platzierter Schlüssel oder ein Passwort ein hilfreiches Code-Snippet in ein Credential-Leak über Versionskontrollen und Produktionsumgebungen hinweg verwandeln kann.

Was der Test enthüllte

Das erste Skript, token_check.py, wurde durch einen Prompt erstellt, der nach einer Funktion zur Signierung von Session-Token fragte und ein „nutzbares Beispiel“ enthalten sollte. Um den Code ausführbar zu machen, fügte das Modell einen HMAC-Signaturschlüssel direkt als Literal in die Quelldatei ein.

  • Problem: Der geheime Schlüssel befindet sich direkt in der Codebase.
  • Risiko: Jeder mit Lesezugriff auf das Repository kann den Schlüssel sehen, und jedes Deployment, das die Datei abruft, übernimmt das Geheimnis.
  • Konsequenz: Ein Angreifer, der den Schlüssel erlangt, kann gültige Session-Token fälschen und so Authentifizierungsprüfungen umgehen.

Das zweite Skript, email_sender.py, beantwortete eine Anfrage nach einer Funktion, die E-Mails via SMTP versendet. Auch hier lieferte das Modell ein Passwort als Literal, damit das Beispiel sofort einsatzbereit ist.

  • Problem: Das Passwort erscheint als Klartext-String im Funktionsaufruf.
  • Risiko: Die Rotation des Passworts erfordert eine Code-Änderung und ein neues Deployment, zudem verbreitet sich die Anmeldeinformation in jeder Umgebung, die die Datei nutzt.
  • Konsequenz: Das Passwort kann aus der Versionskontrolle, aus Logs oder aus kompilierten Paketen extrahiert werden, was einem Angreifer unbefugten Zugriff auf den Mailserver ermöglicht.

Warum KI Geheimnisse ausgibt

Große Sprachmodelle generieren Text, indem sie den Prompt vervollständigen. Wenn ein Benutzer nach einem „nutzbaren Beispiel“ fragt, interpretiert das Modell dies als „Code, der ohne zusätzliche Einrichtung läuft“. Daher füllt es fehlende Werte – API-Schlüssel, Passwörter, Token – mit plausiblen Platzhaltern auf. Das Modell hat kein Bewusstsein für Best Practices im Geheimnismanagement, sofern der Prompt diese nicht explizit erwähnt.

Eine aktuelle Analyse von Veracode zu KI-generiertem Code ergab, dass 45 % der Snippets mindestens eine in den OWASP Top 10 aufgeführte Schwachstelle enthalten, wobei die Offenlegung von Anmeldeinformationen einen beträchtlichen Anteil ausmacht. Diese Statistik unterstreicht, dass das Problem nicht auf wenige Ausreißer beschränkt ist; es ist ein systemisches Nebenprodukt der Art und Weise, wie diese Modelle trainiert und abgefragt werden.

Maßnahmen zur Risikominderung, die Entwickler jetzt ergreifen können

Die einfachste Verteidigung besteht darin, jegliche Geheimnisse aus der Code-Datei selbst fernzuhalten. Umgebungsvariablen sind die gängigste, sprachunabhängige Methode:

# token_check.py – secure version
import os
import hmac
import hashlib

SECRET_KEY = os.environ["HMAC_SECRET_KEY"]

def sign_token(data: bytes) -> str:
    return hmac.new(SECRET_KEY.encode(), data, hashlib.sha256).hexdigest()

# email_sender.py – secure version
import os
import smtplib

smtp_password = os.environ["SMTP_PASSWORD"]
server = smtplib.SMTP("smtp.example.com", 587)
server.starttls()
server.login("noreply@example.com", smtp_password)

Die Verwendung von os.environ ruft den Wert aus der Laufzeitumgebung ab, hält ihn so aus der Versionskontrolle heraus und ermöglicht eine Rotation, ohne die Quelldateien ändern zu müssen. Dasselbe Prinzip funktioniert mit Konfigurationsdateien, die von Commits ausgeschlossen werden, mit Secret-Management-Diensten oder mit Container-orchestrierten Geheimnissen.

Zusätzliche Schutzmaßnahmen

  • Code-Reviews, die auf Literal-Strings achten, die gängigen Geheimnis-Mustern entsprechen (z. B. lange alphanumerische Sequenzen).
  • Statische Analyse-Tools, die darauf abgestimmt sind, hartcodierte Anmeldeinformationen in neu hinzugefügten Dateien zu erkennen.
  • Prompt Engineering: Fragen Sie das Modell explizit, „Umgebungsvariablen für alle Geheimnisse zu verwenden“ oder „echte Anmeldeinformationen wegzulassen“.
  • Linting nach der Generierung: Führen Sie ein kurzes Skript aus, das nach verdächtigen Literalen sucht, bevor Sie den Code in ein Projekt kopieren.

Gegenargument: Bedeutet das, dass KI-Code unsicher ist?

Das Vorhandensein von hartcodierten Geheimnissen bedeutet nicht, dass KI-generierter Code universell unsicher ist. In vielen Fällen produziert das Modell saubere, gut strukturierte Logik, die die Entwicklung beschleunigen kann. Das Risiko entsteht, wenn Entwickler den Output als produktionsreif behandeln, ohne ein Sicherheitsaudit durchzuführen. Betrachten Sie die KI als Entwurfsassistenten, nicht als Ersatz für etablierte Sicherheitspraktiken.

Worauf man als Nächstes achten sollte

  • Tooling-Updates: KI-Plattformen beginnen damit, Sicherheitsfilter zu integrieren, die Geheimnisse durch Platzhalter ersetzen. Die Überwachung dieser Änderungen kann das Risiko verringern.
  • Richtlinienänderungen: Unternehmen könnten Richtlinien für KI-gestütztes Coding formalisieren und Geheimnismanagement-Prüfungen als Teil der CI-Pipeline vorschreiben.
  • Community-Muster: Da Entwickler mehr „sichere Prompts“ teilen, könnten Best-Practice-Vorlagen zum Standard-Output für häufige Aufgaben wie die Signierung von Token oder den E-Mail-Versand werden.

Fazit: KI kann in Sekundenschnelle funktionalen Code erstellen, aber wenn Entwickler keine Disziplin beim Secret-Management an den Tag legen, hat die Bequemlichkeit einen versteckten Preis – offengelegte Zugangsdaten, die ein gesamtes System gefährden können. Betrachten Sie jedes Snippet als Entwurf, entfernen Sie alle hartcodierten Geheimnisse und injizieren Sie diese über Umgebungsvariablen oder einen dedizierten Vault, bevor Sie den Code committen.