Sintesi Tecnica: Dal Verdetto alla Diagnosi: Revisione di Sicurezza Attribuibile delle Pull Request

1. Definizione del Problema: Il Gap Verdetto–Diagnosi (VD)

Gli attuali revisori automatici del codice sono valutati principalmente sulla loro capacità di emettere un verdetto di "blocco" per le Pull Request (PR) malevole. Tuttavia, il documento identifica un difetto critico in questo paradigma di valutazione: un revisore può bloccare correttamente una PR per il motivo sbagliato. Un blocco potrebbe essere innescato da un problema non correlato (ad esempio, un errore di formattazione o un avviso non critico) piuttosto che dalla specifica vulnerabilità che rende la PR insicura.

Questa discrepanza è definita gap Verdetto–Diagnosi (VD).

• Verdetto: La decisione di approvare o bloccare una PR.
• Diagnosi: L'identificazione specifica della vulnerabilità e le prove a supporto di essa.
• Il Gap: Un verdetto di blocco corretto accoppiato a una diagnosi errata o non supportata. In tali casi, gli sforzi di rimedio vengono indirizzati in modo errato, lasciando la vulnerabilità reale non affrontata.

Il documento sostiene che i benchmark e le metriche di valutazione esistenti non riescono a distinguere tra un sistema che si limita a "bloccare" e uno che "diagnostica" correttamente il difetto di sicurezza sottostante. Inoltre, molte vulnerabilità (particolarmente i difetti di tipo "assenza", dove manca una guardia necessaria) richiedono prove provenienti da parti non modificate del repository, che l'analisi basata solo sul diff spesso perde.

2. Metodologia

2.1 MALPR-BENCH: Un Benchmark Basato sui Meccanismi

Per misurare il gap VD, gli autori introducono MALPR-BENCH, un benchmark progettato per valutare separatamente tre dimensioni distinte:

1. Correttezza del Verdetto (V): Il sistema ha bloccato la PR?
2. Identificazione della Vulnerabilità Target (I): Il sistema ha identificato correttamente il meccanismo specifico della vulnerabilità?
3. Validazione delle Prove (E): Il sistema ha fondato la sua diagnosi su fatti concreti e verificabili del repository (posizioni del codice, file non modificati, ecc.)?

Costruzione:

• Scala: 89 PR malevole e 50 controlli benigni in 44 repository e otto famiglie di linguaggi.
• Fonti:
  • Storia Minata: Recupero di correzioni incomplete dalle cronologie dei progetti.
  • Derivata da Advisory: Costruzione di stati malevoli partendo da advisory di sicurezza pubbliche (Pool A: correzione incompleta; Pool B: enforcement invertito).
  • Scoperta nel Mondo Reale: Vulnerabilità precedentemente non dichiarate trovate dallo strumento degli autori.
• Ground Truth: Ogni caso include una "rubrica congelata" che specifica la vulnerabilità target, la catena di prove richiesta e le descrizioni accettate. Ciò consente una valutazione precisa se una revisione sia "attribuibile" (ovvero, $A = V \land I \land E$).
• Classificazione dei Difetti: I casi sono categorizzati come Present-type (il comportamento insicuro è visibile nel diff) o Absence-type (manca un necessario controllo di sicurezza). Le posizioni delle prove sono classificate da L0 (solo diff) a L2b (corrispondenza semantica in file non correlati).

2.2 PRGUARD: Un Revisore di Sicurezza Attribuibile

Per affrontare il gap VD, gli autori propongono PRGUARD, un sistema che separa l'identificazione della vulnerabilità dalla validazione delle prove. A differenza dei modelli end-to-end che passano direttamente dal diff al verdetto, PRGUARD opera attraverso una pipeline a stadi:

• Stadio 0 (Raccolta Strutturale): Raccoglie deterministicamente il contesto strutturale (chiamanti, chiamati, import) attorno al codice modificato prima di qualsiasi ragionamento del modello.
• Stadio 1 (Caratterizzazione della Modifica): Il modello descrive il comportamento rilevante per la sicurezza della modifica senza proporre ancora una vulnerabilità specifica.
• Stadi 2 & 2.5 (Acquisizione delle Prove):
  • Percorso 1 (Guidato dalla Conoscenza): Utilizza una Base di Conoscenza dei Meccanismi (KB) derivata dai casi di sviluppo per recuperare prove specifiche del repository tramite relazioni tipizzate (es. SIBLING-ENDPOINT).
  • Percorso 2 (Guidato dal Codice): Costruisce una lista di lavoro di percorsi del repository basata sulla struttura del codice modificato, indipendentemente dalla KB.
