KI-Modelle generieren heute vollständige Features, Workflows und Services, die produktiv eingesetzt werden. Wenn Ihr Entwicklungsteam Copilot, Cursor oder einen agentenbasierten Code-Assistenten verwendet, wurde ein wachsender Anteil Ihrer Codebasis von einem Modell geschrieben, (in unterschiedlichem Maße) von einem Menschen überprüft und über Ihre bestehende Pipeline bereitgestellt.

Diese Pipeline wurde für von Menschen geschriebenen Code konzipiert. Der Überprüfungsprozess, die CI-Prüfungen und die Freigabeschranken setzen alle einen Entwickler voraus, der die Kompromisse hinter seinen Designentscheidungen versteht. KI-generierter Code geht nicht von einer solchen Annahme aus. Er optimiert auf funktionale Korrektheit im Idealfall und tut dies in einem Umfang, der die Verifizierungsfähigkeit der meisten Teams übersteigt.

Eine umfassende Evaluierung modernster Modelle ergab, dass mindestens 62 % der generierten Programme anfällig waren für gängige Schwachstellen (CWEs). Die DORA-Forschung von Google Cloud bietet eine nützliche Perspektive: KI verstärkt jede bereits vorhandene Ingenieursdisziplin. Starke Teams werden schneller. Schwache Grundlagen verschlechtern sich schneller.

Dies macht KI-generierten Code zu einem Governance-Problem. Ihr SDLC muss Code berücksichtigen, der mit Maschinengeschwindigkeit produziert wird, keine Autorenabsicht hat und standardmäßig eher plausibel als sicher ist. Dieser Artikel legt einen Kontrollrahmen dafür dar: Richtlinien, Spezifikationen, Sandboxing, Überprüfungsebenen und CI-Durchsetzung.

Warum KI-generierter Code traditionelle Code-Reviews sprengt

Code-Reviews beruhten immer auf drei impliziten Annahmen: Der Autor hatte eine Absicht hinter seinen Designentscheidungen, er verstand den Bereich und er konnte die Kompromisse erklären, die er eingegangen war. KI-generierter Code erfüllt keine davon. Das Modell hat kein Bewusstsein für die Invarianten Ihres Systems, keine Erinnerung an frühere Architektur-Entscheidungen und keine Rechenschaftspflicht für seine Ausgabe. Wenn ein Prüfer einen PR öffnet, bewertet er eine Ausgabe, die aussieht, als hätte sie ein Senior-Ingenieur geschrieben, aber keine der Begründungen enthält, die sie normalerweise untermauern würden.

Der Wandel in der Review-Ökonomie

Ihr Team kann jetzt Code in einem Tempo generieren, das Ihr Überprüfungsprozess nie aufnehmen sollte. Ein einzelner Entwickler, der einen agentenbasierten Assistenten verwendet, kann an einem Tag mehr PRs öffnen, als ein Team früher in einem Sprint erstellt hat. Die entscheidende Frage ist: „Wie schnell kann ein qualifizierter Prüfer verifizieren, dass dieser Code korrekt, sicher und wartbar ist?“

In der Praxis bedeutet dies, dass Ihre erfahrensten Ingenieure zum Engpass werden. PR-Warteschlangen stauen sich auf. Die Überprüfungstiefe nimmt mit steigendem Volumen ab. Teams beginnen, sich auf die Oberflächenqualität zu konzentrieren („der Code sieht sauber aus, die Tests bestehen“), anstatt über Verhalten, Grenzfälle und Fehlermodi nachzudenken. Die Generierungsgeschwindigkeit erzeugt die Illusion von Durchsatz, während die Verifizierungsqualität abnimmt.

Review-Müdigkeit als Sicherheitslücke

Die Gefahr ist nicht nur das Vorhandensein von anfälligem Code, sondern auch die Erosion des Überprüfungsprozesses selbst. Wenn Code günstig zu produzieren ist, sinken auch die wahrgenommenen Kosten für dessen Überprüfung. 

