Deine KI schreibt unsicheren Code — so hörst du auf, ihn zu deployen

Du vertraust deinem KI-Coding-Assistenten. Er schreibt saubere Funktionen, fängt Edge Cases ab, hinterlässt hilfreiche Kommentare. Der Code kompiliert, die Tests laufen durch, der Pull Request — ein Vorschlag, neuen Code ins Hauptprojekt zu mergen — bekommt einen Daumen hoch. Drei Monate später findet ein Pentester eine Lücke in einer Funktion, die dein Agent nachts um zwei geschrieben hat. Keiner hat es hinterfragt, weil es "gut aussah."

Das ist kein Gedankenexperiment. Das ist Dienstag.

Die Lücke zwischen Selbstvertrauen und Kompetenz

KI-generierter Code macht mittlerweile etwa 46 % des neuen Codes in vielen Unternehmen aus. Da kommst du nicht drum herum. Aber irgendwo zwischen "die KI hat's geschrieben" und "wir haben's ausgeliefert" hat sich eine gefährliche Annahme eingeschlichen: dass die Maschine weiß, was sie tut. Tut sie nicht. Sie ist eine extrem schnelle Tippse ohne jegliches Konzept von Angreifern.

Du brauchst ein Feldhandbuch. Hier ist deins.

Jeder vierte Schnipsel hat eine Lücke

Im Februar 2026 testete die Sicherheitsforschungsgruppe AppSecSanta sechs große LLMs — Large Language Models, die Gehirne hinter ChatGPT, Claude, Gemini und Konsorten — mit 89 sicherheitskritischen Coding-Prompts. Python und JavaScript. Praxisnahe Aufgaben, gemappt auf die OWASP Top 10 — die allgemein anerkannte Liste der kritischsten Sicherheitsrisiken für Webanwendungen.

Das Ergebnis: 25,1 % des generierten Codes enthielten bestätigte Sicherheitslücken. Jeder vierte Schnipsel. Deine KI produziert Bugs im Industriemaßstab — und das mit der gelassenen Selbstsicherheit von jemandem, der noch nie gehackt wurde.

Schwachstellenquoten nach Modell:

Modell	Schwachstellenquote
GPT-5.2	19,1 % (bester Wert)
Gemini 2.5 Pro	22,4 %
Grok 4	23,7 %
Claude Opus 4.6	29,2 %
DeepSeek V3	29,2 %
Llama 4 Maverick	29,2 %

Diese 10-Punkte-Spanne bedeutet: Deine Modellwahl ist relevant. Aber selbst das beste Modell liefert bei fast jedem fünften Output eine Schwachstelle mit. GPT-5.2 statt Llama 4 zu nehmen hilft. Retten wird es dich nicht.

Wo die Modelle am häufigsten versagen:

• SSRF (Server-Side Request Forgery — wenn dein Server dazu gebracht wird, im Auftrag eines Angreifers interne URLs aufzurufen): 32 Funde. Die mit Abstand größte Kategorie.
• Injection (SQL Injection, Command Injection — wenn Benutzereingaben sich in Datenbankabfragen oder Systembefehle einschleichen): 30 Funde, 33,1 % aller Probleme.
• Sicherheitsfehlkonfiguration: 25 Funde — hardcodierte Secrets, Debug-Modus in Produktion vergessen.
• Broken Access Control (Benutzer können Dinge tun, die sie nicht tun dürfen sollten): bei jedem getesteten Modell vorhanden.

Eine separate Help Net Security-Studie von März 2026 testete Claude Code, OpenAI Codex und Google Gemini im Agent-Modus — nicht nur Autocomplete, sondern vollautonom codierend. Die Agents produzierten 143 Sicherheitsprobleme in 38 Scans über 30 Pull Requests. 87 % dieser PRs enthielten mindestens eine Schwachstelle. Broken Access Control tauchte in der Ausgabe jedes einzelnen Agents auf. Jedes. Einzelnen.

Warum die Maschine unsicheren Code schreibt

Die Modelle sind nicht bösartig. Sie sind Wahrscheinlichkeitsmaschinen, trainiert auf GitHub — und GitHub ist voll mit unsicherem Code. Stack-Overflow-Antworten von 2015, die JWT-Secrets hardcoden (JWT — JSON Web Token, ein digitaler Ausweis, der beweist, dass du eingeloggt bist). Tutorial-Code, der Input-Validierung überspringt, weil "das hier nur eine Demo ist". Produktivcode von Firmen, die nie ein Security-Audit gemacht haben.

Drei Muster tauchen immer wieder auf:

