CyberGym-Benchmark erklärt: Was der E2E-Score tatsächlich misst

Der am weitesten verbreitete CyberGym-Score — die Zahl im Launch-Post, diejenige, die modellübergreifend verglichen wird — ist eine Erfolgsquote bei 131 gefilterten Aufgaben, wobei Erfolg bedeutet, dass ein Agent eine Proof-of-Concept-Eingabe erzeugte, die einen ungepatchten C/C++-Build zum Absturz bringt, einen Patch schrieb, der diesen Absturz verhindert, und die von Entwicklern geschriebenen Tests des Projekts nicht beschädigte. In der Zusammenstellung von BenchLM führt MiMo-V2.6-Flash mit 95,1 % und MiMo-V2.6-Pro mit 94,0 %, wobei DeepSeek-V4.1-Flash einige Punkte dahinter im oberen Achtzigerbereich liegt. Fast niemand, der diese Tabelle zitiert, erwähnt drei Dinge, die darüber entscheiden, ob die Zahlen vergleichbar sind: der Benchmark existiert in mehr als einer Implementierung, die meisten Zeilen sind Selbstauskünfte der Anbieter statt unabhängiger Läufe, und die interessanteste einzelne Stufe wird erfasst, aber nicht gezählt. Das ist derselbe Attributionsstandard, den das KI-Vorfallarchiv an seine eigenen Einträge anlegt — eine Behauptung ohne Quelle ist kein Ergebnis — und der CyberGym-Korpus verfehlt ihn häufiger, als sein Ruf vermuten lässt.

Dies ist ein Leitfaden dazu, was der Benchmark von einem Agenten verlangt, wie das Aufgabenset erstellt wurde, wo die Implementierungen voneinander abweichen und was ein Verteidiger aus einer hohen Punktzahl schließen sollte und was nicht.

Die Aufgabe: finden, reproduzieren, patchen – ohne etwas kaputt zu machen

CyberGym stammt vom Berkeley Center for Responsible, Decentralized Intelligence, und seine Prämisse ist bewusst eng gefasst. Jede Aufgabe zielt auf eine Speichersicherheitslücke in einem weit verbreiteten Open-Source-C/C++-Projekt ab. Der Agent muss den Fehler lokalisieren, eine Proof-of-Concept-Eingabe schreiben, die einen Sanitizer-Absturz auslöst, und dann den Code so patchen, dass der Absturz nicht mehr reproduziert wird – während die eigenen Tests des Projekts weiterhin bestehen. Genau diese Abfolge ist der Kern. Ein Benchmark, der nur „Finde den Fehler“ verlangen würde, würde Mustererkennung belohnen; die Anforderung einer funktionierenden Absturzeingabe und eines nicht brechenden Patches zwingt den Agenten, den Kreis von Verdacht über demonstrierten Defekt bis hin zur Behebung zu schließen.

RDI beherbergt den Benchmark in einem breiteren Observatorium, das KI-Cyberfähigkeiten über Angriffs- und Verteidigungsphasen hinweg verfolgt, und die Rahmung ist beachtenswert: CyberGym ist ein Instrument auf einem Prüfstand, neben ExploitGym und der Ende-zu-Ende-Variante. Liest man es als eigenständiges Leaderboard, geht dieser Kontext verloren, was einer der Gründe dafür ist, dass die Zahlen sich schlecht übertragen lassen.

Vier Stufen, von denen drei gewertet werden

Die Bewertungsregel ist der am wenigsten berücksichtigte Teil des Benchmarks, denn hier kann eine plausibel klingende Punktzahl von dem abweichen, was tatsächlich geschehen ist.

Stufe 1 ist die Reproduktion: Bringt die Proof-of-Concept-Eingabe des Agenten den ungepatchten Build zum Absturz. Stufe 2 ist der Patch: Stoppt die eingereichte Änderung genau diesen Absturz. Stufe 3 ist die Regression: Bestehen die vom Entwickler geschriebenen Funktionstests weiterhin. Diese drei ergeben die Punktzahl.

Stufe 4 fragt, ob der Patch die tatsächliche Ground-Truth-Schwachstelle behebt, und wird als Diagnose erfasst statt gezählt. Diese Asymmetrie verdient einen Moment Aufmerksamkeit, denn sie ist der Unterschied zwischen „der Agent kann einen Absturz verschwinden lassen“ und „der Agent kann den Fehler beheben“. Beides sind nützliche Aussagen; sie sind nicht dieselbe Aussage. Ein Agent, der einen Absturz unterdrückt, indem er das Signal abfängt, eine Grenzprüfung über den Überlauf hinaus ausweitet oder den Codepfad vollständig deaktiviert, wird in den Stufen 1 bis 3 punkten und Stufe 4 nicht bestehen. Wenn ein Bericht eine einzelne Zahl nennt, ohne zu sagen, ob Stufe 4 herangezogen wurde, lässt sich nicht erkennen, welche der beiden Dinge gemessen wurde — und die Diagnose existiert genau deshalb, damit man danach fragen kann.

Wie die 131 Aufgaben ausgewählt wurden – und was das für die Punktzahl bedeutet.

