Vibe-Coding-Sicherheit: Die Risiken, die Sie mitliefern, und die Checkliste dagegen

Wie sicher ist Vibe Coding?

Nicht von Haus aus. Für eine arXiv-Studie aus dem Jahr 2026 haben Forscher 200 öffentlich betriebene Vibe-Coding-Anwendungen geprüft und in 91,0 % davon mindestens eine Schwachstelle gefunden; 65,8 % der 1.186 protokollierten Befunde waren als kritisch oder hoch eingestuft. Vibe Coding produziert zuverlässig funktionierende Software und sichere Software nur zufällig.

91,0 %

der 200 geprüften Vibe-Coding-Anwendungen trugen mindestens eine Schwachstelle (Deng, Fan und Meng, arXiv 2606.23130)

11,8 %

der Agentenlösungen waren sicher, gegenüber 57 % funktional korrekt (SusVibes-Benchmark, Carnegie Mellon und Partner)

65,8 %

der 1.186 Schwachstellen in diesem Audit waren als kritisch oder hoch eingestuft

Das Audit heißt Understanding the (In)Security of Vibe-Coded Applications und stammt von Junquan Deng, Zhiyu Fan und Ruijie Meng, erstmals veröffentlicht im Juni 2026 und zuletzt im September 2026 überarbeitet. Die Autoren sammelten 9.041 quelloffene Anwendungen, die mit verbreiteten Agenten gebaut wurden, darunter Claude Code und Lovable, und prüften davon die 200, die öffentlich erreichbar liefen. Die 1.186 Befunde führen sie auf acht wiederkehrende Fehlermuster zurück und auf drei Grenzen der Agenten selbst: memory defects, objective defects und knowledge defects.

Die Benchmark-Evidenz zeigt in dieselbe Richtung. Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks, von einem Team unter Führung der Carnegie Mellon University, baute SusVibes aus 186 Feature-Request-Aufgaben, die aus echten Open-Source-Projekten stammen und bei denen seinerzeit ein Mensch eine verwundbare Implementierung committet hatte. Über 12 gebräuchliche Agentenkonfigurationen hinweg waren 57 % der Lösungen von SWE-Agent mit Claude 4 Sonnet funktional korrekt und 11,8 % sicher. Zwischen „läuft“ und „hält stand“ liegt in diesem Benchmark also der größere Teil der Arbeit.

Die ehrliche Antwort lautet damit: Vibe Coding ist so sicher wie die Kontrollen darum herum, und die meisten Vibe-Coding-Setups haben keine, die handelt, bevor der Code landet. Funktional aussehender Code ist genau die Sorte, die ein gehetzter Prüfer durchwinkt. Geschwindigkeit ohne einen Sicherheitskontrollpunkt ist der Weg, auf dem Sie die Schwachstelle und das Feature im selben Commit ausliefern.

Was ist Vibe Coding?

Vibe Coding ist das Bauen von Software, indem Sie einen KI-Agenten in natürlicher Sprache prompten, statt den Code selbst zu schreiben. Sie beschreiben das Ergebnis, der Agent erzeugt und bearbeitet die Dateien, und Sie iterieren mit dem nächsten Prompt. Autor des Codes ist das Modell, und der Mensch prüft eine Ausgabe, die er oft nicht vollständig lesen kann.

Der Begriff verbreitete sich Anfang 2025 für einen Arbeitsablauf, in dem ein Entwickler, zunehmend auch ein Nicht-Entwickler, sich auf den Agenten stützt und akzeptiert, was dieser produziert, solange das Ergebnis sich richtig verhält. Tools wie Claude Code, Cursor, Windsurf, OpenAI Codex und GitHub Copilot haben das praktikabel gemacht: Sie indizieren ein Repository, bearbeiten quer über den Dateibaum, führen Befehle aus und machen aus einem Absatz formulierter Absicht ein funktionierendes Feature. Das ist ehrlich beeindruckend. Es ist zugleich der Punkt, an dem die Sicherheitslücke aufgeht, denn dieselbe Geschwindigkeit, die Vibe Coding attraktiv macht, begräbt die Schwachstellen unter der nächsten Änderung.

