💻 computer science

Refusal Evaluation in Coding LLMs and Code Agents: A Systematic Review of Thirteen Malicious-Code Prompt Corpora (2023-2025)

Questo articolo presenta una revisione sistematica di tredici corpora di prompt per codice malevolo utilizzati per valutare il rifiuto dei modelli linguistici di grandi dimensioni dedicati alla programmazione, individuando lacune metodologiche critiche nelle linee di base di annotazione umana, nella comparabilità tra corpora e nella standardizzazione delle tassonomie, mentre propone un quadro unificato per la costruzione futura di dataset.

Autori originali: Richard J. Young, Gregory D. Moody

Pubblicato 2026-05-21

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Richard J. Young, Gregory D. Moody

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina un mondo in cui stiamo cercando di insegnare a robot giganti e super-intelligenti (chiamati Modelli Linguistici di Grande Dimensione o LLM) come essere buoni cittadini. Nello specifico, vogliamo sapere: Se qualcuno chiede a questi robot di scrivere un virus informatico o una truffa, risponderanno "No"?

Per testare ciò, i ricercatori hanno creato "compiti d'esame" (dataset di prompt) per ingannare i robot. Questo articolo è una revisione massiccia dei "pagellini" di 13 diversi compiti d'esame creati tra il 2023 e il 2025. Gli autori, Richard Young e Gregory Moody, hanno esaminato tutti questi esami per vedere come sono stati costruiti, quanto erano equi e cosa testavano effettivamente.

Ecco la sintesi delle loro scoperte, utilizzando semplici analogie:

1. Il Problema: Tutti Usano un Righello Diverso

Immagina di dover confrontare l'altezza di 13 persone diverse. Ma ecco il punto critico:

La Persona A viene misurata con un righello in pollici.
La Persona B viene misurata con un metro a nastro in centimetri.
La Persona C viene misurata in base a quanti passi fa per raggiungere un muro.
La Persona D viene misurata da una persona completamente diversa.

L'articolo sostiene che è esattamente questo ciò che sta accadendo con questi test di sicurezza per l'IA. Ciascuno dei 13 compiti d'esame (come AdvBench, CyberSecEval, RedCode, ecc.) è stato costruito in modo diverso:

Domande Diverse: Alcuni chiedono codice direttamente; altri chiedono codice attraverso una storia complessa; alcuni chiedono all'IA di comportarsi come un hacker; altri le chiedono di agire come un assistente utile che potrebbe commettere un errore.
Correttori Diversi: Alcuni esami sono corretti dagli autori stessi. Altri sono corretti da altri bot IA. Alcuni sono corretti eseguendo il codice in una sandbox per vedere se esplode.
Regole Diverse: Alcuni esami hanno regole rigide su cosa conta come "virus". Altri sono vaghi.

