Vibe-Coding-Sicherheit: Die Risiken, die Sie mitliefern, und wie Sie sie abfangen

Was ist Vibe Coding?

Vibe Coding ist das Bauen von Software, indem man einen KI-Agenten in natürlicher Sprache promptet, statt den Code selbst zu schreiben. Sie beschreiben das Ergebnis ("füge einen Checkout-Endpunkt hinzu, der die gespeicherte Karte belastet"), der Agent generiert und bearbeitet die Dateien, und Sie iterieren, indem Sie erneut prompten. Die Verschiebung ist, dass der Autor des Codes jetzt das Modell ist, und der Mensch der Prüfer einer Ausgabe, die er oft nicht vollständig lesen kann.

Der Begriff verbreitete sich Anfang 2025, um einen Workflow zu beschreiben, in dem ein Entwickler, oder zunehmend ein Nicht-Entwickler, sich auf den Agenten stützt und akzeptiert, was er produziert, solange das Ergebnis sich verhält. Tools wie Claude Code, Cursor, Windsurf, OpenAI Codex und GitHub Copilot machten es praktikabel: Sie indizieren ein Repository, bearbeiten über den Baum hinweg, führen Befehle aus und produzieren funktionale Features aus einem Absatz an Absicht. Das ist wirklich mächtig. Es ist auch, wo die Sicherheitslücke aufgeht, weil die Geschwindigkeit, die Vibe Coding attraktiv macht, dieselbe Geschwindigkeit ist, die Schwachstellen vergräbt.

Ist Vibe Coding sicher?

Vibe Coding ist sicher für die Dinge, in denen Software schon immer aus Versehen sicher war, und unsicher genau bei den Dingen, die ein Urteilsvermögen erfordern, das ein Prompt nicht trägt. Der Agent produziert zuverlässig Code, der kompiliert und den Happy Path besteht. Er produziert nicht zuverlässig Code, der einem Angreifer widersteht, weil Sicherheit eine Abwesenheit ist (einer fehlenden Prüfung, einer nicht escapeten Eingabe), nach der ein "mach es funktionierend"-Prompt nie fragt.

Die ehrliche Antwort ist, dass Vibe Coding so sicher ist wie die Kontrollen darum herum, und die meisten Vibe-Coding-Setups haben keine, die handeln, bevor der Code landet. Das Modell lernte aus einem öffentlichen Korpus voller unsicherer Muster, also reproduziert es sie in Maschinengeschwindigkeit. Unabhängige Tests landen immer wieder an derselben Stelle: Ein großer Anteil des KI-generierten Codes fällt durch Sicherheitstests, selbst wenn er funktional korrekt ist, und die Lücke zwischen "funktioniert" und "sicher" ist, wo die Sicherheitsverletzung lebt.

Die Erkenntnis ist nicht "vibe-code nicht". Sie ist, dass funktional aussehender Code genau die Art ist, die ein gehetzter Prüfer durchwinkt, und dass über 80 % der funktional korrekten KI-Lösungen im Carnegie-Mellon-SusVibes-Benchmark dennoch eine Schwachstelle trugen. Geschwindigkeit ohne einen Sicherheitskontrollpunkt ist, wie Sie die Schwachstelle und das Feature im selben Commit ausliefern.

Was sind die Sicherheitsrisiken von Vibe Coding?

Die Risiken sind keine neuen Schwachstellentypen. Es sind die Klassiker der OWASP Top 10, schneller reproduziert, als die Prüfung mithalten kann, weil das Modell das gängige Muster schreibt und das gängige Muster oft das unsichere ist. Hier sind die Klassen, die wiederkehren, jede an ihrer CWE verankert.

Zwei davon verdienen einen näheren Blick, weil sie zeigen, wie gewöhnlich der generierte Code ist. Injection zuerst. Bitten Sie um "einen Such-Endpunkt, der Benutzer nach Namen filtert", und der Pfad des geringsten Widerstands ist Verkettung.

# Vulnerable (CWE-89): user input concatenated into SQL
q = f"SELECT * FROM users WHERE name = '{name}'"
db.execute(q)

# Fixed: parameterized query, input never becomes code
db.execute("SELECT * FROM users WHERE name = %s", (name,))

Kaputte Autorisierung ist subtiler, weil die verwundbare Version vollständig aussieht. Sie gibt die richtige Form zurück, besteht den Test, der nach "hole Bestellung 42" fragt, und wird ausgeliefert.

