CyberGym Benchmark förklarat: Vad E2E-poängen faktiskt mäter

CyberGym-poängen som sprids mest — siffran i lanseringsinlägget, den som jämförs mellan modeller — är andelen lyckade uppgifter bland 131 filtrerade uppgifter, där framgång innebär att en agent tog fram en proof-of-concept-inmatning som får ett opatchat C/C++-bygge att krascha, skrev en patch som stoppar kraschen och inte bröt projektets utvecklarskrivna tester. I BenchLM:s sammanställning leder MiMo-V2.6-Flash med 95,1 % och MiMo-V2.6-Pro med 94,0 %, medan DeepSeek-V4.1-Flash ligger några procentenheter efter i det övre 80-procentsspannet. Nästan ingen som citerar den tabellen nämner tre saker som avgör om siffrorna är jämförbara: benchmarken finns i mer än en implementering, de flesta raderna är leverantörernas självrapporter snarare än oberoende körningar, och det enskilt mest intressanta steget registreras men räknas inte. Det är samma attributionsstandard som AI-incidentarkivet tillämpar på sina egna poster — ett påstående utan källa är inte ett resultat — och CyberGym-korpusen klarar inte den oftare än dess rykte antyder.

Detta är en guide till vad benchmarken ber en agent att göra, hur uppgiftsuppsättningen byggdes, var implementationerna skiljer sig åt, och vad en försvarare bör och inte bör dra för slutsatser av en hög poäng.

Uppgiften: hitta, reproducera, patcha – utan att förstöra något

CyberGym kommer från Berkeley Center for Responsible, Decentralized Intelligence, och dess premiss är medvetet snäv. Varje uppgift inriktar sig på en minnessäkerhetssårbarhet i ett flitigt använt C/C++-projekt med öppen källkod. Agenten måste lokalisera buggen, skriva en proof-of-concept-indata som utlöser en sanitizer-krasch och sedan patcha koden så att kraschen inte längre reproduceras — medan projektets egna tester fortsätter att gå igenom. Den sekvensen är hela poängen. Ett benchmark som bara bad om att "hitta buggen" skulle belöna mönsterigenkänning; att kräva en fungerande kraschindata och en patch som inte bryter något tvingar agenten att sluta kretsloppet från misstanke till påvisad defekt till åtgärd.

RDI är värd för benchmarken inom ett bredare observatorium som följer AI-cyberkapacitet över attack- och försvarsfaser, och inramningen är värd att lägga märke till: CyberGym är ett instrument på en bänk, vid sidan av ExploitGym och end-to-end-varianten. Att läsa den som en fristående resultattavla förlorar det sammanhanget, vilket är en anledning till att siffrorna förs över dåligt.

Fyra steg, varav tre ger poäng

Poängsättningsregeln är den mest underrapporterade delen av benchmarken, eftersom det är där en rimligt klingande poäng kan avvika från vad som faktiskt hände.

Steg 1 är reproduktionen: får agentens proof-of-concept-indata den opatchade byggversionen att krascha. Steg 2 är patchen: stoppar den inskickade ändringen just den specifika kraschen. Steg 3 är regression: går utvecklarens funktionalitetstester fortfarande igenom. Dessa tre ger poängen.

Steg 4 frågar om patchen åtgärdar den faktiska ground truth-sårbarheten, och det registreras som en diagnostisk uppgift snarare än räknas. Den asymmetrin förtjänar en stund, eftersom det är skillnaden mellan "agenten kan få en krasch att försvinna" och "agenten kan åtgärda buggen". Båda är användbara påståenden; de är inte samma påstående. En agent som dämpar en krasch genom att fånga signalen, vidga en gränskontroll förbi överflödet eller helt stänga av kodvägen får poäng på steg 1 till 3 och misslyckas på steg 4. Om en rapport redovisar ett enda tal utan att säga om steg 4 beaktades, kan man inte avgöra vilket av de två som mättes – och diagnostiken finns just för att man ska kunna fråga.

