Vibe-Code-Risiken: Was in KI-Code schiefgeht
Aktualisiert am 13.10.2026
«Vibe Coding» heisst: Man beschreibt einer KI, was man will, und übernimmt, was sie liefert — oft ohne jede Zeile zu lesen. Das funktioniert erstaunlich gut, solange man nur auf das Ergebnis im Browser schaut. Die Frage ist, was man dabei nicht sieht. Dazu gibt es inzwischen belastbare Forschung.
Was die Forschung misst
Drei Befunde ziehen sich durch:
- Funktionierender Code ist nicht sicherer Code. In der Untersuchung von Veracode (2025) bauten die getesteten Modelle in 45 % der Aufgaben eine Sicherheitslücke ein — obwohl es jeweils eine sichere Lösung gab. Bei Cross-Site-Scripting und Log-Injection war der Anteil unsicherer Lösungen besonders hoch.
- Modelle erfinden Abhängigkeiten. Spracklen und Kollegen (USENIX Security 2025) fanden in 19,7 % aller vorgeschlagenen Pakete Namen, die es gar nicht gibt — viele davon reproduzierbar immer wieder dieselben. Wer einen solchen Namen registriert, kann Schadcode in fremde Projekte schmuggeln. Der Angriff hat inzwischen einen Namen: Slopsquatting.
- Menschen werden unvorsichtiger. In der Stanford-Studie von Perry und Kollegen (ACM CCS 2023) schrieben Teilnehmende mit KI-Assistent unsichereren Code als ohne — und hielten ihn zugleich häufiger für sicher. Das ist der eigentliche Kern des Problems: Nicht nur der Code wird schwächer, auch die Kontrolle.
Auch die Behörden sehen das so: BSI und die französische ANSSI haben 2024 eine gemeinsame Einschätzung zu KI-Programmierassistenten veröffentlicht. Sinngemäss: Die Werkzeuge steigern die Produktivität, erzeugen aber keinen Code, dem man ohne Prüfung vertrauen darf.
Die acht Muster, die wir am häufigsten sehen
Aus dem Betrieb unserer eigenen Plattform für KI-gebaute Anwendungen und aus Begutachtungen:
- Berechtigung nur im Frontend. Knöpfe sind ausgeblendet, der Server prüft aber nicht, wer fragt. Die häufigste schwere Schwachstelle überhaupt.
- Geheimnisse im Code. API-Schlüssel im Quelltext, im ausgelieferten JavaScript oder in der Git-Historie — «später entfernt» heisst nicht «weg».
- Erfundene oder verwaiste Pakete. Siehe oben; dazu veraltete Versionen, weil das Modell den Stand seines Trainings kennt, nicht den von heute.
- Offene Datenbank-Regeln. Backend-Dienste mit Standard-Freigaben, Zeilenrechte «kommen noch».
- Platzhalter in Produktion. Test-Logins, Beispieldaten, auskommentierte Prüfungen.
- Kopieren statt strukturieren. Dieselbe Regel steht an vier Stellen — und wird an einer korrigiert.
- Kein Betrieb mitgedacht. Keine Sicherung, keine sinnvollen Logs, kein Update-Weg.
- Personendaten ohne Konzept. Alles wird gespeichert, nichts gelöscht; Drittdienste werden nebenbei eingebunden.
Gemeinsam ist allen acht: In der Demo sieht man keines davon. Die Anwendung funktioniert, sieht gut aus, und der Fehler wartet im Repository, in der Konfiguration oder im Betrieb.
Was daraus folgt
Nicht, dass man auf KI verzichten sollte — der Produktivitätsgewinn ist real. Sondern, dass KI-gebaute Software vor dem Produktivbetrieb dieselbe Frage beantworten muss wie jede andere: Wer hat das geprüft, und woran? Bei klassischer Entwicklung erledigt das ein Teil des Teams im Alltag (Review, Tests, Architekturentscheidungen). Beim Vibe Coding fehlt dieser Teil oft komplett — er muss nachgeholt werden.
Quellen
- Veracode: 2025 GenAI Code Security Report, Pressemitteilung vom 30.07.2025 — veracode.com
- Spracklen, Wijewickrama, Sakib, Maiti, Viswanath, Jadliwala: We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs. USENIX Security 2025 — arXiv:2406.10279
- Pearce, Ahmad, Tan, Dolan-Gavitt, Karri: Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions. IEEE S&P 2022 — arXiv:2108.09293
- Perry, Srivastava, Kumar, Boneh: Do Users Write More Insecure Code with AI Assistants? ACM CCS 2023 — arXiv:2211.03622
- BSI und ANSSI: AI Coding Assistants, 04.10.2024 — bsi.bund.de (PDF)