Die Sicherheitsrisiken bei Vibe Codierung sind nicht mit gewöhnlichen Sicherheitsrisiken vergleichbar.

Es war wohl unvermeidlich, dass Vibe Codierung eine Kettenreaktion komplexer Veränderungen in den Programmierpraktiken und der Softwareentwicklung auslösen würde. Da KI-generierter Code einen immer größeren Anteil an realen Codebasen ausmacht, besteht eine der folgenreichsten Veränderungen in einer deutlichen Verschiebung der Anzahl der Cybersicherheitsrisiken – und der Art dieser Sicherheitsrisiken.

Kurz gesagt, Vibe Codierung lässt sich als der Ansatz beschreiben, Produkte ausschließlich mit KI-Tools und Prompts in natürlicher Sprache zu entwickeln. Es sollte als Unterscheidung von agentischer Codierung oder agentischer Technik verstanden werden, die einen gezielteren Einsatz von AI-Coding-Tools durch einen erfahrenen Programmierer erfordern. Der Begriff wurde in einem Tweet von Andrej Karpathy geprägt – einem angesehenen Entwickler und KI-Veteranen –, in dem er einen unkonventionellen Stil der KI-Coding beschrieb, der sich ausschließlich auf die Eingabeaufforderung Large Language Models (LLM) stützt und es dem Benutzer ermöglicht, sich „vollkommen den Vibes hinzugeben“ und „zu vergessen, dass der Code überhaupt existiert“.

Er bezeichnete dies als unterhaltsamen Ansatz für „kurzfristige Wochenendprojekte“, doch die zunehmende Verbreitung leistungsfähiger KI-Codierung hat den Weg für „Vibe-Coding“ am Arbeitsplatz geebnet – sogar bei Produktionssoftware, die sensible Daten verarbeitet. Ende 2025 zeigen Branchenforschung, dass KI-generierter Code mittlerweile 22 % aller zusammengeführten Codes ausmacht.¹ Auf GitHub schätzen Berichte, dass 46 % des gesamten geschriebenen Codes von Copilot generiert wurden.²

Dies hat zu einer erheblichen Zunahme von Schwachstellen und Sicherheitsproblemen geführt, die über das hinausgeht, was sich durch den natürlichen Anstieg des Umfangs und der Geschwindigkeit neuer Code-Erstellung erklären ließe, den Codierungsassistenten ermöglichen. Eine Analyse realer Codebasen ergab, dass KI-unterstützte Teams zwar viermal schneller Code veröffentlichten, dabei jedoch zehnmal so viele Sicherheitslücken verursachten.³

Ein vollständiger Verzicht auf „Vibe-Coding“ würde erhebliche Produktivitätsgewinne durch Automatisierung und eine stärkere Einbindung der Mitarbeiter zunichte machen; es ist jedoch klar, dass sich die Praktiken der sicheren Codierung entsprechend weiterentwickeln müssen. Herkömmliche Sicherheitsprüfungen sind darauf ausgelegt, die Art und Weise zu berücksichtigen, wie Entwickler – genauer gesagt, geschulte menschliche Entwickler – typischerweise Fehler begehen. Unternehmen benötigen heute einen zeitgemäßen Sicherheitsstatus und moderne Sicherheitstools, die auf die neue Realität zugeschnitten sind, die durch KI-Agenten und unerfahrene Vibe-Programmierer geprägt ist.

Branchenstudien zeigen über verschiedene Plattformen, Umgebungen und große Sprachmodelle hinweg durchweg, dass eine zunehmende Nutzung der KI-gestützten Codegenerierung mit einer Zunahme von Schwachstellen im Bereich der Anwendungssicherheit (AppSec) einhergeht.

Einige Beispiele:

• Eine im Dezember 2025 durchgeführte Untersuchung von Open-Source-Repositories ergab, dass durch KI generierter Code bei 45 % der Entwicklungsaufgaben Sicherheitslücken verursachte. Beim Vergleich von KI-gestützten Pull-Requests (PRs) mit ausschließlich von Menschen erstellten PRs stellten die Forscher fest, dass KI-gestützte PRs 2,74-mal mehr Sicherheitsprobleme (und insgesamt 1,7-mal mehr Probleme) verursachten als von Menschen verfasster Code.⁴

