LLM-based Vulnerability Detection at Project Scale: An Empirical Study

Sintesi Tecnica: Rilevamento di Vulnerabilità basato su LLM su Scala di Progetto: Uno Studio Empirico

Definizione del Problema
Con l'aumento della complessità del software e delle scale di distribuzione, le vulnerabilità di sicurezza sono diventate più frequenti e dannose, rendendo necessario un rilevamento automatizzato robusto. Sebbene gli strumenti di analisi statica tradizionale siano ampiamente adottati, essi si affidano a regole ingegnerizzate manualmente e modelli predefiniti, limitando la loro capacità di generalizzare verso tipi di vulnerabilità non visti o in evoluzione. Al contrario, i recenti rilevatori basati su Large Language Models (LLM) promettono un potenziamento del ragionamento semantico interpretando la semantica del codice e la logica complessa senza l'ingegneria esplicita di regole. Tuttavia, la maggior parte degli approcci basati su LLM esistenti viene valutata su snippet a livello di funzione o di hunk, lasciando poco chiara la loro efficacia, affidabilità e scalabilità su scala di progetto. Vi è una mancanza di comprensione sistematica riguardo alle cause radici dei fallimenti (specificamente i falsi positivi) e al carico computazionale quando questi rilevatori specializzati vengono applicati a codebase reali e di grandi dimensioni.

Metodologia
Gli autori presentano il primo studio empirico completo che confronta cinque rilevatori di vulnerabilità specializzati basati su LLM su scala di progetto rispetto a due analizzatori statici tradizionali (CodeQL e Semgrep). Lo studio impiega una strategia di valutazione a doppio setting:

1. Benchmark In-House: Un dataset curato di 222 vulnerabilità reali note (che copre 8 tipi di CWE in C/C++ e Java) derivate da ReposVul, CWE-Bench-Java e JLeaks. Questo setting valuta la capacità di rilevamento (Recall) rispetto alla verità fondamentale (ground truth).
2. Progetti Reali: Un set di 24 progetti open-source attivamente mantenuti (inclusi componenti del kernel Linux, ImageMagick, Jenkins e Keycloak). Questo setting valuta l'usabilità pratica analizzando i volumi di avvisi e i tassi di falsa scoperta (False Discovery Rates, FDR).
3. Analisi Manuale: Due esperti di sicurezza hanno ispezionato manualmente 385 avvisi campionati (richiedendo oltre 150 ore uomo) per costruire una tassonomia delle cause dei falsi positivi.
4. Misurazione dei Costi: Lo studio ha quantificato l'overhead computazionale, misurando il consumo di token di input/output e il tempo di esecuzione end-to-end per ogni strumento.

I metodi basati su LLM valutati includono RepoAudit, KNighter, IRIS, LLMDFA e INFERROI, che rappresentano diversi workflow come framework multi-agente, generazione di checker assistita da LLM e inferenza guidata dal controllo del flusso.

Contributi Chiave

• Primo Confronto su Scala di Progetto: Lo studio fornisce il primo confronto sistematico di cinque rilevatori basati su LLM rappresentativi contro strumenti tradizionali su scala di progetto.
• Valutazione Comprensiva: Valuta l'efficacia del rilevamento su 222 vulnerabilità note e l'usabilità pratica attraverso 24 progetti reali.
• Tassonomia dei Fallimenti: Gli autori hanno etichettato manualmente 385 report per costruire una tassonomia dettagliata delle cause dei falsi positivi, quantificando come le scelte di progettazione (ad esempio, costruzione del dataflow, inferenza di source/sink) contribuiscano ai fallimenti.
• Analisi dei Costi: Il documento misura e riporta l'elevato consumo di token e i costi temporali associati al rilevamento basato su LLM su scala di progetto.
• Rilascio degli Artefatti: Tutti gli artefatti sperimentali, inclusi script, prompt e label della tassonomia, sono rilasciati per favorire la riproducibilità.

Risultati Chiave

