🤖 AI

An Insight into Security Code Review with LLMs: Capabilities, Obstacles, and Influential Factors

Questo studio empirico dimostra che i Large Language Models, in particolare quelli ottimizzati per il ragionamento come DeepSeek-R1, superano significativamente gli strumenti di analisi statica all'avanguardia nella revisione del codice per la sicurezza, individuando al contempo che le strategie di prompt engineering, la complessità del codice e le dimensioni dei file sono fattori critici che influenzano la loro accuratezza di rilevamento e la qualità delle risposte.

Autori originali: Jiaxin Yu, Peng Liang, Yujia Fu, Amjed Tahir, Mojtaba Shahin, Chong Wang, Yangxiao Cai

Pubblicato 2026-05-12

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Jiaxin Yu, Peng Liang, Yujia Fu, Amjed Tahir, Mojtaba Shahin, Chong Wang, Yangxiao Cai

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 di essere l'editore di una biblioteca enorme e caotica, dove migliaia di persone scrivono costantemente nuovi capitoli per una gigantesca storia condivisa. Il tuo compito è trovare i buchi di trama pericolosi, i colpi di scena che potrebbero far crollare l'intera storia, o le pagine che potrebbero permettere a un ladro di infiltrarsi e rubare i libri. Questo è il Security Code Review (Revisione del codice di sicurezza).

Tradizionalmente, hai avuto due modi per farlo:

L'Editore Umano: Un esperto stanco che legge ogni parola. È bravo a comprendere il contesto, ma è lento e costoso.
Il Controllore Ortografico Automatizzato: Un robot che scansiona alla ricerca di parole note come "cattive". È veloce, ma spesso urla "ERRORE!" quando non c'è nulla che non va (falsi allarmi) e perde trucci sottili e intelligenti.

Questo articolo chiede: Un nuovo tipo di "Super-Lettore" (Modelli Linguistici di Grande Dimensione o LLM) può fare un lavoro migliore rispetto ai vecchi controllori ortografici?

Ecco cosa hanno scoperto i ricercatori, spiegato attraverso semplici analogie:

1. I Contendenti: Chi è arrivato alla biblioteca?

I ricercatori hanno portato sette diversi "Super-Lettori" (LLM). Alcuni sono generici (bravi a scrivere poesie ed e-mail), e uno è un modello "Ottimizzato per il Ragionamento" (addestrato specificamente a pensare passo dopo passo come un detective). Hanno anche portato i vecchi "Controllori Ortografici Automatizzati" (strumenti di analisi statica) per vedere chi vince.

Il Risultato: I Super-Lettori hanno schiacciato i vecchi controllori ortografici. Il detective "Ottimizzato per il Ragionamento" (chiamato DeepSeek-R1) è stato il campione indiscusso, seguito da vicino da GPT-4 (quello che potresti conoscere da ChatGPT). I vecchi strumenti sono rimasti nella polvere, principalmente perché si confondono con trame complesse (come le condizioni di gara nel codice) che richiedono di comprendere come diverse parti della storia interagiscono nel tempo.

2. Il Prompt Magico: Come chiedi conta

Proprio come chiedere a un bibliotecario una domanda, come chiedi al Super-Lettore conta. I ricercatori hanno provato cinque modi diversi per chiedere:

La Richiesta Base: "Trova i bug."
La Richiesta Contestuale: "Ecco il messaggio di commit (la nota che l'autore ha lasciato su cosa hanno modificato). Pensa passo dopo passo."
La Richiesta con Copia Spia: "Ecco un elenco di tipi di crimine noti (lista CWE). Cerca questi."

Il Vincitore:

Per DeepSeek-R1, il metodo migliore è stato dargli la nota dell'autore (messaggio di commit) e dirgli di "pensare passo dopo passo" (Chain-of-Thought). È come dare a un detective il diario del sospettato e chiedergli di percorrere logicamente la scena del crimine.
Per GPT-4, il metodo migliore è stato consegnargli la "Copia Spia" (l'elenco dei crimini noti). Funziona meglio quando ha una lista di controllo specifica da seguire.

3. I Difetti: Anche i Super-Lettori fanno errori

I ricercatori non hanno guardato solo chi ha trovato i bug; hanno guardato come i Super-Lettori li hanno riportati. Hanno trovato due difetti di personalità distinti:

GPT-4 (Il Poeta Vago): Spesso trova il problema giusto ma lo descrive in modo nebbioso e vago. Potrebbe dire: "C'è un rischio di sicurezza da qualche parte in questo file", senza indicare la riga esatta. A volte ignora anche le istruzioni, come dimenticare di dire "Nessun bug trovato" quando non ce ne sono.
DeepSeek-R1 (Il Verificatore di Fatti Eccessivamente Sicuro): Questo è molto specifico. Indica numeri di riga esatti e frammenti di codice. Tuttavia, a volte allucina. Potrebbe indicare con sicurezza la riga 42 e dire: "Questa riga è pericolosa", quando la riga 42 è in realtà sicura. È come un detective così ansioso di risolvere il caso da inventare prove che non esistono.

4. Il Problema dell'"Ago nel Fieno"

I ricercatori hanno scoperto che questi Super-Lettori faticano quando la storia diventa troppo lunga.

File Brevi: Sono ottimi nel trovare bug in file di codice brevi e concisi.
File Lunghi: Man mano che il codice diventa più lungo (più "token"), i Super-Lettori si distraggono. Perdono i piccoli dettagli pericolosi sepolti nel mezzo di un file enorme. È come cercare un singolo errore di battitura in un romanzo di 500 pagine; i tuoi occhi si annebbiano e lo perdi.

5. Il Paradosso della Complessità

Ecco un colpo di scena sorprendente:

Di solito, pensiamo che il codice complesso sia più difficile da controllare.
Ma per DeepSeek-R1, il codice più complesso in realtà lo ha aiutato a trovare certi tipi di bug (tranne quelli legati alla memoria).
Perché? I ricercatori suggeriscono che il codice complesso spesso ha più "indizi" e struttura all'interno del file stesso. Il Super-Lettore può usare questi indizi interni per ragionare sul problema. Il codice semplice e disordinato offre meno indizi, rendendo più difficile per l'AI capire cosa sta succedendo.

La Conclusione

L'articolo conclude che i Super-Lettori AI sono nuovi strumenti potenti che attualmente sono migliori dei vecchi scanner automatizzati nel trovare falle di sicurezza nel codice. Tuttavia, non sono ancora sostituti perfetti degli editori umani.

DeepSeek-R1 è il migliore nel ragionare sui problemi, ma deve essere sorvegliato affinché non inventi fatti.
GPT-4 è bravo a seguire le liste di controllo, ma può essere troppo vago.
La Strategia: L'approccio migliore non è sostituire gli umani, ma utilizzare questi strumenti AI come primo passaggio. Lascia che l'AI scansioni prima i file brevi e complessi, e poi fai controllare il lavoro dell'AI agli editori umani, specialmente quando l'AI diventa troppo sicura o troppo vaga.

L'articolo non afferma che questi strumenti sono pronti a gestire la biblioteca da soli, né suggerisce che siano perfetti. Mostra semplicemente che sono un nuovo assistente molto promettente che richiede una gestione attenta.

Titolo: Un'analisi della revisione del codice di sicurezza con LLM: capacità, ostacoli e fattori influenti

Enunciato del Problema
La revisione del codice di sicurezza è un processo critico ma laborioso, essenziale per prevenire violazioni dei dati e perdite finanziarie. Sebbene le organizzazioni integrino sempre più l'analisi di sicurezza nella revisione del codice, gli strumenti automatizzati esistenti (analisi statica/dinamica/ibrida) soffrono di scarsa generalizzazione, alti tassi di falsi positivi e una granularità di rilevamento grossolana. Inoltre, gli approcci basati sui dati, fondati su machine learning o deep learning tradizionali, spesso mancano di robustezza a causa della scarsità di dataset di addestramento realistici, ottenendo risultati scadenti su progetti reali. Sebbene i Modelli Linguistici di Grandi Dimensioni (LLM) abbiano dimostrato promesse in varie attività di ingegneria del software, le loro specifiche capacità, limitazioni e i fattori che influenzano le loro prestazioni nel contesto dettagliato della revisione del codice di sicurezza rimangono in gran parte inesplorati.

Metodologia
Gli autori hanno condotto uno studio empirico per valutare il potenziale degli LLM nel rilevare difetti di sicurezza durante la revisione del codice. Lo studio ha utilizzato un dataset curato manualmente di 534 file di codice (258 Python, 276 C/C++) derivati da quattro progetti open-source (OpenStack Nova/Neutron e Qt Base/Creator), contenente 614 commenti di revisione relativi alla sicurezza.

Modelli Valutati: Sono stati testati sette LLM, inclusi modelli proprietari (GPT-4, GPT-4 Turbo, Gemini Pro), modelli open-source (Llama 2 7B, Llama 2 70B) e un modello ottimizzato per il ragionamento (DeepSeek-R1).
Prompt Engineering: Sono stati progettati cinque modelli di prompt distinti basati sulle migliori pratiche e strategie precedenti:
1. Prompt Base ( $P_b$ ): Istruzione diretta di revisionare il codice.
2. Informazioni sul Progetto ( $P_r$ ): Aggiunta del contesto del nome del progetto.
3. Istruzione CWE Generale ( $P_c$ ): Istruzione a utilizzare CWE come riferimento.
4. Istruzione CWE Specifica ( $P_{cid}$ ): Fornita una lista di CWE di livello superiore.
5. Catena di Pensiero ( $P_{cot}$ ): Un prompt in due fasi che richiede al modello di generare il contesto del codice da un messaggio di commit prima di analizzare i difetti. È stata testata anche una versione "guardrail" ( $P_{cot-guardrail}$ ) per isolare l'impatto del contesto generato.
Metriche di Valutazione: Le risposte sono state etichettate manualmente in quattro categorie: Strumentale (tipo, posizione e descrizione accurati del difetto), Utile (parzialmente accurata), Fuorviante (mancato rilevamento o falsi negativi) e Incerta. Le metriche includevano I-Score, IH-Score e M-Score. La coerenza è stata misurata tramite entropia delle risposte su tre esecuzioni sperimentali.
Analisi: Lo studio ha confrontato le prestazioni degli LLM con strumenti di analisi statica all'avanguardia (es. CodeQL, Bandit, CppCheck). Per i modelli migliori, un'analisi linguistica ha identificato problemi di qualità (es. allucinazioni, vaghezza). Infine, sono stati costruiti modelli di regressione a link cumulativo per analizzare l'influenza di 11 fattori (es. numero di token, complessità del codice, tipo di difetto) sulle prestazioni.

Contributi Chiave

Valutazione Dettagliata: Fornita una valutazione completa di LLM popolari nella revisione del codice di sicurezza, andando oltre la classificazione binaria per valutare la localizzazione del difetto, la descrizione e i suggerimenti di rimedio.
Analisi della Non-Deterministicità: Misurato l'impatto della non-deterministicità degli LLM sulla coerenza dei risultati della revisione del codice di sicurezza.
Quantificazione dei Problemi di Qualità: Identificati e quantificati specifici problemi di qualità, incluse le allucinazioni (fattuali e di fedeltà), nelle risposte dei modelli migliori.
Analisi dell'Influenza dei Fattori: Condotta la prima analisi di regressione per validare statisticamente come specifici attributi del codice e del progetto influenzino le prestazioni degli LLM in questo dominio.

Risultati

Prestazioni vs Baseline: Gli LLM hanno superato significativamente gli strumenti di analisi statica all'avanguardia nella revisione del codice di sicurezza. Tra gli LLM, il modello ottimizzato per il ragionamento (DeepSeek-R1) ha superato i modelli generici.
Migliori Prestazioni: DeepSeek-R1 ha raggiunto le prestazioni complessive più elevate, seguito da GPT-4 (tramite la piattaforma ChatGPT).
- Prompt Ottimali: DeepSeek-R1 ha ottenuto i risultati migliori con un prompt che combinava il messaggio di commit e la guida Chain-of-Thought (CoT) ( $P_{cot-guardrail}$ ). GPT-4 (ChatGPT) ha ottenuto i risultati migliori con un prompt contenente una lista specifica di CWE ( $P_{cid}$ ).
Problemi di Qualità:
- GPT-4 (ChatGPT): Ha prodotto frequentemente espressioni vaghe e ha avuto difficoltà nel seguire le istruzioni (es. numeri di riga mancanti), sebbene avesse meno errori fattuali riguardanti i dettagli del codice.
- DeepSeek-R1: Più propenso a generare dettagli del codice inaccurati (es. numeri di riga o nomi di funzioni errati) e ha mostrato un tasso più elevato di allucinazioni di "Fatto Errato", nonostante migliori capacità di seguire le istruzioni.
Fattori Influenti:
- Numero di Token: Gli LLM sono stati più abili nell'identificare difetti in file con meno token; le prestazioni sono generalmente diminuite all'aumentare del numero di token.
- Annotazioni: La presenza di annotazioni relative alla sicurezza nel codice ha migliorato le capacità di rilevamento.
- Complessità: Una maggiore complessità del codice è correlata a capacità di rilevamento potenziate per DeepSeek-R1 per specifici tipi di difetti (esclusi quelli legati alla memoria), contrariamente all'assunzione che la complessità ostacoli sempre il rilevamento.
- Coerenza: I modelli con maggiori capacità di rilevamento (DeepSeek-R1, GPT-4 ChatGPT) hanno mostrato una coerenza inferiore (entropia più alta) tra le esecuzioni rispetto a modelli meno capaci.

Significato e Affermazioni
Il documento afferma che, sebbene gli attuali LLM non siano ancora un sostituto dei revisori umani, fungono da potenti strumenti ausiliari che superano significativamente gli strumenti di analisi statica tradizionali nel rilevare difetti di sicurezza. Lo studio evidenzia che l'efficacia degli LLM dipende fortemente dal prompt engineering (in particolare dall'inclusione di messaggi di commit, CoT o liste CWE) e dalle caratteristiche specifiche del codice revisionato (numero di token, complessità, annotazioni).

Gli autori sottolineano che la non-deterministicità degli LLM è un'arma a doppio taglio: i modelli capaci di un ragionamento più profondo (e quindi di un rilevamento migliore) tendono a produrre output meno coerenti. Concludono che è necessaria una strategia di revisione a più livelli, in cui gli LLM gestiscono le revisioni iniziali di codice a bassa difficoltà (meno token), mentre gli esperti umani si concentrano sul codice ad alta difficoltà e validano le scoperte degli LLM. Lo studio sottolinea inoltre la necessità di lavori futuri per affrontare le allucinazioni riguardanti i dettagli del codice e migliorare la stabilità degli output degli LLM senza sacrificare la sensibilità di rilevamento.