KI-generierter Code: fünf Prüfschritte, bevor er produktiv geht

Code aus einem KI-Coding-Assistenten sieht richtig aus, kompiliert und besteht Tests, und genau das ist das Problem. Teams, die mit Assistenten entwickeln, prüfen deshalb das Ergebnis unter echten Bedingungen: Rechte, Datenabfluss, Verhalten im Fehlerfall, die mitgebrachten Abhängigkeiten und die Frage, ob die Lösung überhaupt die richtige Aufgabe löst. Die fünf Prüfschritte unten gehen das der Reihe nach durch, eine Checkliste für die Pipeline schließt die Seite ab.

Warum Code aus dem Assistenten anders geprüft werden muss

KI-Coding-Assistenten gehören zum Entwickleralltag. Nach der Stack Overflow Developer Survey 2025 nutzen 84 % der Entwickler KI-Werkzeuge oder planen den Einsatz, nach 76 % im Vorjahr. Mit den Werkzeugen ändert sich das Tempo: Ein Assistent erzeugt Code schneller, als ein Mensch ihn lesen kann.

Die Prüfprozesse vieler Teams stammen aus der Zeit davor. Ein Kollege sieht sich den Merge Request an, vor dem Release läuft eine Sicherheitsprüfung. Für von Hand geschriebenen Code hat das gereicht, mit Assistenten wächst die Menge schneller als die Zeit der Prüfer. Kommt die Sicherheit erst am Ende, wird sie zum Flaschenhals: Entweder staut sich die Arbeit vor der Prüfung, oder die Prüfung wird übersprungen. Wie Teams Assistenten einführen und wo sie helfen, beschreibt unsere Seite zu KI-Coding-Assistenten.

Das Ergebnis prüfen, nicht die Erzeugung

Code, der funktioniert, ist noch nicht sicher. Vier Fragen zeigen, ob er es ist:

Rechte: Greift der erzeugte Dienst auf alles zu, was die Datenbank hergibt, oder nur auf das, was er braucht?
Datenabfluss: Schreibt er Daten an Orte, die niemand vorgesehen hat, etwa in ein Protokoll oder auf ein gemeinsames Laufwerk?
Fehlerverhalten: Ist der Anmeldedienst nicht erreichbar oder meldet er einen Fehler, verweigert der Dienst dann den Zugriff (fail closed) oder lässt er ihn durch (fail open)?
Fehlerhafte Eingaben: Was passiert, wenn ein Feld leer, zu lang oder mit Steuerzeichen gefüllt ist?

Ein typischer Fall: Der Vertrieb braucht wöchentlich eine Tabelle mit Kundendaten aus dem ERP, und der Assistent schreibt das Export-Skript in kurzer Zeit. Es läuft, die Tabelle stimmt. Ungeprüft bleibt, dass das Skript mit einem Administratorkonto auf die Datenbank zugreift, alle Spalten exportiert, auch die Bankverbindungen, und die Datei in einem Ordner ablegt, den das ganze Unternehmen lesen kann. Keiner dieser Punkte fällt in einem Test auf, der nur die Tabelle prüft. Dieselbe Vorsicht gilt für alles, was eine Anwendung aus einer Modellantwort übernimmt; OWASP behandelt das als Improper Output Handling (LLM05).

Sicherheit beginnt beim Schreiben

Shift Left heißt, dass die Prüfungen laufen, während der Code entsteht, und nicht erst nach dem Commit. Statische Analyse meldet unsichere Muster schon in der Entwicklungsumgebung. Secret Scanning (die Suche nach Zugangsdaten im Code) findet Passwörter und API-Schlüssel, bevor sie im Repository landen. Richtlinienprüfungen kontrollieren Hausregeln, etwa verbotene Funktionen oder fehlende Protokollierung, und die Abhängigkeitsprüfung schlägt an, sobald ein Paket mit bekannter Schwachstelle hinzukommt.

Je früher ein Fehler auffällt, desto günstiger ist er zu beheben. In der Entwicklungsumgebung kostet er einen Moment, im Produktivbetrieb einen Vorfall. Bei Code aus dem Assistenten zählt das doppelt, weil er in einer Menge entsteht, die eine Prüfung am Ende nicht mehr bewältigt.

Abhängigkeiten gehören zur Generierung

