Ist KI-generierter Code sicher? Was die Daten von 2026 sagen, und was Scanner übersehen

Ist KI-generierter Code sicher?

Nein, nicht standardmäßig. KI-generierter Code ist so sicher wie die Kontrollen drumherum, und die meisten KI-Coding-Setups haben keine Kontrolle, die handelt, bevor der Code landet. Das Modell produziert zuverlässig Code, der kompiliert und den Happy Path besteht; es produziert nicht zuverlässig Code, der einem Angreifer widersteht, denn einem Angreifer zu widerstehen dreht sich um die Prüfungen, die fehlen, und ein Prompt, der nach einem funktionierenden Feature fragt, fragt nie nach dem fehlenden Schutz.

Die ehrliche Einordnung ist, dass KI-generierter Code nicht kategorisch gefährlich ist, er ist ungeprüfter Code, produziert in einem Tempo, das kein Mensch prüfen kann. Ein Junior-Entwickler schreibt ebenfalls unsicheren Code, aber langsam genug, dass die Prüfung Schritt hält. Ein KI-Agent schreibt täglich tausende Zeilen, sodass die Lücke zwischen "sieht richtig aus" und "ist richtig" schneller wächst, als irgendjemand sie schließen kann. Die Sicherheitsfrage ist daher in Wahrheit eine Kontrollfrage: Was fängt die Schwachstelle ab, und wann?

40%

des KI-generierten Codes war über die MITRE-Top-25-Sicherheitsszenarien hinweg verwundbar (NYU, Asleep at the Keyboard)

10.5%

der KI-Coding-Agenten-Lösungen waren sicher, gegenüber 61 % funktional korrekt (Carnegie Mellon SusVibes)

#1

Broken Access Control, das wichtigste Risiko der OWASP Top 10, und eine Klasse, die generische Scanner selten erkennen

Warum ist so viel KI-generierter Code unsicher?

Weil das Modell den Durchschnitt seiner Trainingsdaten reproduziert, und der Durchschnitt öffentlichen Codes ist nicht sicher. Drei Kräfte verstärken sich, und keine davon wird durch ein besseres Modell behoben.

Erstens das Korpus-Problem. Das Modell hat aus einem riesigen Bestand öffentlichen Codes gelernt, der voll von den OWASP-Klassikern ist: per String konkateniertes SQL, fehlende Autorisierungsprüfungen, schwache Kryptografie, eingebettete Secrets. Unsicher-als-Standard ist sein statistischer Prior, also greift es zum gängigen Muster, und das gängige Muster ist häufig das unsichere.

Zweitens das Abwesenheits-Problem. Sicherheit ist meist ein Schutz, der vorhanden ist: eine Grenzprüfung, eine Eigentumsprüfung, eine maskierte Eingabe. Ein Modell, das nach einem positiven Ergebnis gefragt wird ("füge einen Checkout-Endpunkt hinzu"), fügt keinen negativen Schutz hinzu, nach dem niemand gefragt hat. Das Feature funktioniert genau deshalb, weil die fehlende Prüfung den Happy Path nicht beeinträchtigt.

Drittens das Leser-Problem, und es ist das entscheidende. Die Person, die promptet, kann erkennen, ob das Feature funktioniert. Sie kann oft nicht erkennen, ob es sicher ist. Diese Lücke, zwischen der Absicht des Autors und der Fähigkeit des Prüfers, ist das gesamte Sicherheitsproblem, und sie ist genau das, was sich vergrößert, wenn ein Nicht-Spezialist ein Feature in einem Absatz Absicht vibe-codet. Wir gehen darauf in Vibe-Coding-Sicherheit tiefer ein.

Welche Arten von Schwachstellen führt KI-Code ein?

Dieselben, die Menschen einführen, schneller reproduziert, als die Prüfung Schritt halten kann. Dies sind die Klassen, die in jeder Studie und jedem Tool wiederkehren, jede verankert dort, wo wir sie ausführlich behandeln:

• Injection (CWE-89, CWE-78). Konkateniertes SQL und Shell-Befehle, aus Benutzereingaben gebaut, weil das Modell sie aus einem damit vollen Korpus gelernt hat. Siehe warum die meisten SAST-Befunde Rauschen sind, um zu verstehen, warum nur die erreichbaren zählen.
• Gebrochene Autorisierung und IDOR (CWE-862, CWE-639). Der Agent baut den Endpunkt, der den Datensatz zurückgibt, aber selten die Prüfung, dass der Aufrufer ihn besitzt. Das ist OWASPs Risiko Nummer eins und das, welches Scanner am wenigsten sehen.
• Fest codierte Secrets (CWE-798). Nach einer funktionierenden Integration gefragt, bettet das Modell einen API-Schlüssel oder ein Passwort ein, damit der Code beim ersten Versuch läuft, und dann lebt es im Repo und in jedem Fork.
• Fehlende Eingabevalidierung (CWE-20). Generierte Endpunkte vertrauen ihren Eingaben, was der stille Wegbereiter von Injection und Deserialisierung weiter unten ist.
• Unsichere Deserialisierung (CWE-502). "Lade das gespeicherte Objekt" wird zu pickle oder yaml.load auf nicht vertrauenswürdigen Bytes und verwandelt einen gespeicherten Blob in Remote Code Execution.
• Business-Logik-Fehler. Die gefährlichste Klasse, weil kein Scanner darauf ausgelegt ist, sie zu erkennen: ein Warenkorb mit negativer Menge, ein Gutschein, der sich stapelt, eine Rückerstattung, die die Eigentumsprüfung überspringt. Der Code ist syntaktisch perfekt und semantisch falsch. Das ist unsere Tiefenanalyse zu Business-Logik-Fehlern in KI-generiertem Code.

