💻 computer science

Vulnerability Detection with Interprocedural Context in Multiple Languages: Assessing Effectiveness and Cost of Modern LLMs

Questo studio valuta l'efficacia e i costi di quattro moderni modelli linguistici (LLM) nel rilevare vulnerabilità di sicurezza interprocedurali in C, C++ e Python, dimostrando che l'aggiunta del contesto delle funzioni chiamate e chiamanti migliora significativamente l'individuazione e che Gemini 3 Flash offre il miglior compromesso costo-efficacia per il codice C.

Autori originali: Kevin Lira, Baldoino Fonseca, Davy Baía, Márcio Ribeiro, Wesley K. G. Assunção

Pubblicato 2026-04-10

📖 4 min di lettura☕ Lettura da pausa caffè

CC BY 4.0

Autori originali: Kevin Lira, Baldoino Fonseca, Davy Baía, Márcio Ribeiro, Wesley K. G. Assunção

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

🕵️‍♂️ L'Investigatore IA: Trovare i Ladri nel Codice

Immagina che il codice di un programma sia una città enorme fatta di case (funzioni). Ogni casa ha le sue regole, ma spesso i problemi di sicurezza (i "ladri" o le vulnerabilità) non nascono dentro una singola casa, ma nel modo in cui le case si parlano tra loro.

