Welche Sicherheitslücken erzeugt KI-Code am häufigsten?

Das bestgemessene Bild liefert Veracodes Auswertung von über 100 LLMs (2025): 45 % der generierten Samples führten insgesamt OWASP-Top-10-Schwachstellen ein, mit Cross-Site-Scripting als Ausreißer – Modelle versäumten die Abwehr in 86 % der relevanten Samples. Injection-Klassen, unsicherer Umgang mit Credentials und schwache Krypto-Entscheidungen runden das wiederkehrende Set ab. Das Muster ist konsistent: Am schlechtesten scheitern die Klassen, deren Sicherheit an Kontext hängt, den das Modell nicht sieht.

Sind neuere, größere Modelle sicherer?

Messbar nein – der unbequemste Befund des Reports. Während die funktionale Korrektheit über Modellgenerationen stieg, blieb die Security-Leistung flach, unabhängig von Modellgröße und Trainings-Raffinesse. Die praktische Konsequenz: Auf die nächste Modellgeneration zu warten ist keine Sicherheitsstrategie – der Fix muss im Prozess um die Generierung leben (Checks, Kriterien, Gates), nicht in der Modellwahl.

Warum produziert KI genau diese Schwachstellen immer wieder?

Drei sich verstärkende Gründe. Trainingsdaten: Die Modelle lernten aus Jahrzehnten öffentlichen Codes, viel davon unsicher – das unsichere Muster ist oft das statistisch häufige. Fehlender Kontext: Ob Output-Encoding nötig ist, hängt davon ab, wo Daten landen – was das Modell aus dem Prompt oft nicht sieht. Und Ziel-Verfehlung: Generierung optimiert auf Code, der funktioniert – und unsicherer Code funktioniert meist; die Schwachstelle ist für den impliziten „läuft es?“-Test unsichtbar.

Spielt die Programmiersprache eine Rolle?

Erheblich, laut derselben Auswertung: Java-Samples fielen mit 72 % durch die Security-Tests – der schlechteste Wert der vier getesteten Sprachen –, gegen 38 % bei Python, 43 % bei JavaScript und 45 % bei C#. Das exakte Ranking verschiebt sich mit Aufgaben und Modellen, aber die Spreizung selbst ist der Befund: Euer Risikoprofil hängt am Stack, und Härtungs-Aufwand gehört entsprechend gewichtet.

Was fängt diese Schwachstellen-Klassen wirklich?

Eine geschichtete Antwort, deterministisch-zuerst: SAST und Secret-Scanning fangen die musterförmigen Klassen (Injection, hartkodierte Credentials, schwache Krypto) reproduzierbar und billig – hier verdienen Tools wie SonarQube ihren Platz. Security-Akzeptanzkriterien im Auftrag fangen die kontextabhängigen Klassen, die kein Scanner beurteilen kann. Und menschliches Review, von der mechanischen Ebene entlastet, beurteilt die Vertrauensgrenzen. Keine Schicht deckt die Spreizung allein; der Stapel tut es.

Sollten wir KI für sicherheitskritischen Code meiden?

Die Daten tragen eine engere Schlussfolgerung: KI-generierten sicherheitskritischen Code nie auf Generierungs-Vertrauen allein mergen. Teams, die Security-Anforderungen in den Auftrag schreiben (Input-Validierung, Encoding, Auth-Pfade als explizite Kriterien), SAST pro Änderung fahren und auf menschliches Review gaten, nutzen KI an sensiblem Code mit gemessenem statt angenommenem Risiko. Die 45 % beschreiben ungeprüften Output – ein Argument für die Pipeline, nicht gegen das Tool.

Sicherheit

Sicherheitslücken in KI-Code

Zuletzt aktualisiert: 2026-07-02Lesezeit ca. 4 Min.

KI-generierter Code fällt mit gemessenen, stabilen Raten durch Security-Tests: Über 100+ LLMs führten 45 % der Samples OWASP-Top-10-Schwachstellen ein, Cross-Site-Scripting scheiterte in 86 % der relevanten Fälle, Java-Samples bei 72 % – und die Raten blieben über Modellgenerationen flach. Die Schlussfolgerung ist unbequem und nützlich: Der Fix lebt im Prozess um die Generierung, nicht im Warten auf bessere Modelle.

Inhalt

Die gemessene Ausgangslage

