OSS-CRS: Liberating AIxCC Cyber Reasoning Systems for Real-World Open-Source Security

Il paper presenta OSS-CRS, un framework open-source e localmente deployabile che libera i sistemi di ragionamento cibernetico (CRS) dall'infrastruttura cloud originale del DARPA AIxCC, permettendo loro di essere riutilizzati per scoprire e correggere autonomamente vulnerabilità in progetti open-source reali, come dimostrato dal successo nel trovare 10 nuovi bug tramite il porting del sistema vincitore Atlantis.

L'essenziale

Immagina di avere un esercito di super-eroi robot (chiamati "Sistemi di Ragionamento Cyber" o CRS) che sono stati addestrati in un campo di battaglia virtuale per trovare buchi di sicurezza nei software e ripararli da soli. Questi robot hanno vinto una grande competizione organizzata dal governo americano (DARPA), dimostrando di poter non solo trovare i bug, ma anche inventare le toppe per sistemarli.

Il problema? Quando la competizione è finita, questi robot sono rimasti intrappolati nel loro campo di battaglia. Erano costruiti su una tecnologia specifica (il cloud di Microsoft Azure) che è stata smantellata. Se provavi a portarli fuori per usarli su software reali (come quelli che usiamo tutti i giorni), non funzionavano. Erano come macchine da Formula 1 costruite per una pista specifica: bellissime, veloci, ma inutili se provi a guidarle su una strada sterrata.

Ecco cosa fa questo paper, OSS-CRS, spiegato in modo semplice:

1. Il Problema: Robot bloccati in una gabbia

Gli scienziati hanno scoperto che tutti e 7 i robot vincenti avevano tre grossi difetti:

• Duplicazione inutile: Ogni squadra aveva costruito la propria "scuderia" (server, database, sistemi di gestione) da zero, invece di usare una base comune.
• Blocco nel Cloud: Erano programmati per funzionare solo su un tipo di computer remoto che non esiste più.
• Design "Monolitico": Erano come un blocco unico di cemento. Se volevi prendere il "motore" (la parte che trova i bug) del robot A e il "braccio" (la parte che ripara i bug) del robot B, non potevi farlo. Erano fusi insieme.

2. La Soluzione: OSS-CRS, il "Trasformatore"

Gli autori del paper hanno creato OSS-CRS. Immagina OSS-CRS come un grande garage universale e un manuale di istruzioni.

• Il Garage (Infrastruttura): Invece di far costruire a ogni squadra il proprio garage, OSS-CRS fornisce un unico garage moderno. Qui, ogni robot può essere parcheggiato, alimentato e controllato.
• Il Traduttore (Interfaccia): OSS-CRS parla una lingua universale. Se un robot sa parlare solo "Azure", OSS-CRS fa da traduttore, permettendogli di funzionare sul tuo computer personale o su qualsiasi server, senza bisogno di quel vecchio cloud.
• Il Mercato degli Scambi (Artifacts): OSS-CRS crea una piazza dove i robot possono scambiarsi le "prove" (i bug trovati) e le "toppe" (le riparazioni). Se il Robot A trova un bug, lo lascia nella piazza. Il Robot B, che è bravo a riparare, lo prende e lo sistema. Non devono parlarsi direttamente, basta che lascino i messaggi in un cassetto comune.

3. La Gestione del Budget (Il "Portafoglio")

Usare l'Intelligenza Artificiale costa soldi (ogni volta che il robot "pensa" e chiede aiuto a un modello AI, si consumano crediti).
OSS-CRS agisce come un tesoriere severo. Assegna a ogni robot un budget preciso (ad esempio, 50 dollari). Se un robot sta spendendo troppo o non sta lavorando bene, il tesoriere lo ferma. Questo permette di confrontare i robot in modo equo: chi risolve più problemi spendendo meno?

4. La Prova sul Campo: I Robot in Azione

Per dimostrare che funziona, gli autori hanno preso il robot più forte della competizione (chiamato ATLANTIS) e lo hanno "trasformato" per funzionare nel nuovo garage OSS-CRS.
Hanno mandato questo robot a controllare 8 progetti software open-source reali (come librerie per internet o database).
Il risultato? Il robot ha trovato 10 nuovi bug che nessuno conosceva (alcuni molto pericolosi) e ha creato le toppe per ripararli. Tutto questo senza usare il vecchio cloud, ma girando su un computer normale.