Welche Sicherheitsrisiken hat Vibe Coding?

Es sind die Klassiker der OWASP Top 10, nur schneller reproduziert, als die Prüfung mithalten kann. Das arXiv-Audit von 2026 fand sie konzentriert auf Broken Access Control, Injection und Authentifizierungsfehler. Vier dieser Klassen stehen in den CWE Top 25 von 2025: SQL-Injection auf Rang 2, fehlende Autorisierung auf Rang 4, OS-Command-Injection auf Rang 9, unsichere Deserialisierung auf Rang 15.

Zwei davon verdienen einen näheren Blick, weil sie zeigen, wie unauffällig der erzeugte Code aussieht. Zuerst Injection. Bitten Sie um „einen Such-Endpunkt, der Benutzer nach Namen filtert“, und der Weg des geringsten Widerstands ist Verkettung.

# Verwundbar (CWE-89): Benutzereingabe wird in SQL verkettet
q = f"SELECT * FROM users WHERE name = '{name}'"
db.execute(q)

# Behoben: parametrisierte Query, die Eingabe wird nie zu Code
db.execute("SELECT * FROM users WHERE name = %s", (name,))

Kaputte Autorisierung ist subtiler, denn die verwundbare Fassung sieht fertig aus. Sie liefert die richtige Struktur zurück, besteht den Test, der nach „hole Bestellung 42“ fragt, und geht in Produktion.

// Verwundbar (CWE-639 IDOR): jeder angemeldete Nutzer liest jede Bestellung
app.get('/orders/:id', auth, async (req, res) => {
  const order = await Order.findById(req.params.id)
  res.json(order)
})

// Behoben: den Lookup auf den Aufrufer begrenzen, dem sie gehört
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 beiden Fassungen ist eine einzige Klausel. Ein Prüfer, der 5.000 Zeilen am Tag liest, sieht die fehlende Klausel nicht; er sieht einen Endpunkt, der eine Bestellung zurückgibt, und zieht weiter. Dasselbe Muster wiederholt sich in jeder Sprache, in der der Agent schreibt, was wir im größeren Zusammenhang in Ist KI-generierter Code sicher? untersuchen.

Eine Risikoklasse stammt gar nicht aus dem Code. Ein Agent liest Dateien, die Dokumentation von Abhängigkeiten und Tool-Beschreibungen, und jede dieser Quellen kann Anweisungen tragen, die sich an den Agenten richten statt an Sie. Prompt Injection ist LLM01, der erste Eintrag der OWASP Top 10 for LLM Applications 2025, und genau deshalb fragt Schritt 10 der folgenden Checkliste danach, was der Agent ausgeführt hat, nicht nur danach, was er geschrieben hat.

Warum produziert Vibe Coding diese Schwachstellen?

Weil der Prompt auf Verhalten optimiert und das Modell auf das häufigste Muster, und keines von beidem ist dasselbe wie Sicherheit. Die Bitte, den Checkout zum Laufen zu bringen, enthält keine Anweisung, Eingaben zu validieren, Autorisierung zu begrenzen oder eine Query zu parametrisieren. Der Agent füllt diese Lücke mit dem, was sein Trainingskorpus statistisch wahrscheinlich gemacht hat.

Zwei Mechanismen verstärken sich dabei. Das Korpusproblem: Das Modell hat aus öffentlichem Code gelernt, der voller OWASP-Klassiker ist, also geht es standardmäßig vom unsicheren Muster aus. Das Abwesenheitsproblem: Sicherheit ist meistens 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. Dem Modell zu sagen, es solle vorsichtig sein, behebt keines von beidem. Das SusVibes-Team hat genau das getestet, indem es die funktionale Anforderung um Hinweise auf mögliche Schwachstellen ergänzte, und berichtet, dass diese Strategie die Sicherheitsprobleme nicht entschärft hat.

