# Ist Vibe Coding sicher? Was ein Benchmark mit 186 realen Aufgaben ergab > Die Konfiguration, die unter zwölf Agenten-Konfigurationen am häufigsten funktionierenden Code erzeugte, tat dies in 57 % der Aufgaben; nur in 11,8 % funktionierte ihr Code und bestand zugleich den Sicherheitstest. Den Agenten auf das Risiko hinzuweisen, half ein wenig. Die Studie konnte auf jede Schwachstelle testen, weil sie bereits gefunden und behoben worden war und der Fix einen Sicherheitstest mitbrachte. Der neue Code Ihres Agenten hat noch keinen solchen Test. Source: https://counterproof.io/de/notes/ist-vibe-coding-sicher/ · Published 28 September 2026 · CounterProof ist eine Praxis der Clavestra Capital Limited (Malta, C 113987). **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](https://counterproof.io/glossary/#benchmark-score). 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*](https://counterproof.io/de/adversarielles-code-review/) 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](https://counterproof.io/glossary/#correlated-errors) (Kim et al., ICML 2025). Siehe [*The attacker can run any model. How many do you run?*](https://counterproof.io/notes/the-attacker-can-run-any-model/). 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](https://counterproof.io/refusals/). ## 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*](https://counterproof.io/notes/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](https://research.counterproof.io/agentic-stemmatics.html) 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*](https://counterproof.io/notes/a-clean-benchmark-is-not-a-clean-codebase/) und [*Das Tempo verfliegt. Die Komplexität bleibt.*](https://counterproof.io/de/notes/das-tempo-verfliegt-die-komplexitaet-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.* ## Questions this page answers **Ist Vibe Coding sicher?** In diesem Benchmark nicht von vornherein. Die Konfiguration, die unter zwölf Agenten-Konfigurationen am häufigsten funktionierenden Code erzeugte, tat dies in 57 % der Aufgaben; nur in 11,8 % bestand ihr Code auch den Sicherheitstest, und wenn die Agenten nicht auf Sicherheit hingewiesen wurden, lag keine Konfiguration über 12,9 %. Jede Aufgabe wurde ausgewählt, weil sie sicherheitsrelevant war; diese Raten beschreiben also diese Art von Feature, nicht jeglichen von Agenten geschriebenen Code. **Wenn der Code meine Tests besteht, ist er dann sicher?** Bestandene Funktionstests sagen Ihnen, dass das Feature funktioniert. In der Studie scheiterten 79,3 % der funktionierenden Lösungen von SWE-agent mit Claude 4 Sonnet, der Konfiguration, die am häufigsten funktionierenden Code erzeugte, dennoch an einem Sicherheitstest. **Hilft es, den Agenten zu bitten, an Sicherheit zu denken?** Ein wenig. Ein Prompt forderte den Agenten auf, vor dem Schreiben des Codes Risiken anhand einer mitgelieferten Liste zu bestimmen. Ein anderer nannte den Schwachstellentyp, den er vermeiden sollte. Der Anteil der Aufgaben mit Lösungen, die sowohl funktionierten als auch den Sicherheitstest bestanden, stieg von 11,8 % auf 14,5 % beziehungsweise 15,1 %. Beide Prompts verringerten außerdem den Anteil der Aufgaben mit funktionierenden Lösungen. **Würde ein zweites KI-Modell finden, was das erste übersehen hat?** Die Studie hat das Schreiben von Code gemessen, nicht das Prüfen. Sie fand, dass verschiedene Modelle verschiedene Schwachstellentypen vermeiden. Ob ein zweites Modell die Fehler des ersten findet, ist eine eigene Frage. Modelle verschiedener Unternehmen sind nicht automatisch unabhängig.