1. Fehlende serverseitige Validierung. KI-Agents akzeptieren clientseitige Werte — Punktestände, Kontostände, Benutzerrollen — ohne sie auf dem Server zu verifizieren. Das Modell hat aus Tausenden Tutorials gelernt, die "Validierung als Übung für den Leser" übrig gelassen haben. Der Leser hat die Übung nie gemacht. Die KI auch nicht.

2. Unsichere Defaults. JWT-Tokens ohne Ablaufdatum. OAuth-Implementierungen (OAuth — ein Protokoll, das dir erlaubt, "Mit Google anmelden" zu nutzen, statt schon wieder ein neues Passwort zu erstellen) ohne den State-Parameter, der Hijacking verhindert. Refresh-Tokens, die nicht widerrufen werden können. Die Modelle generieren Code, der funktioniert, aber die faule Standardeinstellung wählt — nicht die sichere.

3. SSRF überall. Wenn ein Modell Code schreibt, der eine URL abruft, prüft es fast nie, wohin diese URL zeigt. Keine Allowlists, kein Blockieren interner IP-Adressen, keine Protokollbeschränkungen. Es ruft einfach requests.get(user_input) auf und liefert es aus. Ein Angreifer füttert es mit http://169.254.169.254/ und hat plötzlich deine Cloud-Zugangsdaten.

Dein Fünf-Schichten-Verteidigungsstack

Hör auf darauf zu warten, dass Modelle bei Security schlauer werden. Bau eine Pipeline — eine automatisierte Abfolge von Prüfungen —, die Probleme abfängt, egal wer oder was den Code geschrieben hat.

Schicht 1: Sicherheitsorientiertes Prompting

Der einfachste Fix kostet nichts. Eine Veracode-Studie ergab, dass ein generischer Sicherheitshinweis im Prompt die Rate sicheren Codes für Claude Opus 4.6 von 56 % auf 66 % verbesserte. Zehn Prozent Verbesserung durch einen einzigen Satz. Kein Wunder. Aber kostenlos.

Füg das zu deinem System Prompt, deinen Cursor Rules oder deiner CLAUDE.md hinzu:

When writing code: validate all inputs server-side. Never trust
client data. Use parameterized queries. Set secure defaults for
auth tokens (expiration, rotation). Block SSRF by validating URLs
against allowlists. Never hardcode secrets.

Für KI-Coding-Agents wie Claude Code, Codex oder Copilot im Agent-Modus: Pack diese Anweisungen in die Konfigurationsdateien deines Projekts. Der Agent liest sie bei jeder Aufgabe.

Schicht 2: SAST in deinem Editor

SAST — Static Application Security Testing — scannt deinen Code auf Schwachstellen, ohne ihn auszuführen. Wie eine Rechtschreibprüfung, nur für Sicherheitslücken. Die zentrale Erkenntnis von AppSecSanta: Nur ein SAST-Tool fand 78 % der KI-generierten Schwachstellen. Mehrere Scanner gleichzeitig zu nutzen verbessert die Abdeckung dramatisch.

Empfohlenes Setup:

• Semgrep — kostenlos, schnell, über 3.000 Regeln. Läuft in VS Code, JetBrains und CI. Fängt Injection, SSRF und hardcodierte Secrets ab.
• Bandit (Python) — erkennt häufige Python-Sicherheitsprobleme. Null Konfiguration nötig.
• ESLint Security Plugins (JavaScript) — eslint-plugin-security und eslint-plugin-no-unsanitized.

Installier Semgrep als Pre-Commit-Hook — ein Skript, das automatisch vor jedem Commit läuft und schlechten Code daran hindert, ins Repository zu gelangen:

pip install semgrep
semgrep --config auto --error .

Jetzt wird jeder Commit gescannt. Die KI schreibt den Code, Semgrep gibt ihm eine Ohrfeige, bevor du pushst.

Schicht 3: CI-Pipeline-Scanning

Dein Pre-Commit-Hook fängt das Offensichtliche ab. Deine CI-Pipeline — das automatisierte Build-und-Test-System, das beim Pushen läuft — sollte tiefergehende Analysen fahren:

# GitHub Actions Beispiel
- name: Semgrep SAST
  uses: semgrep/semgrep-action@v1
  with:
    config: >-
      p/owasp-top-ten
      p/cwe-top-25
      p/python-security
      p/javascript-security

- name: Dependency check
  uses: dependency-check/dependency-check-action@v1

Fokussier deine Regeln auf die Kategorien, bei denen KI am häufigsten versagt: SSRF (CWE-918), Injection (CWE-89, CWE-78), unsichere Deserialisierung (CWE-502 — wenn bösartige Daten in ausführbare Objekte entpackt werden) und Path Traversal (CWE-22 — wenn ein Angreifer ../../ nutzt, um aus einem Verzeichnis auszubrechen und Dateien zu lesen, die er nicht sehen sollte).