Ein dritter Mechanismus entscheidet über den Ausgang, und er sitzt auf der menschlichen Seite.

“

Wer promptet, erkennt, ob das Feature funktioniert. Ob es sicher ist, erkennt er in der Regel nicht. Diese Lücke zwischen der Absicht des Autors und der Urteilsfähigkeit des Prüfers ist das gesamte Sicherheitsproblem.

Deshalb ist Vibe Coding strukturell etwas anderes als ein Junior-Entwickler, der denselben Code schreibt. Der Junior ist langsam genug, dass die Review Schritt hält, und der Prüfer liest Code, den ein Mensch in menschlichem Tempo geschrieben hat. Vibe Coding nimmt beide Bremsen heraus: Die Ausgabe kommt in Maschinengeschwindigkeit, und der Person, die dafür geradesteht, fehlt oft die Sicherheitskompetenz, um sie zu beurteilen. Der Pull Request, der Ort, an dem AppSec immer gelebt hat, wird damit zum Protokoll bereits gefallener Entscheidungen statt zum Kontrollpunkt.

Was gehört auf eine Checkliste für Vibe-Coding-Sicherheit?

Zehn Schritte, geordnet nach Wirkung pro investierter Stunde. Die ersten schließen die Klassen, die Agenten laut dem arXiv-Audit von 2026 am häufigsten auslassen: Broken Access Control, Injection und Authentifizierungsfehler. Der Rest sind die Leitplanken, die verhindern, dass der nächste Prompt sie wieder aufreißt. Arbeiten Sie die Liste der Reihe nach an jedem Repository ab, das ein Agent angefasst hat.

1. Rotieren Sie jedes Credential, das der Agent gelesen haben könnte, und scannen Sie danach die Historie. Ein fest codierter Schlüssel ist ausnutzbar, ohne dass ein Angreifer erst einen Bug finden muss, und deshalb steht dieser Schritt an erster Stelle. CWE-798 überlebt in der Git-Historie und in jedem Fork, lange nachdem Sie die Zeile gelöscht haben. Die Rotation kommt also vor dem Löschen, nicht danach.

2. Begrenzen Sie jeden datenliefernden Endpunkt auf seinen Aufrufer. Öffnen Sie jeden generierten Handler und prüfen Sie, ob der Lookup auf den authentifizierten Benutzer filtert und nicht allein auf eine ID aus der URL. CWE-862 und CWE-639 stehen auf Rang 4 und Rang 24 der CWE Top 25 von 2025, und es sind die Schwachstellen, die der Agent am zuverlässigsten auslässt, weil kein funktionaler Test nach ihnen fragt.

3. Parametrisieren Sie jede Query und jeden Shell-Aufruf. Durchsuchen Sie die generierten Dateien nach String-Interpolation innerhalb einer Query oder eines Befehls. CWE-89 steht auf Rang 2 der CWE Top 25 und CWE-78 auf Rang 9, und beide sind eine einzige mechanische Änderung davon entfernt, geschlossen zu sein.

4. Validieren Sie jeden Request-Body am Rand gegen ein Schema. Grenzen, Typen und Allowlists, bei Verstoß wird abgelehnt. CWE-20 liegt oberhalb von Injection und Deserialisierung, sodass Sie mit einem Schritt mehrere Klassen auf einmal schließen, und es ist der Punkt dieser Liste, der sich am günstigsten automatisieren lässt.

5. Ersetzen Sie jeden Deserializer, der auf nicht vertrauenswürdigen Bytes läuft. pickle, yaml.load und native Objekt-Deserializer machen aus einem gespeicherten Blob Remote Code Execution. CWE-502 steht auf Rang 15 der CWE Top 25, und der sichere Ersatz ist meist ein typisierter Parser, den Sie ohnehin schon im Haus haben.