Entwickler „vibe-coden“ ganze Features und erstellen gerüstbasierte Anwendungen aus der Modellausgabe mit minimaler manueller Inspektion. Prüfer, angesichts einer wachsenden Warteschlange von poliert aussehenden Diffs, beginnen zu überfliegen. Freigaben werden oberflächlich, und der Stempel ersetzt die Überprüfung.

Hier verschärft sich das Sicherheitsrisiko. Der Code, der durchgewunken wird, ist nicht offensichtlich fehlerhaft. Er besteht das Linting. Er hat Tests. Er behandelt den Idealfall. Aber er kann auch fest codierte Anmeldeinformationen, unparametrisierte Abfragen oder Abhängigkeiten enthalten, die noch nicht existieren (ein Risiko, das wir im nächsten Abschnitt behandeln werden). 

Verantwortung verlagert sich auf Kontrollen

Sie können nicht mehr davon ausgehen, dass die Person, die den PR geöffnet hat, den darin enthaltenen Code vollständig verstanden hat. Das eliminiert nicht die Notwendigkeit menschlicher Verantwortung. Jede KI-generierte Änderung benötigt weiterhin einen namentlich genannten Verantwortlichen, der ihre Logik erklären und sie im Laufe der Zeit warten kann. Aber die alleinige Verantwortung ist keine ausreichende Absicherung, wenn der Verantwortliche den Code nicht selbst geschrieben und möglicherweise nicht gründlich überprüft hat.

Die praktische Antwort ist eine risikogestufte Überprüfung. Änderungen mit geringem Risiko (Testgenerierung, Boilerplate-Code, Dokumentation, interne Tools) können einen beschleunigten Pfad mit starken automatisierten Prüfungen durchlaufen. Änderungen mit hohem Risiko (Authentifizierungsabläufe, Zahlungslogik, Infrastrukturkonfiguration, alles, was regulierte Daten betrifft) erfordern namentlich genannte menschliche Prüfer mit Domänenexpertise und expliziter Sicherheitsfreigabe. 

Die Leitlinien von OWASP sind eindeutig und besagen, dass Ihr Team für den gesamten committeten Code verantwortlich ist, unabhängig davon, ob er von einem Menschen oder einem Modell geschrieben wurde. Die Überprüfungsebene bestimmt, wie Sie dieser Verantwortung nachkommen.

Sicherheitsrisiken in KI-generiertem Code: Was in der Praxis schiefgeht

KI-generierter Code versagt anders als von Menschen geschriebener Code. Wenn ein Entwickler eine Schwachstelle einführt, ist dies meist auf einen Denkfehler, eine Wissenslücke oder eine Abkürzung unter Zeitdruck zurückzuführen. Wenn ein Modell eine einführt, sieht der Code immer noch gut strukturiert aus, besteht grundlegende Prüfungen und deckt den „Happy Path“ ab. Das Versagen verbirgt sich hinter Plausibilität.

Zu verstehen, wo KI-generierter Code versagt, hilft Ihnen, Kontrollen zu entwickeln, die die richtigen Risiken adressieren. Einige davon sind bekannte Schwachstellen in größerem Umfang. Andere sind Kategorien, die es nicht gab, bevor Modelle anfingen, Produktionscode zu schreiben.

Unsichere Codemuster aus Trainingsdaten übernommen

Modelle lernen aus öffentlichem Code, und öffentlicher Code ist voller bekannter Schwachstellen. KI-generierte Ausgaben reproduzieren häufig SQL-Injection-Muster (CWE-89), Cross-Site-Scripting (CWE-79) und fest codierte Anmeldeinformationen (CWE-798), da diese Muster in den Trainingsdaten in Code vorkommen, der ansonsten korrekt funktioniert. Das Modell wählt keinen unsicheren Ansatz. Es reproduziert, was statistisch aus dem Prompt folgt, und unsichere Muster sind im Korpus gut vertreten.