Ein Assistent schreibt nicht nur Code, er bringt Pakete, Bibliotheken und Dienste mit. Oft fällt das niemandem auf: Die neue Zeile im Lockfile geht im Review unter, weil alle auf den Quellcode schauen. Jede Abhängigkeit bringt Fähigkeiten und Risiken mit und gehört deshalb genauso geprüft wie der erzeugte Code. Worauf es dabei ankommt:

Ruf des Pakets: Wer pflegt es, wie aktiv, wie verbreitet ist es?
Bekannte Schwachstellen in der vorgeschlagenen Version.
Lizenz: Passt sie zum geplanten Einsatz, auch im verkauften Produkt?
Herkunft: Stammt das Paket aus dem offiziellen Verzeichnis und vom erwarteten Herausgeber?
Hausstandard: Gibt es im Unternehmen schon eine freigegebene Bibliothek für dieselbe Aufgabe?

Eine Gefahr ist eigen: Assistenten schlagen gelegentlich Paketnamen vor, die es nicht gibt. Registriert ein Angreifer genau diesen Namen und legt Schadcode hinein, installiert das nächste Team, das denselben Vorschlag bekommt, sein Paket. Wie Angriffe über zugelieferte Bausteine funktionieren, steht auf der Seite zu Supply Chain (OWASP LLM03).

Die Absicht hinter dem Code klären

Viele Sicherheitsprobleme haben ihren Ursprung in falschen Annahmen über die Aufgabe. Bevor der Assistent loslegt, gehört geklärt, wer auf die Daten zugreifen darf, welche Aktionen erlaubt sind, welche Geschäftsregeln gelten und was geschützt bleiben muss.

Ein Workflow bereitet die monatlichen Finanzzahlen auf, rechnet korrekt und stellt das Ergebnis in den Teamkanal. In dem Kanal lesen auch Praktikanten und ein externer Dienstleister mit. Der Code ist fehlerfrei, die Anforderung war unvollständig, und genau dort liegt das Problem. König Midas wünschte sich, dass alles zu Gold werde, was er berührt, und bekam genau das. Ein Assistent liefert ebenso, was verlangt wurde. Ob das Verlangte das Richtige war, bleibt Aufgabe des Teams.

Prüfen ist Daueraufgabe

Software ändert sich laufend, mit Assistenten noch schneller. Prüfung gehört deshalb in jeden Schritt des Kreislaufs aus Entwickeln, Testen, Ausrollen, Beobachten und Verbessern, auch nach dem Release. Abhängigkeiten werden überwacht und gepatcht, sobald eine Schwachstelle bekannt wird, und Richtlinien greifen bei jeder Änderung. Wie lange ein Fehler unentdeckt bleiben kann, zeigt ein Fund aus dem Jahr 2026: Das KI-Modell Claude Mythos Preview fand in OpenBSD einen nach Angaben von Anthropic 27 Jahre alten Fehler in der TCP-Verarbeitung, über den ein Angreifer jeden über TCP erreichbaren OpenBSD-Rechner zum Absturz bringen konnte. Der Fehler ist inzwischen behoben, und was solche Funde für den eigenen Patch-Prozess bedeuten, steht auf der Seite zur KI-gestützten Schwachstellensuche.

Agenten, die über Repositories und Pipelines hinweg arbeiten, verschärfen die Lage. Sie ändern Code und Konfiguration in mehreren Repositories in einem Zug, und die Prüfung einzelner Dateien reicht dann nicht mehr. Solche Agenten brauchen eine eigene Identität, damit nachvollziehbar bleibt, wer was geändert hat, dazu enge Zugriffsgrenzen und menschliche Aufsicht. Wie sich Rechte für Agenten zuschneiden lassen, steht auf der Seite zu Excessive Agency (OWASP LLM06).

Prüfschritte für die Pipeline

Acht Punkte, die sich in jede Pipeline einbauen lassen:

Secret-Scan vor dem Commit, damit Zugangsdaten nie im Repository landen.
Statische Analyse in jedem Merge Request, mit den Befunden als Kommentar im Review.
Änderungen an Lockfiles als eigener Prüfpunkt im Review, damit jedes neue Paket bewusst angenommen wird.
Lizenzprüfung für jede neue Abhängigkeit.
Abhängigkeitsprüfung gegen bekannte Schwachstellen, bei jedem Build und regelmäßig für den Bestand.
Absichtsprüfung als Frage im MR-Template: „Wer darf das Ergebnis sehen?“
Testlauf mit fehlerhaften Eingaben: leere, zu lange und manipulierte Werte.
Freigabe durch einen Menschen für alles, was Rechte oder Datenflüsse ändert.