Ad esempio, il Signor Mario (una funzione) potrebbe dire alla Signora Giulia (un'altra funzione): "Ehi, tieni questo pacco!". Se Giulia non controlla cosa c'è nel pacco e lo apre senza guardare, potrebbe esplodere. Il problema non è in casa di Mario, né solo in quella di Giulia, ma nel messaggio che passa tra loro.

Fino a poco tempo fa, gli investigatori IA (i Modelli Linguistici o LLM) guardavano solo una casa alla volta, chiedendo: "C'è un ladro qui dentro?". Questo studio ha chiesto: "E se invece diamo all'IA una mappa completa che mostra chi chiama chi, e chi parla con chi, diventa più bravo a trovare i ladri?"

🧪 L'Esperimento: Tre Scenari

Gli scienziati hanno preso 509 casi reali di "ladri" (vulnerabilità) da programmi scritti in tre lingue diverse (C, C++ e Python) e hanno testato quattro investigatori IA famosi (Claude, GPT-4, GPT-5, Gemini). Hanno provato tre approcci diversi:

Solo la Casa (Context Zero): L'IA guarda solo la stanza del sospetto, senza sapere chi è entrato o uscito.
La Casa + I Vicini che Entrano (Callers): L'IA vede la stanza e sa chi ha bussato alla porta prima.
La Casa + I Vicini che Escono (Callees): L'IA vede la stanza e sa chi la stanza ha mandato fuori.

📉 La Sorpresa: "Più informazioni" non significa "Migliore risposta"

Il risultato più strano? Avere più informazioni ha spesso peggiorato le cose!

L'analogia del Rumore: Immagina di dover ascoltare una conversazione segreta in una stanza. Se ti metti le cuffie e ascolti solo quella stanza, capisci bene. Se ti metti le cuffie e ascolti anche tutte le conversazioni dei vicini, il rumore di fondo diventa così forte che non riesci più a distinguere la voce importante.
Cosa è successo: Per alcuni investigatori (specialmente i modelli GPT di OpenAI), aggiungere il contesto dei vicini ha creato confusione. La loro accuratezza è crollata fino al 25%. Sembrava che più dati avessero, più si distraevano.
I Super Investigatori: Altri modelli (come Claude e Gemini) sono stati più bravi a filtrare il rumore. Hanno mantenuto la loro efficacia anche con la mappa completa, ma non sono diventati molto più bravi di prima.

💰 Il Costo: Pagare il doppio per lo stesso risultato

C'è un altro aspetto importante: il denaro.
Chiedere all'IA di leggere la mappa completa dei vicini costa quasi il doppio rispetto a guardare solo la stanza, perché l'IA deve elaborare molte più parole (token).

Il verdetto economico: Pagare il doppio per ottenere lo stesso (o peggio) risultato non ha senso.
Il vincitore: Il modello Gemini 3 Flash è stato il migliore nel rapporto "soldi spesi / risultati ottenuti". È stato veloce, economico e molto preciso, specialmente per i programmi scritti in C.
Il re delle spiegazioni: Claude Haiku 4.5 è stato il migliore nel spiegare perché aveva trovato un ladro. Se vuoi sapere come riparare il buco, lui è il tuo uomo, anche se costa un po' di più.

🌍 Le Lingue Contano

Non tutte le città sono uguali:

C e C++: Sono come vecchie case di mattoni dove i proprietari devono gestire tutto manualmente (la memoria). Qui, dare troppe informazioni all'IA ha creato confusione.
Python: È come un condominio moderno e automatizzato. Qui l'IA ha funzionato bene in tutti i modi, ma non c'è stato un grande vantaggio nel guardare i vicini.

🎯 Le Conclusioni in Pillole

Non sempre "di più" è meglio: Dare all'IA troppi dettagli su come il codice si collega ad altre parti può confonderla, specialmente se l'IA non è molto avanzata. A volte, guardare solo il pezzo di codice sospetto è la strategia migliore.
Il prezzo conta: Aggiungere contesto raddoppia il costo senza raddoppiare la sicurezza. Bisogna scegliere l'investigatore giusto per il proprio budget.
Spiegare è difficile: Un'IA che sbaglia a trovare il ladro, spesso sbaglia anche a spiegare come lo ha trovato. Un buon detective deve essere bravo sia a trovare il colpevole sia a scrivere il rapporto.

In sintesi: Se vuoi costruire un sistema di sicurezza automatico, non buttare tutte le informazioni possibili all'IA. Scegli il modello giusto (come Gemini per risparmiare o Claude per le spiegazioni) e, soprattutto, non pensare che più contesto significhi automaticamente più sicurezza. A volte, meno è meglio!

1. Il Problema

La rilevazione automatica delle vulnerabilità software è fondamentale per la sicurezza, ma gli studi precedenti si sono concentrati prevalentemente sull'analisi di singole funzioni, ignorando le dipendenze interprocedurali (il flusso di dati e controllo tra funzioni chiamate e chiamanti). Molte vulnerabilità critiche (es. use-after-free, overflow di buffer, iniezioni mediate da argomenti) emergono solo analizzando l'interazione tra più funzioni. Inoltre, la letteratura attuale presenta tre lacune principali:

Mancanza di valutazione su contesti interprocedurali (chiamanti e chiamati).
Limitazione a un singolo linguaggio di programmazione, trascurando l'eterogeneità dei progetti moderni.
Assenza di analisi sui costi economici e sulla qualità delle spiegazioni generate dai modelli, fattori cruciali per l'adozione industriale.

2. Metodologia

Gli autori hanno condotto uno studio empirico su larga scala per valutare l'efficacia, il costo e la qualità esplicativa di quattro moderni Large Language Models (LLM):

Modelli valutati: Claude Haiku 4.5, GPT-4.1 Mini, GPT-5 Mini e Gemini 3 Flash.
Dataset: 509 vulnerabilità interprocedurali estratte dal dataset ReposVul, coprendo i linguaggi C, C++ e Python.
Configurazioni di Input: Per ogni funzione target, sono state testate tre configurazioni di contesto:
1. Code Only (CO): Solo il codice della funzione target.
2. Code + Callees (CC): Funzione target + codice delle funzioni che essa invoca.
3. Code + Callers (CK): Funzione target + codice delle funzioni che la invocano.
Metriche:
- Efficacia: Accuratezza, F1-score, Precisione e Recall.
- Efficienza: Costo di inferenza stimato basato sul consumo di token (prezzi API di marzo 2026).
- Qualità Esplicativa: Valutazione manuale (su un campione di 986 risposte) di Correttezza (identificazione corretta del tipo e posizione) e Completezza (presenza di vettori di attacco e suggerimenti di riparazione) su una scala 0-2.
Analisi Statistica: Utilizzo del test di McNemar per confrontare le configurazioni e correzione di Holm-Bonferroni per l'errore di tipo I.

3. Risultati Chiave

A. Efficacia e Impatto del Contesto (RQ1 & RQ2)

Il contesto non aiuta sempre: Contrariamente alle aspettative, l'aggiunta di contesto interprocedurale non migliora costantemente le prestazioni e, in molti casi, le peggiora significativamente.
Dipendenza dal Modello:
- Claude Haiku 4.5 e Gemini 3 Flash: Mostrano robustezza. Le prestazioni rimangono stabili o leggermente migliori con il solo codice (CO). Non subiscono degradazioni statisticamente significative con l'aggiunta di contesto.
- GPT-4.1 Mini e GPT-5 Mini: Soffrono di un forte degrado delle prestazioni quando viene aggiunto il contesto. In C, GPT-4.1 Mini vede un crollo dell'accuratezza dal 75,6% (CO) al 54,0% (CC). Si ipotizza che questi modelli introducano "rumore" o distraggano l'attenzione su elementi non rilevanti quando il contesto si espande.
Dipendenza dal Linguaggio:
- C: Il degrado per i modelli GPT è marcato.
- Python: Le tendenze sono simili ma meno pronunciate e non statisticamente significative (probabilmente a causa di un accoppiamento interprocedurale inferiore).
- C++: Il campione era troppo piccolo per conclusioni statistiche robuste.

B. Efficienza e Costi (RQ3)

Costo vs. Performance: L'aggiunta di contesto interprocedurale raddoppia quasi il consumo di token e, di conseguenza, il costo di inferenza, senza fornire guadagni proporzionali in accuratezza.
Miglior Trade-off: Gemini 3 Flash offre il miglior compromesso costo-performance, specialmente per le vulnerabilità in C, raggiungendo un F1-score ≥ 0,978 con un costo stimato di $0,50–$ 0,58 per configurazione.
Costi Assoluti: Claude Haiku 4.5 è il più costoso (circa 8 volte più di GPT-4.1 Mini), mentre GPT-4.1 Mini è il più economico ma meno accurato.

C. Qualità delle Spiegazioni (RQ4)

Leader Esplicativo: Claude Haiku 4.5 eccelle nella generazione di spiegazioni, ottenendo un punteggio perfetto (2,2) nel 93,6% dei casi valutati.
Correlazione: Esiste una correlazione tra capacità di rilevamento e qualità esplicativa. I modelli GPT, che commettono più errori di classificazione, mostrano anche tassi più alti di spiegazioni fondamentalmente errate (6-7% di punteggi zero) rispetto a Claude e Gemini (<1,2%).
Completezza: La completezza delle spiegazioni (inclusione di vettori di attacco e riparazione) è generalmente più bassa rispetto alla correttezza tecnica, specialmente per Gemini 3 Flash.

4. Contributi Principali

Sfatare il mito del "più contesto è meglio": Dimostrano empiricamente che per molti LLM, l'aggiunta di contesto interprocedurale può degradare le prestazioni, specialmente in linguaggi a gestione manuale della memoria come il C.
Analisi Multi-Linguaggio e Multi-Modello: Forniscono una delle prime valutazioni comparative sistematiche di LLM moderni su vulnerabilità reali in C, C++ e Python, considerando sia l'efficacia che il costo.
Valutazione Economica: Quantificano il costo reale dell'uso degli LLM per la sicurezza, mostrando che l'aumento del contesto raddoppia i costi senza benefici lineari.
Valutazione Qualitativa delle Spiegazioni: Introducono una valutazione manuale rigorosa sulla qualità delle giustificazioni fornite dai modelli, collegando la capacità di ragionamento alla qualità dell'output.

5. Significato e Implicazioni Pratiche

Progettazione degli Strumenti: Gli strumenti di analisi sicurezza basati su LLM non dovrebbero applicare ciecamente l'aggiunta di tutto il contesto disponibile. La strategia di prompt engineering deve essere calibrata in base al modello specifico e al linguaggio target.
Selezione del Modello: Non esiste un modello "migliore" in assoluto.
- Per massima accuratezza e spiegazioni dettagliate: Claude Haiku 4.5.
- Per il miglior equilibrio costo/accuratezza (specialmente in C): Gemini 3 Flash.
- Per costi minimi (accettando minore accuratezza): GPT-4.1 Mini.
Sicurezza Industriale: I risultati suggeriscono che investire in modelli con capacità di ragionamento più forti (come Claude e Gemini) porta benefici sia nella rilevazione che nella spiegazione delle vulnerabilità, rendendoli più adatti a pipeline di sviluppo reali dove la spiegazione è cruciale per i developer.

In sintesi, lo studio evidenzia che l'uso efficace degli LLM per la sicurezza richiede una comprensione profonda delle interazioni tra architettura del modello, linguaggio di programmazione e configurazione del contesto, piuttosto che un approccio "one-size-fits-all".