Vibe Coding: Der blinde Fleck der KI

Wir haben 50 echte KI-generierte Projekte auf GitHub gescannt. 88 Prozent haben kritische Sicherheitslücken. Was die Daten über den blinden Fleck von Vibe Coding verraten, und was Entwickler jetzt konkret tun können.

Es gibt diesen Moment: Der Code läuft. Die Demo beeindruckt. Deployen. Was dabei fehlt, ist nicht sichtbar, und genau das ist das Problem. Die Sicherheitslücken stecken nicht im sichtbaren Fehler, sondern im fehlenden Schutz. Wir wollten wissen, wie verbreitet das ist. Also haben wir es gemessen.

50 Repos, eine klare Antwort

Für eine eigene Sicherheitsstudie haben wir 50 öffentliche GitHub-Projekte gescannt, die nachweislich mit KI-Coding-Werkzeugen entstanden sind, erkennbar an Konfigurationsdateien wie .cursorrules oder CLAUDE.md. Keine Laborbedingungen. Echte Projekte, von echten Entwicklern, deployed wie sie sind.

Das Ergebnis: Der durchschnittliche Sicherheits-Score lag bei 34 von 100 möglichen Punkten. 88 Prozent der Projekte hatten mindestens eine Schwachstelle mit hohem Schweregrad. Mehr als jedes zweite Projekt (52 Prozent) enthielt mindestens eine direkt ausnutzbare, kritische Lücke. Und 36 Prozent hatten API-Keys, Datenbankpasswörter oder Zugangsdaten direkt im Quellcode, offen einsehbar für jeden, der das Repository findet.

Das ist kein Randproblem schlecht formulierter Prompts. Das ist der Standard-Output der meistgenutzten Entwicklungswerkzeuge der Welt.

Was KI systematisch vergisst

Die häufigste Schwachstellenkategorie: Injection-Angriffe, also SQL-, Command- und verwandte Vektoren, mit 200 bestätigten Findings. Dahinter folgen Path-Traversal-Lücken (87), Authentifizierungsprobleme (39) und hart codierte Zugangsdaten (38). Was diese Zahlen interessant macht: Es handelt sich überwiegend nicht um Fehler im Code. Es handelt sich um Fehler durch fehlenden Code.

Das hat einen strukturellen Grund: KI-Modelle werden auf öffentlichem Code trainiert. Dieser Code enthält funktionierende Beispiele, aber keinen Sicherheitskontext. Ein Modell lernt, welcher Code häufig vorkommt und als korrekt gilt, aber nicht, welcher in einer spezifischen Produktionsumgebung sicher ist. Wer einen API-Endpunkt per Prompt erstellt, bekommt einen funktionalen Endpunkt. Die Frage „Kann dieser Endpunkt in einer Sekunde tausendmal aufgerufen werden, ohne dass das System zusammenbricht?“ stellt das Modell nicht von sich aus.

Warum klassische Scanner das Problem nicht lösen

Ein zentraler Befund der Studie: Ein erheblicher Teil der Schwachstellen wäre mit herkömmlichen statischen Code-Analyse-Tools (SAST) unsichtbar geblieben. Tools wie Semgrep arbeiten regelbasiert: Sie erkennen bekannte Muster im Code. Einen fehlenden Rate-Limiter zu erkennen bedeutet aber, sichtbar zu machen, was nicht da ist. Das übersteigt das Konzept regelbasierter Analyse grundsätzlich.

Sichtbar wird dieses Problem auch in der Qualitätssicherung der Analyse selbst: Von 1.087 Findings, die einem KI-basierten Validierungsschritt unterzogen wurden, waren 486 davon False Positives, das entspricht 45 Prozent. Jedes einzelne wurde mit einer konkreten Begründung entfernt: „Der SQL-Query nutzt parametrisierte Abfragen, keine Injection möglich.“ Oder: „Das Secret steht in einer Beispieldatei mit dem Platzhalter your_key_here und ist nicht produktiv.“

Herkömmliche Scanner hätten all diese Warnungen ungefiltert ausgegeben. Das Ergebnis wäre eine Liste von Hunderten Meldungen, von denen fast die Hälfte keine echten Probleme beschreibt. Alert Fatigue ist einer der Hauptgründe, warum Security-Checks in der Praxis ignoriert werden: Wenn jede Analyse Lärm erzeugt, hört man irgendwann auf zuzuhören.