Veracodes GenAI Code Security Report 2025 ist die größte öffentliche Messung der Frage: über 100 LLMs, vier Sprachen, Aufgaben mit bekannt-sicheren Lösungen. Die Schlagzeile – 45 % der Samples führten OWASP-Top-10-Schwachstellen ein – zählt weniger als zwei strukturelle Befunde. Pro Sprache ist die Spreizung groß: Java 72 %, C# 45 %, JavaScript 43 %, Python 38 %. Und über Modellgenerationen stieg die funktionale Qualität, während die Security-Leistung flach blieb – neuer und größer kaufte keine Sicherheit. Was auch immer eure Modell-Roadmap ist: Die Security-Arbeit bleibt eure.

Die wiederkehrenden Klassen – und was welche fängt

Klasse	Warum KI sie produziert	Was sie fängt
Cross-Site-Scripting (86 % Durchfallrate)	Encoding hängt am Output-Kontext, den das Modell nicht sieht	SAST-Regeln + Security-Kriterien im Auftrag
Injection (SQL, Command, Log)	String-Konkatenation ist das statistisch häufige Muster der Trainingsdaten	SAST – der klassische, reproduzierbare Fang
Hartkodierte Credentials	Beispiele in Trainingsdaten hartkodieren; das Modell imitiert	Secret-Scanning pre-commit; Secrets ganz raus aus Repos
Schwache Kryptografie	Veraltete Algorithmen sind in altem öffentlichem Code überrepräsentiert	SAST + Dependency-Richtlinien mit freigegebenen Primitiven
Fehlende Authentifizierungs-/Autorisierungs-Checks	Vertrauensgrenzen leben in der Architektur, nicht im Prompt	Menschliches Review der Vertrauensgrenzen; Kriterien pro Auftrag

Die wiederkehrenden Schwachstellen-Klassen in KI-Code, warum Generierung sie produziert und die Schicht, die jede fängt – keine Schicht deckt die Spreizung allein (Quellen: Veracode 2025; Verteidigungs-Mapping von uns).

Das Mapping erklärt den Flach-über-Generationen-Befund: Am schlechtesten stehen die Klassen, deren Sicherheit an Kontext außerhalb des Generierungs-Fensters hängt – wo Output landet, wo die Vertrauensgrenze verläuft, was die Organisation als freigegebene Krypto betrachtet. Mehr Parameter liefern keinen fehlenden Kontext nach. Die allgemeine Fehler-Taxonomie dahinter steht in Warum KI-Code Fehler macht.

Der Verteidigungs-Stapel, deterministisch-zuerst

SAST und Secret-Scanning pro Änderung. Die musterförmigen Klassen fallen an deterministische Tools, reproduzierbar und billig – die Arbeitsteilung mit statischer Analyse steht in SonarQube vs. Verifikation.
Security-Kriterien im Auftrag. „Validiert Input nach X, encodiert Output für Y, fasst keine Auth-Pfade an“ – vor dem Run geschrieben, danach prüfbar. Das liefert den Kontext nach, der dem Modell fehlte.
Menschliches Review an den Vertrauensgrenzen. Von der mechanischen Ebene entlastet, beurteilt Review, was kein Scanner kann: ob die Grenze selbst richtig ist.
Und darunter die BSI/ANSSI-Grundlinie: generierten Output als ungeprüften Input behandeln. Bei nur 48 % konsequenter Prüfung trifft der 45-%-Defekt-Nachschub auf ein zu 52 % offenes Tor.

Wo Reality Graph ansetzt

Reality Graph ist kein Security-Scanner und ersetzt kein SAST. Sein Beitrag zu diesem Stapel ist die zweite Schicht: Security-Kriterien in den Auftrag geschrieben, die Änderung pro Run dagegen verifiziert, und das Ergebnis – inklusive übersprungener Checks – im Prüfbericht festgehalten. Scanner beantworten „enthält dieser Code bekannt-schlechte Muster?“; Verifikation beantwortet „hat diese Änderung die Security-Anforderungen respektiert, die wir tatsächlich gesetzt haben?“ – beides, pro Änderung, ist die Haltung, für die die Zahlen argumentieren.

Diese Analyse gibt euch

Das gemessene Klassen-Bild, mit benanntem Studien-Design
Den Flach-über-Generationen-Befund und seine Konsequenz
Einen Verteidigungs-Stapel, deterministisch-zuerst geordnet
Sprach-Gewichtung des Risikos für euren Stack

Sie gibt euch nicht

Einen SAST-Ersatz – Reality Graph ist kein Scanner
Ein Argument gegen KI an sensiblem Code – gegen ungeprüfte KI
Exakte Raten für eure Codebasis – messt mit eurer Pipeline
Eine Modell-Empfehlung – Security variierte nicht nutzbar nach Modell