Schicht 4: Code Review durch Menschen — mit Security-Brille

Code Review für KI-generierten Code unterscheidet sich vom normalen Review. Du suchst nicht nach Logikfehlern — das kann die KI einigermaßen gut. Du suchst nach:

• Endpoints ohne Auth-Checks. Die KI schreibt den Route Handler, vergisst aber die Middleware — den Türsteher-Code, der prüft: "Darfst du hier überhaupt rein?"
• Benutzereingaben, die an gefährliche Stellen fließen. Datenbankabfragen, Dateioperationen, HTTP-Requests, Shell-Befehle. Wenn Benutzereingaben an irgendetwas davon ohne Sanitizing gelangen, hast du ein Problem.
• Fehlendes Rate Limiting. KI fügt nie Rate Limiting hinzu, es sei denn, du fragst explizit danach. Jeder öffentliche Endpoint braucht es — sonst hämmert jemand mit 10.000 Requests pro Sekunde drauf.
• Secrets im Code. Das Modell generiert manchmal Platzhalter-API-Keys, die echt genug aussehen, um ausgeliefert zu werden. Dann landen sie auf GitHub. Dann in den Händen von jemand anderem.

Bring deinem Team bei, bei jeder KI-generierten Funktion eine Frage zu stellen: "Was passiert, wenn der Input feindlich ist?"

Schicht 5: Die OpenSSF Rules File

Die OpenSSF — Open Source Security Foundation — hat einen standardisierten sicherheitsfokussierten Leitfaden für KI-Code-Assistenten-Anweisungen veröffentlicht. Eine Rules-Datei, die du ins Root deines Projekts legst. Jedes KI-Coding-Tool, das projektweite Anweisungen unterstützt, liest sie automatisch.

Die Datei deckt Input-Validierung, Output-Encoding, Authentifizierung, Session-Management, Kryptografie, Fehlerbehandlung und Logging ab. Statt eigene Sicherheitsregeln von Grund auf zu schreiben, nimm ihre — gepflegt von Security-Profis, regelmäßig aktualisiert und kostenlos.

Was dich das kostet

Zeit. Jede Schicht erzeugt Reibung. Pre-Commit-Hooks addieren 5–15 Sekunden pro Commit. CI-Scans addieren Minuten zu deiner Pipeline. Code Reviews durch Menschen erfordern Menschen, die wissen, wie SSRF aussieht. Die OpenSSF-Datei erfordert, sie einmal zu lesen und zu verstehen, was sie tut.

False Positives werden dich nerven. Semgrep wird Code flaggen, der eigentlich in Ordnung ist. Du wirst Zeit damit verbringen, Nicht-Probleme zu untersuchen. Das ist die Steuer, die du zahlst, um die echten zu erwischen.

Und nichts davon ist narrensicher. Die AppSecSanta-Studie fand heraus, dass 22 % der Schwachstellen an allen getesteten SAST-Tools vorbeikamen. Manche Lücken erfordern dynamisches Testing — den Code tatsächlich auszuführen und anzugreifen — um sie zu finden. Statische Analyse ist notwendig, aber nicht hinreichend.

Was du am Montagmorgen tust

Du musst nicht alle fünf Schichten bis nächste Woche implementieren. Fang mit zweien an:

1. Füg Sicherheitsanweisungen zu deiner KI-Konfiguration hinzu. Kopier den Prompt-Block aus Schicht 1. Füg ihn in dein Projekt ein. Fünf Minuten.
2. Installier Semgrep als Pre-Commit-Hook. Zwei Befehle. Fertig, bevor dein Kaffee kalt wird.

Das allein bringt dich weiter als die meisten Teams, die heute KI-generierten Code ausliefern. CI-Scanning kommt dazu, wenn du einen Sprint mit Luft zum Atmen hast. Die OpenSSF-Datei, wenn jemand in deinem Team sie gelesen und verstanden hat. Reviewer-Training kommt mit der Zeit.

Die neue Normalität

Die Schwachstellenquote in KI-generiertem Code sank von rund 40 % in 2024 auf 25 % in 2026. Fortschritt, klar. Bei diesem Tempo erreichen wir "akzeptabel" irgendwann um 2030. Vier Jahre warten kannst du dir nicht leisten.

Behandle KI-generierten Code wie die Ausgabe eines Junior-Entwicklers, der mit 500 Wörtern pro Minute tippt, Selbstvertrauen ausstrahlt und noch nie von OWASP gehört hat. Review ihn. Scann ihn. Test ihn. Dann liefer ihn aus.

Die KI schreibt Code mit 10-facher Geschwindigkeit. Dein Security-Tooling muss mithalten. Die Werkzeuge gibt es. Was fehlt, ist nur die Gewohnheit, sie auch zu benutzen.