• Ein Bericht von GitGuardian aus dem Jahr 2026 über Secret Sprawl kommt zu dem Schluss, dass durch Claude Code unterstützte Commits vertrauliche Informationen mehr als doppelt so häufig offenlegten wie Commits, die ausschließlich von Menschen erstellt wurden. Insgesamt stieg die Anzahl der in öffentlichen GitHub-Commits offengelegten, fest codierten Geheimnisse (wie Passwörter und API-Schlüssel) im Jahr 2025 im Vergleich zum Vorjahr um 34 % – der größte jemals verzeichnete Anstieg innerhalb eines Jahres.⁵ 

• In einem Bericht vom Oktober 2025 wurde festgestellt, dass kritische Sicherheitslücken und Datenlecks in mit Vibe programmierten Anwendungen, wie beispielsweise falsch konfigurierte APIs und andere Authentifizierungsprobleme, häufig „offen“ lagen und direkt über öffentliche Endgeräte zugänglich waren.⁶

Sicherheitsteams sollten zudem berücksichtigen, dass öffentliche Repositorys auf GitHub (und ähnlichen Diensten) lediglich die sichtbare Spitze des Eisbergs darstellen. GitGuardian weist darauf hin, dass interne Repositorys mit sechsmal höherer Wahrscheinlichkeit fest codierte Geheimnisse enthalten als öffentliche Repositorys.

Ebenso besorgniserregend ist die Tatsache, dass sensible Anmeldedaten, die durch „Vibe-Coding“ offengelegt werden, offenbar seltener behoben und abgestellt werden als Sicherheitsprobleme, die durch herkömmliche Codierungs-Workflows entstehen. In dem Bericht von GitGuardian wurde festgestellt, dass fast 70 % der offengelegten Zugangsdaten, die im Jahr 2022 als gültig bestätigt worden waren, bis Januar 2025 gültig blieben. 64 % waren im Januar 2026 noch immer exponiert und nicht widerrufen. In einem besonders bemerkenswerten Vorfall hat Football Australia versehentlich seine AWS-Zugriffsschlüssel im Quellcode seiner Website offengelegt – diese blieben über 700 Tage lang einsehbar.

Insgesamt deuten diese Muster darauf hin, dass sich Sicherheitsrisiken im Zusammenhang mit der Vibe-Codierung schneller häufen, als dies mit herkömmlichen Abhilfemaßnahmen bewältigt werden kann.

Die Häufigkeit und das Ausmaß der durch KI verursachten Sicherheitslücken scheinen auch dann noch anzuhalten, wenn sich die Funktionalität der großen Sprachmodelle (LLM) weiter verbessert. Branchenbeobachter haben daher darauf hingewiesen, dass die Trainings-Pipelines und Benchmarks, die zur Optimierung und Validierung der Modellleistung verwendet werden, nicht immer von Natur aus auf die sichere Codegenerierung in der Praxis abgestimmt sind.⁴ In den meisten Studien wird von KI generierter Code isoliert bewertet, wobei der Schwerpunkt auf der Korrektheit – also darauf, ob er sich einfach kompilieren lässt, läuft und seine Aufgabe ausführt – sowie auf der Leistung bei synthetischen Benchmarks liegt.⁷

In Unternehmensentwicklungsumgebungen funktionieren Modelle jedoch nicht isoliert. Der Bericht von GitGuardian stellte fest, dass LLM-bezogene Infrastrukturen, wie Dienste für Orchestrierung, Retrieval-Augmented Generation (RAG) oder Speicher, Geheimnisse mit einer fünfmal höheren Rate offenlegten als die von Kernmodellanbietern.⁵

Mit anderen Worten: Viele Sicherheitsrisiken der Vibe-Codierung resultieren nicht aus den LLMs selbst, sondern aus dem Ökosystem, in dem die Modelle verwendet werden. Neu veröffentlichte Inferenzanbieter, Gateways, Registries und Integration treten schnell in Workflow ein – oft zu schnell, als dass der Sicherheitsstatus (oder unerfahrene Vibe-Programmierer) Schritt halten könnten.