// Vulnerable (CWE-639 IDOR): any logged-in user reads any order
app.get('/orders/:id', auth, async (req, res) => {
  const order = await Order.findById(req.params.id)
  res.json(order)
})

// Fixed: scope the lookup to the caller who owns it
app.get('/orders/:id', auth, async (req, res) => {
  const order = await Order.findOne({ _id: req.params.id, userId: req.user.id })
  if (!order) return res.status(404).end()
  res.json(order)
})

Der Unterschied zwischen den beiden Versionen ist eine Klausel. Ein Prüfer, der 5.000 Zeilen pro Tag liest, sieht die fehlende Klausel nicht; er sieht einen Endpunkt, der eine Bestellung zurückgibt, und zieht weiter.

Warum produziert Vibe Coding diese Schwachstellen?

Weil der Prompt für Verhalten optimiert und das Modell für das gängigste Muster, und keines ist dasselbe wie Sicherheit. "Mach den Checkout funktionierend" ist eine funktionale Spezifikation. Sie enthält keine Anweisung, Eingaben zu validieren, Autorisierung zu begrenzen oder eine Query zu parametrisieren, sodass der Agent die Lücke mit dem füllt, was sein Trainingskorpus statistisch wahrscheinlich machte, was häufig die unsichere Version ist.

Es gibt drei sich verstärkende Gründe. Erstens das Korpusproblem: Das Modell lernte aus öffentlichem Code, der voller OWASP-Klassiker ist, sodass unsicher-standardmäßig sein Vorwissen ist. Zweitens das Abwesenheitsproblem: Sicherheit ist normalerweise eine Prüfung, die vorhanden ist, und ein Modell, das um ein positives Ergebnis gebeten wird, fügt keinen negativen Schutz hinzu, nach dem niemand gefragt hat. Drittens, und am entscheidendsten, das Leserproblem.

“

Die Person, die promptet, kann erkennen, ob das Feature funktioniert. Sie kann normalerweise nicht erkennen, ob es sicher ist. Diese Lücke, zwischen der Absicht des Autors und der Fähigkeit des Prüfers, ist das ganze Sicherheitsproblem.

Deshalb ist Vibe Coding strukturell anders, als wenn ein Junior-Entwickler denselben Code schreibt. Der Junior ist langsam genug, dass die Prüfung Schritt hält, und der Prüfer liest Code, den ein Mensch in menschlicher Geschwindigkeit schrieb. Vibe Coding entfernt beide Bremsen: Die Ausgabe kommt in Maschinengeschwindigkeit an, und die Person, die dafür verantwortlich ist, fehlt oft die Sicherheitskompetenz, um sie zu beurteilen. Der Pull Request, der Ort, an dem AppSec schon immer gelebt hat, wird zu einem Protokoll bereits getroffener Entscheidungen statt zu einem Kontrollpunkt.

Wie betreibt man sicheres Vibe Coding?

Sicheres Vibe Coding bedeutet, eine Sicherheitskontrolle dorthin zu setzen, wo der Code tatsächlich verfasst wird, was der Prompt ist, nicht der Pull Request. Sie behalten die Geschwindigkeit und fügen eine Ebene hinzu, die formt, was der Agent schreibt, bevor er es schreibt, plus die übliche unabhängige Validierung dahinter. Die folgenden Prinzipien sind, was "wir vibe-coden" von "wir vibe-coden sicher" trennt.

1. Geben Sie dem Agenten die Regeln zum Zeitpunkt des Prompts. Das Modell kann einem Standard nicht folgen, den es nie sieht. Laden Sie Ihre Sicherheitsanforderungen (Queries parametrisieren, jeden Lookup auf den Aufrufer begrenzen, nie ein Geheimnis inline einbauen) vor jeder Bearbeitung in den Kontext des Agenten, sodass das sichere Muster der Standardwert ist, nach dem er greift, kein nachträglicher Gedanke, den ein Scanner später markiert.

2. Halten Sie Geheimnisse vollständig außer Reichweite. Keine Klartext-Zugangsdaten im Workspace, den der Agent lesen kann. Verwenden Sie einen Vault, injizieren Sie zur Laufzeit und fügen Sie deny-Regeln für .env-Dateien und Zugangsdatenspeicher hinzu, sodass der Agent nicht inline einbauen kann (CWE-798), was er nicht sehen kann. Rotieren Sie alles, was jemals in einem Protokoll auftaucht.