6. Nehmen Sie Credential-Speicher aus der Reichweite des Agenten. Keine Klartext-Zugangsdaten in dem Workspace, den er lesen kann. Nutzen Sie einen Vault, injizieren Sie zur Laufzeit, und legen Sie deny-Regeln für .env-Dateien an, damit der Agent nicht inline einbauen kann, was er nicht sieht. Rotieren Sie alles, was je in einem Transkript aufgetaucht ist.

7. Schreiben Sie Ihre Sicherheitsregeln dorthin, wo der Agent sie bei jeder Bearbeitung liest. Das Secure Software Development Framework des NIST (SP 800-218, Version 1.1) ordnet das Dokumentieren von Sicherheitsanforderungen seiner Gruppe Prepare the Organization zu, also der Phase, bevor überhaupt Code entsteht. Der nächste Abschnitt behandelt, was in diesen Regeln stehen sollte.

8. Setzen Sie ein SAST-Gate in die CI und lassen Sie den Build bei hoher Schwere fehlschlagen. Funktionale Tests lassen einen verwundbaren, aber funktionierenden Endpunkt durch; nur eine sicherheitsbewusste Prüfung tut das nicht. Das ist Erkennung statt Prävention, und genau deshalb steht dieser Schritt hier und nicht ganz oben.

9. Schreiben Sie einen Missbrauchstest pro Geldpfad und pro Eigentumspfad. Erst eine negative Menge, dann die ID eines anderen Nutzers. Business-Logik-Schwachstellen haben keine Signatur, die sich abgleichen ließe, also ist ein Test, der die Regel kodiert, die einzige mechanische Verteidigung. Ausführlicher wird es in Business-Logik-Schwachstellen in KI-generiertem Code.

10. Prüfen Sie, was der Agent ausgeführt hat, nicht nur, was er geschrieben hat. Halten Sie die ausgeführten Befehle in einem Log fest, das Sie nachlesen können. Destruktive Shell-Aufrufe und ein spontaner Datenbankzugriff auf einen laufenden Host tauchen in keinem Diff auf, eine Code-Review allein bringt sie also nie ans Licht.

Die Schritte 1 bis 5 sind Remediation, die Sie auf einem kleinen Repository an einem Nachmittag abschließen. Die Schritte 6 bis 10 sind das, was dieselben Klassen daran hindert, beim nächsten Prompt zurückzukommen.

Was muss ein Security-Prompt für Vibe Coding enthalten?

Er muss die Regeln als Bedingungen formulieren, die der Agent vor dem Schreiben prüft, nicht als Wunsch. Benennen Sie die Query-Schnittstelle, den Autorisierungs-Helper und das Eingabeschema, die Ihre Codebasis bereits verwendet, und weisen Sie den Agenten an, die Bearbeitung abzulehnen, wenn er sie nicht erfüllen kann. Regeln außerhalb des Agentenkontextes gelten nicht.

Die brauchbare Form ist konkret und mechanisch. Eine vage Anweisung wie „schreib sicheren Code“ gibt dem Modell nichts, wogegen es prüfen könnte. Benannte Schnittstellen tun das.

# Sicherheitsregeln für dieses Repository

- Jeder Datenbank-Lesezugriff läuft über `db.query(sql, params)`. Interpolieren
  Sie nie einen Wert in SQL. Ist Parametrisierung nicht möglich, brechen Sie ab
  und sagen Sie es.
- Jeder Handler, der einen Datensatz zurückgibt, filtert auf `req.user.id`.
  Eine ID aus der URL genügt für sich allein nie.
- Jeder Request-Body wird vor der Verwendung von seinem zod-Schema geparst.
  Bei Verstoß ablehnen.
- Schreiben Sie nie ein Credential in eine Datei. Lesen Sie es aus der Umgebung.
- Geld ist Decimal128. Mengen sind Ganzzahlen strikt größer als null.