• Stadio 3 (Costruzione del Candidato): Formula vulnerabilità candidate concrete basate sulle prove raccolte.
• Stadio 4 (Validazione delle Prove): Una chiamata separata al modello testa i candidati contro le prove del repository. Verifica le premesse critiche per la sicurezza (controllo dell'attaccante, raggiungibilità, guardie mancanti). I candidati sono contrassegnati come VALIDATI, DECLASSATI o RIJECTATI.
• Stadio 5 (Sintesi della Revisione): Una policy deterministica mappa gli esiti della validazione verso un verdetto (Blocca, Commenta, Approva) e sintetizza una revisione che spiega i risultati validati con specifiche posizioni del codice.

3. Contributi Chiave

1. Formulazione del Gap VD: Il documento definisce e caratterizza la discrepanza tra un verdetto di blocco corretto e una diagnosi corretta, sostenendo che le metriche di valutazione attuali oscurano questo modo di fallimento.
2. MALPR-BENCH: Un framework di valutazione sistematica e un benchmark che separa la correttezza del verdetto dall'identificazione della vulnerabilità e dalla validazione delle prove, utilizzando rubriche pre-impegnate per la verità di base (ground truth).
3. PRGUARD: Un'architettura di revisore di sicurezza per PR attribuibile che decouple la generazione di ipotesi dalla validazione delle prove e recupera il contesto oltre il diff.
4. Validazione Empirica: Dimostrazione che la separazione dell'identificazione dalla validazione migliora l'attribuzione dei risultati di sicurezza, particolarmente per i difetti di tipo "assenza".

4. Risultati

4.1 Prestazioni sul Set di Test Common-Coverage

Valutato su 31 PR malevole tenute fuori dal test (19 auto-generalizzazione + 12 casi di scoperta) rispetto a CodeRabbit (un popolare revisore AI commerciale):

• Prestazioni di Blocco: Entrambi i sistemi hanno ottenuto tassi di blocco simili (CodeRabbit: 24/31; PRGUARD/DeepSeek: 22/31).
• Identificazione della Vulnerabilità (I): PRGUARD/DeepSeek ha identificato 1.38× più vulnerabilità target rispetto a CodeRabbit (22 vs 16).
• Difetti di Tipo Assenza: Su 14 casi in cui mancava una guardia necessaria, entrambi i sistemi hanno bloccato 9 PR. Tuttavia, PRGUARD/DeepSeek ha identificato la vulnerabilità target in 9/14 casi, mentre CodeRabbit l'ha identificata in soli 3/14 (una differenza di 3×).
• Blocchi Attribuibili (A): PRGUARD/DeepSeek ha ottenuto 19/31 blocchi attribuibili, rispetto ai 16/31 di CodeRabbit.
• Posizione delle Prove: CodeRabbit ha fallito l'identificazione dei target in 0/7 casi che richiedevano prove al di fuori dei file toccati (L2a/L2b), mentre PRGUARD ha avuto successo nella maggior parte dei casi.

4.2 Valutazione dell'Intera Pipeline

Su 63 casi malevoli tenuti fuori (escludendo il livello di scoperta per evitare bias):

• Pool B (Enforcement Invertito): Entrambi i backend (GPT-5.5 e DeepSeek) hanno identificato tutte le 37 vulnerabilità target (I=37/37). Tuttavia, la validazione delle prove (E) variava (26/37 per GPT-5.5, 34/37 per DeepSeek), evidenziando che l'identificazione non garantisce l'ancoraggio a prove valide.
• Controlli Benigni: PRGUARD ha mostrato bassi tassi di falsi positivi (4–5 blocchi su 50 controlli benigni), comparabili a CodeRabbit (0 blocchi su un sottoinsieme di 6 controlli).

4.3 Scoperta nel Mondo Reale

Applicato a repository di produzione, PRGUARD ha scoperto 12 vulnerabilità precedentemente non dichiarate, supportate da proof-of-concept in cinque progetti ampiamente utilizzati.

• Esecuzioni indipendenti di PRGUARD e CodeRabbit hanno bloccato entrambi 10/12 PR in questo livello di scoperta.
• Tuttavia, PRGUARD ha prodotto 10/12 blocchi attribuibili, mentre CodeRabbit ne ha prodotti solo 4/12, dimostrando che totali di verdetto identici possono mascherare una differenza di 2.5× nella qualità diagnostica.

5. Significato e Rivendicazioni

Il documento sostiene che il gap Verdetto–Diagnosi è un limite fondamentale nell'attuale revisione di sicurezza automatizzata. Un blocco "riuscito" è insufficiente se non identifica e sostiene correttamente la vulnerabilità, poiché ciò porta a un rimedio inefficace.

• L'Attribuibilità è la Chiave: Gli autori sostengono che le revisioni di sicurezza debbano essere attribuibili — il verdetto deve essere fondato su prove specifiche del repository che validino il meccanismo identificato.
• Separazione delle Responsabilità: I risultati suggeriscono che separare i compiti di identificazione di una vulnerabilità candidata e la sua validazione rispetto alle prove migliori la affidabilità della diagnosi, specialmente per difetti complessi che richiedono il contesto tra più file.
• Limitazioni: Il documento riconosce che PRGUARD non è una soluzione definitiva. Tratta l'iniezione di prompt e gli errori di giudizio come superfici di attacco residue. La scoperta di vulnerabilità nel mondo reale dimostra la capacità, ma non pretende di stimare il tasso di richiamo su arbitrarie PR, poiché lo stream dei candidati è stato filtrato per la validazione manuale.

In sintesi, il lavoro sposta il focus della valutazione da "ha bloccato?" a "ha bloccato per il motivo giusto, con una prova?", introducendo una metodologia e un set di strumenti per misurare e mitigare i rischi di revisioni di sicurezza mal diagnosticate.