3. Behandeln Sie jeden generierten Endpunkt als unautorisiert, bis das Gegenteil bewiesen ist. Die wertvollste Prüfgewohnheit für vibe-codeten Code ist, zu prüfen, dass jeder datenzurückgebende Pfad auf den Aufrufer begrenzt ist. Autorisierung (CWE-862, CWE-639) ist die Schwachstelle, die der Agent am zuverlässigsten auslässt, und diejenige, die kein Test abfängt.

4. Validieren Sie Eingaben als harte Anforderung, nicht als nettes Extra. Verlangen Sie Grenzen, Typen und Allowlists bei jedem generierten Handler. CWE-20 liegt oberhalb von Injection und Deserialisierung, sodass das Schließen mehrere Klassen auf einmal schließt.

5. Behalten Sie einen Menschen in der Schleife und ein SAST-Gate dahinter. Leiten Sie generierten Code durch die Prüfung mit zusätzlicher Sorgfalt bei Auth, Queries und Validierung und lassen Sie den Build bei Befunden hoher Schwere fehlschlagen. Funktionale Tests bestehen einen verwundbaren-aber-funktionierenden Endpunkt; nur eine sicherheitsbewusste Prüfung tut das nicht.

6. Achten Sie ausdrücklich auf Business-Logik-Schwachstellen. Scanner fangen einen Rabatt mit negativer Menge oder einen gestapelten Coupon nicht ab. Fördern Sie die Konventionen, die Ihr eigener Code bereits kodiert (Geld ist Decimal128, Erstattungen laufen über requireOwner), und setzen Sie sie durch, während der Agent schreibt. Wir gehen tief darauf ein in Business-Logik-Schwachstellen in KI-generiertem Code.

Das Muster über alle sechs hinweg ist dasselbe: Hören Sie auf, sich auf eine Kontrolle zu verlassen, die eintrifft, nachdem der Code auf der Festplatte liegt, und verschieben Sie sie in den Moment, in dem der Code geschrieben wird.

Wo das Scannen zu kurz greift: Durchsetzung zum Agent-Time

Gehen Sie die Risikoklassen noch einmal durch, und eine einzige Schwäche im Standardansatz sticht heraus. SAST, Geheimnis-Scanner und Code-Review wirken alle auf Code, der bereits existiert. Sie scharen sich um den Pull Request, weil dort AppSec schon immer gelebt hat. Aber der PR war nur deshalb überhaupt ein Kontrollpunkt, weil ein Mensch ihn las, und im Vibe-Coding-Takt liest ihn niemand mehr von Anfang bis Ende. Der Scanner wird zum Historiker, der Schwachstellen dokumentiert, nachdem der Agent sie ausgeliefert hat und weitergezogen ist.

Der Ort, an dem eine Regel durchzusetzen ist, ist der Prompt, bevor die unsichere Zeile geschrieben wird. Welche Regel der Agent auch befolgen soll, sie muss in seinen Händen sein in dem Moment, in dem er schreibt, nicht in einem Tool warten, das eintrifft, sobald der Code auf der Festplatte liegt.

Lesen Sie die rechte Spalte als das Ziel. Scannen ist nicht falsch; es ist spät. Die Durchsetzung zum Agent-Time ersetzt nicht den Scanner, die Prüfung oder das CI-Gate. Sie setzt eine Kontrolle vor sie alle, sodass die unsichere Zeile umgeschrieben wird, bevor sie überhaupt vorgeschlagen wird, statt drei Stufen später von einem Tool erfasst zu werden, das ein Diff liest, das niemand Zeit hatte zu lesen.

Welche Tools fangen Vibe-Coding-Schwachstellen ab?

Sie brauchen zwei Arten von Kontrolle, und die meisten Teams haben nur eine. Die vertraute Art ist Erkennung: SAST für Injection und schwache Kryptografie, Software Composition Analysis für verwundbare Abhängigkeiten und Geheimnis-Scanning für Zugangsdaten in der Historie. Diese sind notwendig, und sie gehören in die CI bei jedem Pull Request. Sie sind auch reaktiv, und in Vibe-Coding-Geschwindigkeit treffen sie ein, nachdem die Schwachstelle ausgeliefert wurde.

