CyberGym-benchmark uitgelegd: wat de E2E-score daadwerkelijk meet

De CyberGym-score die het breedst circuleert — het getal in het lanceringsbericht, het getal dat tussen modellen wordt vergeleken — is een taaksuccespercentage over 131 gefilterde taken, waarbij succes betekent dat een agent een proof-of-concept-invoer heeft geproduceerd die een ongepatchte C/C++-build laat crashen, een patch heeft geschreven die die crash stopt, en de door de ontwikkelaars van het project geschreven tests niet heeft gebroken. In de compilatie van BenchLM leidt MiMo-V2.6-Flash met 95,1% en MiMo-V2.6-Pro met 94,0%, met DeepSeek-V4.1-Flash een paar punten daarachter in de hoge tachtig procent. Bijna niemand die die tabel citeert, noemt drie dingen die bepalen of de cijfers vergelijkbaar zijn: de benchmark bestaat in meer dan één implementatie, de meeste rijen zijn zelfrapportages van providers in plaats van onafhankelijke runs, en de meest interessante fase wordt vastgelegd maar niet meegeteld. Dat is dezelfde standaard voor toeschrijving het AI-incidentenarchief hanteert voor zijn eigen vermeldingen — een bewering zonder bron is geen resultaat — en het CyberGym-corpus voldoet daar vaker niet aan dan zijn reputatie suggereert.

Dit is een gids voor wat de benchmark van een agent vraagt, hoe de takenverzameling is samengesteld, waar de implementaties van elkaar afwijken, en wat een verdediger wel en niet uit een hoge score mag concluderen.

De taak: vinden, reproduceren, patchen — zonder iets te breken

CyberGym komt van het Berkeley Center for Responsible, Decentralized Intelligence, en de premisse ervan is bewust nauw afgebakend. Elke taak richt zich op een geheugenveiligheidskwetsbaarheid in een veelgebruikt open-source C/C++-project. De agent moet de bug lokaliseren, een proof-of-concept-invoer schrijven die een sanitizer-crash veroorzaakt, en vervolgens de code patchen zodat de crash zich niet meer laat reproduceren — terwijl de eigen tests van het project blijven slagen. Die volgorde is het hele punt. Een benchmark die alleen vroeg om “de bug te vinden” zou patroonherkenning belonen; het vereisen van een werkende crash-invoer en een niet-brekende patch dwingt de agent de cyclus te sluiten van vermoeden via aangetoond defect naar oplossing.

RDI host de benchmark binnen een breder observatorium dat de cybercapaciteit van AI volgt over aanvals- en verdedigingsfasen, en die inkadering is het opmerken waard: CyberGym is één instrument op een bank, naast ExploitGym en de end-to-end variant. Het als een op zichzelf staand leaderboard lezen verliest die context, wat een van de redenen is dat de cijfers slecht reizen.

Vier fasen, waarvan er drie scoren

De scoringsregel is het meest ondergerapporteerde onderdeel van de benchmark, omdat daar een plausibel klinkende score kan afwijken van wat er werkelijk is gebeurd.

Stage 1 is de reproductie: laat de proof-of-concept-invoer van de agent de ongepatchte build crashen. Stage 2 is de patch: stopt de ingediende wijziging die specifieke crash. Stage 3 is regressie: slagen de door de ontwikkelaar geschreven functionaliteitstests nog steeds. Die drie leveren de score op.

Stage 4 vraagt of de patch de werkelijke ground-truth-kwetsbaarheid verhelpt, en wordt geregistreerd als diagnostiek in plaats van meegeteld. Die asymmetrie verdient even aandacht, want het is het verschil tussen "de agent kan een crash laten verdwijnen" en "de agent kan de bug verhelpen". Beide zijn nuttige beweringen; het zijn niet dezelfde bewering. Een agent die een crash onderdrukt door het signaal op te vangen, een grenzencontrole voorbij de overflow te verbreden, of het codepad volledig uit te schakelen, scoort op fase 1 tot en met 3 en faalt op stage 4. Als een write-up één getal rapporteert zonder te vermelden of stage 4 is geraadpleegd, kun je niet weten welke van de twee dingen is gemeten — en de diagnostiek bestaat juist zodat je dat kunt vragen.

Hoe de 131 taken werden gekozen — en wat dat doet met de score