Der Quelldatensatz ist größer als das bewertete Set, und die Filterung ist der größte einzelne Hebel für die Vergleichbarkeit. Der Datensatz von RDI enthält 920 Schwachstellen in 139 Open-Source-Projekten, die aus dem OSS-Fuzz von Google stammen. Die von Drittanbieter-Trackern verwendete End-to-End-Variante reduziert dies auf 131 Aufgaben, mit einer Aufgabe pro Projekt, ausgewählt nach Schwierigkeit, wobei Aufgaben mit Oracle-Leaks oder Sandbox-Kompatibilitätsbeschränkungen ausgeschlossen werden.

Daraus folgen direkt drei Konsequenzen. Erstens, eine Aufgabe pro Projekt bedeutet, dass der Score von der Breite statt von der Tiefe dominiert wird: Ein Agent, der über viele Projekte hinweg durchschnittlich ist, wird einen übertreffen, der bei drei hervorragend ist, was eine vertretbare Designentscheidung und eine andere Messung ist als „wie viele Schwachstellen dieser Agent beheben kann“. Zweitens, das Ausschließen von Oracle-Leaks entfernt Aufgaben, bei denen die Antwort aus der Umgebung auffindbar ist, statt durch Schlussfolgerungen hergeleitet zu werden, sodass die verbleibende Menge auf eine bestimmte Weise schwieriger ist — sie entfernt Abkürzungen, statt einfache Aufgaben zu entfernen. Drittens, ein Zeitbudget von 90 Minuten pro Aufgabe innerhalb einer Sandbox, die aus dem OSS-Fuzz-Image des Projekts erstellt wird, ist Teil der Definition von Erfolg, nicht ein Detail, denn ein großer Teil der realen Arbeit an Schwachstellen ist genau durch diese Art von Einschränkung begrenzt, und Agenten, die auf unbegrenzte Erkundung angewiesen sind, werden hier scheitern, während sie anderswo erfolgreich sind.

Jeder Vergleich, der die Regel zur Aufgabenauswahl ignoriert, vergleicht zwei verschiedene Tests, die zufällig denselben Namen tragen.

Zwei Implementierungen – und warum sie nicht übereinstimmen müssen

Hier liegt der Großteil der Verwirrung. {{1}}CyberGym-E2E existiert als RDI-Benchmark und als eine Implementierung, die von einem Drittanbieter-Evaluator betrieben wird{{/1}}, und es ist nicht garantiert, dass die beiden für dasselbe Modell dieselbe Zahl liefern. {{2}}Die Dokumentation des Evaluators selbst sagt das ganz offen: Seine Implementierung verwendet einen gefilterten Satz von 131 Aufgaben, eine pro Projekt, nach Schwierigkeit ausgewählt, und führt jede Aufgabe in einer isolierten Sandbox aus, die aus dem OSS-Fuzz-Image des Projekts erstellt wird, wobei ein eigener Agent-Harness mit einem 90-Minuten-Budget pro Aufgabe zum Einsatz kommt.{{/2}}

Dieser Satz enthält die beiden Variablen, die über die Punktzahl entscheiden. Der Harness ist die Schleife, in der der Agent läuft – wie er Tool-Ausgaben beobachtet, wie viele Schritte er machen kann, wie er sich von einem fehlgeschlagenen Versuch erholt. Ein stärkerer Harness mit einem schwächeren Modell kann das Umgekehrte übertreffen, und der Harness ist nicht Teil der Gewichte des Modells. Das Budget wirkt mit beiden zusammen. Eine CyberGym-Zahl wird also korrekt als „dieses Modell, in diesem Harness, in dieser Implementierung“ geschrieben, und eine Zahl, die ohne die Implementierung zitiert wird, ist eine Zahl ohne Nenner.

Es gibt einen Effekt zweiter Ordnung, der erwähnt werden sollte: Da das Harness echte Arbeit leistet, kann eine Verbesserung des CyberGym-Scores zwischen zwei Modellversionen teilweise auf eine Harness-Verbesserung zurückgehen, und ein Anbieter, der seine eigenen Harness-Ergebnisse meldet, meldet Systemfähigkeit statt Modellfähigkeit. Beides ist legitim; beides zu vermengen nicht.

Den Tracker-Table ehrlich lesen

Die Tabelle, auf die die meisten stoßen, ist eine sekundäre Zusammenstellung, und sie kennzeichnet ihre eigene Herkunft – das ist der nützliche Teil, wenn man die Kennzeichnung liest. Von den 29 Zeilen stammen 7 vom Benchmark-Eigentümer oder aus einem unabhängigen Lauf, 21 sind Selbstauskünfte der Anbieter und eine ist ein Sekundärbericht. Die Zusammenstellung erklärt unumwunden, dass sie die Tabelle nur als Referenz zeigt und darauf keine Rangfolge vornimmt, und rät, sie mit Vorsicht zu lesen, weil die meisten Zeilen Selbstauskünfte sind. Ihr eigener Sättigungshinweis ist die nützlichste Zeile auf der Seite: Die obersten drei sind über etwa 70 Punkte verteilt, während die obersten zehn innerhalb von rund 10 liegen, sodass die Tabelle Modelle noch unterscheidet – aber nicht an der Spitze des Bereichs, wo die Rangfolge dünn ist.