Die Art, die den meisten Setups fehlt, ist Prävention am Punkt der Verfassung: eine Ebene, die in der Agentenschleife lebt und den Code formt, während er geschrieben wird. Das ist die Lücke, die VibeDefend füllt. Es ist eine kostenlose npm-CLI, die in etwa fünf Sekunden installiert ist und Claude Code, Cursor, Windsurf, OpenAI Codex und GitHub Copilot in vier Governance-Ebenen verdrahtet, die innerhalb der Agentenschleife laufen, sodass die sichere Version des Codes die erste Version ist. Für das vollständige Bild, wie das über jeden KI-Coding-Agenten hinweg sitzt, siehe unseren Pfeiler zur Sicherheit von KI-Coding-Agenten.

Die vier Ebenen behandeln die Fehlermodi, die dieser Leitfaden benannt hat. Business Rules sind die Konventionen, die aus Ihrem eigenen Repo gefördert wurden (Geld ist Decimal128, Autorisierung läuft über requireOwner), vor jeder Bearbeitung in den Agenten geladen, sodass Business-Logik-Schwachstellen nie geschrieben werden. Security Rules bringen OWASP Top 10, SOC 2, DSGVO und ISO 27001 in den Code, während er geschrieben wird, sodass Injection, fehlende Validierung und kaputte Autorisierung bei der Verfassung auf eine Regel treffen statt auf eine Checkbox zum Audit-Zeitpunkt. Action Guard fängt destruktive Aufrufe (ein sudo rm -rf, ein roher Lesezugriff auf eine geheimnisartige Umgebungsvariable, ein ad-hoc psql gegen einen Produktionshost) ab, bevor sie ausgelöst werden, warnt oder blockiert pro Regel, mit jedem Abfangen im Audit-Trail. Live Findings verdrahtet den Agenten in CybeDefends vollständige AppSec-Plattform, seinen Scannern (SAST mit Erreichbarkeit, SCA, Secrets, IaC und CI/CD), die kontinuierlich laufen, sodass der Agent nicht nur sicheren Code schreibt, sondern die Schwachstellen triagiert und behebt, die Sie bereits haben. Entscheidend ist: Nichts über Ihren Code geht über die Leitung: Entscheidungen geschehen lokal neben dem Agenten, und nur strukturierte Governance-Metadaten (die ausgelöste Regel, der Dateipfad, die Schwere, ein Zeitstempel) erreichen das Backend. EU- und US-Mandanten sind physisch getrennt, und Sie wählen die Region zum Installationszeitpunkt, sodass die Kontrolle so nah am Code sitzt, ohne selbst zu einem Datenexfiltrationsrisiko zu werden.

Häufig gestellte Fragen

Ist Vibe Coding sicher?

Vibe Coding ist sicher beim Produzieren funktionierender Software und unzuverlässig beim Produzieren sicherer Software, weil ein "mach es funktionierend"-Prompt nie nach der fehlenden Sicherheitsprüfung fragt. Unabhängige Tests finden immer wieder, dass ein großer Anteil des KI-generierten Codes durch Sicherheitstests fällt, selbst wenn er funktional korrekt ist. Es wird sicher zu betreiben, wenn Sie eine Kontrolle hinzufügen, die zum Zeitpunkt der Verfassung handelt, dem Agenten Ihre Sicherheitsregeln in seinen Kontext geben, einen Menschen in der Schleife behalten und Pull Requests mit SAST absichern. Ohne diese liefert Vibe Coding die OWASP Top 10 in Maschinengeschwindigkeit.

Was sind die häufigsten Vibe-Coding-Schwachstellen?

Die wiederkehrenden Klassen sind fest codierte Geheimnisse (CWE-798), kaputte Autorisierung und IDOR (CWE-862, CWE-639), Injection (CWE-89 für SQL, CWE-78 für Befehle), fehlende Eingabevalidierung (CWE-20), unsichere Deserialisierung (CWE-502) und Business-Logik-Schwachstellen. Keine ist neu. Es sind die OWASP-Klassiker, schneller reproduziert, als die Prüfung mithalten kann, weil das Modell das gängigste Muster schreibt und das gängigste Muster häufig das unsichere ist.

Warum hat KI-generierter Code so viele Sicherheitsschwachstellen?

