CyberGym Benchmark spiegato: cosa misura davvero il punteggio E2E

Il punteggio CyberGym che circola più ampiamente — il numero nel post di lancio, quello che viene confrontato tra i modelli — è un tasso di successo sui task calcolato su 131 task filtrati, dove successo significa che un agente ha prodotto un input proof-of-concept che manda in crash una build C/C++ non patchata, ha scritto una patch che ferma quel crash e non ha rotto i test scritti dagli sviluppatori del progetto. Nella compilazione di BenchLM, MiMo-V2.6-Flash è in testa al 95,1% e MiMo-V2.6-Pro al 94,0%, con DeepSeek-V4.1-Flash qualche punto dietro, nella fascia alta degli ottanta. Quasi nessuno che citi quella tabella menziona tre cose che decidono se i numeri sono comparabili: il benchmark esiste in più di un'implementazione, la maggior parte delle righe sono autodichiarazioni dei fornitori anziché esecuzioni indipendenti, e la singola fase più interessante viene registrata ma non conteggiata. È lo stesso standard di attribuzione che l'archivio degli incidenti AI applica alle proprie voci — un'affermazione senza fonte non è un risultato — e il corpus CyberGym lo disattende più spesso di quanto la sua reputazione suggerisca.

Questa è una guida a ciò che il benchmark chiede a un agente di fare, a come è stato costruito l'insieme di attività, a dove le implementazioni divergono e a cosa un difensore dovrebbe e non dovrebbe concludere da un punteggio elevato.

Il compito: trovare, riprodurre, applicare una patch — senza rompere nulla.

CyberGym proviene dal Berkeley Center for Responsible, Decentralized Intelligence, e la sua premessa è volutamente ristretta. Ogni attività mira a una vulnerabilità di sicurezza della memoria in un progetto open-source C/C++ ampiamente utilizzato. L'agente deve individuare il bug, scrivere un input proof-of-concept che provochi un crash del sanitizer e poi correggere il codice affinché il crash non si riproduca più — mentre i test del progetto continuano a passare. Questa sequenza è il punto centrale. Un benchmark che chiedesse solo "trovare il bug" premiererebbe il riconoscimento di pattern; richiedere un input di crash funzionante e una patch che non introduca regressioni costringe l'agente a chiudere il ciclo dal sospetto al difetto dimostrato fino alla correzione.

RDI ospita il benchmark all'interno di un osservatorio più ampio che monitora le capacità cyber dell'IA nelle fasi di attacco e difesa, e l'inquadramento merita attenzione: CyberGym è uno strumento su una panchina, insieme a ExploitGym e alla variante end-to-end. Leggerlo come una classifica a sé stante perde questo contesto, ed è una delle ragioni per cui i numeri viaggiano male.

Quattro fasi, tre delle quali danno un punteggio

La regola di punteggio è la parte meno riportata del benchmark, perché è qui che un punteggio che sembra plausibile può divergere da ciò che è realmente accaduto.

Fase 1 è la riproduzione: l'input proof-of-concept dell'agente fa crashare la build non patchata. Fase 2 è la patch: la modifica inviata impedisce quel crash specifico. Fase 3 è la regressione: i test di funzionalità scritti dagli sviluppatori passano ancora? Queste tre fasi producono il punteggio.

Fase 4 chiede se la patch corregge la vulnerabilità effettiva di riferimento, ed è registrata come diagnostica anziché conteggiata. Questa asimmetria merita un momento di riflessione, perché è la differenza tra "l'agente riesce a far sparire un crash" e "l'agente riesce a correggere il bug". Entrambe sono affermazioni utili; non sono la stessa affermazione. Un agente che sopprime un crash intercettando il segnale, ampliando un controllo dei limiti oltre l'overflow o disabilitando del tutto il percorso di codice otterrà un punteggio nelle fasi da 1 a 3 e fallirà la fase 4. Se un resoconto riporta un singolo numero senza dire se la fase 4 è stata consultata, non è possibile capire quale delle due cose sia stata misurata — e la diagnostica esiste proprio perché tu possa chiederlo.

