Vibe Coding: Warum KI-generierter Code Ihr neues Sicherheitsrisiko ist

55 Prozent. So viele der KI-generierten Codebeispiele haben im Spring 2026 GenAI Code Security Update von Veracode vom 24. März den Sicherheitstest bestanden. Getestet wurden über 150 Modelle mit 80 Programmieraufgaben in vier Sprachen. Syntaktisch korrekt waren mehr als 95 Prozent der Ergebnisse. Der Code kompiliert also fast immer, und in knapp der Hälfte der Fälle steckt eine bekannte Schwachstelle darin.

Bei Java lag die Bestehensquote bei 29 Prozent.

Ich habe diese Zahl zweimal gelesen. Java ist die Sprache, in der bei vielen Banken, Versicherern und Industrieunternehmen im DACH-Raum die Kernsysteme geschrieben sind. Und genau in diesen Häusern werden gerade Lizenzen für Coding-Assistenten in großem Stil ausgerollt.

Was Vibe Coding ist und warum der Begriff in Ihr Unternehmen gehört

Den Begriff hat Andrej Karpathy im Februar 2025 geprägt. Er beschrieb damit eine Art zu programmieren, bei der man sich ganz den "vibes" hingibt und vergisst, "that the code even exists" (Wikipedia, Vibe coding). Collins hat daraus im November 2025 das Wort des Jahres gemacht. Gemeint war ursprünglich das Wochenendprojekt: Man beschreibt, was man haben will, das Modell schreibt, man klickt auf "Accept all" und schaut, ob es läuft.

Professionelle Entwickler grenzen sich davon ab. Im Stack Overflow Developer Survey 2025 sagen 72 Prozent, Vibe Coding sei kein Teil ihrer beruflichen Arbeit. Gleichzeitig nutzen oder planen 84 Prozent der Befragten KI-Werkzeuge, und 51 Prozent der professionellen Entwickler nutzen sie täglich.

Ich halte diese Abgrenzung für ehrlich gemeint und trotzdem für brüchig. Der Entwickler, der am Donnerstagnachmittag noch drei Tickets schließen muss, liest den vierten generierten Vorschlag nicht mehr so gründlich wie den ersten. In Projekten sehe ich oft, dass der Übergang vom geprüften Assistenten-Code zum durchgewinkten Assistenten-Code fließend ist und niemand ihn bemerkt, am wenigsten der Entwickler selbst.

Funktionierender Code besteht den Test, den der Entwickler im Kopf hat

Ein Entwickler prüft generierten Code zuerst darauf, ob er tut, was er soll. Läuft der Endpunkt, kommt das richtige JSON zurück, sind die Tests grün. Eine fehlende Ausgabekodierung fällt bei dieser Prüfung nicht auf, weil sie das Verhalten im Normalfall nicht verändert. Sie fällt erst auf, wenn jemand <script> in ein Namensfeld schreibt.

Die Veracode-Daten zeigen, wo die Modelle gut sind und wo nicht:

Quelle: Veracode, 24.03.2026

SQL Injection und schwache Kryptografie lassen sich an der einzelnen Codezeile erkennen. Parametrisierte Abfrage ja oder nein, SHA-256 oder MD5. Das haben die Modelle gelernt. Bei XSS und Log Injection muss man dagegen verfolgen, woher ein Wert kommt, durch welche Schichten er wandert und wo er wieder ausgegeben wird. Veracode schreibt, das verlange ein Kontextverständnis, das über Mustererkennung hinausgeht, und genau daran scheiterten aktuelle LLMs.

Das deckt sich mit älterer Forschung. Schon 2021 haben Pearce und Kollegen GitHub Copilot mit 89 Szenarien getestet und 1.689 Programme erzeugt, rund 40 Prozent davon waren verwundbar. Noch unangenehmer finde ich die Stanford-Studie von Perry, Srivastava, Kumar und Boneh (CCS 2023). Teilnehmer mit KI-Assistent schrieben dort signifikant unsichereren Code als die Kontrollgruppe und waren zugleich häufiger davon überzeugt, sicheren Code geschrieben zu haben. Wer dem Assistenten weniger vertraute und mehr Arbeit in seine Prompts steckte, produzierte weniger Schwachstellen.