Drei Gründe verstärken sich. Das Modell lernte aus einem öffentlichen Korpus voller unsicherer Muster, sodass unsicher-standardmäßig sein Vorwissen ist. Sicherheit ist normalerweise ein Schutz, der vorhanden ist, und ein Modell, das um ein positives Ergebnis gebeten wird, fügt keine negative Prüfung hinzu, nach der niemand gefragt hat. Und die Person, die promptet, kann erkennen, ob das Feature funktioniert, aber oft nicht, ob es sicher ist, sodass die Schwachstelle die Prüfung besteht. Das Ergebnis ist funktional aussehender Code, der die Schwachstelle mit dem Feature ausliefert.

Kann ein Nicht-Entwickler sicher vibe-coden?

Nur mit einer Kontrolle, die nicht davon abhängt, dass die Person die Sicherheitsimplikationen liest, weil das genau die Fähigkeit ist, die einem Nicht-Entwickler fehlt. Ein Linter oder ein Scanner, der Befunde zum Sichten produziert, setzt voraus, dass der Leser sie interpretieren kann. Eine Ebene zum Agent-Time, die die Regeln in den Agenten lädt und die unsichere Zeile umschreibt, bevor sie landet, entfernt diese Abhängigkeit: Das sichere Muster ist der Standardwert, nach dem der Agent greift, sodass Sicherheit nicht auf der Fähigkeit des Prompters ruht, eine fehlende Autorisierungsprüfung zu erkennen.

Wie unterscheidet sich Vibe Coding von der Nutzung einer Autovervollständigung wie altem Copilot?

Alte Autovervollständigung schlug einen Codeblock vor, den ein Mensch anzunehmen wählte; der Wirkungsradius war ein Schnipsel, den ein Entwickler trotzdem noch einfügen musste. Vibe Coding lässt den Agenten Aktionen ausführen: Er bearbeitet über den Baum hinweg, führt Befehle aus und liefert funktionale Features aus einem Absatz an Absicht, in einem Volumen, das kein Prüfer lesen kann. Das Sicherheitsmodell muss sich vom Prüfen eines Entwurfs, den ein Mensch annimmt, hin zum Eingrenzen und Formen dessen verschieben, was ein Agent überhaupt erst schreibt.

Fängt ein SAST-Scanner Vibe-Coding-Schwachstellen ab?

Ein SAST-Scanner fängt einen bedeutsamen Teil von ihnen ab, besonders Injection und schwache Kryptografie, und er gehört in die CI bei jedem Pull Request. Was er weitgehend verfehlt, sind Business-Logik-Schwachstellen, weil ein Rabatt mit negativer Menge oder eine Erstattung, die die Eigentümerprüfung überspringt, syntaktisch perfekt und semantisch falsch ist, ohne eine Signatur zum Abgleichen. Er ist auch reaktiv: Er handelt, nachdem der Code geschrieben ist, was in Vibe-Coding-Geschwindigkeit bedeutet, nachdem die Schwachstelle ausgeliefert wurde. Paaren Sie Erkennung in der CI mit Prävention zum Zeitpunkt der Verfassung.

Was ist die einzelne wirksamste Kontrolle für sicheres Vibe Coding?

Den Sicherheitskontrollpunkt vom Pull Request zum Prompt zu verschieben. Erkennung, die läuft, nachdem der Code existiert, liest im Agententakt immer Geschichte, weil niemand tausende generierte Zeilen von Anfang bis Ende prüft. Eine Ebene, die Ihre Sicherheits- und Geschäftsregeln vor jeder Bearbeitung in den Agenten lädt und die unsichere Zeile umschreibt, bevor sie landet, verhindert die Schwachstelle, statt sie später zu finden. Alles andere (SAST, Prüfung, CI-Gates) ist Tiefenverteidigung dahinter.

Wo fange ich an, ein bestehendes vibe-codetes Projekt abzusichern?

Beginnen Sie damit, die zwei Klassen zu schließen, die der Agent am häufigsten auslässt: Scannen Sie die Historie nach fest codierten Geheimnissen und rotieren Sie alles Offengelegte, dann prüfen Sie jeden datenzurückgebenden Endpunkt auf eine aufrufer-begrenzte Autorisierungsprüfung. Fügen Sie der CI ein SAST-Gate hinzu, das bei Befunden hoher Schwere fehlschlägt, und setzen Sie eine Ebene zum Agent-Time wie VibeDefend davor, sodass neuer Code gesteuert wird, während er geschrieben wird. Das Ziel ist, zuerst aufzuhören, Schwachstellen hinzuzufügen, dann den Rückstand abzuarbeiten, den die frühen Prompts hinterlassen haben.