TOSSS: a CVE-based Software Security Benchmark for Large Language Models

Il paper introduce TOSSS, un nuovo benchmark basato sul database CVE per valutare la capacità dei Large Language Models di selezionare frammenti di codice sicuri rispetto a quelli vulnerabili, fornendo un punteggio di sicurezza complementare alle valutazioni esistenti.

L'essenziale

Ecco una spiegazione semplice e creativa del paper TOSSS, pensata per chiunque, anche senza competenze tecniche.

🛡️ TOSSS: Il "Test di Sapore" per l'Intelligenza Artificiale

Immagina di avere un cuoco robot (l'Intelligenza Artificiale o LLM) che sta imparando a cucinare per te. Fino a poco tempo fa, per capire se questo cuoco era bravo, gli chiedevamo di creare un piatto da zero. Se il piatto sapeva di bruciato o c'era veleno, dicevamo: "Oh, non è stato bravo".

Il problema è che a volte il robot crea un piatto che sembra buono, ma nasconde un segreto pericoloso (una vulnerabilità di sicurezza), e noi non ce ne accorgiamo subito. Inoltre, ogni volta che esce un nuovo tipo di veleno (una nuova falla di sicurezza), dovremmo ricreare tutto il menu di test, il che è lentissimo e costoso.

TOSSS (Two-Option Secure Snippet Selection) è un nuovo modo di fare il test, molto più intelligente e veloce.

🍎 La Metafora del "Scegli la Mela"

Invece di chiedere al robot: "Cucina una mela per me!", TOSSS gli mette davanti due mele già pronte e gli chiede: "Quale delle due è quella sana?"

1. Opzione A: Una mela perfetta, croccante e sicura.
2. Opzione B: Una mela che sembra uguale, ma ha un verme dentro (la vulnerabilità).

Il compito del robot è semplicemente indicare A o B.

• Se sceglie sempre la mela sana, è un cuoco sicuro (Punteggio 1).
• Se sceglie sempre quella col verme, è pericoloso (Punteggio 0).
• Se sceglie a caso, è come un principiante (Punteggio 0.5).

🕵️‍♂️ Da dove arrivano le mele? (Il Database CVE)

La parte geniale di questo studio è come hanno preparato le mele. Non le hanno inventate a mano (cosa che richiederebbe anni). Hanno usato un "detective automatico" chiamato MegaVul.

Questo detective guarda il registro mondiale degli incidenti (chiamato CVE, dove vengono registrate tutte le falle di sicurezza dei software nel mondo). Ogni volta che un programmatore umano corregge una falla, il detective prende:

1. La versione "vecchia" e rotta del codice (la mela col verme).
2. La versione "nuova" e corretta (la mela sana).

In questo modo, TOSSS ha un magazzino infinito di mele. Appena viene scoperta una nuova falla nel mondo reale, il detective la aggiunge al test. È come se il test si aggiornasse da solo ogni giorno!

🧪 Cosa hanno scoperto?

Gli autori hanno fatto questo test a 14 robot diversi (alcuni famosi come GPT, altri più specializzati) usando codice scritto in due lingue: C/C++ e Java.

Ecco le scoperte principali, spiegate in modo semplice:

1. Non tutti i robot sono uguali: Alcuni robot sono bravissimi (punteggio 0.88), altri sono quasi alla pari con il caso (punteggio 0.48). C'è una grande differenza tra chi è sicuro e chi no.
2. Il trucco della "Frase Magica":
   • Senza indizi: Se chiedi al robot "Scegli il codice migliore", molti scelgono quello sbagliato.
   • Con indizi: Se dici esplicitamente "Scegli il codice più sicuro", quasi tutti migliorano! È come se il robot avesse bisogno che gli ricordassimo di fare attenzione alla sicurezza.
3. I "Cuochi Specializzati" non sono sempre i migliori: Alcuni robot sono stati addestrati specificamente per scrivere codice (sono i "chef stellati"). Sorprendentemente, non sono sempre i migliori nel riconoscere le mele avvelenate. A volte, i robot più generici sono più attenti alla sicurezza.
4. Il paradosso: C'è stato un robot che, quando gli hanno detto "Fai attenzione alla sicurezza", è diventato peggio! È come se, pensando troppo a non sbagliare, si fosse confuso.

🚀 Perché è importante?

Prima, per testare la sicurezza dell'AI, dovevamo aspettare che un esperto umano guardasse il codice o usare strumenti complessi che spesso si bloccavano.

Con TOSSS:

• È facile da usare: Basta scegliere A o B.
• È sempre aggiornato: Non serve ricreare i test ogni volta che esce una nuova falla.
• È chiaro: Il punteggio ti dice esattamente quanto è probabile che il robot scelga la strada sicura.

In sintesi, TOSSS è come un semaforo automatico per l'Intelligenza Artificiale. Invece di aspettare che l'AI crei un disastro, le chiediamo di riconoscere il pericolo. Se sa riconoscere il pericolo, possiamo fidarci di più quando ci chiederà di scrivere codice per noi.

Il team ha reso tutto questo disponibile gratuitamente, così chiunque può usare questo "test delle mele" per vedere se il proprio assistente AI è davvero sicuro. 🍏🔒

Sommario tecnico

Ecco un riassunto tecnico dettagliato del paper "TOSSS: a CVE-based Software Security Benchmark for Large Language Models" in italiano.

Titolo

TOSSS: un Benchmark di Sicurezza Software basato su CVE per i Modelli Linguistici di Grande Dimensione (LLM)

1. Il Problema

Con la rapida integrazione dei Large Language Models (LLM) nei flussi di lavoro di ingegneria del software (es. GitHub Copilot, Codestral), sorge una domanda critica: gli LLM sono competenti nella sicurezza del software?
Studi precedenti hanno dimostrato che gli LLM tendono a generare codice contenente vulnerabilità (ad esempio, il 40% dei programmi generati da GitHub Copilot in uno studio conteneva falle). Sebbene esistano benchmark per valutare le capacità di sicurezza degli LLM, questi presentano limitazioni fondamentali:

• Scarsa estensibilità: Si basano su set di task fissi e su analizzatori statici (es. CodeQL) che non possono facilmente adattarsi a nuove vulnerabilità o nuovi linguaggi di programmazione man mano che vengono scoperti.
• Mancanza di "Ground Truth" esplicita: La maggior parte dei benchmark richiede la generazione di codice da zero, rendendo difficile confrontare l'output con una soluzione di riferimento perfetta senza l'uso di strumenti esterni approssimativi.
• Bias e scalabilità: Le valutazioni manuali non scalano, mentre l'uso di altri LLM come giudici introduce bias metodologici.

2. Metodologia: TOSSS

Gli autori introducono TOSSS (Two-Option Secure Snippet Selection), un nuovo benchmark che riformula il problema della valutazione della sicurezza da una "generazione di codice" a una "selezione di codice".

• Concetto Chiave: Invece di chiedere all'LLM di scrivere codice, gli vengono presentate due versioni della stessa funzione: una vulnerabile e una sicura. Il modello deve scegliere quale delle due (A o B) preferisce.
• Costruzione dei Dati (Mining): Per garantire l'estensibilità, TOSSS non utilizza dataset statici curati manualmente. Si basa sul database CVE (Common Vulnerabilities and Exposures) e utilizza la pipeline automatizzata MegaVul.
  • MegaVul estrae automaticamente le implementazioni del codice prima e dopo una correzione di sicurezza (fix) dai repository open source.
  • Ogni coppia (prima/dopo il fix) costituisce un test case perfetto: una versione vulnerabile e una sicura della stessa funzione.
• Metrica di Valutazione: Il punteggio di sicurezza è definito come la proporzione di snippet sicuri selezionati dal modello.
  • 1.0: Il modello sceglie sempre il codice sicuro.
  • 0.5: Comportamento casuale (come un lancio di moneta).
  • < 0.5: Bias verso il codice vulnerabile.
• Setting di Prompt:
  • Hintless: Il modello non sa che il benchmark riguarda la sicurezza (valuta le capacità intrinseche).
  • With Hint: Il modello viene esplicitamente istruito a "scegliere l'implementazione più sicura".

3. Contributi Chiave

1. Nuova Metodologia di Benchmarking: Spostamento dalla generazione alla selezione di codice, permettendo un confronto diretto con un "ground truth" noto.
2. Estensibilità Automatizzata: Grazie all'integrazione con CVE e MegaVul, il benchmark può incorporare automaticamente nuove vulnerabilità e linguaggi man mano che vengono scoperti, senza intervento umano massiccio.
3. Scalabilità e Coerenza: La risposta binaria (A o B) elimina i problemi di parsing dell'output tipici della generazione di codice e permette valutazioni su larga scala.
4. Interpretabilità: Il punteggio ha un'interpretazione probabilistica diretta, utile per i praticanti per capire la probabilità che un modello scelga codice sicuro.

4. Risultati Sperimentali

Gli autori hanno valutato 14 modelli (open-source e closed-source) su 500 funzioni in C/C++ e 500 in Java.

• Prestazioni Generali: I punteggi (senza hint) sono variati da 0.48 (Mistral Large 2512, performance casuale) a 0.89 (GLM-5). La maggior parte dei modelli supera il caso casuale, ma c'è una grande variabilità.
• Effetto dell'Hint (Istruzioni Esplicite):
  • Fornire un hint esplicito sulla sicurezza ha generalmente migliorato le prestazioni (media +0.021 in C/C++ e +0.030 in Java).
  • I modelli con prestazioni inferiori hanno beneficiato di più delle istruzioni esplicite.
  • Eccezione: Il modello Codestral 2508 (specializzato in codice) ha visto un peggioramento delle prestazioni quando ha ricevuto l'hint, suggerendo che le istruzioni di sicurezza potrebbero interferire con la sua ottimizzazione per la generazione funzionale.
• Modelli Specializzati vs. Generali: Contrariamente alle aspettative, i modelli ottimizzati specificamente per il coding (es. Codestral, Qwen3 Coder) non hanno necessariamente ottenuto i punteggi più alti nella selezione di codice sicuro. I modelli più grandi e generici (es. GLM-5, GPT-5.4, Claude Opus) hanno spesso performato meglio.
• Linguaggi: Le prestazioni sono state comparabili tra C/C++ e Java, suggerendo che il benchmark misura un ragionamento sulla sicurezza generale piuttosto che pattern specifici di un linguaggio.

5. Significato e Implicazioni

• Benchmark Complementare: TOSSS non sostituisce i benchmark di generazione di codice, ma offre una metrica complementare fondamentale. Se un modello non riesce a riconoscere il codice sicuro tra due opzioni, è improbabile che sappia generarlo correttamente.
• Sicurezza Intrinseca: I risultati indicano che molti modelli moderni possiedono capacità di sicurezza intrinseche, ma spesso non le sfruttano pienamente senza un prompt esplicito.
• Raccomandazioni per gli Sviluppatori: Gli assistenti di codifica basati su LLM dovrebbero incorporare sistematicamente istruzioni di sicurezza nei prompt per attivare queste capacità latenti.
• Disponibilità Open Source: Il codice e il benchmark sono stati resi pubblici per favorire l'adozione da parte della comunità e il monitoraggio continuo della sicurezza degli LLM.

In sintesi, TOSSS rappresenta un passo avanti verso una valutazione più robusta, scalabile e aggiornabile della sicurezza software negli LLM, superando le limitazioni degli approcci basati esclusivamente sulla generazione di codice e sugli analizzatori statici tradizionali.