L’ANALISI
CWE-bench v2: 100 task, accesso e limiti dei test
CWE-bench v2 pubblica 100 task su 91 classi di debolezza. L’accesso ai file richiede condizioni accettate: ecco come leggere test e risultati.
In breve: CWE-bench v2 è un benchmark difensivo con 100 task che coprono 91 classi CWE. Ogni task richiede una correzione che chiuda la debolezza senza compromettere le funzioni legittime. Il set è pubblico ma gated: vedere la scheda non equivale ad avere accesso ai file. Non abbiamo eseguito il benchmark. CWE-bench v2: annuncio degli autori e istruzioni Harbor.
Verifica documentale del 3 novembre 2026: lettura dell’annuncio degli autori su Hugging Face e della scheda pubblica del dataset, più richieste dirette ai file README e registry. Non sono state accettate condizioni per conto del lettore, scaricati task riservati, avviati container o invocati modelli per la valutazione.
Che cosa cambia rispetto a una classifica di modelli?
La novità utile è il set pubblico con task e verificatori, non soltanto un punteggio da confrontare. Gli autori descrivono un checkout di un repository reale e una richiesta breve: l’agente cerca e corregge una debolezza. Il successo richiede sia la chiusura del problema sia la conservazione del comportamento normale. Questo distingue una patch plausibile da una patch che supera i controlli previsti dal task; non dimostra che il repository sia privo di altre vulnerabilità. CWE-bench v2: annuncio degli autori e istruzioni Harbor.
Il dataset è davvero scaricabile senza passaggi aggiuntivi?
No. La scheda è consultabile pubblicamente ma specifica che l’accesso a file e contenuti richiede l’accettazione delle condizioni e la condivisione delle informazioni Hugging Face indicate. Nelle nostre richieste non autenticate README e registry hanno risposto 401: è coerente con quel confine di accesso, non la prova che il dataset manchi. Chi vuole eseguirlo deve prima leggere e accettare personalmente le condizioni, poi configurare l’autenticazione secondo le istruzioni ufficiali. Non pubblichiamo né chiediamo token. CWE-bench: scheda pubblica e condizioni di accesso.
Qual è il ruolo di Harbor e dei verificatori?
Il blog descrive ciascun task come un ambiente Harbor con container Docker, istruzione e verificatore deterministico; il dataset include un registry. Il comando proposto dagli autori usa quattro tentativi per task e un host API del modello esplicitamente consentito. Prima di eseguirlo va controllato ciò che il container può raggiungere e quali dati vengono inviati al provider. Il numero di tentativi moltiplica le esecuzioni: il fatto che il materiale di valutazione sia pubblico non rende gratuite inferenza e risorse di calcolo. CWE-bench v2: annuncio degli autori e istruzioni Harbor.
Come leggere pass@1, pass@4 e ricompensa media?
L’annuncio presenta una classifica con pass@1 e pass@4, mentre descrive il comando con quattro tentativi come una media delle ricompense su 400 prove. Sono etichette da controllare nell’output, non valori da trattare come intercambiabili. In un confronto vanno annotati modello, agente, numero di tentativi, versione del set e regola di aggregazione. I punteggi e i costi pubblicati restano risultati degli autori: non li abbiamo riprodotti e non li usiamo come preventivo per un’esecuzione diversa. CWE-bench v2: annuncio degli autori e istruzioni Harbor.
Che cosa controllare prima di una prova interna?
Protocollo proposto, non eseguito: usare un ambiente separato e dati non sensibili, fissare versioni e configurazione, limitare rete e spesa del provider e conservare i log di agente e verificatore. Esaminare anche i casi falliti e il comportamento legittimo, non soltanto il riepilogo della classifica. Prima di una prova completa conviene validare il percorso su un task consentito, con un tetto di spesa esplicito. Un risultato favorevole sul set non sostituisce la revisione del codice distribuito. CWE-bench: scheda pubblica e condizioni di accesso.
Condizioni e limitazioni
Annuncio e scheda pubblica verificati, benchmark non eseguito qui. I file README e registry richiesti senza autenticazione hanno restituito HTTP 401. I risultati degli autori non certificano la sicurezza di un prodotto né misurano i costi del nostro ambiente.
Checklist pratica
- Leggere e accettare personalmente le condizioni di accesso prima del download.
- Fissare versione del dataset, agente, modello e numero di tentativi.
- Preparare un ambiente isolato senza dati personali o segreti nei repository.
- Autorizzare soltanto gli host di rete necessari e definire un limite di spesa.
- Conservare esiti del verificatore e controlli sul comportamento legittimo.
- Separare pass@1, pass@4, ricompensa media e costo effettivamente osservato.