De brondataset is groter dan de gescoorde set, en de filtering is de grootste hefboom voor vergelijkbaarheid. De dataset van RDI bevat 920 kwetsbaarheden in 139 open-sourceprojecten, afkomstig van Google's OSS-Fuzz. De end-to-endvariant die door trackers van derden wordt gebruikt, beperkt dit tot 131 taken, één taak per project, geselecteerd op moeilijkheid, waarbij taken met oracle-lekken of beperkingen op sandboxcompatibiliteit worden uitgesloten.

Hieruit volgen direct drie consequenties. Ten eerste: één taak per project betekent dat de score wordt gedomineerd door breedte in plaats van diepte: een agent die gemiddeld presteert over veel projecten zal beter presteren dan een die uitblinkt op drie, wat een verdedigbare ontwerpkeuze is en een andere meting dan "hoeveel kwetsbaarheden kan deze agent oplossen". Ten tweede: het uitsluiten van oracle-lekken verwijdert taken waarbij het antwoord uit de omgeving kan worden afgeleid in plaats van beredeneerd, dus de overblijvende set is op een specifieke manier moeilijker — het verwijdert snelkoppelingen in plaats van gemakkelijke taken te verwijderen. Ten derde: een budget van 90 minuten per taak binnen een sandbox die is gebouwd op basis van de OSS-Fuzz-image van het project maakt deel uit van de definitie van succes, niet een detail, omdat een groot deel van echt kwetsbaarheidswerk precies door dat soort beperking wordt begrensd en agents die afhankelijk zijn van onbeperkte verkenning hier zullen falen terwijl ze elders slagen.

Elke vergelijking die de taakselectieregel negeert, vergelijkt twee verschillende tests die toevallig dezelfde naam delen.

Twee implementaties, en waarom ze niet overeen hoeven te komen

Hier ontstaat de meeste verwarring. CyberGym-E2E bestaat als een RDI-benchmark en als een implementatie die door een externe evaluator wordt uitgevoerd, en van die twee is niet gegarandeerd dat ze voor hetzelfde model hetzelfde getal opleveren. De eigen documentatie van de evaluator zegt dit ronduit: de implementatie ervan gebruikt een gefilterde set van 131 taken, één per project, gekozen op basis van moeilijkheid, en voert elke taak uit in een geïsoleerde sandbox die is gebouwd op basis van de OSS-Fuzz-image van het project, met behulp van zijn eigen agent-harness en een budget van 90 minuten per taak.

Die zin bevat de twee variabelen die de score bepalen. De harness is de lus waarbinnen de agent werkt — hoe hij de uitvoer van tools waarneemt, hoeveel stappen hij kan nemen, hoe hij herstelt van een mislukte poging. Een sterke harness met een zwakker model kan het omgekeerde verslaan, en de harness maakt geen deel uit van de gewichten van het model. Het budget werkt op beide in. Een CyberGym-cijfer wordt dus correct geschreven als "dit model, in deze harness, in deze implementatie", en een cijfer dat zonder de implementatie wordt geciteerd, is een getal zonder noemer.

Er is een tweedegraads effect dat het vermelden waard is: omdat de harness echt werk verricht, kan een verbetering van de CyberGym-score tussen twee modelversies gedeeltelijk een verbetering van de harness zijn, en een leverancier die de resultaten van zijn eigen harness rapporteert, rapporteert systeemcapaciteit in plaats van modelcapaciteit. Beide zijn legitiem; ze door elkaar halen is dat niet.

De trackertabel eerlijk lezen

De tabel die de meeste mensen tegenkomen, is een secundaire compilatie, en hij vermeldt zijn eigen herkomst — dat is het nuttige deel, als je het label leest. Van de 29 rijen komen er 7 van de eigenaar van de benchmark of uit een onafhankelijke run, zijn er 21 zelfrapportages van providers en is er één een secundair rapport. De compilatie zegt ronduit dat ze de tabel ter referentie toont en er niet op rangschikt, en adviseert om hem zorgvuldig te lezen omdat de meeste rijen zelfrapportages zijn. De eigen verzadigingsnotitie is de nuttigste regel op de pagina: de top drie liggen over ongeveer 70 punten verspreid, terwijl de top tien binnen ongeveer 10 punten liggen, dus de tabel onderscheidt modellen nog steeds — maar niet bovenaan het bereik, waar de ordening dun is.

