Ist Vibe Coding sicher? Was ein Benchmark mit 186 realen Aufgaben ergab

Die Agenten-Konfiguration, die in der Studie am häufigsten funktionierenden Code erzeugte, tat dies in 57 % der Aufgaben. Nur in 11,8 % der Aufgaben funktionierte ihr Code und bestand zugleich den Sicherheitstest. Von ihren funktionierenden Lösungen scheiterten 79,3 % dennoch an einem Sicherheitstest. Wenn die Agenten nicht auf Sicherheit hingewiesen wurden, erzeugte keine Konfiguration in mehr als 12,9 % der Aufgaben Code, der funktionierte und zugleich den Sicherheitstest bestand.

Das sind die Kernzahlen. Um zu verstehen, was sie bedeuten, müssen wir uns ansehen, wie der Benchmark aufgebaut war.

Die Studie ist Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks (Zhao, Wang, Zhang, Luo, Li und Li, ICML 2026, arXiv:2512.03262).

Was der Benchmark tat

Die Autoren erstellten 186 Aufgaben aus großen Open-Source-Repositories auf GitHub. Jede ging von einem realen Fall aus: Ein Mensch implementierte ein Feature, die Implementierung erwies sich als verwundbar, und die Schwachstelle wurde später behoben. Zusammen decken die Aufgaben 79 Schwachstellenkategorien aus der Common Weakness Enumeration von MITRE ab.

Für jede Aufgabe erhält der Agent die Codebasis und eine Beschreibung des Features, „ohne Implementierungsdetails oder Sicherheitshinweise“. Anschließend wird er aufgefordert, das Feature zu implementieren. Sein Patch wird gegen zwei Sätze von Tests ausgeführt, die Menschen geschrieben haben. Der eine prüft, ob das Feature funktioniert; der andere prüft, ob die Schwachstelle vorliegt, die der eigene Fix des Projekts entfernt hat.

Die Autoren testeten drei Agenten-Frameworks (SWE-agent, OpenHands und Claude Code) mit vier Modellen: Claude 4 Sonnet, Kimi K2, Gemini 2.5 Pro und Gemini 3 Pro. Das ergab zwölf Konfigurationen, jede mit einem Versuch pro Aufgabe.

Was er ergab

• Die Konfiguration, die am häufigsten funktionierenden Code erzeugte (SWE-agent mit Claude 4 Sonnet), tat dies in 57,0 % der Aufgaben. In 11,8 % bestand der Code auch den Sicherheitstest. Wie die Autoren es formulieren: „79,3 % dieser funktional korrekten Lösungen sind unsicher“.
• OpenHands mit demselben Modell zeigte ein ähnliches Muster: 77,8 % seiner funktionierenden Lösungen waren unsicher.
• Claude Code mit Claude 4 Sonnet erzeugte in 41,4 % der Aufgaben funktionierenden Code. In 5,9 % bestand der Code auch den Sicherheitstest.
• Wenn die Agenten nicht auf Sicherheit hingewiesen wurden, lag der höchste Anteil an Aufgaben, die sowohl korrekt als auch sicher gelöst wurden, bei 12,9 %, für SWE-agent mit Gemini 3 Pro, das in 37,1 % der Aufgaben funktionierenden Code erzeugte.
• Über die zwölf Konfigurationen hinweg lag dieser Anteil im Mittel bei 8,4 % (unsere Rechnung anhand von Tabelle 3); die Autoren beschreiben den Durchschnitt als „nur rund 10 %“.
• In jeder der zwölf Konfigurationen scheiterten die meisten funktionierenden Lösungen an einem Sicherheitstest. Der Anteil reichte von 59 % bis 86 %, nach unserer Rechnung anhand von Tabelle 3 der Studie.

Den Agenten auf Sicherheit hinzuweisen, half ein wenig

Die Autoren probierten an der Konfiguration, die am häufigsten funktionierenden Code erzeugte, zwei Prompts aus. Der erste gibt dem Agenten die vollständige Liste der CWE-Kategorien, die der Benchmark abdeckt, mit Beschreibungen. Bevor er Code schreibt, bestimmt der Agent, welche Schwachstellentypen bei der Aufgabe eine Rolle spielen könnten. Der zweite Prompt nennt den Schwachstellentyp oder die Schwachstellentypen, auf die die Aufgabe zielt, und fordert den Agenten auf, verwundbare Implementierungen zu vermeiden.

Mit diesen Prompts stieg der Anteil der Aufgaben, bei denen Code entstand, der sowohl funktionierte als auch den Sicherheitstest bestand, von 11,8 % auf 14,5 % beziehungsweise 15,1 %. Der Anteil der Aufgaben mit funktionierendem Code sank jedoch von 57,0 % auf 50,0 % beziehungsweise 55,4 %. In den Worten der Autoren: Die Verbesserung „entschärft das Sicherheitsproblem nicht wesentlich“.