Come sono stati scelti i 131 task — e quale impatto ha sul punteggio

Il dataset di origine è più ampio dell'insieme valutato, e il filtraggio è la singola leva più importante sulla comparabilità. Il dataset di RDI contiene 920 vulnerabilità in 139 progetti open source, tratte da OSS-Fuzz di Google. La variante end-to-end usata dai tracker di terze parti lo riduce a 131 attività, con un'attività per progetto, selezionate in base alla difficoltà, escludendo le attività con fughe di informazioni dall'oracle o vincoli di compatibilità con la sandbox.

Ne derivano direttamente tre conseguenze. In primo luogo, un compito per progetto significa che il punteggio è dominato dall'ampiezza anziché dalla profondità: un agente che è nella media su molti progetti supererà uno che è eccellente su tre, il che è una scelta progettuale difendibile e una misurazione diversa da "quante vulnerabilità riesce a correggere questo agente". In secondo luogo, escludere le perdite dell'oracle rimuove i compiti in cui la risposta è individuabile dall'ambiente anziché dedotta, quindi l'insieme rimanente è più difficile in un modo specifico: rimuove le scorciatoie anziché rimuovere i compiti facili. In terzo luogo, un budget di 90 minuti per compito all'interno di una sandbox creata dall'immagine OSS-Fuzz del progetto fa parte della definizione di successo, non è un dettaglio, perché una larga parte del lavoro reale sulle vulnerabilità è limitata proprio da quel tipo di vincolo e gli agenti che dipendono da un'esplorazione illimitata falliranno qui pur riuscendo altrove.

Qualsiasi confronto che ignora la regola di selezione del compito sta confrontando due test diversi che per caso condividono un nome.

Due implementazioni, e perché non devono necessariamente concordare

È qui che risiede la maggior parte della confusione. CyberGym-E2E esiste come benchmark RDI e come implementazione eseguita da un valutatore di terze parti, e non è garantito che i due producano lo stesso numero per lo stesso modello. La documentazione del valutatore stesso lo dice chiaramente: la sua implementazione utilizza un set filtrato di 131 task, uno per progetto, scelti in base alla difficoltà, ed esegue ogni task in una sandbox isolata costruita dall'immagine OSS-Fuzz del progetto, usando il proprio harness di agenti con un budget di 90 minuti per task.

Quella frase contiene le due variabili che decidono il punteggio. L'harness è il ciclo in cui l'agente opera: come osserva l'output degli strumenti, quanti passi può compiere, come si riprende da un tentativo fallito. Un harness più robusto con un modello più debole può battere il caso opposto, e l'harness non fa parte dei pesi del modello. Il budget interagisce con entrambi. Quindi un dato di CyberGym va scritto correttamente come "questo modello, in questo harness, in questa implementazione", e un dato citato senza l'implementazione è un numero senza denominatore.

C'è un effetto di secondo ordine che vale la pena menzionare: poiché l'harness svolge un lavoro reale, un miglioramento del punteggio CyberGym tra due versioni di modello può essere in parte un miglioramento dell'harness, e un fornitore che riporta i risultati del proprio harness sta riportando la capacità del sistema anziché la capacità del modello. Entrambe le cose sono legittime; confonderle non lo è.

Leggere con onestà la tabella del tracker

La tabella che la maggior parte delle persone incontra è una compilazione secondaria, e riporta la propria provenienza — che è la parte utile, se si legge l'etichetta. Delle 29 righe, 7 provengono dal proprietario del benchmark o da un'esecuzione indipendente, 21 sono autodichiarazioni dei fornitori e una è un rapporto secondario. La compilazione dichiara apertamente che mostra la tabella a scopo di riferimento e non vi si basa per stabilire una classifica, e consiglia di leggerla con cautela perché la maggior parte delle righe sono autodichiarazioni. La sua stessa nota sulla saturazione è la riga più utile della pagina: i primi tre sono distribuiti su circa 70 punti mentre i primi dieci stanno entro circa 10, quindi la tabella separa ancora i modelli — ma non nella parte alta dell'intervallo, dove l'ordinamento è debole.