Bimodale Verteilung: Sicherheit ist eine Entscheidung

Ein unerwartetes Muster in den Daten: Die Score-Verteilung ist bimodal. 46 Prozent der Projekte liegen unter 30 Punkten, also im kritischen Bereich. Gleichzeitig erreichen 8 Prozent über 90. Die Mitte zwischen diesen Polen ist dünn besetzt.

Diese Polarisierung hat eine klare Ursache: Die Projekte mit hohen Scores haben aktiv Sicherheitsmaßnahmen implementiert. Dependency-Pinning, strukturiertes Secrets-Management, explizit definierte Authentifizierungsschichten. Diese Entscheidungen entstehen nicht zufällig. Sie müssen bewusst getroffen werden.

Das bedeutet: Vibe Coding produziert nicht automatisch mittelmäßig sichere Anwendungen. Es produziert entweder sehr unsichere oder, bei bewusstem Umgang, überraschend gute. Sicherheit in KI-gestützter Entwicklung ist kein Qualitätsmerkmal, das sich von selbst ergibt. Es ist eine Entscheidung, die vor dem ersten Deployment getroffen werden muss.

Was Entwickler jetzt tun können

Die gute Nachricht aus den Daten: Die Projekte mit hohen Scores haben keine komplexen Security-Frameworks eingesetzt. Der Unterschied liegt in fünf strukturellen Maßnahmen, die zusammen weniger als eine Stunde Einrichtungszeit kosten:

• Dependency-Scanning: Jede importierte Bibliothek kann bekannte CVEs mitbringen. Tools wie npm audit oder pip-audit identifizieren diese automatisch, als Pre-Commit-Hook oder in der CI/CD-Pipeline. KI generiert Code mit Abhängigkeiten; wer deployt, muss prüfen, ob diese sicher sind.

• Keine Secrets im Code: 36 Prozent der gescannten Projekte hatten Credentials inline. KI optimiert für Demo-Kontexte. Wer deployt, muss diesen Schritt explizit revidieren: Umgebungsvariablen statt Hardcoding, dazu ein einfacher Pre-Commit-Hook wie git-secrets oder detect-secrets.

• Schutzmechanismen explizit anfragen: Rate-Limiting, CSRF-Schutz und Input-Sanitization entstehen nicht automatisch. Sie müssen im Prompt spezifiziert oder in einem zweiten Schritt ergänzt werden. Ein gezielter Review-Prompt wie „Prüfe diesen Code auf fehlende Sicherheitsschichten“, liefert dem Modell den Kontext, den es braucht.

• Environment-Separation: Debug-Modi, verbose Logging und Test-Credentials gehören nicht in Produktionsumgebungen. Diese Trennung muss explizit erfolgen, idealerweise durch unterschiedliche Konfigurationsdateien, die nie in dasselbe Repository landen.

• Statische Analyse in die Pipeline: Semgrep, Bandit oder ESLint-Security-Plugins fangen bekannte Angriffsmuster ab, bevor sie deployed werden. Als Pre-Commit-Hook oder im CI/CD-Prozess läuft diese Prüfung ohne manuelle Intervention.

Diese fünf Punkte verhindern die häufigsten Angriffsvektoren aus unserer Studie. Sie erfordern keine Security-Expertise, nur die Entscheidung, sie einzubauen, bevor der erste echte Nutzer auf den Deploy-Button klickt.

Deploy mutig, aber nicht blind

KI-Coding-Werkzeuge senken die Barriere für das Bauen digitaler Produkte dramatisch. Das ist gut. Aber sie verlagern auch Verantwortung: Wer mit KI-generiertem Code arbeitet, übernimmt implizit die Security-Verantwortung, die früher ein Team von Spezialisten getragen hat.

Die Daten zeigen: Diese Verantwortung wird heute mehrheitlich nicht wahrgenommen. Nicht aus Fahrlässigkeit, sondern weil die Lücke zwischen Entwicklung und sicherem Deployment unsichtbar ist. Wer nicht weiß, dass Rate-Limiting fehlt, baut es nicht ein.

Der blinde Fleck ist nicht die KI. Der blinde Fleck ist der Schritt zwischen „es funktioniert“ und „es ist bereit“. Wer diesen Schritt bewusst einplant, kann mutig deployen.