Claude Opus 4.7 stoppte in einer neuen Studie den vorgegebenen Exploit in 90,2% der Fälle, doch nur 60,7% seiner Patches bestanden Tests der ursprünglichen Entwickler. Die Differenz von 29,5 Prozentpunkten ist entscheidend: Ein verhinderter Absturz beweist nicht, dass die Reparatur das beabsichtigte Verhalten erhält.
Dang K Le, Wenxuan Shi und Xinyu Xing von Northwestern berichteten die Benchmark-Zuverlässigkeitsstudie am 7. Oktober. Sie umfasst 112 historische Fehler in 84 offenen Projekten aus C, C++, Go und Rust. Der Preprint betrifft bestimmte Claude-Agenten-Konfigurationen, keine allgemeine Ausfallrate sämtlicher automatischer oder produktiver Sicherheitsreparaturen.
Bessere Modelle behalten eine Bewertungslücke
Kontrollierte Läufe nutzten OpenCode mit Sonnet 4.0, Sonnet 4.5 und Opus 4.7 auf denselben Fällen. Die Agenten erhielten Build- und Testanweisungen, anfangs aber nicht den PoC-Inhalt. Ein Proof of Concept ist die Eingabe oder Prozedur, die einen Fehler vorführt.
Sonnet 4.0 bestand PoCs zu 77,7% und Entwicklertests zu 43,8%, Sonnet 4.5 zu 84,8% und 48,2%, Opus zu 90,2% und 60,7%. Opus verbesserte beide Werte wirklich. Trotzdem scheiterten 32,7% seiner PoC-erfolgreichen Patches an Entwicklertests, etwa einer von drei scheinbaren Erfolgen, wie die öffentliche Bewertungsanalyse hervorhebt.
Opus bestand bestehende Regressionstests zu 94,6%. Das löst die niedrigere Entwicklerquote nicht: Alte Tests prüfen bekannte Beispiele, ein mit dem echten Fix hinzugefügter Test kann die zuvor fehlende Bedeutung rund um den Fehler erfassen.
Die Forscher rekonstruierten Unit- oder Integrationstests aus Upstream-Reparaturcommits und spielten sie nach dem Agentenpatch ein. Bewertet wird Verhalten statt textlicher Ähnlichkeit; alternative Implementierungen können bestehen. Vollständige Lösung erforderte vier aufeinanderfolgende Tore: Build, wiederholte PoC-Unterdrückung, alte Regression und neuer Entwicklertest.
PHP zeigt einen falschen Weg zum verschwundenen Absturz
Ein historischer PHP-Fehler in range() klassifizierte gemischte Typen falsch und konnte einen Nichtstring als String behandeln. Sofortige Ablehnung gemischter Typen könnte Absturz und viele alte Tests bestehen, würde aber gültige Zahlen-String-Kombinationen ablehnen, die PHP umwandeln sollte.
Der Upstream-Fix korrigierte die Klassifikation unter Erhalt gültigen Verhaltens. Ein naher gültiger Testfall trennte die Reparatur vom überrestriktiven Workaround. Ein Absturzgrader würde beide gleich belohnen.
Eine solche Schranke kann Notfallminderung sein, ohne vollständige Reparatur zu sein. Testsuite-Überanpassung erfüllt Beispiele statt Anforderungen. In Sicherheitsarbeit kann sie Symptome verstecken, andere Pfade offenlassen und falsche Sicherheit erzeugen, die Review reduziert.
Entwicklertests sind bessere Stellvertreter, keine vollständige Akzeptanz. Sie erschöpfen weder Leistung, Kompatibilität, Lesbarkeit noch Architektur. Eine vertretbare Alternative kann undokumentiertes Verhalten absichtlich ändern; ein fehlgeschlagener historischer Test ist deshalb untersuchungsbedürftige Abweichung, nicht automatisch Gefahr.
Anweisungen verändern die gemessene Fähigkeit
Mit detaillierten Buildkommandos bestand Sonnet 4.0 77,7% der PoCs, ohne 74,1%. Entwicklererfolg stieg von 41,1% auf 43,8%. Bei C/C++ allein bewegten Anweisungen PoC von 72% auf 92%, Entwicklertests nur von 28% auf 36%.
Dokumentation ist legitime Hilfe, auch für Menschen. Ohne offengelegte Informationsbudgets lassen sich Benchmarks aber nicht sicher vergleichen. Go und Rust haben oft vorhersehbare Kommandos; C/C++ vielfältige Systeme, Flags und Wrapper. Umgebungshilfe kann Werte verändern, bevor Reparaturqualität geprüft wird.
Bei 62 Go-Fällen erhöhte ein lesbarer Quell-PoC den Absturzerfolg von 69,4% auf 95,2%, Entwicklererfolg von 41,9% auf 48,4%. Der Harness zeigt API und Aufrufform und erleichtert Anpassung an den sichtbaren Test.
Bei 25 C/C++-Fällen änderte undurchsichtige Binär- oder Texteingabe weder 92% PoC noch 36% Entwickler. Beide Konfigurationen können PoC-Zugang behaupten, aber nur eine verrät ausführbare Absicht. Das sind keine gleichen Bedingungen.
Suche und Infrastruktur verzerren in beide Richtungen
Historische Aufgaben besitzen häufig öffentliche Issues, Hinweise und Fixes. Die Arbeit dokumentiert einen Agenten, der per Web den Upstream-Patch fand, und einen weiteren, der eine frühere Reparatur in unbereinigter Git-Historie fand. Erfolgreiche Patches maßen damit nicht sauber unabhängiges Reparaturdenken.
Web- und Verlaufssuche sind im Betrieb sinnvoll. Kontamination entsteht relativ zum Anspruch ungestützter Schlussfolgerung. Ein Werkzeug- und Suchbenchmark kann sie ausdrücklich zulassen. Mögliche Erinnerung historischer Fixes begrenzt außerdem absolute Erfolgswerte.
Frameworkfehler können dagegen richtige Arbeit verbergen oder geheime Lösungen offenlegen. Rechte, Timeouts und kollidierende Testdateien verhindern Builds, bestrafen langsame Projekte oder markieren gute Änderungen falsch. Einzelne Infrastrukturprobleme betrafen in vollständigen Läufen etwa 5–32% der Fälle, teils mehr als Ranglistenabstände.
Ein Wert gehört deshalb zu Modell, Agentengerüst, Prompt, Werkzeugen, Quellverpackung, Grenzen und Bewertung zusammen. Kontrolltests nutzten OpenCode mit Claude, Fallstudien auch Claude Code mit Sonnet 4.5. Die Gerüste sind nicht austauschbar.
Verwandte Studien verlangen mehrere Tests
PVBench untersuchte 209 Fälle aus 20 Projekten. Über 40% der von Basistests akzeptierten Patches scheiterten an aus Entwicklerfixes gewonnenen Zusatztests. Daten und Design unterscheiden sich; das ist keine direkt vergleichbare Claude-Quote.
PatchBench fand bei elf Agenten durchschnittlich Faktor 1,83 überhöhte Lösungsraten durch PoC-Alleinprüfung. Sicherheitswiederholung, Unit- und Ausgabetests senkten die stärksten von über 97% ursprünglichen PoCs auf etwa die Hälfte bei kombinierter Prüfung.
PatchBench wählte zudem Fehler mit Reparaturen außerhalb des Absturzstacks und verpflanzte sie in geänderte Repository-Kontexte, um Erinnerung weniger nützlich zu machen. Erfolg wird nicht einfach als neue Schlussfolgerung angenommen.
Berkeleys CyberGym-E2E umfasst 920 Schwachstellen aus 139 Projekten und kombiniert Entdeckung, Reproduktion und Reparatur. Beste Konfigurationen reparierten etwa 80% bei vorgegebenem Ziel; mit notwendiger Entdeckung sank das End-to-End-Ergebnis. Oberflächliche Absturzschranken blieben sichtbar.
Andere Modelle, Aufgaben und Definitionen ergeben keine gemeinsame Rangliste. Die Cyber-Index-Methodik erweitert ebenfalls auf Audit, Entdeckung, Reproduktion und Reparatur ohne legitimes Verhalten zu zerstören. Gemeinsam ist die Frage, was Erfolg einschließt.
Stärkere Bewertung ist noch kein Produktionsbeweis
Northwesterns Auswahl erforderte reproduzierbare Builds und sinnvolle Upstream-Tests. Die 112 Fehler sind vielfältig, repräsentieren aber nicht jede Produktionslücke. Öffentliches Material kann im Training gewesen sein. Das begrenzt absolute Raten, nicht die kontrolliert gezeigte Empfindlichkeit gegenüber Prompts und Gradern.
Produktion kann mit Projekttests, statischer Analyse, Fuzzing, Review und gestaffeltem Rollout sicherer werden, durch unvollständige Tests, undokumentiertes Verhalten und fehlende Abhängigkeiten aber auch schwieriger sein. Kuratierte Benchmarks oder ein bestandener PoC belegen keine unbeaufsichtigte Bereitstellung.
Nützlich wären getrennte PoC- und Intentionstests, offengelegte Werkzeug- und Netzrechte, bereinigte Historie, Zeitlimits und Stufenfehler sowie reale Akzeptanz, Überarbeitung und Ablehnung durch Maintainer. Andere Exploitwege und neue Schwächen zählen ebenfalls. Textgleichheit mit dem alten Patch wäre kein Ersatz für Verhalten.
Eine durchsuchbare technische Wissensbasis kann Prompts, Werkzeugspuren, Patches und Prüfungen erhalten, macht die Änderung aber nicht richtig. Belegt sind ein deutlicher Opus-Fortschritt und 29,5 Punkte Überzeichnung durch Absturzbewertung. Generierte Reparaturen bleiben Kandidaten, deren Sicherheit und legitimes Verhalten unabhängige Nachweise brauchen.