Die Werkzeuge erzeugen also Lücken und zusätzlich das Gefühl, es gebe keine.

Neuere Modelle lösen das Problem bisher nicht

Die naheliegende Hoffnung lautet, das nächste Modell werde es richten. Die Daten geben das nicht her. Veracode hat im ersten Report vom Juli 2025 eine Fehlerquote von 45 Prozent gemessen. Im März 2026 sind es wieder rund 45 Prozent. Laut Veracode bringen auch die jüngsten Flaggschiff-Modelle der großen Anbieter keinen nennenswerten Sicherheitsgewinn, und die Modellgröße wirkt sich nur marginal aus. Eine Ausnahme nennt der Bericht: Die Reasoning-Modelle von OpenAI erreichen 70 bis 72 Prozent. Veracode vermutet, dass die Denkschritte wie ein internes Code-Review wirken. Das ist besser, aber auch bei 72 Prozent bleibt mehr als jedes vierte Ergebnis verwundbar.

Java-Bestände und Coding-Assistenten sind die riskanteste Kombination

Quellen: Veracode, 30.07.2025 und 24.03.2026

Veracode merkt an, dass viele Modelle bei den Java-Aufgaben selbst bei den eigentlich leichten Schwachstellentypen wie SQL Injection deutlich schlechter abschneiden. Die Erklärung der Autoren ist ausdrücklich eine Hypothese: Die Modelle seien mit alten Java-Mustern übertrainiert. Sie lernen aus Häufigkeit, und von Java gibt es sehr viel sehr alten Code im Netz, geschrieben lange bevor Prepared Statements und Ausgabekodierung in jedem Framework Standard waren.

Beweisen kann ich diese Hypothese nicht, plausibel finde ich sie. Und sie trifft auf eine ungünstige Umgebung. Ein gewachsenes Java-System hat oft eigene Hilfsklassen für Logging, selbstgebaute Templating-Schichten und Validierung, die irgendwo in einem Basisprojekt liegt. Der Assistent kennt diese Konventionen nicht, solange ihm niemand davon erzählt. Er ergänzt Code, der zum Stil der umliegenden Datei passt, und wenn diese Datei von 2011 ist, dann passt er eben zu 2011.

Dazu kommt, dass in diesen Systemen die Daten liegen, um die es einem Angreifer geht. Kundenstammdaten, Zahlungsverkehr, Vertragsbestände. Wenn ich priorisieren müsste, wo ich Coding-Assistenten zuerst mit strengen Leitplanken versehe, dann wäre es das Java-Team mit dem fünfzehn Jahre alten Kernsystem. Das Python-Team mit dem internen Dashboard kann warten.

Was ich im SSDLC konkret ändern würde

Die Grundregel steht bereits im Artikel zum Secure Software Development Lifecycle: KI-generierter Code ist ein Entwurf und durchläuft denselben Prozess wie jeder andere Code. Mit den aktuellen Zahlen reicht mir das nicht mehr. Fünf Änderungen halte ich für nötig, dazu kommt ein Blick auf den CRA.

Sicherheitsvorgaben gehören in die Rules-Datei

Veracode testet ohne Sicherheitshinweise im Prompt und formuliert das Ergebnis entsprechend: Knapp die Hälfte des KI-generierten Codes enthält bekannte Schwachstellen, wenn keine Sicherheitsvorgaben mitgegeben werden. Alle gängigen Assistenten lesen heute projektweite Anweisungsdateien. Die OpenSSF hat dazu im August 2025 einen Leitfaden für sicherheitsorientierte Assistenten-Anweisungen veröffentlicht, mit Bausteinen zu Eingabevalidierung, Ausgabekodierung, Secrets, Logging und Abhängigkeiten, auch sprachspezifisch für Java.

