Program Analysis Guided LLM Agent for Proof-of-Concept Generation

1. Il Problema

La generazione automatica di un Proof-of-Concept (PoC) per le vulnerabilità software è una sfida critica nella sicurezza informatica. Quando viene scoperta una vulnerabilità, gli sviluppatori devono spesso riprodurla in modo affidabile per confermarne l'esistenza, analizzare l'impatto e sviluppare patch.
Attualmente, questo processo presenta diverse difficoltà:

• Mancanza di PoC: Molti report di vulnerabilità non includono un PoC valido, costringendo gli sviluppatori a un lavoro manuale e dispendioso in termini di tempo.
• Limiti delle tecniche tradizionali:
  • L'analisi statica è scalabile ma soggetta a molti falsi positivi e non genera automaticamente input di attacco.
  • L'esecuzione simbolica può generare PoC ma soffre del problema dell'esplosione dei percorsi e richiede spesso guida manuale.
  • Il fuzzing automatizzato richiede harness, grammatiche e semi di alta qualità, oltre a una significativa esperienza umana.
• Limiti degli Agenti LLM: Sebbene i Large Language Models (LLM) offrano potenziale per l'automazione, gli agenti basati su LLM tendono a "allucinare" (generare informazioni errate) e falliscono frequentemente nel generare PoC precisi senza una guida contestuale specifica, specialmente quando devono inferire vincoli di input complessi per raggiungere un punto vulnerabile specifico nel codice.

2. Metodologia: PAGENT

Il paper propone PAGENT (Program Analysis Guided proof of concept generation agENT), un approccio ibrido che integra analisi statica, analisi dinamica e un agente LLM in un ciclo iterativo. L'obiettivo è generare un input PoC funzionale dato il codice sorgente e una specifica posizione del codice vulnerabile.

Il framework si compone di tre fasi principali:

A. Analisi Statica Guidata (Static Analysis Guidance)

Questa fase ha lo scopo di fornire all'agente LLM informazioni precise e scalabili sul codice, riducendo l'ambiguità.

1. Analisi Statica Leggera: Viene costruita una reachability graph (grafo di raggiungibilità) partendo dagli entrypoint (es. main, LLVMFuzzerTestOneInput). Utilizza la risoluzione delle chiamate indirette (tramite analisi delle firme delle funzioni) per filtrare il codice irraggiungibile, garantendo scalabilità su grandi codebase.
2. Analisi Statica Basata su Regole: Utilizza un motore di analisi basato su regole (implementato in Datalog tramite lo strumento cclyzerpp su LLVM-IR) per identificare pattern di vulnerabilità specifici (es. overflow di buffer, divisione per zero).
   • Produce un Vulnerability Report che include: tipo di vulnerabilità, funzione vulnerabile, percorso di "taint" (taint path), entrypoint e un template di asserzione che descrive la violazione.
   • Questo report serve come "grounding" semantico per l'agente, evitando che debba indovinare la struttura del codice.

B. Agente di Generazione PoC (PoC Generation Agent)

L'agente (basato sull'architettura CodeAct e implementato con OpenHands) riceve il report di vulnerabilità e il codice sorgente.

• Fase di Preparazione: L'agente riceve istruzioni contestuali che includono il report statico e le istruzioni per il test.
• Ciclo Iterativo: L'agente genera un candidato PoC (un file di input binario o testuale). A differenza dei metodi puramente testuali, l'agente può interagire con l'ambiente di test, scrivere script e modificare il codice per costruire l'exploit.

C. Analisi Dinamica Guidata (Dynamic Analysis Guidance)

Questa fase valida il candidato PoC e fornisce feedback all'agente.

1. Esecuzione Strumentata: Il PoC candidato viene eseguito su una versione del programma compilata con sanitizer (es. AddressSanitizer, MemorySanitizer) per rilevare crash o comportamenti indefiniti.
2. Feedback Dinamico:
   • Se il PoC causa un crash (exit code non zero), il processo è completato con successo.
   • Se non causa un crash, l'agente riceve un report dettagliato che include: copertura del codice (linee, rami, regioni), tempo di esecuzione e punto di ingresso dell'esecuzione.