Dies macht KI-generierte Schwachstellen schwerer zu erkennen als von Menschen eingeführte. Ein Entwickler, der Anmeldeinformationen fest codiert, nimmt meist eine Abkürzung, von der er weiß. Ein Modell, das Anmeldeinformationen fest codiert, erzeugt Code, der einer bewussten, durchdachten Implementierung gleicht. Der Diff sieht sauber aus. Die Überprüfung muss tiefer gehen.

Veraltete Abhängigkeiten und die temporale Lücke von KI-Modellen

Modelle haben einen Trainingsstichtag. Wenn sie eine Bibliotheksversion vorschlagen, schlagen sie eine vor, die zum Zeitpunkt des Trainings aktuell und sicher war. Wenn diese Version seitdem mit einer kritischen CVE gekennzeichnet wurde, kann das Modell dies nicht wissen. Ihre CI-Pipeline zieht eine Abhängigkeit herein, die vor sechs Monaten eine vernünftige Wahl war und heute eine bekannte Schwachstelle darstellt. Diese „temporale Lücke“ verstärkt sich mit jedem Monat zwischen Modelltraining und Produktionseinsatz.

Abhängigkeitshalluzinationen und Slopsquatting beim KI-Coding

Dies ist eines der gefährlicheren Risiken, die spezifisch für KI-generierten Code sind. Modelle schlagen manchmal Pakete vor, die nicht existieren. Ein Modell könnte fastapi-security-helper als Import empfehlen. Das Paket wurde nie veröffentlicht. Aber die Halluzination ist konsistent: Mehrere Benutzer erhalten über mehrere Sitzungen hinweg denselben Vorschlag.

Angreifer haben gelernt, dies auszunutzen. Sie überwachen häufig halluzinierte Paketnamen und registrieren sie in öffentlichen Repositories wie npm oder PyPI, mit bösartigen Payloads darin. Wenn Ihr Entwickler den Vorschlag des Modells annimmt und Ihr Build die Abhängigkeit zieht, haben Sie Angreifer-kontrollierten Code über Ihre eigene CI-Pipeline in Ihre Umgebung installiert. Kein Exploit erforderlich. Das Modell lieferte den Einstiegspunkt in die Lieferkette.

Prompt-Injection-Risiken in agentenbasierten KI-Codierungs-Workflows

Wenn KI-Assistenten die Fähigkeit erlangen, Dateien zu lesen, Repositories zu durchsuchen und Befehle auszuführen, eröffnet sich eine neue Angriffsart. Traditionelle Sicherheit trennt Anweisungen von Daten. LLMs tun dies nicht. Sie verarbeiten einen Code-Kommentar, eine README-Datei und einen Benutzer-Prompt über dasselbe Kontextfenster ohne Privilegiengrenze dazwischen.

Bei einer indirekten Prompt-Injection bettet ein Angreifer Anweisungen in eine Datei ein, die der Agent lesen wird: eine README-Datei, einen Docstring, einen Konfigurationskommentar. Der Agent behandelt die eingebetteten Anweisungen als Kontext und handelt danach. Er könnte Umgebungsvariablen exfiltrieren, Konfigurationsdateien ändern oder vom Angreifer entworfene Änderungen pushen. Der Agent folgt den injizierten Anweisungen, weil er keinen Mechanismus hat, sie von legitimen zu unterscheiden.

Schatten-KI: Datenoffenlegungsrisiken in der KI-gestützten Entwicklung

Unabhängig vom Risiko auf Agenten-Ebene treffen Ihre Entwickler täglich Entscheidungen darüber, welchen Kontext sie in KI-Tools einspeisen. Wenn jemand proprietären Quellcode, interne API-Schemata oder Kundendaten in die Chat-Oberfläche eines öffentlichen Modells einfügt, kann diese Eingabe für zukünftiges Training verwendet werden. Ihre interne Logik, Namenskonventionen und Systemarchitektur werden Teil des Wissens eines öffentlichen Modells. Dies ist eine operative Daten-Governance-Lücke, die die meisten Teams noch nicht mit einer klaren Richtlinie adressiert haben.

