💻 computer science

Security in a Workflow: Exploring Role-Based Agentic Architectures for Vulnerability Handling

Questo articolo propone e valuta un flusso di lavoro agentico basato su ruoli che comprende gli agenti Planner, Analyzer, Fixer e Verifier per colmare il divario tra i compiti di sicurezza isolati degli LLM e le pratiche industriali reali, dimostrando un'accuratezza di rilevamento delle vulnerabilità del 44% e un'accuratezza di correzione del 19% su 25 vulnerabilità reali in C/C++.

Autori originali: Srijita Basu, Miroslaw Staron

Pubblicato 2026-06-15

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Srijita Basu, Miroslaw Staron

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 cercare di riparare una casa molto vecchia e complessa (un programma software scritto in C o C++) che presenta crepe nascoste e punti deboli (vulnerabilità di sicurezza). In passato, avresti potuto assumere un singolo detective super intelligente (un'IA standard) per esaminare la casa, trovare le crepe e cercare di tappare tutto in una volta. A volte questo detective ci riesce, ma spesso viene sopraffatto, perde indizi sottili o ripara la parete sbagliata.

Questo articolo propone un approccio diverso: assumere un team di agenti specializzati invece di un solo detective solitario. Lavorano insieme in una rigorosa catena di montaggio, dove ognuno ha un compito specifico.

Ecco come funziona il team, utilizzando le scoperte dell'articolo:

1. I Ruoli del Team (Il "Workflow Agente")

I ricercatori hanno allestito un team digitale con quattro ruoli distinti, simili a una squadra di costruzione:

Il Pianificatore (Il Capocantiere): Prima che chiunque inizi a scavare, questo agente scansiona i progetti (il codice) per individuare i punti di problemi ovvi. Non ripara nulla; si limita a indicare al team le aree che sembrano sospette, come "Controlla la porta sul retro" o "Guarda le fondamenta".
- Risultato chiave: L'articolo ha scoperto che avere questo "Capocantiere" era fondamentale. Quando hanno rimosso questo ruolo, la capacità del team di trovare i problemi è diminuita di quasi la metà.
L'Analizzatore (L'Ispettore): Questo è il detective principale. Prende gli indizi dal Pianificatore e dal codice grezzo per capire esattamente cosa è rotto, perché è rotto e come un ladro potrebbe entrare.
- Risultato chiave: I ricercatori hanno provato a dare a questo agente un metal detector hi-tech (uno strumento chiamato CodeQL) per aiutarlo a trovare le crepe. Sorprendentemente, il metal detector non sempre aiutava. A volte generava troppi falsi allarmi, confondendo l'Ispettore. I risultati migliori sono arrivati dal fatto che l'IA stessa faceva il lavoro di pensiero profondo, piuttosto che fare affidamento pesantemente sullo strumento extra.
Il Riparatore (L'Operaio): Una volta che l'Ispettore dice: "Il telaio della porta sta marcendo", il Riparatore prova a costruire una nuova porta. Scrive il codice per tappare il buco.
- Risultato chiave: Questo era il lavoro più difficile. Mentre il team era abbastanza bravo a trovare il problema (circa il 44% di precisione), ripararlo correttamente era molto più difficile (solo il 19% di precisione). Spesso, il Riparatore tappareva il buco ma accidentalmente rompeva qualcos'altro nelle vicinanze o aggiungeva parti non necessarie.
Il Verificatore (L'Ispettore di Sicurezza): Dopo che la riparazione è stata completata, questo agente ricontrolla il lavoro. Chiede: "Hai davvero riparato il marciume? Hai reso la casa più sicura o hai solo dipinto sopra la crepa?".
- Risolo chiave: Questo ruolo è stato piuttosto bravo a individuare gli errori, catturando circa il 69% degli errori nelle riparazioni.

2. L'Esperimento

I ricercatori hanno testato questo team su 25 falle di sicurezza reali trovate in popolari software C/C++ (come quelli utilizzati in sistemi critici per la sicurezza). Hanno utilizzato tre diversi "cervelli" (modelli IA) per alimentare i membri del team.

Hanno confrontato due versioni del team:

Team A: Solo i quattro ruoli che comunicano tra loro.
Team B: Gli stessi quattro ruoli, ma l'Ispettore ha ricevuto il metal detector CodeQL per aiutare a trovare le crepe.

3. Cosa hanno scoperto

Il "Manager" conta di più: La parte più importante del processo è stato il Pianificatore. Senza un manager che guidasse il team su dove guardare, l'IA si perdeva. Con il manager, il team ha ottenuto prestazioni pari a un'IA commerciale di alto livello (GPT-5.5) nel trovare i bug.
Gli strumenti non sono magici: Dare all'Ispettore uno strumento sofisticato (CodeQL) non lo ha reso automaticamente migliore. In realtà, a volte ha peggiorato le cose perché l'IA faticava a interpretare correttamente i dati dello strumento. L'articolo suggerisce che per i linguaggi informatici di basso livello (come il C), l'IA deve essere abbastanza intelligente da dare priorità ai segnali da sola.
Trovare vs Riparare: È molto più facile per l'IA trovare un buco di sicurezza che ripararlo. Il team ha trovato i bug circa il 44% delle volte, ma li ha riparati correttamente solo il 19% delle volte.
Il tocco umano è ancora necessario: Poiché il "Riparatore" (Fixer) spesso commetteva errori o aggiungeva modifiche non necessarie, l'articolo conclude che, nella sicurezza reale, non si può lasciare che l'IA gestisca tutto da sola. È necessario un essere umano che controlli il lavoro dell'IA, verifichi le riparazioni e si assicuri che la casa sia effettivamente sicura.

In sintesi

Questo articolo non sostiene che l'IA possa ora mettere in sicurezza il software perfettamente da sola. Inveve, dimostra che organizzare l'IA in un team strutturato con ruoli chiari è un modo migliore per gestire la sicurezza rispetto al lasciare che un'unica IA faccia tutto. Tuttavia, anche con un grande team, la parte della "riparazione" è ancora complicata e gli esperti umani sono ancora essenziali per verificare il lavoro.

Riepilogo Tecnico: La Sicurezza in un Workflow – Esplorazione di Architetture Agenti basate su Ruoli per la Gestione delle Vulnerabilità

Definizione del Problema

L'ingegneria del software sicura nella pratica industriale prevede un workflow strutturato e multistadio che comprende l'analisi delle vulnerabilità, la rimedio (remediation) e la verifica della correzione. Tuttavia, gli attuali approcci basati sui Large Language Model (LLM) alla sicurezza del software sono spesso frammentati, concentrandosi su compiti isolati come il rilevamento o la generazione di patch, piuttosto che riflettere i workflow agentici end-to-end utilizzati nei processi di sicurezza del mondo reale. Ciò crea un divario tra i metodi LLM esistenti e l'ingegneria del software sicura pratica, particolarmente per i linguaggi di sistema a basso livello come C e C++. In questi linguaggi, le vulnerabilità dipendono da complesse semantiche di memoria, manipolazione di puntatori e gestione dei buffer, rendendo la diagnosi e il rimedio difficili per gli LLM. Inoltre, esiste una limitata esplorazione di workflow agentici aumentati da strumenti e dell'integrazione di skill tramite Model Context Protocol (MCP) specificamente per questi contesti a basso livello.

Metodologia

Gli autori propongono e valutano un workflow agentico basato su ruoli progettato per decomporre la gestione delle vulnerabilità in fasi esplicite: pianificazione dell'investigazione, analisi della vulnerabilità, generazione della patch e verifica della correzione.

Design del Workflow

Lo studio implementa due varianti di workflow utilizzando il framework CrewAI, istanziato con tre LLM open-source: nemotron-cascade-2:30b, qwen3-coder-next e gpt-oss:120b. I workflow consistono in quattro ruoli distinti:

Planner (Pianificatore): Un modulo statico basato su regole (non un LLM) che scansiona il codice C in input per pattern di vulnerabilità predefiniti (es. buffer overflow, dereferenziazione di puntatori nulli) utilizzando espressioni regolari. Produce regioni di investigazione e temi prioritari per guidare l'Analyzer.
Analyzer (Analizzatore): Un agente LLM responsabile della diagnosi tecnica. Determina la vulnerabilità primaria, assegna l'ID CWE (Common Weakness Enumeration), identifica le linee vulnerabili, spiega la causa radice e traccia il flusso source-to-sink.
- Workflow 1: L'Analyzer si affida esclusivamente alla guida del Planner.
- Workflow 2: L'Analyzer è aumentato dall'integrazione MCP CodeQL, fornendo capacità di analisi statica durante la diagnosi.
Fixer (Riparatore): Un agente LLM che genera una patch minima e sicura basata sulla diagnosi dell'Analyzer. È vincolato a produrre la patch e una spiegazione concisa, evitando la ri-diagnosi.
Verifier (Verificatore): Un agente LLM indipendente che valuta se la patch generata risolve la vulnerabilità identificata, rimuove la causa radice ed evita l'introduzione di regressioni.

Setup Sperimentale

Dataset: Un set curato di 25 CVE (Common Vulnerabilities and Exposures) reali in C/C++ che coprono cinque categorie CWE: CWE-787 (Out-of-bounds Write), CWE-476 (Null Pointer Dereference), CWE-190 (Integer Overflow), CWE-125 (Out-of-bounds Read) e CWE-191 (Integer Underflow).
Ground Truth (Verità di Base): Derivata dalle descrizioni del National Vulnerability Database (NVD) e dal codice patchato fornito dagli sviluppatori.
Valutazione: Valutazione manuale basata su rubrica da parte di due autori (coefficiente kappa di Cohen $\kappa = 0.83$ ) confrontando gli output degli agenti con la ground truth. Le metriche includevano l'accuratezza del rilevamento (assegnazione CWE, identificazione della linea, causa radice) e l'accuratezza della correzione (similarità semantica con le correzioni affidabili).
Ambito: Lo studio è una valutazione esplorativa orientata alla metodologia piuttosto che un benchmark su larga scala, focalizzandosi su 150 esecuzioni di workflow (25 CVE $\times$ 3 modelli $\times$ 2 varianti).

Contributi Chiave

Architettura Agente basata su Ruoli: Proposta e valutazione di un workflow end-to-end che separa pianificazione, analisi, riparazione e verifica, dimostrando come la separazione esplicita dei ruoli possa strutturare le attività di sicurezza.
Design del Planner Statico: Implementazione di un planner basato su regole per guidare l'investigazione delle vulnerabilità in progetti C rilevanti per l'industria, mostrando il suo impatto critico sulla qualità del rilevamento.
Set di Riferimento Curato: Fornitura di 25 istanze di vulnerabilità reali C/C++ con metadati di ground-truth, correzioni degli sviluppatori e output generati da LLM, insieme al codice del framework CrewAI open-source per la riproducibilità.
Analisi dell'Integrazione degli Strumenti: Investigazione sull'efficacia dell'integrazione dell'analisi statica basata su MCP (CodeQL) nella fase di analisi di un workflow multi-agente.

Risultati

Lo studio riporta le seguenti metriche di prestazione (utilizzando nemotron-cascade-2:30b come modello primario per il confronto):

Accuratezza del Rilevamento:
- Workflow 1 (Senza CodeQL): Ha raggiunto un'accuratezza di rilevamento del 44%, comparabile ai baseline di GPT-5.5.
- Workflow 2 (Con CodeQL): L'accuratezza è scesa al 31%, suggerendo che l'integrazione degli strumenti da sola non garantisce miglioramenti se l'agente non è in grado di interpretare o dare la giusta priorità agli indizi dello strumento.
- Ablazione: La rimozione del Planner ha ridotto l'accuratezza del rilevamento al 25% (senza CodeQL) e al 19% (con CodeQL), sottolineando il ruolo critico del Planner.
Accuratezza della Correzione:
- L'accuratezza complessiva della correzione è stata bassa al 19% per il Workflow 1 e al 13% per il Workflow 2.
- La riparazione si è rivelata significativamente più difficile del rilevamento. Sebbene alcune patch fossero "comparabili" o persino "migliori" della ground truth (particolarmente per CWE-476 e CWE-787), molte contenevano logica non necessaria o introducevano nuovi bug.
Accuratezza del Verifier:
- Il Verifier ha raggiunto un'accuratezza del 69% con nemotron-cascade-2:30b, indicando una capacità di valutazione post-rimedio più forte rispetto alla generazione.
Variabilità CWE: CWE-787 e CWE-476 sono stati i più facili da rilevare, mentre CWE-191 (Integer Underflow) è rimasto il più difficile in tutti i modelli e le impostazioni.

Significato e Rivendicazioni

Il documento posiziona questo lavoro come uno studio esplorativo iniziale piuttosto che un benchmark definitivo. Il suo significato principale risiede in:

Miglioramento dei Processi: Dimostrare che scomporre i compiti di sicurezza in stadi strutturati e basati su ruoli (Pianificazione, Analisi, Riparazione, Verifica) può rendere le attività di sicurezza più ripetibili e trasparenti.
Necessità dell'Umano nel Loop (Human-in-the-Loop): Riaffermare che, nonostante i progressi degli LLM, la qualità disomogenea delle patch generate e l'efficacia mista dell'integrazione degli strumenti rendono necessaria la continua supervisione umana in contesti critici per la sicurezza.
Workflow sopra il Modello: Spostare il focus dalla selezione del "miglior" modello al perfezionamento dell'architettura del workflow sottostante e delle tecniche di integrazione. Gli autori osservano che, sebbene lo screening del modello sia essenziale, il design del workflow è il principale leva di miglioramento.
Sfumatura dell'Integrazione degli Strumenti: Evidenziare che l'integrazione di strumenti come CodeQL richiede un design accurato degli agenti per garantire che gli indizi siano prioritizzati correttamente; aggiungere semplicemente strumenti non aumenta automaticamente le prestazioni.

Gli autori concludono che le architetture agentiche basate su ruoli sono una direzione promettente per il miglioramento dei processi del software sicuro, motivando il lavoro futuro su dataset più ampi, analisi a livello di repository e workflow alternativi raffinati (es. analisi multipli, cicli di raffinamento).