Agentische KI fügt Sicherheitsaspekten zusätzliche Komplexität hinzu: Wenn einem KI-Agenten lokaler Zugriff auf Dateien, Zugangsdatenspeicher und Terminals gewährt wird, kann der Computer selbst zu einer weiteren potenziellen Angriffsfläche werden. Prompt-Injection und Angriffe auf die Lieferkette, bei denen offengelegte lokale Anmeldedaten ausgenutzt werden, können sich zu Risiken für das Unternehmen ausweiten. Im berüchtigten Shai-Hulud-Wurm, der Ende 2025 das weltweit größte JavaScript-Register kompromittierte, waren fast 60 % der kompromittierten Rechner keine persönlichen Arbeitsplätze – es waren Continuous Integration/Continuous Delivery (CI/CD) Runner⁴ (deren Zweck ironischerweise die Automatisierung von Sicherheitstests und die Sicherstellung der Codequalität ist).

Ein wichtiger Faktor, der die Sicherheitsrisiken beim Vibe-Coding verschärft, ist die Art und Weise, wie KI-gesteuerte Codeänderungen in der Regel gebündelt werden: Im Durchschnitt erstellen KI-unterstützte Entwickler mehr als dreimal so viele Commits wie ihre Kollegen, die ohne KI arbeiten, bündeln diese Commits jedoch in deutlich weniger – und dafür wesentlich umfangreicheren – Pull-Requests (PRs). Diese „Vibe“-codierten PRs sind in der Regel umfangreicher und betreffen mehrere Dateien und Dienste.

Im „Developer Habits Report“ von Cursor, der im Frühjahr 2026 veröffentlicht wurde, wurde festgestellt, dass die durchschnittliche Anzahl an Codezeilen pro Pull-Request im Vergleich zum Vorjahr um rund 250 % gestiegen war (und dass sich die Wachstumsrate selbst weiter beschleunigte). Der Anteil der „Mega-PRs“ – die von Cursor als PRs definiert wurden, die Änderungen an mindestens 1.000 Codezeilen enthalten – stieg von 8 % aller PRs im Januar 2025 auf 13,9 % aller PRs im Mai 2026.⁸

Große, weitläufige PRs, die viele Teile der Codebasis berühren, sind viel schwieriger zu überprüfen als kleinere, gezieltere PRs. Einzelne Änderungen an einem Dienst oder Code-Block erfordern unter Umständen zusätzliche Änderungen an anderer Stelle, um nachgelagerte Probleme zu vermeiden; diese Nebeneffekte werden jedoch bei einer Code-Review eher übersehen, wenn der zu prüfende Pull-Request einen „Schrotflintenansatz“ (Shotgun Approach) verfolgt, der die Aufmerksamkeit des Prüfers verwässert. Eine Untersuchung von Apiiro, einer AppSec-Plattform, ergab, dass das PR-Volumen bei KI-gestützten Teams zwar um fast ein Drittel zurückging, diese Teams jedoch zehnmal mehr Sicherheitsmängel in die Produktion einbrachten.³

Kurz gesagt, KI beschleunigt jeden Teil der Codeerstellung – einschließlich der schlechten Angewohnheit, zu viele Änderungen auf einmal umzusetzen. Die Konzentration und Beschleunigung des Wandels kann auch das Risiko jeder einzelnen Fusion verstärken und beschleunigen.

Eine groß angelegte Studie mit 500.000 Code-Beispielen, die auf dem 36. IEEE International Symposium on Software Reliability Engineering (ISSRE 2025) vorgestellt wurde, kam zu dem Ergebnis, dass „sich von KI generierter Code von von Menschen geschriebenem Code nicht nur hinsichtlich der Anzahl der Sicherheitslücken, sondern auch hinsichtlich ihrer Art und Verteilung unterscheidet.“ 