Für ein Java-Bestandssystem würde ich dort die hauseigenen Konventionen ergänzen, etwa so:

## Sicherheit (verbindlich)
- Benutzereingaben nie direkt loggen. Immer LogSanitizer.clean() verwenden.
- HTML-Ausgabe nur über die Template-Engine mit aktivem Auto-Escaping.
- SQL ausschließlich über PreparedStatement oder das Repository-Layer.
- Keine neuen Abhängigkeiten ohne Eintrag in der Freigabeliste.

Die Datei liegt im Repository, wird versioniert und vom Security Champion des Teams gepflegt. Wie viel sie bringt, kann ich nicht beziffern, und ich kenne keine unabhängige Messung dazu. Sie ersetzt deshalb keinen der folgenden Punkte.

SAST wird zum Gate

Ein Scan, der Befunde in ein Dashboard schreibt, das niemand öffnet, hilft hier nicht. Bei einer Ausgangsquote von 45 Prozent fehlerhaftem Code muss die Pipeline den Merge bei neuen Befunden der Klassen Injection und XSS blockieren. Veracode empfiehlt verpflichtende SAST-Integration, was bei einem SAST-Anbieter nicht überrascht. Richtig ist es trotzdem. Für die Akzeptanz kommt es aus meiner Sicht darauf an, dass nur neue Befunde im geänderten Code blockieren. Wer beim ersten Lauf sämtliche Altbefunde zum Gate macht, hat das Gate nach einer Woche wieder abgeschaltet.

Review-Pflicht mit Blick auf Datenflüsse

Das Vier-Augen-Prinzip haben die meisten Teams. Neu ist, worauf der Reviewer achten muss. Bei generiertem Code würde ich die Frage "Woher kommt dieser Wert und wo landet er?" zur Pflichtfrage machen, denn genau dort liegen die 13 und 15 Prozent aus der Tabelle oben. BSI und ANSSI formulieren es in ihren gemeinsamen Empfehlungen zu KI-Programmierassistenten vom Oktober 2024 so: Generierter Quellcode sollte grundsätzlich von den Entwicklern geprüft und nachvollzogen werden.

Eine neue Kennzahl

Im SSDLC-Artikel steht die Kennzahl "AI Code Review Rate". Sie setzt voraus, dass Sie wissen, wie viel Code überhaupt aus dem Assistenten stammt. Die meisten Unternehmen wissen es nicht. Ich würde den Anteil KI-geschriebenen Codes pro Repository erheben, über die Nutzungsstatistiken der Assistenten-Lizenzen und über Commit-Kennzeichnungen, die agentische Werkzeuge ohnehin setzen. Die Zahl wird ungenau sein, weil niemand sauber trennen kann, was vorgeschlagen und was danach umgeschrieben wurde. Als Trend reicht sie. Interessant wird sie neben der SAST-Befunddichte: Steigt in einem Repository der KI-Anteil und mit ihm die Zahl neuer Befunde pro tausend Zeilen, wissen Sie, wo Sie nachschärfen müssen.

Schulung gegen das falsche Sicherheitsgefühl

Die Stanford-Studie ist das beste Schulungsmaterial, das ich kenne, weil sie einen messbaren Effekt zeigt und dabei ohne Vorwurf an die Entwickler auskommt. BSI und ANSSI beschreiben dieselbe kognitive Verzerrung und warnen zusätzlich davor, dass Entwickler mit der Zeit die Fähigkeit verlieren könnten, Code gründlich zu prüfen. Zwei Stunden im Rahmen des Security-Champion-Programms mit echten generierten Beispielen aus dem eigenen Code halte ich für wirksamer als jede Richtlinie.

Der CRA fragt nicht, wer den Code geschrieben hat