Wo diese Datei liegt, zählt mehr als das, was darin steht. In CybeDefends kontrollierter Studie vom 24. August 2026, die 30 Entwicklertickets in dreifacher Ausführung durchlief, also 90 autonome Läufe und 93 unabhängige Sicherheitsscans, kam der Arm, der diese Regeln in einer von Hand gepflegten Datei im Repository hielt, auf durchschnittlich 2,27 Regelabweichungen pro regeltragendem Ticket. Der Arm ganz ohne Tool kam auf 2,28. Die Regeln aufzuschreiben und sonst nichts zu tun, hat also so gut wie nichts verändert. Der Arm, der dieselben Regeln im Moment der Bearbeitung injiziert bekam, kam auf 0,28.

Dieselbe Studie ist offen über die Grenze dieser Zahl. Bei einem Ticket wurde die einschlägige Regel dreizehnmal ausgeliefert, und der Agent baute unter dem Druck der Aufgabe trotzdem seine eigenen Schutzmechanismen ab. Injektion informiert, sie erzwingt nicht, und genau deshalb behält die Checkliste oben ein CI-Gate und einen Menschen dahinter.

Findet ein SAST-Scanner Vibe-Coding-Schwachstellen?

Teilweise. Ein SAST-Scanner findet einen erheblichen Teil, besonders Injection und schwache Kryptografie, und er gehört in die CI bei jedem Pull Request. Was er verfehlt, ist Business-Logik: Eine negative Menge, die den Warenkorb gutschreibt, ist syntaktisch perfekt und hat keine Signatur zum Abgleichen. Außerdem handelt er erst, nachdem der Code geschrieben ist.

Diese zweite Grenze ist die strukturelle. SAST, Secret-Scanner und Code-Review lesen alle Code, der bereits existiert, und sie scharen sich um den Pull Request, weil dort AppSec immer gelebt hat. Ein Kontrollpunkt war der PR aber nur, solange ihn ein Mensch gelesen hat, und im Vibe-Coding-Takt liest ihn niemand mehr von Anfang bis Ende. Der Scanner wird damit zum Historiker: Er dokumentiert Schwachstellen, nachdem der Agent sie ausgeliefert hat und weitergezogen ist.

Lesen Sie die rechte Spalte als Ziel. Scannen ist nicht falsch, es ist spät. Durchsetzung zum Agent-Time ersetzt weder den Scanner noch die Review noch das CI-Gate. Sie setzt eine Kontrolle davor, sodass die unsichere Zeile umgeschrieben wird, bevor sie überhaupt vorgeschlagen wird, statt drei Stufen später von einem Werkzeug erfasst zu werden, das ein Diff liest, für das niemand Zeit hatte.

Worauf sollten Sie bei einem Tool für Vibe-Coding-Sicherheit achten?

Auf zwei Fähigkeiten, und die meisten Tools haben nur eine. Erkennung findet bekannte Muster in Code, der bereits existiert. Prävention formt den Code, während der Agent ihn schreibt, indem sie Ihre Regeln vor jeder Bearbeitung in dessen Kontext lädt. Fragen Sie einen Anbieter, wann seine Kontrolle greift: In Agentengeschwindigkeit ist das die ganze Frage.

Die Erkennungshälfte ist ein gelöster Markt. SAST, Software Composition Analysis und Secret Scanning sind ausgereift, und die etablierten Anbieter in diesem Feld, unter ihnen Snyk, Checkmarx und Semgrep, machen ihre Arbeit gut. Gemeinsam ist ihnen der Moment, in dem sie handeln: in der CI, an einem Diff, nachdem der Agent längst weitergezogen ist. Die Secure-by-Design-Leitlinie der CISA, Shifting the Balance of Cybersecurity Risk, veröffentlicht mit 17 internationalen Partnern, formuliert den Prüfstein anders und besser: Ein Anbieter soll Verantwortung für die Sicherheitsergebnisse seiner Kunden übernehmen, statt dem Kunden eine Liste zum Abarbeiten in die Hand zu drücken.