Was übersehen Scanner, und die Modelle selbst?

Zwei blinde Flecken sind am wichtigsten, und sie sind der Grund, warum "einfach einen Scanner laufen lassen" oder "das Modell bitten, seine eigene Arbeit zu prüfen" beide zu kurz greifen.

Der erste ist Business-Logik. Ein statischer Analyzer argumentiert über Code-Muster; eine Geschäftsregel ("nur der Eigentümer darf dieses Dokument bearbeiten", "die Menge muss positiv sein") lebt außerhalb des Codes, in Ihrer Domäne. Es gibt keine kontaminierte Eingabe und keine gefährliche Senke zum Abgleichen, nur eine if-Anweisung, die nie geschrieben wurde, sodass der Scanner die Datei als sauber meldet, während sie voll ausnutzbar ist.

Der zweite ist das Modell, das seine eigenen Hausaufgaben benotet. Denselben Agenten, der den Code geschrieben hat, zu bitten, ihn zu prüfen, erbt dieselben blinden Flecken: Er kennt Ihr Autorisierungsmodell nicht, er kann die anderen Befunde rund um die Zeile nicht sehen, und er ist über die unsichere Version genauso überzeugt wie über die sichere. Unabhängige Tests bestätigen das, nur ein kleiner Bruchteil der KI-Lösungen ist sicher, selbst wenn die meisten funktional korrekt sind. Eine vertrauenswürdige Prüfung braucht externes Signal: erreichbarkeitsbewusstes Scanning, das echtem Datenfluss folgt, und Ihre eigenen Regeln, geladen als Grundwahrheit, nicht die eigene Meinung des Modells.

“

Die Frage ist nicht, ob KI unsicheren Code schreibt, jeder Autor tut das. Sie ist, ob irgendetwas die unsichere Zeile abfängt, bevor sie ausgeliefert wird, und bei KI-Tempo ist der einzige verbleibende Ort, sie abzufangen, dort, wo die Zeile geschrieben wird.

Kann man einer KI zutrauen, ihre eigenen Schwachstellen zu beheben?

Sie können einem KI-Agenten weit eher zutrauen, einen Fix anzuwenden, als zu entscheiden, was eine echte, erreichbare Schwachstelle ist. Das Modell ist stark darin, eine Zeile umzuschreiben, sobald es genau weiß, was zu ändern ist; es ist schwach darin, zu beurteilen, ob ein Problem ausnutzbar ist, was genau das ist, was ein reifer Scanner bereits berechnet hat. Das vertrauenswürdige Muster ist also nicht "KI, sichere meinen Code ab", sondern "gib dem Agenten bestätigte, nach Erreichbarkeit eingestufte Befunde plus deine Regeln, lass ihn sie beheben und genehmige jedes Diff". Wir behandeln diese Schleife in KI-Vulnerability-Remediation und ob ein Agent Schwachstellen automatisch finden und beheben kann.

Wie macht man KI-generierten Code sicher?

Sie machen ihn sicher, indem Sie die Kontrolle in den Moment verlegen, in dem der Code geschrieben wird, statt dem Modell zu vertrauen oder auf einen Scanner nach dem Merge zu warten. Drei Schritte, in der Reihenfolge des Hebels:

1. Zum Generierungszeitpunkt steuern. Laden Sie Ihre Sicherheits- und Geschäftsregeln vor jeder Bearbeitung in den Agenten, sodass das sichere Muster der Standard ist, zu dem er greift. Die Schwachstelle, die nie geschrieben wird, braucht keine Triage. Das ist die Kernidee der Sicherheit von KI-Coding-Agenten.
2. Kontinuierlich scannen und die Befunde an den Agenten zurückspielen. Halten Sie erreichbarkeitsbewusstes SAST, SCA, Secrets, IaC und den Rest am Laufen, und legen Sie deren bestätigte Befunde in die Hände des Agenten, sodass er die echten in der Schleife behebt.
3. CI und menschliche Prüfung als Auffangnetz behalten. Ein SAST-Gate bei jedem Pull Request und ein Mensch, der Diffs genehmigt, fangen ab, was durchrutscht. Sie sind notwendig, aber bei KI-Tempo können sie nicht die einzige Linie sein.

Die vollständige praktische Version ist wie man Sicherheit zu seinem KI-Coding-Workflow hinzufügt und wie man eine ganze App in fünf Minuten absichert.