Ich bin kein Jurist, und das hier ist keine Rechtsberatung. Aber die Logik des Cyber Resilience Act ist einfach: Der Hersteller verantwortet das Produkt. Ab dem 11. September 2026 gelten laut EU-Kommission die Meldepflichten für aktiv ausgenutzte Schwachstellen, ab dem 11. Dezember 2027 die Hauptpflichten. Für den Entstehungsweg einer Lücke sieht die Verordnung nach meiner Lesart keine Sonderbehandlung vor. Wer seine Pipeline ohnehin für den CRA umbaut, wie im Artikel zu CRA und Softwareentwicklung beschrieben, sollte die Gates gleich auf generierten Code auslegen.

Was die Geschäftsführung entscheiden muss

BSI und ANSSI richten vier Kernempfehlungen an das Management. Eine davon wird in Budgetrunden gern überlesen: Der Produktivitätsgewinn der Entwicklungsteams muss durch eine entsprechende Skalierung der Qualitätssicherung, also AppSec und DevSecOps, ausgeglichen werden. Wer spürbar mehr Code produziert und die Prüfkapazität konstant hält, prüft pro Zeile weniger.

Daraus ergeben sich für mich vier Entscheidungen, in dieser Reihenfolge:

Die systematische Risikoanalyse vor Einführung steht ebenfalls wörtlich in den BSI-Empfehlungen. Wenn die Lizenzen bei Ihnen schon ausgerollt sind, holen Sie sie nach. Die vierte Zeile ist die unbequeme. Sie bedeutet, dass ein Teil des Effizienzgewinns, mit dem die Assistenten intern verkauft wurden, in Sicherheit reinvestiert wird. Ich würde diese Diskussion lieber jetzt führen als nach dem ersten Vorfall.

Eine Grenze will ich nennen: Alle Zahlen in diesem Artikel stammen aus Labortests mit isolierten Aufgaben. Wie hoch die Quote in Ihrem Code ist, mit Ihren Frameworks, Ihren Reviews und Ihren Prompts, weiß niemand, solange Sie es nicht messen.

Ein Schritt für diese Woche

Bitten Sie Ihre Entwicklungsleitung um eine einzige Auswertung: die SAST-Befunde der letzten 90 Tage für Ihr wichtigstes Java-Repository, gefiltert auf Cross-Site Scripting und Log Injection, daneben die Zahl der aktiven Assistenten-Lizenzen im selben Team. Wenn es diese Auswertung nicht gibt, weil kein Scanner läuft oder niemand die Lizenzen einem Team zuordnen kann, haben Sie Ihre Antwort auch.

Weiterführend

• Secure Software Development Lifecycle (SSDLC)
• OWASP Security Champion
• CRA und Softwareentwicklung
• Shadow AI

Quellen

• Veracode, "Spring 2026 GenAI Code Security Update: Despite Claims, AI Models Are Still Failing Security", 24.03.2026, https://www.veracode.com/blog/spring-2026-genai-code-security/
• Veracode, "Insights from 2025 GenAI Code Security Report", 30.07.2025, https://www.veracode.com/blog/genai-code-security-report/
• BSI und ANSSI, "German-French recommendations for the use of AI programming assistants" (AI Coding Assistants), 04.10.2024, https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/KI/ANSSI_BSI_AI_Coding_Assistants.html
• Perry, Srivastava, Kumar, Boneh, "Do Users Write More Insecure Code with AI Assistants?", ACM CCS 2023, https://arxiv.org/abs/2211.03622
• Pearce, Ahmad, Tan, Dolan-Gavitt, Karri, "Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions", IEEE S&P 2022, https://arxiv.org/abs/2108.09293
• OpenSSF Best Practices und AI/ML Working Groups, "Security-Focused Guide for AI Code Assistant Instructions", 01.08.2025, https://best.openssf.org/Security-Focused-Guide-for-AI-Code-Assistant-Instructions
• Stack Overflow, "2025 Developer Survey, AI", 2025, https://survey.stackoverflow.co/2025/ai
• Wikipedia, "Vibe coding", https://en.wikipedia.org/wiki/Vibe_coding
• Europäische Kommission, "Cyber Resilience Act", https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act