Die Liste gilt auch für Low-Code und n8n-Workflows. Ein Workflow, der mit hinterlegten Zugangsdaten ERP und Postfach verbindet, ist derselbe Fall wie ein Skript mit Datenbankzugang. Wie wir solche Abläufe aufbauen, zeigt unsere Seite zu AI Agents.

Fazit

KI-Coding-Assistenten machen Teams schneller, sicherer machen sie Software nur, wenn die Prüfung mitwächst. Entscheidend ist, ob der Code unter echten Bedingungen das Richtige tut, mit den Rechten, die er braucht, und den Abhängigkeiten, die das Team bewusst angenommen hat. Den Überblick über die übrigen Angriffswege auf KI-Systeme gibt unsere Seite zur KI-Sicherheit.

Weiterführend

How Developers Secure AI-Generated Code: 5 Security Best Practices, IBM Technology, 14.9.2026
KI-Schulung: Teams im Umgang mit KI-Werkzeugen schulen
KI-Sicherheit im Überblick: alle Angriffswege nach OWASP und der Sicherheitscheck

Häufige Fragen

Sollen wir KI-Coding-Assistenten wieder abschaffen?

Nein. Ein Verbot verlagert die Nutzung meist auf private Konten, und dann fehlt jede Kontrolle. Sinnvoller ist ein freigegebener Assistent mit klaren Regeln: welche Repositories er sehen darf, ob Code an einen Cloud-Dienst geht und welche Prüfschritte in der Pipeline laufen. Wer sensiblen Quellcode nicht nach außen geben will, kann einen Assistenten auch mit einem lokal betriebenen Modell nutzen. Das Tempo bleibt, das Risiko wird steuerbar.

Reicht ein Code-Review durch einen Menschen?

Als einziges Mittel nicht. Ein Reviewer sieht den Diff, aber selten die Lizenz eines neuen Pakets, eine bekannte Schwachstelle in der vorgeschlagenen Version oder ein Passwort, das drei Dateien weiter im Klartext steht. Dafür gibt es Werkzeuge, die bei jedem Merge Request laufen. Der Mensch bleibt für das zuständig, was keine Maschine beurteilt: ob die Lösung die richtige Aufgabe löst und ob die Rechte zum Zweck passen. Beides zusammen hält mit dem Tempo des Assistenten mit.

Was tun, wenn der Assistent ein Paket vorschlägt, das wir nicht kennen?

Erst nachsehen, dann installieren, und zwar außerhalb des Assistenten: im Paketverzeichnis selbst und im dort verlinkten Quellcode-Repository. Warnzeichen sind ein Paket, das erst seit wenigen Tagen existiert, ein fehlendes oder leeres Repository und Installationsskripte, die beim Einrichten Code ausführen. Den Installationsbefehl aus dem Chat nicht ungeprüft in die Kommandozeile kopieren. Im Zweifel bitten Sie den Assistenten um eine Lösung ohne zusätzliche Abhängigkeit oder fragen im Team, ob es eine bewährte Alternative gibt.

Gilt das auch für n8n-Workflows und Low-Code?

Ja, und dort wird es oft übersehen, weil niemand den Workflow als Code wahrnimmt. Ein Workflow hält Zugangsdaten, liest und schreibt in Fachsysteme und läuft ohne Aufsicht. Exportieren Sie Workflows in die Versionsverwaltung, damit Änderungen ein Review durchlaufen, und legen Sie die Zugangsdaten mit den engsten möglichen Rechten an. Community-Knoten und Erweiterungen sind Abhängigkeiten wie jedes andere Paket und werden genauso geprüft.

Wer trägt die Verantwortung für Code aus dem Assistenten?

Das Team, das ihn übernimmt. Ein Assistent ist ein Werkzeug wie ein Compiler oder eine Bibliothek; organisatorisch zählt, wer den Code freigibt und betreibt. Praktisch heißt das: Wer einen Merge Request mit erzeugtem Code genehmigt, steht dafür ein wie für selbst geschriebenen. Hilfreich ist eine Teamregel, erzeugten Code im Merge Request als solchen zu kennzeichnen, damit Reviewer wissen, wo sie genauer hinsehen. Wie Teams den Umgang mit KI-Werkzeugen lernen, steht unter KI-Schulung.