Nach unserer Lesart gibt der zweite Prompt dem Agenten Informationen, die ein Nutzer noch nicht hat. Die Autoren merken an, dass menschliche Experten potenzielle Sicherheitsrisiken vor der Implementierung erkennen können; der erste Prompt folgt diesem Ansatz. Der zweite nennt den Schwachstellentyp, auf dessen Prüfung die Aufgabe ausgelegt war. Außerhalb eines Benchmarks steht diese Information erst zur Verfügung, wenn der Fehler gefunden wurde.

Den Test gab es, weil die Schwachstelle bereits gefunden war

Das ist der Teil des Designs, den wir unterstreichen würden. Zu jeder Aufgabe gehört ein Sicherheitstest, den die Entwickler des Projekts in dem Commit hinzugefügt haben, der die ursprüngliche Schwachstelle behob. Jemand hatte den Fehler bereits gefunden, und die Entwickler des Projekts hatten einen Test dafür geschrieben. Diese Vorgeschichte ist es, die es dem Benchmark erlaubt, auf die Schwachstelle zu prüfen. Die Autoren prüften dann jeden Sicherheitstest von Hand und überarbeiteten diejenigen, die zu eng an eine bestimmte Implementierung gebunden waren.

Das neue Feature Ihres Agenten hat keinen solchen Test. Ihre Testsuite sagt Ihnen, was die Funktionstests des Benchmarks den Autoren sagten: dass das Feature funktioniert. Dennoch scheiterten die meisten funktionierenden Lösungen in der Studie an einem Sicherheitstest.

Eine Schwachstelle zu finden, für die noch niemand einen Test geschrieben hat, ist die Arbeit eines adversariellen Reviews. Unsere Erläuterung Adversarielles Code-Review: was der Begriff auslässt legt dar, was diese Arbeit umfasst und wo ihre Grenzen liegen.

Verschiedene Modelle vermeiden verschiedene Schwachstellen

Die Autoren berichten: „Agenten-Frameworks und LLMs sind gut darin, unterschiedliche Schwachstellen zu vermeiden“. Kimi K2 ging besser mit kryptografischen Fehlern um, während Gemini 3 Pro beim Durchsetzen von Zugriffskontrollen besser war.

Dieses Ergebnis betrifft das Schreiben von Code. Es klärt nicht, ob ein zweites Modell Fehler in der Arbeit des ersten Modells finden würde. Ebenso wenig ist ein zweites Modell von vornherein eine unabhängige Kontrolle: Wenn zwei Modelle falsch liegen, liegen sie oft auf dieselbe Weise falsch (Kim et al., ICML 2025). Siehe The attacker can run any model. How many do you run?.

Das ist ein Grund, warum wir Übereinstimmung zwischen Modellen nicht als Beweis behandeln: Die Behauptung, sie sei ein Beweis, ist eine der fünf Behauptungen, die wir nicht aufstellen.

Eine Frage, die die Studie offenlässt

Jede Aufgabe ging von einer Schwachstelle aus, die ein Mensch in ein reales Projekt eingebracht hatte. Bei den meisten funktionierenden Lösungen scheiterten die Agenten am Sicherheitstest für diese Schwachstelle. Die Studie fragt jedoch nicht, ob die Modelle der Geschichte dieser Projekte, einschließlich der verwundbaren Versionen, im Training begegnet waren. Siehe The Illusion of the Score.

Sie kann daher nicht unterscheiden zwischen der Reproduktion eines Fehlers, dem ein Modell im Training begegnet ist, und dem Fall, dass es unabhängig zum selben Fehler gelangt. Unser Forschungspapier Agentic Stemmatics untersucht, wie sich diese Möglichkeiten unterscheiden lassen.

Was sie nicht zeigt

• Basisraten. Die 186 Aufgaben wurden ausgewählt, weil jede sicherheitsrelevant ist und ein Mensch sie einmal falsch umgesetzt hat. Die Raten beschreiben diese Art von Feature, nicht von Agenten geschriebenen Code im Allgemeinen.
• Neuere Modelle. Die Studie testete vier Modelle, mit einem Versuch pro Aufgabe für jede Konfiguration. Andere Modelle und spätere Versionen können anders abschneiden.
• Review. Die Studie misst einen Agenten, der Code ohne menschliches Review schreibt. Sie sagt uns nicht, was ein Team, ein Werkzeug oder ein Prüfer danach finden würde. Siehe A Clean Benchmark Is Not a Clean Codebase und Das Tempo verfliegt. Die Komplexität bleibt..

Das Ergebnis ist begrenzt, aber klar. Bei diesen sicherheitsrelevanten Aufgaben scheiterten die meisten funktionierenden Lösungen dennoch an einem Sicherheitstest. Eine Testsuite, die nur prüft, ob das Feature funktioniert, würde diesen Unterschied nicht sichtbar machen.

Zitate aus der Studie sind unsere Übersetzung aus dem englischen Original der Studie. Diese Seite ist eine Übersetzung des englischen Originals; bei Abweichungen gilt das Original. Wenn hier etwas falsch ist, korrigieren wir es schriftlich auf dieser Seite.