Bittet man einen KI-Coding-Agenten um einen Upload-Endpunkt, bekommt man einen. Es kompiliert. Die Demo funktioniert. Der Pull Request sieht um 18 Uhr ordentlich aus. Und irgendwo darin steckt ein Path-Traversal-Fehler, den niemand bemerkt, bis jemand beschließt, genauer hinzusehen.
Das ist keine hypothetische Sorge mehr. Es ist ein gemessenes Ergebnis, und die Zahl ist unangenehm: Der beste Coding-Agent in einem brandneuen Benchmark lieferte Code, der zugleich funktional und sicher war, nur bei 25,1 % der Aufgaben.
Die 25-Prozent-Zahl und warum sie Sie beschäftigen sollte
Am 14. Oktober stellte ein auf Hugging Face veröffentlichtes Paper den Last Secure Code Benchmark (LSCB) vor, mit dem Untertitel «Is the Code You Vibe Secure?». Das Design ist brutal einfach und diesmal realistisch. Die Forscher nahmen 150 echte Schwachstellen, erweiterten sie zu 450 Aufgaben in drei Vibe-Coding-Szenarien und ließen sechs Frontier-Agenten darauf los, in sieben Sprachen, darunter Java, C, C++, JavaScript, Python, PHP und Go. Die Abdeckung umfasst 24 CWEs, darunter 21 der CWE Top 25 von 2025 und 8 der Top 10 aktiv ausgenutzten Schwachstellen.
Die Ergebnisse zerfallen in zwei Zahlen mit sehr unterschiedlichen Geschichten:
- Funktional wirken die Agenten exzellent. Zwischen 73,6 % und 91,3 % der Aufgaben bestehen die verborgenen Funktionstests. Der Code tut, was verlangt wurde.
- Funktional und sicher zugleich bricht das Bild zusammen. Der stärkste Agent, Claude Fable 5, landet bei 25,1 %. Die anderen fünf liegen zwischen 16,4 % und 24,7 %.
Weil die funktionalen Bestehensraten so viel höher liegen, ist der größte Teil dieses Scheiterns Unsicherheit und kein Defekt. Der Code läuft, das Feature wird demonstriert, die Schwachstelle wird ausgeliefert. Die Autoren ergänzen, dass selbst das beste Modell nur 12 % der Verwundbarkeitsszenarien über alle Vibe-Coding-Settings hinweg besteht.
Wie der Benchmark gebaut wurde und warum er fair ist
Die wichtigste Designentscheidung ist, was die Prompts weglassen. Jede Aufgabenspezifikation verlangt nur Funktionalität und erwähnt Sicherheit nie. Das spiegelt, wie Teams einem Agenten tatsächlich Aufträge geben: einen Upload-Endpunkt hinzufügen, nicht einen Upload-Endpunkt hinzufügen, der Path Traversal widersteht.
Jede der 450 Aufgaben wurde anschließend zweimal durch verborgene Tests bewertet. Ein Satz prüft, ob der Code tut, was verlangt wurde. Ein zweiter prüft, ob er die konkrete Schwachstelle vermeidet, die die ursprüngliche reale Verwundbarkeit darstellte. Echte Schwachstellen statt synthetischer Fehler zu nutzen, ist wichtig, und verborgene Tests senken die Chance, dass ein Modell einen sichtbaren Prüfer austrickst.
Es lohnt sich, die Einschränkungen ehrlich zu halten, weil die Forscher hier sorgfältig waren. Der Benchmark misst das Standardverhalten: Die Modelle erhielten keine Sicherheitsanweisungen, keinen Skill für sichere Programmierung und keine Review-Schleife. Agenten mit einer ausdrücklichen Sicherheitsanforderung und einem automatisierten Review-Durchlauf dürften deutlich besser abschneiden. Ein Bestanden bedeutet, dass der Code die geprüfte Schwachstelle vermieden hat, nicht dass jede andere Zeile sicher ist. Und Agent-Harnesses ändern sich monatlich, das hier ist also eine Momentaufnahme, kein Urteil für immer.
Das ist kein Ausreißer
Wäre LSCB die einzige Studie dieser Richtung, ließe sie sich als reißerische Überschrift ablegen. Ist sie nicht. Veracodes GenAI Code Security Update vom Frühjahr 2026 testete über 150 große Sprachmodelle mit 80 Coding-Aufgaben in vier Sprachen, verifiziert per statischer Analyse, und fand dieselbe Form von Problem:
- Syntaktische Korrektheit: über 95 %
- Sicherheitsbestehensrate ohne Sicherheitsanweisung: rund 55 %
- Cross-Site-Scripting: rund 15 %
- Log-Injection: rund 13 %
- SQL-Injection: 82 %
- Zwei Jahre Modellveröffentlichungen: von rund 55 % zu rund 55 %
Die letzte Zeile ist die, bei der man innehalten sollte. Jeder Start in diesem Fenster wurde als Sprung nach vorn gefeiert, und in dieser Messung bewegte sich die Nadel nicht. Auf Reasoning ausgerichtete Modelle lagen mit 70-72 % besser, eine echte Verbesserung und trotzdem nichts, was man ungereviewt ausliefert. Auf Repository-Ebene sieht es ähnlich aus: Der SusVibes-Benchmark meldete, dass die meisten funktional bestandenen Agent-Lösungen unsicher waren, mit dem besten berichteten Ergebnis von etwa 11,8 % korrekt und sicher.
Der zweite Fehlermodus: Abhängigkeiten, die es nicht gibt
Sicherheitsfehler sind das offensichtliche Risiko. Das seltsamere ist die Lieferkette, und sie ist still zu einem Angriff geworden.
Eine Studie, die 576.000 Codebeispiele mit 16 Modellen erzeugte, fand, dass 19,7 % der empfohlenen Pakete nicht existierten, über mehr als 205.000 verschiedene erfundene Namen. Offene Modelle halluzinierten im Schnitt 21,7 % der Zeit, kommerzielle 5,2 %. Die Rate ist nicht der interessante Teil. Das hier ist es: Bei zehn Wiederholungen derselben Prompts kamen 43 % der halluzinierten Paketnamen jedes Mal wieder. Die Erfindungen sind systematisch, nicht zufällig.
Ein vorhersehbarer Name ist ein Name, den jemand registrieren kann, bevor Sie danach fragen. Dieser Angriff hat inzwischen einen Namen, Slopsquatting, und ein Forscher demonstrierte ihn, indem er ein leeres Paket unter einem plausiblen halluzinierten Namen veröffentlichte, das anschließend zehntausendfach heruntergeladen wurde. Geben Sie die Installation von Abhängigkeiten an einen autonomen Agenten, verschwindet lautlos der einzige menschliche Kontrollpunkt dieser Kette: den Paketnamen zu bemerken und zu entscheiden, ihn zu installieren.
Was wir Kunden raten
Nichts davon bedeutet, langsamer zu werden oder die Produktivitätsgewinne aufzugeben. Es bedeutet, den Fokus der menschlichen Aufmerksamkeit zu verlagern. Fünf Regeln, die wir nutzen:
- Benennen Sie das Risiko im Prompt, bevor Code existiert. Diese Änderung berührt Nutzerdaten und Login: Listen Sie zuerst die Sicherheitsanforderungen auf, wir bauen dann dagegen. Das kostet einen Satz, und der Benchmark legt nahe, dass es mehr zählt als die Modellwahl.
- Verifizieren Sie gegen die Kategorien, die tatsächlich durchfallen. Fragen Sie nicht, ob das sicher ist. Das liefert einen Aufsatz. Fragen Sie konkret nach Ausgaben, die unescaped auf eine Seite gelangen, nach Nutzereingaben, die ungeprüft in ein Log oder eine Abfrage fließen, und nach allem, was durch Verkettung von Strings entsteht.
- Behandeln Sie jede neue Abhängigkeit als Lieferkettenereignis. Pro Paket: Existiert es in der offiziellen Registry, wer veröffentlicht es, wann wurde es erstmals veröffentlicht, wie viele Versionen gibt es. Sie auditieren keinen Code, Sie prüfen, ob die Sache eine Vergangenheit hat.
- Halten Sie ein menschliches Gate am Diff. Agenten produzieren mehr Code, nicht mehr geprüfte Software. Review ist jetzt der Engpass und die günstigste Kontrolle, die Sie besitzen.
- Gehen Sie davon aus, dass Defaults unsicher sind, und instrumentieren Sie es. Fügen Sie SAST und Dependency-Scanning in die Pipeline ein, statt darauf zu vertrauen, dass der Agent sorgfältig ist.
Das Fazit für Ihr Team
Agentisches Coding hat die Generierung gelöst. Ungelöst bleiben Korrektheit und Sicherheit, und genau dieser ungelöste Teil war früher das, wofür Ingenieure bezahlt wurden. Die Teams, die die nächsten zwei Jahre gewinnen, sind nicht die mit den besten Prompts. Es sind die, deren Pipelines auffangen, was der Agent hinterlässt: Anforderungen vor dem Prompt, automatisiertes Scannen danach und ein Reviewer, der die vier oder fünf Schwachstellenklassen kennt, die immer wieder auftauchen.
Tempo ist inzwischen Grundvoraussetzung. Was Review, Scanner und Pentest übersteht, ist das Produkt.