Wenn diese Grenzen zu eurem Team passen:

Early Access sichern So funktioniert es

FAQ

Welche Sicherheitslücken erzeugt KI-Code am häufigsten?: Das bestgemessene Bild liefert Veracodes Auswertung von über 100 LLMs (2025): 45 % der generierten Samples führten insgesamt OWASP-Top-10-Schwachstellen ein, mit Cross-Site-Scripting als Ausreißer – Modelle versäumten die Abwehr in 86 % der relevanten Samples. Injection-Klassen, unsicherer Umgang mit Credentials und schwache Krypto-Entscheidungen runden das wiederkehrende Set ab. Das Muster ist konsistent: Am schlechtesten scheitern die Klassen, deren Sicherheit an Kontext hängt, den das Modell nicht sieht.
Sind neuere, größere Modelle sicherer?: Messbar nein – der unbequemste Befund des Reports. Während die funktionale Korrektheit über Modellgenerationen stieg, blieb die Security-Leistung flach, unabhängig von Modellgröße und Trainings-Raffinesse. Die praktische Konsequenz: Auf die nächste Modellgeneration zu warten ist keine Sicherheitsstrategie – der Fix muss im Prozess um die Generierung leben (Checks, Kriterien, Gates), nicht in der Modellwahl.
Warum produziert KI genau diese Schwachstellen immer wieder?: Drei sich verstärkende Gründe. Trainingsdaten: Die Modelle lernten aus Jahrzehnten öffentlichen Codes, viel davon unsicher – das unsichere Muster ist oft das statistisch häufige. Fehlender Kontext: Ob Output-Encoding nötig ist, hängt davon ab, wo Daten landen – was das Modell aus dem Prompt oft nicht sieht. Und Ziel-Verfehlung: Generierung optimiert auf Code, der funktioniert – und unsicherer Code funktioniert meist; die Schwachstelle ist für den impliziten „läuft es?“-Test unsichtbar.
Spielt die Programmiersprache eine Rolle?: Erheblich, laut derselben Auswertung: Java-Samples fielen mit 72 % durch die Security-Tests – der schlechteste Wert der vier getesteten Sprachen –, gegen 38 % bei Python, 43 % bei JavaScript und 45 % bei C#. Das exakte Ranking verschiebt sich mit Aufgaben und Modellen, aber die Spreizung selbst ist der Befund: Euer Risikoprofil hängt am Stack, und Härtungs-Aufwand gehört entsprechend gewichtet.
Was fängt diese Schwachstellen-Klassen wirklich?: Eine geschichtete Antwort, deterministisch-zuerst: SAST und Secret-Scanning fangen die musterförmigen Klassen (Injection, hartkodierte Credentials, schwache Krypto) reproduzierbar und billig – hier verdienen Tools wie SonarQube ihren Platz. Security-Akzeptanzkriterien im Auftrag fangen die kontextabhängigen Klassen, die kein Scanner beurteilen kann. Und menschliches Review, von der mechanischen Ebene entlastet, beurteilt die Vertrauensgrenzen. Keine Schicht deckt die Spreizung allein; der Stapel tut es.
Sollten wir KI für sicherheitskritischen Code meiden?: Die Daten tragen eine engere Schlussfolgerung: KI-generierten sicherheitskritischen Code nie auf Generierungs-Vertrauen allein mergen. Teams, die Security-Anforderungen in den Auftrag schreiben (Input-Validierung, Encoding, Auth-Pfade als explizite Kriterien), SAST pro Änderung fahren und auf menschliches Review gaten, nutzen KI an sensiblem Code mit gemessenem statt angenommenem Risiko. Die 45 % beschreiben ungeprüften Output – ein Argument für die Pipeline, nicht gegen das Tool.

Weiterlesen

SicherheitSlopsquattingAngreifer registrieren die Pakete, die KI halluziniert – 19,7 % der Empfehlungen, 205k erfundene Namen, 43 % konsistent wiederholt. Die Mechanik, die USENIX-2025-Zahlen und die Verteidigung, die den Installations-Pfad schließt.SicherheitPrompt Injection gegen Coding-AgentenEin Agent liest ein vergiftetes README und führt die Anweisungen des Angreifers aus – OWASPs LLM-Risiko Nr. 1, mit 2026er-CVEs gegen Copilot, Claude Code und MCP-Server. Warum es strukturell sein könnte und warum Containment die Heilung schlägt.Alle ArtikelDie ganze Sammlung – 58 belegte, datierte Guides zur Prüfung von KI-generiertem Code.