Ein Fünf-Schichten-Governance-Modell für sicheren KI-generierten Code

Die Absicherung von KI-generiertem Code erfordert Governance auf fünf Ebenen: Richtlinien, Spezifikation, Sandboxing, Überprüfung und Durchsetzung. Jede Ebene löst ein anderes Problem, und das Überspringen einer dieser Ebenen schafft eine Lücke, die die anderen nicht ausgleichen können.

5.1 Die Richtlinienebene: Definieren Sie, wo KI verwendet werden darf und wo nicht

Bevor Ihr Team eine einzige KI-unterstützte Zeile schreibt, benötigen Sie eine Richtlinie zur akzeptablen Nutzung (AUP) die klare Grenzen zieht, wo KI-Generierung erlaubt ist, wo sie eingeschränkt ist und wo sie verboten ist.

Eine nützliche KI-Nutzungsrichtlinie beantwortet drei Fragen: 

1. Welche Aufgaben sind für die KI-Generierung mit Standardüberprüfung freigegeben? Testgerüste, Dokumentation, Boilerplate-Code und interne Tools fallen typischerweise hierher. 
2. Welche Bereiche erfordern zusätzliche Kontrollen? API-Integrationen, Datentransformationen und Geschäftslogik, die externe Systeme berührt, sind häufige Kandidaten. 
3. Wo ist die KI-Generierung gänzlich tabu? Kryptografische Implementierungen, Logik zur Einhaltung gesetzlicher Vorschriften, Bereitstellungsautomatisierung und alles, was mit der Verwaltung von Geheimnissen zu tun hat, sollten Sperrzonen sein, in denen menschliche Urheberschaft erforderlich ist.

Die Richtlinie muss auch Datenbegrenzungen berücksichtigen: welchen Kontext Entwickler in KI-Tools einspeisen dürfen und welchen nicht. Proprietärer Quellcode, Kundendaten, interne Schemata und Cloud-Anmeldeinformationen sollten explizite Handhabungsregeln haben. Ohne dies bleibt Ihr Shadow-AI-Risiko (im vorherigen Abschnitt behandelt) ein unkontrolliertes Risiko.

5.2 Die Spezifikationsebene: Die Arbeit vor der Generierung eingrenzen

Die wirkungsvollste Kontrolle, die Sie auf KI-generierten Code anwenden können, besteht darin, dem Modell eine klar definierte Spezifikation zu geben, bevor es etwas schreibt. Wenn Anforderungen vage und die Architektur unklar sind, improvisiert das Modell. In einem Produktionssystem birgt Improvisation Risiken.

Eine nützliche Spezifikation für KI-unterstützte Arbeit umfasst den Aufgabenbereich und architektonische Einschränkungen (welche Komponenten beteiligt sind, welche Technologien zugelassen sind, wie sie interagieren), Sicherheitsanforderungen und genehmigte Muster (parametrisierte Abfragen, aus Umgebungsvariablen geladene Geheimnisse, Authentifizierung über Ihren bestehenden Identitätsanbieter) sowie Akzeptanzkriterien mit Risikoklassifizierung (wie „erledigt“ aussieht und wie sensibel die Änderung ist).

Das ist es, was GitHubs spezifikationsgesteuertes Entwicklungsmodell formalisiert: Die Spezifikation wird zur gemeinsamen Quelle der Wahrheit, die sowohl das Modell als auch den Prüfer einschränkt. Teams, die nicht verhandelbare Sicherheitsprinzipien (abgeleitet von CWE/MITRE) direkt in die Spezifikationsebene einbetten, haben eine 73%ige Reduzierung von Sicherheitsmängeln im Vergleich zu uneingeschränkter Generierung.

5.3 Die Sandbox-Schicht: Generierung und Ausführung isolieren