Un'autodichiarazione del fornitore è un'evidenza mostrabile. Non è una misurazione indipendente, e la differenza conta in questo benchmark più che nella maggior parte dei casi, perché la variabile dell'harness lascia a un fornitore un margine considerevole per tarare il numero che riporta. Quando un'autodichiarazione e un'esecuzione indipendente sono in disaccordo, prevale l'esecuzione indipendente. Quando esiste solo un'autodichiarazione, la lettura onesta è "non verificata, plausibile, nessuna baseline comparabile".

La stessa cautela vale, al contrario, per la trappola che questo benchmark tende ai lettori: un modello senza una riga CyberGym non ha ottenuto zero. Non è stato misurato in quel harness, il che è un'affermazione diversa. Trattare l'assenza come un fallimento è il modo in cui una tabella smette di essere una misurazione e diventa una classifica.

Che cosa significa e non significa un punteggio alto per un difensore

La domanda che un team di sicurezza si pone davvero non è "quale modello è in cima alla classifica", ma "che cosa fa al mio rischio un agente che ottiene un buon punteggio in questa prova". Il benchmark risponde a una domanda più ristretta di quella che viene posta, e vale la pena dare un nome a questo divario.

Significa davvero che l'agente può, entro 90 minuti e all'interno di una build nota, individuare un bug di sicurezza della memoria in codice open source reale, produrre un input di crash funzionante e scrivere una modifica che arresta il crash senza rompere i test. Si tratta di una capacità concreta, direttamente rilevante per il triage e il lavoro di patch, ed è il tipo di attività in cui un agente competente riduce in modo significativo la coda di un analista.

Non significa che l'agente comprenda la tua base di codice, il tuo modello di minaccia o il tuo deployment. Le attività sono tratte da target OSS-Fuzz pubblici con una vulnerabilità ground-truth nota e una suite di test che indica all'agente se ha finito. Il codice di produzione non ha un tale oracolo. Non significa neanche che l'agente troverà il bug invece di un bug: la fase 4 esiste perché questi divergono, e la fase 4 non conta.

E non si trasferisce al lato offensivo, dove la stessa capacità assume un significato diverso. Un agente in grado di individuare e riprodurre una vulnerabilità di sicurezza della memoria può farlo in codice che non gli è stato dato il permesso di testare, ed è per questo che una capacità di questo livello è esattamente ciò che motiva un controllo degli accessi a livello di modello anziché un'avvertenza in un prompt di sistema.

Cosa chiedere prima di fidarsi di un numero di CyberGym

Cinque domande a cui si può rispondere da un rapporto ben scritto e a cui di solito non si può rispondere da un post di lancio.

• Quale implementazione? Il benchmark di RDI, o una variante filtrata di un valutatore di terze parti. Se il report non lo specifica, il numero non è confrontabile con nulla.

• Di chi è l'esecuzione? Valutazione indipendente o autodichiarazione del fornitore. La tabella di sintesi lo indica riga per riga; la maggior parte del materiale di marketing no.

• Quale harness e con quale budget? Se l'harness è quello del fornitore e non è descritto, tratta il risultato come un'affermazione a livello di sistema su una specifica configurazione del prodotto.

• È stata consultata la fase 4? Un tasso riportato con la diagnostica a fianco ti dice se le patch hanno corretto il bug o si sono limitate a silenziare il crash.

• Quale set di attività? Le 131 attività, una per progetto, scelte in base alla difficoltà sono il set comune; un filtro diverso è un test diverso.

Cybergym è un benchmark ben costruito per un compito difficile e reale, e la sua costruzione è più interessante della sua classifica. Le fasi ti dicono cosa doveva fare un agente; il filtraggio ti dice che cosa sta effettivamente misurando il punteggio; l'harness ti dice a chi va attribuito il merito. Un numero che arriva con quei tre elementi allegati è davvero utile. Un numero che arriva da solo è un comunicato stampa con un segno di percentuale.