Dies wirft eine existenzielle Frage auf: Bestehende Frameworks zur Bewertung der Codequalität und von Sicherheitslücken sind „menschenzentriert und basieren auf Annahmen über die menschliche Wahrnehmung, Fehlermuster und Überprüfungsprozesse“. Von KI generierter Code weist deutlich abweichende Eigenschaften und Tendenzen auf, weshalb diese auf den Menschen ausgerichteten Rahmenkonzepte für dessen Bewertung ungeeignet sind.⁷

Erschwerend kommt hinzu, dass Untersuchungen zu Sicherheitsrisiken bei der Vibe-Codierung zudem zahlreiche neu auftretende Angriffsarten aufgedeckt haben, für die es in von Menschen programmierter Software keine Entsprechung gibt.

Große Sprachmodelle (LLMs) und die von ihnen gesteuerten KI-Programmierwerkzeuge neigen dazu, Pakete zu empfehlen, die in Wirklichkeit gar nicht existieren – und Untersuchungen haben ergeben, dass diese „halluzinierten“ Paketnamen manchmal in verschiedenen Szenarien und sogar bei unterschiedlichen Modellen wiederholt auftreten. Slopsquatting, eine Art Paket-Halluzination-Angriff, nutzt diese Tendenz aus.

Slopsquatting-Angreifer beobachten die Namen halluzinierter Pakete, die LLMs wiederholt generieren, und registrieren diese (zuvor) fiktiven Paketnamen vorab in öffentlichen Registern. Wenn Vibe-Coder, die oft mit gängigen Paketen überhaupt nicht vertraut sind (und daher ein gefälschtes Paket wahrscheinlich nicht erkennen), Code einchecken, der diese Paketnamen enthält, installieren sie unwissentlich bösartigen Code.

In der traditionellen Softwareentwicklung gibt es hierfür kein Pendant. Es ist unwahrscheinlich, dass ein menschlicher Programmierer ein Paket „hervorbringt“, das nicht existiert – und selbst wenn dies der Fall wäre, wäre es für einen potenziellen Angreifer sowohl unmöglich als auch unpraktisch, dies vorherzusehen, den Namen des „hervorgebrachten“ Pakets zu erraten und bösartigen Code unter diesem Paketnamen zu registrieren.

Regeldatei-Backdoor-Angriffe nutzen die Konfigurationsdateien („Regeln“) aus, die zur Anpassung des Verhaltens von KI-Agenten bei der Generierung oder Änderung von Code auf Plattformen wie Cursor, GitHub Copilot und Claude Code verwendet werden. 

Angreifer verändern typischerweise beliebte Open-Source-Regeldateien und betten bösartige Anweisungen in Form versteckter Unicode-Zeichen ein, die nahezu unmöglich zu erkennen sind. Sobald diese Änderungen übernommen wurden, wird dieser Schadcode bei jeder nachfolgenden KI-Codierungssitzung aktiviert, die auf die infizierte Regeldatei verweist. Infolgedessen ist jeglicher Code, der während solcher Sitzungen generiert wird, kompromittiert – doch da die kompromittierte Ausgabe aus Unicode-Zeichen besteht, die im Wesentlichen unsichtbar sind, erscheint sie bei der Codeüberprüfung als fehlerfrei.

Das Ziel der Angreifer besteht in der Regel darin, Sicherheitslücken und „Hintertüren“ in den anschließend generierten Code (und die Anwendungen, die diesen Code verwenden) einzuschleusen, die sie später ausnutzen können.

Mit dem Wissen um diese spezifischen Muster sollten Unternehmen ihre bewährten Sicherheitsverfahren aktualisieren, um die Vorteile von KI-generiertem Code zu nutzen, ohne Opfer jener Sicherheitslücken zu werden, die durch wahlloses „Vibe-Coding“ entstehen.