Eine Selbstauskunft des Anbieters ist darstellbare Evidenz. Sie ist keine unabhängige Messung, und dieser Unterschied ist in diesem Benchmark wichtiger als in den meisten anderen, weil die Harness-Variable einem Anbieter erheblichen Spielraum lässt, die Zahl, die er meldet, anzupassen. Wenn eine Selbstauskunft und ein unabhängiger Lauf voneinander abweichen, gewinnt der unabhängige Lauf. Wenn nur eine Selbstauskunft vorliegt, lautet die ehrliche Lesart „unverifiziert, plausibel, keine vergleichbare Baseline“.

Dieselbe Vorsicht gilt umgekehrt für die Falle, die dieser Benchmark den Lesern stellt: Ein Modell ohne CyberGym-Zeile hat nicht null erreicht. Es wurde in diesem Harness nicht gemessen, was eine andere Aussage ist. Fehlende Werte als Scheitern zu behandeln, ist der Weg, auf dem eine Tabelle aufhört, eine Messung zu sein, und zu einem Leaderboard wird.

Was eine hohe Punktzahl für einen Verteidiger bedeutet – und was nicht.

Die Frage, die ein Sicherheitsteam tatsächlich umtreibt, ist nicht „welches Modell steht an der Spitze der Tabelle“, sondern „was macht ein Agent, der hier gut abschneidet, mit meinem Risiko“. Der Benchmark beantwortet eine engere Frage als die, die gestellt wird – und es lohnt sich, diese Lücke zu benennen.

Das bedeutet, dass der Agent innerhalb von 90 Minuten und innerhalb eines bekannten Builds einen Speichersicherheitsfehler in echtem Open-Source-Code lokalisieren, eine funktionierende Crash-Eingabe erzeugen und eine Änderung schreiben kann, die den Absturz stoppt, ohne Tests zu brechen. Das ist eine echte Fähigkeit, sie ist direkt relevant für Triage- und Patch-Arbeit, und es ist die Art von Aufgabe, bei der ein kompetenter Agent die Warteschlange eines Analysten sinnvoll verkürzt.

Das bedeutet nicht, dass der Agent Ihre Codebasis, Ihr Bedrohungsmodell oder Ihr Deployment versteht. Die Aufgaben stammen aus öffentlichen OSS-Fuzz-Zielen mit einer bekannten Ground-Truth-Schwachstelle und einer Testsuite, die dem Agenten sagt, ob er fertig ist. Produktionscode hat kein solches Orakel. Es bedeutet auch nicht, dass der Agent den Fehler und nicht einen Fehler findet: Stufe 4 existiert, weil diese auseinandergehen, und Stufe 4 zählt nicht.

Und sie lässt sich nicht auf die offensive Seite übertragen, wo dieselbe Fähigkeit anders gelesen wird. Ein Agent, der eine Speichersicherheitslücke finden und reproduzieren kann, kann dies in Code tun, für dessen Test er keine Berechtigung erhalten hat, weshalb eine Fähigkeit dieser Größenordnung genau das ist, was Zugriffskontrolle auf Modellebene motiviert statt eines Haftungsausschlusses in einem System-Prompt.

Welche Fragen man stellen sollte, bevor man einer CyberGym-Zahl vertraut

Fünf Fragen, die sich anhand eines gut geschriebenen Berichts beantworten lassen und anhand eines Launch-Posts normalerweise nicht.

• Welche Implementierung? RDIs Benchmark oder eine gefilterte Variante eines externen Prüfers. Wenn der Bericht dazu nichts sagt, ist die Zahl mit nichts vergleichbar.

• Wessen Testlauf? Unabhängige Bewertung oder Selbstauskunft des Anbieters. Die Übersichtstabelle kennzeichnet dies pro Zeile; die meisten Marketingmaterialien tun das nicht.

• Welches Harness und welches Budget? Wenn das Harness das des Anbieters selbst ist und nicht beschrieben wird, behandeln Sie das Ergebnis als eine Aussage auf Systemebene über eine bestimmte Produktkonfiguration.

• Wurde Phase 4 hinzugezogen? Eine gemeldete Rate samt zugehöriger Diagnose zeigt Ihnen, ob die Patches den Fehler behoben oder den Absturz nur unterdrückt haben.

• Welches Aufgabenset? 131 nach Schwierigkeit ausgewählte Aufgaben, eine pro Projekt, sind das übliche Set; ein anderer Filter ist ein anderer Test.

Cybergym ist ein gut konstruierter Benchmark für eine schwierige, reale Aufgabe, und seine Konstruktion ist interessanter als sein Leaderboard. Die Stages sagen dir, was ein Agent tun musste; die Filterung sagt dir, wovon der Score ein Score ist; der Harness sagt dir, wem Anerkennung gebührt. Eine Zahl, die mit diesen drei Dingen zusammen ankommt, ist wirklich nützlich. Eine Zahl, die allein ankommt, ist eine Pressemitteilung mit Prozentzeichen.