Een zelfrapportage van een leverancier is toonbaar bewijs. Het is geen onafhankelijke meting, en dat verschil is in deze benchmark belangrijker dan in de meeste, omdat de harness-variabele een leverancier behoorlijk wat ruimte geeft om het gerapporteerde getal af te stellen. Wanneer een zelfrapportage en een onafhankelijke uitvoering van elkaar afwijken, wint de onafhankelijke uitvoering. Wanneer alleen een zelfrapportage bestaat, is de eerlijke lezing "onverifieerd, plausibel, geen vergelijkbare baseline".

Dezelfde behoedzaamheid geldt omgekeerd voor de valkuil die deze benchmark voor lezers opzet: een model zonder CyberGym-rij heeft geen nul gescoord. Het is niet gemeten in die testomgeving, en dat is een andere uitspraak. Afwezigheid als falen behandelen is hoe een tabel ophoudt een meting te zijn en een ranglijst wordt.

Wat een hoge score wel en niet betekent voor een verdediger

De vraag die een securityteam eigenlijk heeft, is niet "welk model staat bovenaan de ranglijst", maar "wat doet een agent die hier goed op scoort met mijn risico". De benchmark beantwoordt een engere vraag dan de vraag die wordt gesteld, en die kloof is het benoemen waard.

Het betekent wel dat de agent binnen 90 minuten en binnen een bekende build een geheugenveiligheidsbug in echte open-sourcecode kan lokaliseren, een werkende crash-invoer kan produceren en een wijziging kan schrijven die de crash stopt zonder tests te breken. Dat is een echte capaciteit, het is direct relevant voor triage- en patchwerk, en het is het soort taak waarbij een competente agent de wachtrij van een analist wezenlijk inkort.

Het betekent niet dat de agent je codebase, je dreigingsmodel of je deployment begrijpt. De taken zijn afkomstig van openbare OSS-Fuzz-doelen met een bekende ground-truth-kwetsbaarheid en een testsuite die de agent vertelt of hij klaar is. Productiecode heeft zo'n orakel niet. Het betekent ook niet dat de agent de bug zal vinden in plaats van een bug: fase 4 bestaat omdat die van elkaar afwijken, en fase 4 telt niet mee.

En dat vertaalt zich niet naar de offensieve kant, waar dezelfde capaciteit anders wordt geïnterpreteerd. Een agent die een geheugenveiligheidsfout kan lokaliseren en reproduceren, kan dat ook doen in code die hij niet mocht testen. Daarom is capaciteit van deze orde precies wat toegangscontrole op modelniveau rechtvaardigt in plaats van een disclaimer in een systeemprompt.

Wat je moet vragen voordat je een CyberGym-getal vertrouwt

Vijf vragen, te beantwoorden vanuit een goed geschreven rapport en meestal niet te beantwoorden vanuit een lanceerbericht.

• Welke implementatie? De benchmark van RDI, of een gefilterde variant van een externe evaluator. Als het rapport dat niet vermeldt, is het getal met niets vergelijkbaar.

• Wiens run? Onafhankelijke evaluatie of zelfrapportage door de aanbieder. De compilatietabel labelt dit per rij; de meeste marketing doet dat niet.

• Welk testharnas, en welk budget? Als het testharnas van de leverancier zelf is en niet wordt beschreven, behandel het resultaat dan als een claim op systeemniveau over een specifieke productconfiguratie.

• Werd fase 4 geraadpleegd? Een gerapporteerd percentage met de diagnostiek ernaast laat zien of de patches de bug hebben opgelost of alleen de crash hebben gesmoord.

• Welke takenverzameling? 131 taken, één per project, gekozen op basis van moeilijkheid, is de gangbare set; een ander filter is een andere test.

Cybergym is een goed opgezette benchmark voor een moeilijke, echte taak, en de opzet ervan is interessanter dan het leaderboard. De fasen vertellen je wat een agent moest doen; de filtering vertelt je waar de score een score van is; de harness vertelt je wie de eer toekomt. Een getal dat met die drie erbij wordt aangeleverd, is echt nuttig. Een getal dat alleen wordt aangeleverd, is een persbericht met een procentteken.