Ihr KI-Code-Agent sollte niemals mit denselben Zugriffsrechten wie Ihre Entwickler ausgeführt werden. Die Spezifikation begrenzt, was das Modell tun soll. Die Sandbox begrenzt, was es tun kann.

In der Praxis bedeutet dies, KI-Agenten in kurzlebigen Containern ohne persistenten Zustand auszuführen, mit eingeschränktem Netzwerkzugriff (begrenzt auf interne Registries und genehmigte Endpunkte), standardmäßig Lesezugriff auf das Repository, wobei Schreibzugriff auf einen bestimmten Branch oder ein Verzeichnis beschränkt ist, keinem Zugriff auf Produktionszugangsdaten, Secret Stores oder Deployment-Pipelines und Ressourcenbeschränkungen (CPU, Arbeitsspeicher, Ausführungszeit), die außer Kontrolle geratene Prozesse verhindern.

Diese Schicht ist Ihre Eindämmungsgrenze. Wird ein Agent durch Prompt Injection kompromittiert oder schlägt eine bösartige Abhängigkeit vor, begrenzt die Sandbox den Schaden. Ohne sie kann ein einziger kompromittierter Generierungsschritt Ihre Build-Pipeline, Ihre Secrets oder Ihre Infrastruktur erreichen.

5.4 Die Review-Schicht: Überprüfung risikobasiert, nicht einheitlich gestalten

Wird derselbe Überprüfungsprozess auf jede KI-generierte Änderung angewendet, wird dies entweder Ihr Team extrem verlangsamen oder die Überprüfungsqualität durch Volumenermüdung beeinträchtigen. Die Antwort ist eine risikogestufte Überprüfung.

Änderungen mit geringem Risiko (Testgenerierung, Dokumentationsaktualisierungen, Boilerplate, interne Tools) durchlaufen einen beschleunigten Pfad. Automatisierte Prüfungen übernehmen den Großteil der Verifizierung. Eine leichte menschliche Überprüfung bestätigt, dass die Ausgabe angemessen ist. Diese Änderungen sollten schnell durchlaufen, da es die Aufmerksamkeit der Prüfer verschwendet, sie nach denselben Standards wie sicherheitskritischen Code zu behandeln.

Die Risikoklassifizierung sollte in Ihrer Richtlinie (Schicht 5.1) definiert und konsistent angewendet werden. Muss ein Team die Überprüfungsstufe für jeden PR individuell entscheiden, hängt das System von individuellen Entscheidungen unter Zeitdruck ab, was genau der Fehlerfall ist, den Sie eliminieren möchten.

5.5 Die Durchsetzungsschicht: CI-Gates setzen Governance um

Richtlinien, Spezifikationen, Überprüfungsstufen: Nichts davon zählt, wenn ein Entwickler sie durch direktes Mergen umgehen kann. Die Durchsetzungsschicht macht Governance mechanisch. Besteht eine Prüfung nicht, wird der Code nicht gemergt. Keine Ausnahmen, keine Überschreibungen ohne einen auditierbaren Eskalationspfad.

Für KI-generierten Code sind vier Kategorien automatisierter Prüfungen unerlässlich.

• Static Application Security Testing (SAST): Wird während der Bearbeitung und im PR-Workflow gescannt, um Logikfehler zu erkennen, sobald sie generiert werden.
• Software Composition Analysis (SCA): Unerlässlich für die Zuordnung transitiver Abhängigkeiten und die Erkennung von „Phantom“-Paketen, die durch Halluzinationen eingeführt werden.
• Secrets Detection: ML-gestütztes Scannen, das die mathematische Entropie von Zeichenketten analysiert, um zwischen echten Schlüsseln und harmlosen Platzhaltern zu unterscheiden.
• Dynamic Application Security Testing (DAST): Überprüfung des Laufzeitverhaltens der Anwendung durch Simulation realer Angriffe, um sicherzustellen, dass es der beabsichtigten Sicherheitslage entspricht.