3. Raffinamento: L'agente utilizza questi dati di copertura per capire dove il suo input ha fallito (es. "ho raggiunto solo il 10% della funzione target") e ricalibra il PoC per coprire più percorsi e raggiungere la posizione vulnerabile identificata dall'analisi statica.

3. Contributi Chiave

• Integrazione Ibrida: PAGENT è il primo sistema che combina in modo stretto l'analisi di programma (statica e dinamica) con un agente LLM iterativo per la generazione di PoC.
• Guida Statica Scalabile: L'uso di analisi statica basata su regole a livello LLVM-IR fornisce all'agente vincoli precisi, riducendo drasticamente le allucinazioni.
• Feedback Dinamico per il Raffinamento: L'uso di metriche di copertura (branch/line coverage) come feedback per l'agente permette di correggere errori di analisi semantica in tempo reale.
• Efficienza dei Costi: Il sistema dimostra che modelli open-source più economici (come DeepSeek) possono superare modelli proprietari costosi se adeguatamente guidati dall'analisi di programma.

4. Risultati Sperimentali

Gli esperimenti sono stati condotti su un dataset di 203 vulnerabilità reali (da 10 progetti open-source come GNU Binutils, libredwg, ecc.) tratti dal dataset Cybergym/ARVO.

• Performance Superiore: PAGENT ha superato l'approccio agentiche migliore precedente (basato su GPT-5 e Sonnet-4) del 132% in termini di successo nella generazione di PoC.
• Modelli Open-Source vs Proprietari:
  • Utilizzando il modello DeepSeek-3.1 (considerato uno dei peggiori performer nel benchmark Cybergym senza guida), PAGENT ha raggiunto un'accuratezza del 42%, superando sia Sonnet-4 che GPT-5.
  • Con DeepSeek-3.2, l'accuratezza è salita al 64.6%, superando significativamente i modelli proprietari più potenti.
• Costo: L'approccio con DeepSeek è stato 32 volte più economico (0.42$ vs 14$ per milione di token) rispetto all'uso di modelli chiusi come GPT-5.
• Vulnerabilità Post-Patch: PAGENT ha identificato 32 vulnerabilità che si manifestavano anche nelle versioni del codice già patchate, dimostrando la capacità di trovare difetti nascosti o patch incomplete che gli altri agenti non rilevavano (4 volte più degli altri baseline).
• Ablation Study: Lo studio ha confermato che sia l'analisi statica che quella dinamica sono essenziali; la rimozione di una delle due fasi riduce drasticamente il successo (fino al 42% in meno senza analisi dinamica).

5. Significato e Impatto

Il lavoro di PAGENT segna un passo avanti significativo nell'automazione della sicurezza software:

1. Democratizzazione dell'Analisi: Dimostra che non è necessario utilizzare modelli LLM proprietari costosi e complessi per compiti di sicurezza avanzati; modelli open-source, se combinati con strumenti di analisi di programma tradizionali, possono raggiungere prestazioni superiori.
2. Riduzione del Carico Umano: Automatizza la fase critica di riproduzione delle vulnerabilità, accelerando il triage e la correzione delle falle di sicurezza.
3. Integrazione CI/CD: La metodologia è progettata per essere integrata nelle pipeline di sviluppo continuo, permettendo di rilevare e provare le vulnerabilità immediatamente dopo ogni commit di codice.
4. Nuovo Paradigma: Sposta l'attenzione dal semplice "prompt engineering" verso un'architettura in cui l'agente LLM agisce come un "motore di ragionamento" guidato da dati oggettivi forniti dall'analisi del codice, riducendo l'incertezza intrinseca dei modelli linguistici.

In sintesi, PAGENT risolve il problema della "mancanza di precisione" degli agenti LLM nella generazione di exploit, fornendo loro una mappa precisa (analisi statica) e una bussola di navigazione (analisi dinamica) per raggiungere l'obiettivo di sicurezza.