Während das Potenzial für diese Sicherheitslücken aus den Unvollkommenheiten von AI-Coding-Werkzeugen resultieren mag, ist die Realisierung dieser Risiken ein Versagen der menschlichen Aufsicht. Letztendlich haben die Entwickler nach wie vor die Kontrolle darüber, welche Ergänzungen und Änderungen angenommen, überarbeitet oder ignoriert werden. Coding-Assistenten bauen ihre integrierten Sicherheitsvorkehrungen kontinuierlich aus und verbessern sie, doch die Überprüfung durch den Menschen bleibt die letzte Barriere, die verhindert, dass Sicherheitslücken in die Produktion gelangen – weshalb die Standardeinstellungen von IBM Bob in jeder Phase manuelle Überprüfungen und eine Freigabe durch den Menschen vorsehen.

Dennoch gibt es Möglichkeiten, die Effizienz der manuellen Überprüfung zu verbessern.

• Fehler, die in riesigen, weitläufigen Pull-Requests verborgen sind, lassen sich bei einer Sicherheitsüberprüfung deutlich schwerer aufspüren als solche, die in gezielteren Pull-Requests zu finden sind. Sicherheitsteams sollten entsprechende Richtlinien für die Größe von PRs umsetzen.

• Pakete sollten besonders sorgfältig geprüft werden, um das Risiko von „Slopsquatting“-Angriffen zu minimieren. Sicherheitsteams sollten beachten, dass mit jeder neuen Iteration eines bestimmten KI-Modells neue Muster von „Paket-Halluzinationen“ auftreten können.

• Sowohl Entwickler als auch Sicherheitsteams sollten sich mit den Unterschieden zwischen von Menschen geschriebenen und von KI generierten Codefehlern vertraut machen.

Unternehmen sollten KI-generierten Code als eigenständige Kategorie von Eingabedaten betrachten, die spezifische, eigens dafür vorgesehene Sicherheitsmaßnahmen erfordert (anstatt die KI-Ergebnisse lediglich in standardmäßige, auf Menschen ausgerichtete Überprüfungsprozesse zu integrieren).

Als allgemeiner Grundsatz gilt, dass Unternehmen jeglichen durch KI generierten Code oder Module als nicht vertrauenswürdige Eingabe behandeln sollten, genauso wie sie Code aus externen Bibliotheken behandeln würden. Sicherheitsprüfungen mittels statischer Analyse (SAST) sollten eine obligatorische Kontrollinstanz darstellen, die alle KI-Beiträge durchlaufen müssen, bevor sie in den Quellcode aufgenommen werden. Regeldateien von Drittanbietern – wie beispielsweise Open-Source-Dateien, vorkonfigurierte Cursor-Regeln, Claude.md-Dateien, Copilot-Anweisungen oder Bob-Modi – sollten gründlich geprüft und anschließend selektiv in eine Whitelist aufgenommen werden, anstatt standardmäßig zugelassen zu werden.

Die kontinuierliche Weiterentwicklung agentischer Engineering-Plattformen bietet die Möglichkeit, Feuer mit Feuer zu bekämpfen – und zwar durch KI-gestützte Erkennung von Geheimnissen, bei der KI-spezifische Zugangsdaten wie LLM-API-Schlüssel oder Token für Vektordatenbanken über eigene, speziell dafür entwickelte Erkennungssignaturen verfügen.

IBM Bob verfügt beispielsweise über integrierte Tools zur Durchsetzung sicherer Programmierung und Zugriffskontrolle in großem Maßstab durch eine Kombination aus benutzerdefinierten Bob-Modi, der Integration von HashiCorp Vault und dem IBM MCP Gateway. Zudem führt es eine Codeüberprüfung in Echtzeit durch und scannt den Code auf Komplexitätsprobleme, potenzielle Schwachstellen und Möglichkeiten zur Refaktorisierung, die direkt im Code behoben oder später im Bob Findings-Fenster überprüft werden können.

Die Fähigkeit, neu auftretende Fehler in einer Codebasis zu erkennen, hängt weitgehend von der Lesbarkeit dieser Codebasis ab. Die Festlegung und Durchsetzung von Codequalitätsstandards ist daher unerlässlich, um produktive Sicherheitsüberprüfungen zu ermöglichen. Gemeinsame Standards und routinemäßiges Refactoring maximieren die Wahrscheinlichkeit, dass unsicherer Code identifiziert und behoben wird.