Genau diese Lücke füllt VibeDefend. 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 einhängt, die innerhalb der Agentenschleife laufen, sodass die sichere Version des Codes die erste Version ist. Das vollständige Bild über alle KI-Coding-Agenten hinweg steht in unserem Pfeiler zur Sicherheit von KI-Coding-Agenten.

npx -y @cybedefend/vibedefend@latest installEU oder US wählen, Agenten bestätigen.cybedefend/config.json im Repo ablegenNächster Prompt wird gesteuert

Die vier Ebenen decken die Fehlermuster ab, die dieser Leitfaden benannt hat. Business Rules sind die Konventionen, die aus Ihrem eigenen Repository gewonnen werden (Geld ist Decimal128, Autorisierung läuft über requireOwner), vor jeder Bearbeitung in den Agenten geladen, sodass Business-Logik-Schwachstellen gar nicht erst geschrieben werden. Security Rules tragen die OWASP Top 10 und die Compliance-Regelfamilien, die Sie aktivieren, in den Code hinein, während er entsteht, sodass Injection, fehlende Validierung und kaputte Autorisierung schon beim Verfassen auf eine Regel treffen statt erst zur Audit-Zeit auf eine Checkbox. Action Guard fängt destruktive Aufrufe ab, bevor sie ausgelöst werden; über die Studie vom August hinweg prüfte er 1.769 Shell-Befehle und lehnte 17 davon ab, darunter 1 echter Versuch, an ein gespeichertes Credential zu kommen, 3 richtlinienkonforme Ablehnungen und 13 Fehlalarme, die je einen Durchgang gekostet haben. Live Findings verdrahtet den Agenten mit der Plattform von CybeDefend, auf der SAST mit Reachability, SCA, Secrets, IaC und CI/CD durchgehend laufen, sodass der Agent auch die Schwachstellen triagiert und behebt, die Sie bereits haben. Nichts von Ihrem Code geht dabei über die Leitung: Die Entscheidungen fallen lokal neben dem Agenten, und nur strukturierte Governance-Metadaten erreichen das Backend, also die ausgelöste Regel, der Dateipfad, die Schwere und ein Zeitstempel. EU- und US-Region sind physisch getrennt, und Sie wählen eine davon bei der Installation.

An denselben 30 Tickets gemessen, hinterließ diese Ebene 0,033 neue Befunde aus der statischen Analyse pro Aufgabe gegenüber 0,10 ohne Tool, und jeder dieser Befunde wurde noch innerhalb der Aufgabe behoben, die ihn eingeführt hatte. Eine ehrliche Einschränkung reist mit dieser Zahl: Die Studie hat Codebasen gemessen, die sauber gestartet sind. Sie beschreibt damit das Halten der Null, nicht das Abarbeiten eines Rückstands, den Sie bereits haben.

Häufig gestellte Fragen

Wie sicher ist Vibe Coding?

Nicht von Haus aus sicher. Ein arXiv-Audit von 200 betriebenen Vibe-Coding-Anwendungen fand 2026 in 91,0 % von ihnen mindestens eine Schwachstelle, und der SusVibes-Benchmark kam darauf, dass nur 11,8 % der Agentenlösungen sicher waren, während 57 % funktional korrekt liefen. Sicher wird Vibe Coding, wenn Sie eine Kontrolle hinzufügen, die schon beim Verfassen greift, dem Agenten Ihre Sicherheitsregeln in den Kontext geben, einen Menschen in der Schleife behalten und Pull Requests mit SAST absichern. Ohne das liefert Vibe Coding die OWASP Top 10 in Maschinengeschwindigkeit aus.

Welche Schwachstellen entstehen beim Vibe Coding am häufigsten?

