Wenn die KI den Code schreibt - und die Lücken gleich mit

2026 schreibt die KI mit. In vielen Teams stammt inzwischen ein erheblicher Teil des Codes nicht mehr von Menschen, sondern von Copilot, Cursor & Co. Das ist schnell, das ist bequem - und es bringt ein Problem mit, über das selten geredet wird: Ein großer Teil dieses Codes ist unsicher. Nicht „könnte unsicher sein". Sondern messbar, reproduzierbar unsicher.

Die KI generiert nicht nur Funktionen. Sie generiert Schwachstellen gleich mit - und niemand prüft sie.

Ich sehe dieses Muster seit 2025 immer häufiger in Code-Reviews, technischen Prüfungen und Audits: Code, der funktioniert, sauber aussieht, Tests besteht - und trotzdem eine offene SQL-Injection, einen hartcodierten Token oder eine kaputte Zugriffskontrolle enthält. Der Unterschied zu früher: Diese Lücken kommen jetzt schneller und in größerer Menge rein, weil die KI in Sekunden produziert, was ein Mensch in Stunden geschrieben (und dabei wenigstens kurz nachgedacht) hätte.

Dieser Artikel erklärt, warum das passiert, was es mit der Software-Lieferkette zu tun hat - und vor allem: was Architektur dagegen tut. Denn die Antwort ist nicht „benutzt keine KI". Die Antwort ist: baut Strukturen, die unsicheren Code abfangen, egal wer ihn geschrieben hat.

Warum KI-Code unsicher ist (und es nicht von allein besser wird)

Ein Sprachmodell sagt das statistisch wahrscheinlichste nächste Token voraus. Es wurde auf öffentlichem Code trainiert - und öffentlicher Code ist im Schnitt nicht sicher. Veraltete Beispiele aus Foren, Tutorials mit deaktiviertem CSRF-Schutz, „funktioniert bei mir"-Snippets ohne Input-Validierung: Das alles ist Trainingsmaterial. Das Modell reproduziert die Durchschnittsqualität dessen, was es gesehen hat - nicht die Best Practice.

Die typischen Muster, die ich immer wieder finde

• String-konkatenierte SQL-Queries statt parametrisierter Statements - die KI nimmt die kürzere, „lesbarere" Variante.
• Hartcodierte Secrets in Beispiel-Konfigurationen, die dann nie ersetzt werden.
• Fehlende oder nur im Frontend implementierte Zugriffskontrolle - die KI „weiß" nicht, welche Rolle was darf.
• Veraltete Krypto (MD5, SHA-1) aus alten Trainingsbeispielen.
• Zu großzügige Fehlerausgaben, die Stacktraces und interne Pfade leaken.

Jedes einzelne davon ist harmlos zu beheben - wenn man es findet. Das Problem ist die Menge und die Geschwindigkeit, mit der es entsteht.

Die zweite Front: die Lieferkette

Es bleibt nicht beim Code, den die KI schreibt. Sie entscheidet auch mit, welche Bausteine Sie verwenden. Und hier wird es richtig gefährlich.

Das ergibt eine toxische Kombination: Die KI empfiehlt eine Bibliothek, weil sie in ihren Trainingsdaten oft vorkam - nicht, weil sie aktuell und sicher ist. Schlimmer noch: Angreifer haben begonnen, gezielt Paketnamen zu registrieren, die KI-Modelle „halluzinieren" (sogenanntes Slopsquatting). Dass Sprachmodelle reproduzierbar Pakete erfinden, die es gar nicht gibt, ist in der „package hallucination"-Forschung dokumentiert; Sicherheitsforscher wie Lasso Security haben gezeigt, wie sich genau diese halluzinierten Namen als Angriffsweg missbrauchen lassen. Die KI schlägt ein Paket vor, das es nicht geben sollte - und jemand hat es vorsorglich mit Schadcode hinterlegt.

Was Architektur dagegen tut

Jetzt der Teil, der zählt. Sie können das Tempo der KI nicht verlangsamen - und sollten es auch nicht. Aber Sie können Architektur bauen, die davon ausgeht, dass jeder Code unsicher ist, bis das Gegenteil bewiesen ist. Das ist kein neues Konzept, es heißt Security by Design. Neu ist nur die Dringlichkeit.