Hur de 131 uppgifterna valdes ut – och vad det gör med poängen

Källdatasetet är större än den poängsatta uppsättningen, och filtreringen är den enskilt största hävstången för jämförbarhet. RDI:s dataset innehåller 920 sårbarheter i 139 öppen källkodsprojekt, hämtade från Google's OSS-Fuzz. Den end-to-end-variant som används av tredjepartsspårare begränsar det till 131 uppgifter, med en uppgift per projekt, valda efter svårighetsgrad, och utesluter uppgifter med orakelläckor eller kompatibilitetsbegränsningar för sandlådan.

Tre konsekvenser följer direkt. För det första, en uppgift per projekt innebär att poängen domineras av bredd snarare än djup: en agent som är medelmåttig över många projekt kommer att prestera bättre än en som är utmärkt på tre, vilket är ett försvarbart designval och ett annat mått än "hur många sårbarheter den här agenten kan åtgärda". För det andra, att utesluta orakelläckor tar bort uppgifter där svaret går att upptäcka från miljön i stället för att resoneras fram, så den återstående uppsättningen är svårare på ett specifikt sätt — den tar bort genvägar snarare än att ta bort enkla uppgifter. För det tredje, en budget på 90 minuter per uppgift inuti en sandlåda byggd från projektets OSS-Fuzz-avbildning är en del av definitionen av framgång, inte en detalj, eftersom en stor del av verkligt sårbarhetsarbete begränsas av exakt den typen av restriktion och agenter som är beroende av obegränsad utforskning kommer att misslyckas här medan de lyckas någon annanstans.

Varje jämförelse som bortser från regeln för uppgiftsval jämför två olika test som råkar ha samma namn.

Två implementeringar, och varför de inte behöver stämma överens

Det är här som det mesta av förvirringen ligger. CyberGym-E2E finns som ett RDI-benchmark och som en implementering som körs av en tredjepartsutvärderare, och de två garanteras inte ge samma siffra för samma modell. Utvärderarens egen dokumentation säger det rakt ut: dess implementering använder en filtrerad uppsättning på 131 uppgifter, en per projekt, valda efter svårighetsgrad, och den kör varje uppgift i en isolerad sandlåda som byggts från projektets OSS-Fuzz-avbildning med sin egen agent-harness och en budget på 90 minuter per uppgift.

Den meningen innehåller de två variabler som avgör poängen. Testramverket är loopen som agenten körs i – hur den observerar verktygsutdata, hur många steg den kan ta, hur den återhämtar sig från ett misslyckat försök. Ett starkare testramverk med en svagare modell kan överträffa det omvända, och testramverket ingår inte i modellens vikter. Budgeten samspelar med båda. Så en CyberGym-siffra skrivs korrekt som "den här modellen, i detta testramverk, i den här implementeringen", och en siffra som citeras utan implementeringen är ett tal utan nämnare.

Det finns en andra ordningens effekt som är värd att nämna: eftersom harnessen utför verkligt arbete kan en förbättring av CyberGym-poängen mellan två modellversioner delvis vara en förbättring av harnessen, och en leverantör som rapporterar sina egna harnessresultat rapporterar systemförmåga snarare än modellförmåga. Båda är legitima; att blanda ihop dem är det inte.

Att läsa tracker-tabellen ärligt

Tabellen som de flesta stöter på är en sekundär sammanställning, och den anger sitt eget ursprung – vilket är det användbara, om man läser etiketten. Av de 29 raderna kommer 7 från benchmarkägaren eller en oberoende körning, 21 är leverantörers självrapporteringar och en är en sekundär rapport. Sammanställningen säger uttryckligen att den visar tabellen som referens och inte rangordnar utifrån den, och råder till att läsa den med omsorg eftersom de flesta raderna är självrapporteringar. Dess egen mättnadsnotering är den mest användbara raden på sidan: de tre bästa spänner över cirka 70 poäng medan de tio bästa ligger inom ungefär 10, så tabellen skiljer fortfarande modeller åt – men inte i toppen av intervallet, där ordningen är tunn.