Die wiederkehrenden Klassen sind fest codierte Zugangsdaten (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. Das arXiv-Audit von 2026 fand seine 1.186 Befunde konzentriert auf Broken Access Control, Injection und Authentifizierungsfehler. Neu ist davon nichts: Es sind die OWASP-Klassiker, nur schneller reproduziert, als die Prüfung mithalten kann.

Warum hat KI-generierter Code so viele Sicherheitslücken?

Zwei Mechanismen verstärken sich, ein dritter entscheidet. Das Modell hat aus einem öffentlichen Korpus voller unsicherer Muster gelernt, also greift es standardmäßig zum unsicheren Muster. Sicherheit ist meistens 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 wer promptet, erkennt, ob das Feature funktioniert, aber oft nicht, ob es sicher ist, sodass die Schwachstelle die Review passiert. Hinweise auf mögliche Schwachstellen in der Anforderung haben das in den SusVibes-Tests nicht behoben.

Kann ein Nicht-Entwickler sicher vibe-coden?

Nur mit einer Kontrolle, die nicht davon abhängt, dass die Person die Sicherheitsimplikationen liest, denn genau diese Fähigkeit fehlt einem Nicht-Entwickler. 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, nimmt diese Abhängigkeit heraus: Das sichere Muster wird zu dem, nach dem der Agent standardmäßig greift, und Sicherheit hängt nicht mehr daran, ob die Person am Prompt eine fehlende Autorisierungsprüfung bemerkt.

Ist Vibe Coding für eine Produktivanwendung sicher?

Nicht ohne die Kontrollen der Checkliste oben. Das arXiv-Audit von 2026 hat ausdrücklich Anwendungen betrachtet, die öffentlich erreichbar liefen, keine Spielprojekte, und 91,0 % der 200 geprüften trugen mindestens eine Schwachstelle, bei rund zwei Dritteln der Befunde in der Einstufung kritisch oder hoch. Produktion erhöht den Einsatz genau bei den Klassen, die Agenten auslassen: Ein unbegrenzter Endpunkt legt echte Kundendaten offen, und ein fest codierter Schlüssel in einem öffentlichen Repository ist ab dem Push ausnutzbar.

Findet ein SAST-Scanner Vibe-Coding-Schwachstellen?

Er findet einen erheblichen Teil, besonders Injection und schwache Kryptografie, und er gehört in die CI bei jedem Pull Request. Was er weitgehend verfehlt, ist Business-Logik, denn ein Rabatt mit negativer Menge oder eine Erstattung ohne Eigentümerprüfung ist syntaktisch perfekt und semantisch falsch, ohne Signatur zum Abgleichen. Er ist zudem 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 beim Verfassen.

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

Den Sicherheitskontrollpunkt vom Pull Request zum Prompt zu verschieben. Erkennung, die erst läuft, wenn der Code existiert, liest im Agententakt immer Geschichte, weil niemand tausende generierte Zeilen von Anfang bis Ende prüft. In der kontrollierten Studie von CybeDefend hinterließen Regeln in einer Repository-Datei 2,27 Abweichungen pro regeltragendem Ticket gegenüber 2,28 ganz ohne Tool, während dieselben Regeln, im Moment der Bearbeitung injiziert, 0,28 hinterließen. Alles andere ist Tiefenverteidigung dahinter.

Wo fange ich an, ein bestehendes Vibe-Coding-Projekt abzusichern?

Bei den Schritten 1 bis 3 der Checkliste oben: Rotieren Sie jedes Credential, das der Agent gelesen haben könnte, und scannen Sie die Historie nach weiteren; prüfen Sie dann jeden datenliefernden Endpunkt auf eine aufrufer-begrenzte Autorisierungsprüfung; schließen Sie danach die Injection-Punkte. Ergänzen Sie ein SAST-Gate in der CI, das bei hoher Schwere fehlschlägt, und setzen Sie eine Ebene zum Agent-Time davor, damit neuer Code gesteuert entsteht. Hören Sie zuerst auf, Schwachstellen hinzuzufügen, und arbeiten Sie dann den Rückstand ab, den die frühen Prompts hinterlassen haben.