1. Die KI nie direkt in die Produktion schreiben lassen

Zwischen „die KI hat es generiert" und „es läuft beim Kunden" gehören Schichten, die nicht verhandelbar sind: automatisiertes Security-Scanning (SAST) im CI, Dependency-Scanning bei jedem Build, und ein menschliches Review für sicherheitskritische Pfade. Die KI darf Vorschläge machen. Sie darf nicht das letzte Wort haben.

2. Die Lieferkette sichtbar machen

Sie können nicht schützen, was Sie nicht kennen. Eine SBOM (Software Bill of Materials) listet jede Abhängigkeit inklusive Transitiv-Dependencies. Kombiniert mit Artifact Signing und automatisiertem CVE-Abgleich wird aus „wir hoffen, die Pakete sind okay" ein „wir wissen es". Jedes neu vorgeschlagene Paket wird gegen eine Allowlist und gegen bekannte Schwachstellen geprüft - automatisch, vor dem Merge.

3. Zugriffskontrolle gehört in die Architektur, nicht in den generierten Code

Wenn Autorisierung eine zentrale, getestete Schicht ist, durch die jede Anfrage muss, dann kann die KI im einzelnen Endpoint vergessen, die Rolle zu prüfen - es greift trotzdem. Verlassen Sie sich nie darauf, dass generierter Code an die richtige Stelle den richtigen Check setzt. Bauen Sie die Struktur so, dass das Vergessen folgenlos bleibt.

4. Eine Prüf-Schicht zwischen Anwendung und KI

Wo KI zur Laufzeit eingebunden ist (Agenten, Assistenten, RAG), braucht es eine Schicht, die Prompts vor der Ausführung bewertet, Policy-Grenzen durchsetzt und Nutzungsmuster überwacht - Stichwort Prompt Injection und Datenabfluss. Das ist Architektur-Arbeit, kein Plugin.

Was das für Ihr Unternehmen bedeutet

Wenn Ihr Team mit KI entwickelt - und das tut es, ob offiziell genehmigt oder nicht - dann ist Ihre Angriffsfläche im letzten Jahr gewachsen, ohne dass jemand eine Entscheidung getroffen hätte. „Shadow AI" nennt man das: Entwickler nutzen Tools, die nie geprüft wurden, und produzieren damit Code, der nie auf Sicherheit getestet wird.

Die gute Nachricht: Genau diese Schwachstellen sind auffindbar. Ein Security-Audit, das gezielt nach KI-typischen Mustern sucht, und eine Architektur, die unsicheren Code strukturell abfängt, holen Sie aus der Gefahrenzone - ohne Ihr Team auszubremsen. Ja, SAST-Gates und Review-Pflicht erzeugen Reibung. Das ist ihr Sinn. Diese Reibung ist gewollt, kalkuliert und um Größenordnungen billiger als der Incident, den sie verhindert.

Die Frage ist nicht, ob Sie KI einsetzen. Die Frage ist, ob Ihre Architektur dem gewachsen ist.

Quellen & weiterführende Belege

Sicherheitsaussagen gehören belegt - gerade in diesem Themenfeld. Die zentralen Zahlen dieses Beitrags stützen sich auf:

• Veracode - GenAI Code Security Report 2025: rund 45 % sicherheitsriskante Schwächen in getestetem KI-Code.
• Akademische Untersuchung von Copilot-Snippets (GitHub-Projekte): ca. 29,5 % betroffene Python- und 24,2 % betroffene JavaScript-Snippets (arXiv).
• Verizon Data Breach Investigations Report (DBIR) 2026: 31 % aller Angriffe beginnen mit der Ausnutzung von Software-Schwachstellen (statt mit gestohlenen Credentials); 48 % setzen auf Ransomware. Betrachteter Zeitraum: 1. November 2024 bis 31. Oktober 2025.
• „Package hallucination"-Forschung & Lasso Security: dokumentierte, reproduzierbar von LLMs erfundene Paketnamen als Angriffsweg (Slopsquatting).

Die Werte variieren je nach Sprache, Modell und Testaufbau erheblich. Sie als Größenordnung zu lesen - nicht als exakte Konstante - ist Teil eines ehrlichen Umgangs mit den Daten.

---