VibeDefend ist die Ebene, die die ersten beiden erledigt. Es ist eine kostenlose npm-CLI, die in Sekunden installiert ist und Claude Code, Cursor, Windsurf, OpenAI Codex und VS Code Copilot in vier Governance-Ebenen innerhalb der Agentenschleife verdrahtet.

Drei Ebenen steuern, was der Agent schreibt: Business Rules aus Ihrem Repo gefördert, Security Rules aus OWASP, SOC 2, DSGVO und ISO 27001, und ein Action Guard, der destruktive Aufrufe blockiert. Die vierte, Live Findings, verdrahtet den Agenten in CybeDefends vollständige AppSec-Plattform, seine Scanner, die kontinuierlich laufen, mit jedem Befund live im Kontext des Agenten, sodass der Agent nicht nur sichereren Code schreibt, er behebt auch die Schwachstellen, die Sie bereits haben. Nichts über Ihren Code geht über die Leitung; nur strukturierte Governance-Metadaten, auf EU- oder US-Mandanten, die physisch getrennt gehalten werden.

Häufig gestellte Fragen

Ist KI-generierter Code sicher?

Nicht standardmäßig. KI-generierter Code läuft zuverlässig und besteht den Happy Path, aber unabhängige Tests finden immer wieder einen großen Anteil davon unsicher, etwa 40 % verwundbar in der NYU-Studie "Asleep at the Keyboard" und nur rund 10 % der KI-Coding-Agenten-Lösungen sicher in Carnegie Mellons SusVibes-Benchmark, obwohl die meisten funktional korrekt waren. Er wird sicher, wenn Sie eine Kontrolle hinzufügen, die handelt, wo der Code geschrieben wird, und menschliche Prüfung sowie CI-Scanning dahinter behalten.

Ist es sicher, KI-generierten Code in die Produktion auszurollen?

Nur nachdem er geprüft und gescannt wurde, wie jeder Code es sein sollte, und idealerweise nachdem er beim Schreiben gesteuert wurde. KI-Code direkt aus "es funktioniert" auszurollen ist riskant, weil die Fehler (fehlende Autorisierung, Injection, fest codierte Secrets, Business-Logik-Fehler) den Happy Path nicht beeinträchtigen und so einen funktionalen Test überleben. Sichern Sie ihn mit erreichbarkeitsbewusstem SAST in CI, menschlicher Prüfung sicherheitskritischer Pfade und einer Kontrolle zum Prompt-Zeitpunkt ab, sodass die sichere Version zuerst geschrieben wird.

Warum ist KI-generierter Code unsicher, wenn das Modell so fähig ist?

Weil Fähigkeit beim Produzieren von funktionierendem Code nicht dasselbe ist wie das Produzieren von sicherem Code. Das Modell reproduziert die unsicheren Muster, die in seinen öffentlichen Trainingsdaten verbreitet sind, Sicherheit ist meist ein Schutz, der hinzugefügt werden muss, statt eines positiven Ergebnisses, nach dem ein Prompt fragt, und die Person, die promptet, kann oft nicht beurteilen, ob das Ergebnis sicher ist. Keines davon wird durch ein klügeres Modell behoben; sie werden durch eine Kontrolle rund um das Modell behoben.

Kann ich die KI einfach bitten, ihren eigenen Code auf Schwachstellen zu prüfen?

Es hilft ein wenig und ist nicht ausreichend. Dasselbe Modell, das den Code geschrieben hat, teilt seine blinden Flecken: Es kennt Ihr Autorisierungsmodell oder Ihre Mandantengrenze nicht, es kann die anderen Befunde rund um die Zeile nicht sehen, und es ist über die unsichere und die sichere Version gleich überzeugt. Vertrauenswürdige Prüfung braucht externes Signal, erreichbarkeitsbewusstes Scanning und Ihre eigenen Regeln als Grundwahrheit, nicht die Selbsteinschätzung des Modells.

Was sind die häufigsten Schwachstellen in KI-generiertem Code?

Injection (CWE-89, CWE-78), gebrochene Autorisierung und IDOR (CWE-862, CWE-639), fest codierte Secrets (CWE-798), fehlende Eingabevalidierung (CWE-20), unsichere Deserialisierung (CWE-502) und Business-Logik-Fehler. Die ersten fünf sind von guten Scannern erkennbar, wenn Sie nach Erreichbarkeit filtern; die letzte, Business-Logik, ist die gefährliche, weil kein Scanner darauf ausgelegt ist, eine syntaktisch perfekte, semantisch falsche Regel zu erkennen.

Wie mache ich KI-generierten Code sicher?

Verlegen Sie die Kontrolle auf den Generierungszeitpunkt: Laden Sie Ihre Sicherheits- und Geschäftsregeln in den Agenten, sodass er das sichere Muster zuerst schreibt, scannen Sie kontinuierlich und spielen Sie die bestätigten Befunde an den Agenten zur Behebung zurück, und behalten Sie ein CI-SAST-Gate plus menschliche Prüfung als Auffangnetz. Dem Modell zu vertrauen, sich selbst zu überwachen, oder sich allein auf einen Scan nach dem Merge zu verlassen, der ankommt, nachdem der Agent weitergezogen ist, ist es, was die Lücke offen lässt.