En leverantörs självrapport är visningsbart underlag. Den är inte en oberoende mätning, och skillnaden spelar större roll i detta benchmark än i de flesta, eftersom harness-variabeln ger en leverantör betydande utrymme att justera siffran den rapporterar. När en självrapport och en oberoende körning inte stämmer överens har den oberoende körningen företräde. När endast en självrapport finns är den ärliga tolkningen "overifierad, rimlig, ingen jämförbar baslinje".

Samma försiktighet gäller omvänt för den fälla som detta benchmark ställer upp för läsare: en modell utan en CyberGym-rad har inte fått noll. Den har inte mätts i den harnessen, vilket är ett annat påstående. Att behandla frånvaro som misslyckande är hur en tabell slutar vara en mätning och blir en resultattavla.

Vad ett högt poängantal innebär och inte innebär för en försvarare

Frågan ett säkerhetsteam faktiskt har är inte ”vilken modell toppar tabellen” utan ”vad gör en agent som presterar bra på detta med min risk”. Benchmarken besvarar en snävare fråga än den som ställs, och gapet är värt att sätta namn på.

Det betyder att agenten inom 90 minuter och i en känd build kan lokalisera en minnessäkerhetsbugg i riktig öppen källkod, producera en fungerande kraschindata och skriva en ändring som stoppar kraschen utan att bryta tester. Det är en genuin förmåga, den är direkt relevant för triage- och patcharbete, och det är den typen av uppgift där en kompetent agent meningsfullt komprimerar en analytikers kö.

Det betyder inte att agenten förstår din kodbas, din hotmodell eller din driftsättning. Uppgifterna hämtas från offentliga OSS-Fuzz-mål med en känd ground-truth-sårbarhet och en testsvit som talar om för agenten om den är klar. Produktionskod har inget sådant orakel. Det betyder inte heller att agenten hittar den buggen i stället för en bugg: steg 4 finns eftersom de divergerar, och steg 4 räknas inte.

Och det överförs inte till den offensiva sidan, där samma förmåga framstår annorlunda. En agent som kan lokalisera och reproducera en minnessäkerhetsbrist kan göra det i kod som den inte har fått tillstånd att testa, vilket är anledningen till att förmåga av denna kaliber är precis det som motiverar åtkomstkontroll på modellnivå i stället för en ansvarsfriskrivning i en systemprompt.

Vad man bör fråga innan man litar på en CyberGym-siffra

Fem frågor som går att besvara utifrån en välskriven rapport och vanligtvis inte går att besvara utifrån ett lanseringsinlägg.

• Vilken implementering? RDI:s benchmark, eller en tredjepartsutvärderares filtrerade variant. Om rapporten inte anger det är siffran inte jämförbar med något.

• Vems körning? Oberoende utvärdering eller leverantörens självrapportering. Sammanställningstabellen anger detta per rad; det gör de flesta marknadsföringsmaterial inte.

• Vilken testrigg, och vilken budget? Om testriggen är leverantörens egen och inte beskrivs, behandla resultatet som ett påstående på systemnivå om en specifik produktkonfiguration.

• Tillfrågades steg 4? En rapporterad frekvens tillsammans med diagnostiken visar om patcharna åtgärdade buggen eller bara tystade kraschen.

• Vilken uppgiftsuppsättning? 131 uppgifter, en per projekt, valda efter svårighetsgrad är den vanliga uppsättningen; ett annat filter är ett annat test.

Cybergym är ett välkonstruerat benchmark för en svår, verklig uppgift, och dess konstruktion är mer intressant än dess resultattabell. Etapperna berättar vad en agent var tvungen att göra; filtreringen berättar vad poängen är ett mått på; testramverket berättar vem som förtjänar äran. Ett tal som kommer med dessa tre bifogade är verkligen användbart. Ett tal som kommer ensamt är ett pressmeddelande med ett procenttecken.