1. Bassa Recall ma Rilevamenti Unici: Nel benchmark in-house, i metodi basati su LLM hanno mostrato una recall media bassa (21,09% per C/C++ e 33,82% per Java), spesso mancando vulnerabilità a causa di definizioni di source/sink disallineate. Tuttavia, hanno comunque scoperto più vulnerabilità uniche rispetto agli strumenti tradizionali, suggerendo un valore complementare.
2. Alti Tassi di Falsa Scoperta (FDR): Nei progetti reali, sia gli strumenti basati su LLM che quelli tradizionali hanno generato numerosi avvisi con FDR molto elevati. Anche lo strumento con le prestazioni migliori presentava un FDR medio dell'85,3%. Ad esempio, RepoAudit su progetti C/C++ aveva un SFDR medio del 97,0%.
3. Cause Radice del Fallimento: L'analisi manuale ha identificato due cause dominanti condivise sia dagli strumenti LLM che da quelli tradizionali:
   • Ragionamento Interprocedurale Superficiale (37,47% dei FP): Gli strumenti falliscono nel tracciare i dataflow attraverso catene di chiamate profonde o strutture di controllo complesse.
   • Identificazione Imprecisa di Source/Sink (19,00% dei FP): Gli strumenti identificano erroneamente punti benigni del programma come rilevanti per la sicurezza o non riconoscono API specifiche del progetto.
   • Fallimenti Specifici degli LLM: Gli strumenti basati su LLM hanno inoltre sofferto di comprensione del codice allucinata, ricostruzione errata del controllo del flusso (ad esempio, unendo percorsi mutuamente esclusivi) e incapacità di aderire strettamente alle definizioni dei prompt o agli scope CWE.
4. Overhead Computazionale: Il rilevamento su scala di progetto tramite LLM è computazionalmente costoso. Strumenti come RepoAudit e LLMDFA hanno richiesto da centinaia di migliaia a centinaia di milioni di token per progetto, con tempi di esecuzione che variano da diverse ore a diversi giorni (ad esempio, fino a 4.638 minuti). Gli strumenti tradizionali (CodeQL, Semgrep) completavano le analisi in secondi o minuti con costi di token trascurabili.

Significatività e Implicazioni
Il documento conclude che, sebbene i rilevatori basati su LLM offrano promettenti capacità di ragionamento semantico che possono scoprire vulnerabilità mancate dagli strumenti tradizionali basati su pattern, non sono ancora abbastanza maturi per un deployment affidabile e standalone in scenari reali. Lo studio evidenzia critiche limitazioni in termini di robustezza (alto FDR), affidabilità (bassa recall sulla ground truth) e scalabilità (costi computazionali proibitivi).

Gli autori derivano cinque implicazioni per la ricerca futura:

1. Approfondire il Ragionamento del Dataflow: Andare oltre l'esplorazione superficiale del grafo delle chiamate verso un'analisi olistica "input → propagazione → output".
2. Migliorare l'Inferenza di Source/Sink: Sviluppare meccanismi sensibili al contesto per identificare accuratamente le API specifiche del progetto invece di fare affidamento su definizioni generiche o allucinate.
3. Potenziare la Comprensione Semantica: Integrare gli LLM con rappresentazioni intermedie del programma e segnali di analisi statica per gestire meglio le caratteristiche complesse del linguaggio (ad esempio, distruttori, try-with-resources).
4. Imporre l'Allineamento dei Prompt: Implementare la collaborazione multi-agente strutturata o l'auto-verifica per garantire che i modelli aderiscano strettamente alle definizioni di vulnerabilità.
5. Affrontare la Scalabilità: Adottare l'analisi gerarchica, il caching del ragionamento intermedio e l'ottimizzazione dei workflow per ridurre il consumo di token e i tempi di esecuzione a livelli adatti alla integrazione continua.

Gli autori sottolineano che i risultati attuali evidenziano la necessità di approcci ibridi che sfruttino i punti di forza semantici degli LLM mitigando al contempo i loro problemi di costo e affidabilità attraverso un'integrazione rigorosa con l'analisi statica.