In Sintesi

Prima, questi robot erano come giochi da tavolo chiusi in scatole diverse: non potevi mischiare i pezzi di un gioco con quelli di un altro, e se perdevi la scatola, perdevi il gioco.

OSS-CRS ha aperto tutte le scatole, ha messo i pezzi su un unico grande tavolo, ha creato regole comuni per giocare e ha dimostrato che, mescolando i pezzi migliori, si può costruire un sistema che protegge davvero il software che usiamo ogni giorno.

È un passo fondamentale per trasformare l'IA da un "gioco da competizione" a un strumento pratico che chiunque può usare per rendere internet più sicuro.

Sommario tecnico

1. Il Problema: Il Divario tra Competizione e Reale Utilizzo

Il paper affronta una sfida critica emersa dopo la DARPA AI Cyber Challenge (AIxCC): sebbene sette team abbiano sviluppato Sistemi di Ragionamento Cyber (CRS) autonomi capaci di scoprire, confermare e correggere vulnerabilità software, questi sistemi rimangono inutilizzabili al di fuori dei loro team originali.

Le barriere principali all'adozione pratica sono state identificate come:

1. Duplicazione dell'infrastruttura: Ogni team ha ricostruito indipendentemente servizi di piattaforma simili (orchestrazione container, middleware di messaggistica, gateway LLM), creando un enorme spreco di risorse e sforzo di integrazione.
2. Lock-in Cloud: Tutti i sistemi erano strettamente legati all'infrastruttura Azure e Kubernetes fornita durante la competizione, che è stata successivamente dismessa. Ad esempio, il sistema vincitore (ATLANTIS) richiedeva oltre 20 VM Azure e non poteva essere eseguito localmente senza un ambiente cloud specifico.
3. Design Monolitico: Le tecniche di analisi erano incorporate in sistemi monolitici senza interfacce modulari, impedendo ai ricercatori di confrontare, combinare o riutilizzare singoli componenti (es. un fuzzing migliore di un team con un patcher migliore di un altro).

Di conseguenza, i ricercatori non possono eseguire esperimenti comparativi, e gli sviluppatori di sicurezza non possono adottare flussi di lavoro autonomi, budget-consapevoli e pronti per la produzione.

2. Metodologia: Il Framework OSS-CRS

Per superare queste barriere, gli autori presentano OSS-CRS, un framework open-source, localmente deployabile, progettato per eseguire e combinare tecniche CRS su progetti open-source reali.

Architettura e Componenti Chiave

• Modello di Esecuzione Unificato (Fasi): OSS-CRS introduce un ciclo di vita a tre fasi per separare la configurazione del CRS dalla compilazione del target:
  1. Prepare: Costruisce le immagini container del CRS (indipendenti dal target).
  2. Build-Target: Compila il progetto target specifico (usando lo standard OSS-Fuzz).
  3. Run: Esegue i container CRS in isolamento.
• Interfaccia Standardizzata (libCRS): Una libreria Python iniettata in ogni container CRS che fornisce API per la gestione degli artefatti (PoV, patch, seed), la validazione delle patch e l'interazione con l'infrastruttura, eliminando la necessità di API proprietarie.
• Gestione delle Risorse e Isolamento:
  • Esecuzione in container Docker isolati con limiti di CPU e memoria definiti.
  • Budget LLM: Gestione dei costi delle API LLM come risorsa di primo piano. Ogni CRS riceve un budget specifico (es. in dollari) e un proxy (basato su LiteLLM) che rifiuta le richieste una volta esaurito il budget, prevenendo sprechi finanziari.
  • Isolamento di rete: Ogni CRS ha la propria rete Docker; la comunicazione avviene solo tramite scambio di file su disco condiviso, non tramite messaggi diretti.