Diese vier Prüfungen sollten für alle KI-gestützten Codepfade obligatorisch und nicht umgehbar sein, es sei denn, es liegt eine dokumentierte Ausnahme vor, die von einem namentlich genannten Sicherheitsverantwortlichen genehmigt wurde. Am CI-Gate entscheidet sich, ob Ihr Governance-Framework standhält oder versagt.

Governance für KI-Code im gesamten SDLC: Phasenweise Kontrollen

Die fünf Kontrollebenen sind bestimmten SDLC-Phasen zugeordnet. Dies entspricht der Struktur, die das Secure Software Development Framework (SSDF) des NIST empfiehlt: Governance in jeder Phase, nicht erst am Ende angeflanscht.

• Planung: Richtlinien-Ebene (5.1). Definieren Sie, wo KI-Generierung erlaubt, eingeschränkt oder verboten ist. Klassifizieren Sie Änderungsarten nach Risikostufe.
• Entwicklung: Spezifikations-Ebene (5.2) + Sandboxing-Ebene (5.3). Begrenzen Sie jede Aufgabe mit einer expliziten Spezifikation. Isolieren Sie die Ausführungsumgebung des Agenten.
• Überprüfung: Überprüfungs-Ebene (5.4). Leiten Sie Pull Requests (PRs) nach Risikostufe weiter. Änderungen mit geringem Risiko folgen dem beschleunigten Pfad. Änderungen mit hohem Risiko erfordern namentlich genannte Prüfer mit Domänenexpertise und Sicherheitsfreigabe.
• Build und Test: Durchsetzungs-Ebene (5.5). SAST, SCA, Secrets Detection und DAST steuern den Merge. Keine bestandenen Prüfungen, kein Merge.
• Freigabe: Freigabesteuerung. Änderungen mit hohem Risiko erfordern eine explizite Freigabegenehmigung von einem namentlich genannten Verantwortlichen in jeder Phase (Staging, Produktion). Geringere Risikostufen können bei bestandenen Gates automatisch freigegeben werden.
• Nach der Freigabe: Audit und Nachvollziehbarkeit. Protokollieren Sie, welches Modell den Code generiert hat, gegen welche Spezifikation er generiert wurde, wer ihn überprüft hat, welche Prüfungen er bestanden hat und wann er freigegeben wurde. Speichern Sie bei agentenbasierten Workflows die vollständige Agent-Server-Interaktion (Prompts, Tool-Aufrufe, Ausgaben) in einem unveränderlichen Protokoll. Diese Aufzeichnungen sind Ihr forensischer Pfad bei Vorfällen und Ihre Dokumentation für SOC 2, ISO 27001 oder jedes Compliance-Framework, das die Nachvollziehbarkeit von Codeänderungen erfordert.

Die ersten vier Phasen werden vom Governance-Modell abgedeckt. Release und Post-Release erweitern es in Bereiche, die die meisten Teams für KI-gestützten Code noch nicht formalisiert haben.

Checkliste für Führungskräfte zur Skalierung sicherer KI-gestützter Entwicklung

Wenn Sie die KI-gestützte Entwicklung über einige Early Adopters hinaus ausweiten, werden Ihnen diese sieben Fragen zeigen, ob Ihre Governance bereit ist.

Wenn Sie alle sieben Fragen mit Ja beantworten können, verfügen Sie über ein Governance-Framework. Wenn nicht, zeigen Ihnen die Lücken, wo Sie ansetzen müssen.

KI-generierter Code wird immer besser, schneller und autonomer werden. Die Teams, die von dieser Entwicklung profitieren, sind diejenigen, deren Spezifikationen, Überprüfungsprozesse und CI-Gates bereits auf maschinelle Geschwindigkeit ausgelegt sind. Etablieren Sie die Governance jetzt, solange das Volumen noch überschaubar ist. Sie später unter Druck nachzurüsten, gefährdet die Kontrollen.