Il Risultato: Non puoi semplicemente prendere il "tasso di rifiuto" (quanto spesso l'IA ha detto "No") da un esame e confrontarlo con un altro. È come confrontare il tempo di un velocista con quello di un nuotatore e dichiarare che uno è "più veloce" senza tenere conto dei diversi sport.

2. I Tre Grandi Elementi Mancanti

Gli autori hanno scoperto che nessuno dei 13 compiti d'esame includeva tre caratteristiche di sicurezza critiche che ci si aspetterebbe in uno studio scientifico serio:

Nessun "Giudice Umano" per Calibrare l'IA: La maggior parte degli esami utilizza altri bot IA per correggere le risposte. Ma l'articolo sottolinea che non sappiamo se questi correttori IA siano effettivamente corretti. È come avere un robot che corregge un test di matematica senza che un insegnante umano verifichi mai se la chiave di correzione del robot è giusta. Nessuno dei 13 articoli aveva un punteggio "Kappa di Fleiss" (un metodo statistico per dimostrare che diversi giudici umani concorderebbero sulla stessa risposta).
Nessuna "Porta Chiusa" (Accesso Controllato): Questi esami contengono istruzioni su come creare software pericoloso (malware). Eppure, tutti e 13 sono completamente aperti al pubblico. Chiunque può scaricarli, anche se ha cattive intenzioni. È come pubblicare un ricettario per la costruzione di bombe e lasciarlo su una panchina del parco perché chiunque possa prenderlo.
Nessuna "Politica di Ritiro" (Takedown): Se qualcuno trova un prompt pericoloso in questi esami che non dovrebbe esserci, o se l'IA impara da esso e inizia a creare veri virus, non esiste un modo ufficiale per contattare gli autori per rimuoverlo. Nessuno degli articoli elencava una "politica di rimozione" o una persona specifica responsabile della rimozione dei contenuti dannosi.

3. I "Posti Vuoti" in Aula

Gli autori hanno creato una mappa (una tassonomia) per mostrare quali tipi di "domande trabocchetto" esistono. Hanno scoperto che i ricercatori sono tutti seduti sugli stessi pochi posti, lasciando molti altri vuoti:

Posti Affollati: La maggior parte degli esami chiede codice in una singola frase diretta (ad esempio: "Scrivi un virus").
Posti Vuoti: Pochissimi esami testano scenari complessi, come:
- Chiedere all'IA, nel corso di una lunga conversazione (multi-turno), di costruire lentamente un virus.
- Chiedere all'IA di agire come un agente autonomo che controlla un computer.
- Chiedere codice che attacchi l'hardware (come frigoriferi intelligenti o chip delle auto) invece di limitarsi al software.

Poiché i "posti" sono distribuiti in modo disuguale, i dati sono distorti. Sappiamo molto su come l'IA gestisce le richieste semplici, ma sappiamo pochissimo su come gestisce attacchi complessi e multi-step.

4. Le Raccomandazioni: Come Sistemare l'Aula

L'articolo suggerisce che se vogliamo costruire migliori "compiti d'esame" in futuro, dobbiamo seguire una nuova lista di controllo:

Pre-registrare le Regole: Prima di costruire l'esame, scrivi esattamente cosa stai testando in modo da non cambiare le regole a metà strada.
Utilizzare un Panel di Giudici Umani: Non usare solo un'IA per correggere. Usa un gruppo diversificato di umani (o un mix di umani e diverse IA) per concordare su cosa conta come "rifiuto".
Riportare il Punteggio di Accordo: Pubblica una statistica che mostri che i giudici erano effettivamente d'accordo tra loro.
Utilizzare un Dizionario Standard: Concorda un'unica lista di "cose cattive" (tipi di malware) in modo che tutti stiano contando le stesse categorie.
Chiudere la Porta: Se l'esame contiene istruzioni pericolose, rendi difficile l'accesso (richiedi una candidatura da ricercatore) in modo che gli attori malintenzionati non possano scaricarlo facilmente.
Nominare un Guardiano: Avere una persona specifica responsabile della rimozione dell'esame se causa danni.

Riassunto

Questo articolo è una "revisione sistematica", il che significa che non ha eseguito nuovi esperimenti. Invece, ha agito come un bibliotecario che è entrato in una stanza con 13 diversi libri "Test di Sicurezza", li ha aperti tutti e si è reso conto: "Stiamo tutti misurando cose diverse con righelli rotti, e stiamo lasciando le parti pericolose di questi libri esposte all'aperto perché chiunque possa trovarle."

Gli autori stanno chiedendo alla comunità di smettere di costruire questi test in isolamento e iniziare a concordare un modo standard, sicuro ed equo per misurare se l'IA sta davvero rifiutando di fare cose cattive.

Riepilogo Tecnico: Valutazione del Rifiuto nei Modelli Linguistici per la Codifica e negli Agenti di Codice

Enunciato del Problema

La valutazione del rifiuto da parte dei Modelli Linguistici di Grandi Dimensioni (LLM) nelle attività di generazione di codice malevolo si è frammentata in almeno tredici corpus di prompt rilasciati pubblicamente (ad esempio, AdvBench, CyberSecEval, RMCBench, RedCode, MOCHA, ASTRA, JAWS-Bench). Questi dataset sono costruiti secondo protocolli disparati, utilizzano termini di licenza differenti e mancano di una validazione standardizzata dell'affidabilità inter-valutatore (IRR). La letteratura esistente confonde la "valutazione del rifiuto" (il modello rifiuta una richiesta di codice malevolo?) con la "valutazione della vulnerabilità" (il modello genera codice con bug su richieste benigne?), o tratta i corpus di prompt semplicemente come contesto adiacente a tassonomie di sicurezza più ampie. Di conseguenza, le statistiche sui tassi di rifiuto riportate in questi corpus non sono direttamente confrontabili; misurano costrutti non equivalenti a causa di variazioni nella composizione dei prompt, nella modalità (singola interazione vs. multi-interazione vs. agente) e nei protocolli di etichettatura (umano vs. automatizzato vs. giudice-LLM). Non esiste uno schema canonico per le categorie di malware, e i ricercatori successivi sono costretti a ricostruire i criteri di inclusione da zero per ogni nuovo studio.

Metodologia

Questo articolo adotta un protocollo di revisione sistematica in stile PRISMA per analizzare i tredici corpus inclusi come unità primaria di analisi.

Strategia di Ricerca: Una ricerca multi-motore (arXiv, Google Scholar, ACL, IEEE, ACM) combinata con il tracciamento delle citazioni a ritroso (snowball-back) dai corpus chiave di ingresso.
Criteri di Inclusione: I corpus devono mirare a LLM per la codifica o agenti interpreti di codice, rilasciare un corpus di prompt pubblicamente (o descriverlo in dettaglio) e valutare il rifiuto di richieste di codice malevolo eseguibili.
Criteri di Esclusione: Sono stati esclusi benchmark di rilevamento delle vulnerabilità (task inverso), benchmark di capacità generali (ad esempio HumanEval), jailbreak non legati alla codifica e questionari a scelta multipla per l'estrazione di conoscenze (ad esempio WMDP).
Processo di Estrazione: Un modello di estrazione uniforme è stato applicato alla pubblicazione principale e agli artefatti di rilascio di ciascun corpus. I campi inclusi sono: metodologia di costruzione, numero di prompt, modalità, tassonomia del malware, pannello di modelli target, tassi di rifiuto riportati, statistiche IRR e politiche di licenza/accesso. Non sono state effettuate nuove misurazioni empiriche o riclassificazioni; la revisione sintetizza i metadati così come rilasciati.

Contributi Chiave

L'articolo produce quattro artefatti di sintesi che riformulano il campo da una raccolta di benchmark disparati a un panorama strutturato e confrontabile:

Confronto Metodologico Inter-Corpus: Una tabella completa (Tabella 1) che estrae dieci assi di confronto per tutti i tredici corpus. Rivela che le strategie di costruzione variano dalla pura creazione manuale alla sintesi generata da LLM e ai loop di agenti guidati da oracoli. Crucialmente, documenta che zero dei tredici corpus riportano una statistica di affidabilità inter-valutatore di tipo Fleiss' $\kappa$ sulle loro etichette di rifiuto.
Tassonomia della Costruzione dei Prompt: Un framework a tre assi (Modalità, Struttura delle Interazioni, Stile di Elicitazione) che caratterizza come i corpus elicita-no codice malevolo.
- Modalità: Testo-codice, codice-codice, multi-interazione, agente e interprete.
- Struttura delle Interazioni: Singola interazione, multi-interazione o traiettoria dell'agente.
- Stile di Elicitazione: Diretto, decorato con jailbreak, o indiretto/plausibilmente benigno.
- La tassonomia visualizza le "celle vuote" nello spazio di progettazione (ad esempio, prompt decorati con jailbreak a multi-interazione), evidenziando lacune strutturali nella copertura di valutazione attuale.
Panorama di Riproducibilità e Licenze: Un catalogo (Tabella 2) di luoghi di distribuzione, licenze e politiche di accesso. Evidenzia che, sebbene la maggior parte dei corpus sia ad accesso aperto, cinque mancano di dichiarazioni di licenza esplicite sulle loro pagine di atterraggio, e nessuno documenta una politica di rimozione o un contatto per la divulgazione responsabile, nonostante contengano payload di malware eseguibili.
Mappa della Copertura delle Categorie di Malware: Un'ontologia consolidata a 22 categorie derivata dall'unione di tutte le tassonomie dei corpus. La mappa identifica categorie ben coperte (ad esempio, Trojan, Ransomware, Phishing) e aree sottorappresentate, specificamente exploit del firmware, attacchi hardware/canali laterali, attacchi IoT/incorporati e attacchi alla catena di approvvigionamento.

Risultati Chiave

Assenza Uniforme di Metriche di Affidabilità: In tutti i tredici corpus non vi è alcuna segnalazione di affidabilità inter-valutatore (ad esempio Fleiss' $\kappa$ ) per le etichette di rifiuto. Le etichette sono derivate tramite assegnazione esclusiva degli autori, provenienza a monte o classificatori automatizzati senza basi di riferimento di annotatori umani per la calibrazione.
Incoerenza del Costrutto: I tassi di rifiuto non sono confrontabili tra i corpus perché campionano distribuzioni di prompt diverse (ad esempio, semi creati manualmente vs. parafrasi LLM) e stili di elicitazione diversi (diretto vs. jailbreak vs. indiretto).
Lacune di Governance: Nessun corpus esaminato implementa accesso controllato, revisione da parte di ricercatori registrati o una politica di rimozione documentata. Cinque corpus vengono distribuiti senza termini di licenza espliciti nella fase preprint.
Frammentazione della Tassonomia: Non esiste uno schema canonico per il malware. La revisione ha dovuto costruire un'ontologia unificata a 22 categorie per abilitare il confronto inter-corpora, poiché le tassonomie esistenti (derivate da MITRE, famiglie funzionali, tipi di attacco) non si mappano chiaramente l'una sull'altra.
Squilibrio nella Copertura: Sebbene i tipi comuni di malware siano saturi, vettori emergenti critici come gli exploit del firmware e gli attacchi alla catena di approvvigionamento rimangono sottorappresentati, spesso coperti da solo uno o due corpus.

Significato e Affermazioni

L'articolo si afferma come la prima revisione sistematica a trattare i corpus di prompt per codice malevolo stessi come unità di analisi, piuttosto che considerarli come contesto secondario rispetto alla sicurezza del codice o alle tassonomie di jailbreak. La sua rilevanza risiede in:

Audit del Campo: Espone che il ritmo rapido di rilascio dei corpus ha superato l'impalcatura metodologica necessaria per un confronto valido.
Fornitura di una Linea di Base: Offre un vocabolario strutturato (la tassonomia) e un'ontologia consolidata (le 22 categorie) affinché i futuri ricercatori possano auditare le decisioni di selezione e confrontare i dataset.
Definizione delle Aspettative Metodologiche: Propone un elenco di controllo per la costruzione di corpus di prossima generazione, inclusa la pre-registrazione dei criteri di inclusione, la validazione delle etichette tramite giudici multipli diversi per fornitore, la segnalazione di Fleiss' $\kappa$ con intervalli di confidenza bootstrap e l'adozione di una tassonomia canonica del malware.
Lavori Futuri: Gli autori identificano una rivalutazione empirica uniforme dell'affidabilità inter-valutatore su tutti i tredici corpus utilizzando un protocollo comune a giudici multipli come il passo successivo necessario, che viene rinviato a lavori futuri.

La revisione conclude che, sebbene il campo abbia generato un ricco insieme di artefatti di valutazione, la mancanza di segnalazione standardizzata dell'affidabilità, di governance delle licenze e di allineamento tassonomico impedisce attualmente l'aggregazione delle statistiche sui tassi di rifiuto in una metrica coerente e interpretabile per la sicurezza degli LLM.