• Scambio di Artefatti Cross-CRS: Un "Exchange Sidecar" sincronizza gli artefatti (seed, Proof of Vulnerability, patch) tra diversi CRS in esecuzione simultaneamente, permettendo un'esecuzione "ensemble" senza che i sistemi debbano comunicare direttamente.

Integrazione

Il framework utilizza il formato OSS-Fuzz come interfaccia target, permettendo di analizzare oltre 1.000 progetti open-source senza configurazioni specifiche per progetto. Gli autori hanno integrato cinque CRS, inclusi tre sottosistemi portati da ATLANTIS (il sistema vincitore di AIxCC) e un nuovo sistema di generazione patch basato su LLM chiamato CLAUDECODE.

3. Risultati Sperimentali

Per validare il framework, gli autori hanno portato ATLANTIS su OSS-CRS e lo hanno eseguito contro 8 progetti OSS-Fuzz (C/C++ e Java) su una singola macchina locale (32 CPU, 128 GB RAM) con un budget LLM di 50$ per campagna.

• Scoperta di Vulnerabilità: Sono state scoperte 10 vulnerabilità precedentemente sconosciute (zero-day).
  • 3 sono state classificate come ad alta severità.
  • La maggior parte sono bug di sicurezza della memoria in C, ma sono stati trovati anche bug logici e errori di comportamento indefinito.
  • A differenza dei semplici fuzzing, il sistema ha identificato problemi di validazione dello schema e conversioni numeriche.
• Stato delle Patch: Al momento della pubblicazione, 3 vulnerabilità sono state corrette dai maintainer upstream, 1 è confermata, e 6 sono in attesa di revisione.
• Validazione delle Patch: Il sistema ha generato automaticamente patch candidate che sono state validate ri-eseguendo i test di regressione e confermando che il PoV non si attivava più.
• Efficienza del Porting: L'adattamento di ATLANTIS ha richiesto circa 3-4 giorni-persona per sottosistema, dimostrando che la logica di analisi centrale può essere decouplata dall'infrastruttura cloud originale con modifiche minime (principalmente configurazione e I/O).

4. Contributi Chiave

1. Analisi Empirica: Identificazione sistematica delle tre barriere (duplicazione infrastrutturale, lock-in cloud, design monolitico) che impediscono l'adozione dei CRS di AIxCC.
2. OSS-CRS Framework: Un'infrastruttura open-source che fornisce un modello di esecuzione unificato, gestione delle risorse (CPU, memoria, budget LLM) e scambio di artefatti, permettendo l'esecuzione locale e composita di CRS.
3. Validazione nel Mondo Reale: Dimostrazione che le tecniche di livello competizione possono essere eseguite su infrastrutture locali semplici, scoprendo bug reali e generando patch valide senza dipendere da cloud provider specifici.
4. Disponibilità Pubblica: Tutto il codice, i CRS integrati e gli artefatti di valutazione sono open-source, promuovendo la ricerca riproducibile.

5. Significato e Impatto

Il lavoro di OSS-CRS rappresenta un passo fondamentale per trasformare i sistemi di sicurezza autonoma da "esperimenti di laboratorio" a strumenti pratici per la sicurezza open-source.

• Democratizzazione della Sicurezza: Rimuove la barriera dell'infrastruttura cloud costosa, permettendo a ricercatori e praticanti di eseguire CRS avanzati localmente.
• Riproducibilità e Confronto: Fornisce un terreno di prova comune per confrontare tecniche diverse (fuzzing, analisi statica, ragionamento LLM) in condizioni controllate, facilitando la ricerca su quali combinazioni siano più efficaci.
• Sicurezza Proattiva: Dimostra che è possibile automatizzare l'intero ciclo di vita della vulnerabilità (scoperta -> conferma -> patch), riducendo il carico sui maintainer open-source che spesso vengono sopraffatti da report non verificati generati dall'AI.
• Sostenibilità Economica: La gestione del budget LLM integrata nel framework è cruciale per rendere sostenibile l'uso di modelli linguistici su larga scala nella sicurezza informatica.

In sintesi, OSS-CRS non è solo un tool, ma un'infrastruttura abilitante che permette alla comunità di costruire, combinare e valutare sistemi di ragionamento cyber autonomi per proteggere il software open-source reale.