Vibe Coding: Wie sicher ist KI-generierter Code?

Was Vibe Coding ist

Den Begriff prägte der KI-Forscher Andrej Karpathy Anfang 2025: Sie beschreiben, was Sie wollen, die KI schreibt den Code, und Sie lesen ihn kaum noch. Was funktioniert, bleibt. Mit Werkzeugen wie Cursor, Claude Code, GitHub Copilot, Lovable oder Bolt entstehen so in Stunden Anwendungen, für die ein Team früher Wochen brauchte.

Das ist ein echter Fortschritt. Das Risiko liegt nicht in der KI, sondern im fehlenden zweiten Blick. Code, den niemand gelesen hat, hat auch niemand geprüft.

Was die Studien zeigen

Veracode lässt Sprachmodelle 80 Programmieraufgaben lösen, bei denen es jeweils eine sichere und eine unsichere Lösung gibt. Im ersten Report 2025 mit über 100 Modellen wählten die Modelle in 45 % der Fälle die unsichere Variante und bauten eine bekannte Lücke aus den OWASP Top 10 ein. Die Ausgabe vom Juli 2026 zeigt kaum Fortschritt: Im Schnitt besteht nur 56 % des KI-Codes die Sicherheitstests, in 44 % steckt eine bekannte Lücke. Selbst das beste Modell kommt auf 68 %. Größere Modelle sind kaum sicherer als kleine.

Die Modelle sind auf funktionierenden Code optimiert, nicht auf sicheren. Und sie lernen von öffentlichem Code, in dem dieselben Fehler millionenfach vorkommen.

Die fünf typischen Lücken in KI-Code

Diese Muster sehen wir in KI-generierten Anwendungen immer wieder:

1. Fehlende Zugriffskontrolle. Der Endpunkt /api/rechnungen/123 liefert die Rechnung. Ändert man die Zahl auf 124, kommt die Rechnung eines anderen Kunden. Die KI hat einen Endpunkt gebaut, der funktioniert, aber nicht prüft, wem der Datensatz gehört. Das ist Platz 1 der OWASP Top 10:2025.
2. Secrets im Code. API-Keys, Datenbank-Passwörter oder Tokens stehen direkt im Quelltext, oder die .env-Datei landet im Repository. Was einmal in der Git-Historie steht, bleibt dort. Betroffene Schlüssel deshalb sofort austauschen. Betroffene Schlüssel deshalb sofort austauschen.
3. Unsichere Standardeinstellungen. CORS für alle Domains offen, Debug-Modus aktiv, fehlende Security-Header, Datenbankregeln bei Supabase oder Firebase ohne Row Level Security.
4. Injection. SQL-Abfragen werden aus Nutzereingaben zusammengesetzt, HTML wird ungefiltert ausgegeben. Ergebnis: SQL-Injection und Cross-Site-Scripting.
5. Erfundene oder veraltete Pakete. KI-Modelle schlagen Bibliotheken vor, die es nicht gibt. Angreifer können genau diese Namen registrieren und dort Schadcode hinterlegen („Slopsquatting“). Dazu kommen veraltete Versionen mit bekannten CVEs. Die OWASP Top 10:2025 haben die frühere Kategorie für veraltete Komponenten deshalb zu A03 Software Supply Chain Failures erweitert.

Warum Ihre Tests das nicht finden

Funktionstests prüfen, ob die Anwendung tut, was sie soll. Sicherheitslücken entstehen dort, wo sie etwas tut, was sie nicht soll. Wenn Nutzer B die Daten von Nutzer A sieht, schlägt kein Test fehl: Die Seite lädt, die Daten sind korrekt formatiert, alles grün.

Genau deshalb braucht KI-Code einen Prüfschritt, der anders denkt als der Code, der ihn erzeugt hat.

So setzen Sie KI-Code sicher ein

Sie müssen nicht auf KI verzichten. Sie brauchen ein paar feste Leitplanken:

• Sicherheit in den Prompt. Fordern Sie ausdrücklich: Berechtigungsprüfung an jedem Endpunkt, parametrisierte Abfragen, keine Secrets im Code, Eingaben validieren.
• Secret-Scanner vor jedem Commit. Werkzeuge wie gitleaks laufen als Pre-Commit-Hook und stoppen Schlüssel, bevor sie im Repository landen.
• Abhängigkeiten prüfen. Jedes neue Paket gegen die echte Registry und gegen bekannte Schwachstellen prüfen, etwa mit osv-scanner. Versionen über ein Lockfile festschreiben.
• Statische Analyse in der CI. semgrep oder vergleichbare Werkzeuge finden unsichere Muster automatisch bei jedem Pull Request.
• Zugriff mit zwei Konten testen. Melden Sie sich als Nutzer A an und versuchen Sie, Daten von Nutzer B zu öffnen. Dieser einfache Test findet viele Fälle der häufigsten Lücke.
• Ein unabhängiges Review vor dem Livegang. Jemand, der den Code nicht geschrieben hat, Mensch oder eigenständiger Prüf-Agent, liest ihn mit der Frage: Wie lässt sich das missbrauchen?

Wann sich ein Audit lohnt

Ein externes Audit ist sinnvoll, sobald Ihre KI-gebaute Anwendung Logins, Kundendaten oder Zahlungen verarbeitet. Typische Anlässe: kurz vor dem Launch, vor einem Gespräch mit Investoren oder wenn ein Kunde einen Sicherheitsnachweis verlangt.

Unser Code-Audit liest Ihr Repository nur lesend, prüft entlang der OWASP Top 10:2025 und liefert jeden Befund mit Fundstelle, CVSS-Bewertung und konkreter Empfehlung. Zum Festpreis von 890 € netto, in 2 Werktagen. Der KI-Anbieter trainiert nicht mit Ihrem Code. Ein Code-Audit ist weder Penetrationstest noch Lasttest. Was der Unterschied ist, lesen Sie in unserem Vergleich Code-Audit oder Penetrationstest.

Dieser Artikel entstand mit Unterstützung automatisierter Recherche und KI. David Kreutzer hat ihn fachlich geprüft und am 1. November 2026 freigegeben.