I revisori di Cardano chiedono revisioni continue mentre le bug bounty di Intersect restano senza fondi

La discussione del 28 settembre ha riunito Philip DiSarro di Midgard Labs, Santiago di TxPipe, Aleksandr di Tweag, Ben Hart di MLabs e Leathers. Moderata da Denicio Bute della Cardano Foundation, ha esaminato come l'IA stia cambiando sia la scoperta delle vulnerabilità sia il lavoro necessario per difendere le applicazioni su Cardano.

L'IA divide gli esperti di sicurezza di Cardano

Bute ha aperto chiedendo se i recenti exploit nell'ecosistema Cardano possano aver coinvolto aggressori assistiti dall'IA. DiSarro ha sostenuto che i modelli attuali forniscono ad aggressori esperti strumenti potenti per esaminare il codice e portare avanti exploit complessi. A suo avviso, i team di sviluppo devono testare ripetutamente i propri protocolli man mano che tali strumenti migliorano.

Hart ha contestato l'idea che l'IA possa già svolgere autonomamente il lavoro di un aggressore o revisore esperto. Negli audit in cui ha utilizzato l'IA, sono state comunque le persone a individuare i problemi più significativi. Un essere umano ha riconosciuto la debolezza nelle specifiche di un prodotto e ha ideato un modo per testarla, anche quando un modello ha contribuito a produrre il codice di test.

Leathers ha descritto un limite pratico emerso dalle segnalazioni di vulnerabilità di Intersect. Gli invii sono aumentati notevolmente, ma molti non dimostrano un reale problema di sicurezza. Ha affermato che le segnalazioni più solide in genere provengono ancora da ricercatori con competenze pertinenti. Il panel non ha offerto prove specifiche di casi che attestino l'uso dell'IA negli exploit di Cardano discussi durante la sessione.

I relatori hanno anche respinto l'assunzione secondo cui il modello UTxO esteso di Cardano renderebbe difficili da analizzare le sue applicazioni per gli strumenti di IA, poiché tali strumenti hanno maggiore familiarità con il codice EVM. Leathers ha richiamato la documentazione disponibile per Cardano e Plutus. L'architettura di Cardano impedisce alcune classi di attacchi agli smart contract, ma un'applicazione può comunque contenere difetti nella propria logica o nei sistemi circostanti.

Gli audit su Cardano vanno oltre gli smart contract

La discussione si è spostata dal codice del contratto all'intero percorso con cui un'applicazione gestisce i fondi degli utenti. Server, librerie software, connessioni ai wallet, dispositivi di firma e chiavi amministrative possono tutti influenzare l'esito di una transazione. Un validatore on-chain sicuro non può proteggere gli utenti da ogni guasto in tali componenti.

Hart ha affermato che il codice generato dall'IA ha reso le specifiche più importanti. Se un team di sviluppo non riesce a descrivere con precisione ciò che il proprio prodotto dovrebbe consentire e vietare, un revisore non ha uno standard affidabile con cui verificare l'implementazione. Santiago ha aggiunto che i team devono definire il proprio modello di minaccia e decidere quanta flessibilità o possibilità di aggiornamento desiderano, poiché tali scelte possono introdurre ulteriori modalità di modificare un sistema.

Questo lavoro conferisce a test e verifica formale uno scopo concreto, controllare se l'applicazione preserva le regole dichiarate. DiSarro ha sostenuto che i team dovrebbero spingersi oltre tentando attacchi controllati contro i propri protocolli. Le revisioni devono inoltre seguire cambiamenti significativi al codice, all'infrastruttura e alle procedure operative, anziché fare affidamento indefinitamente su un audit completato prima del lancio.

Le società di auditing hanno descritto l'IA come parte di quel processo. I modelli possono cercare schemi, confrontare il codice con le specifiche e suggerire potenziali percorsi di attacco. Santiago ha affermato che il suo team verifica i riscontri automatizzati tramite revisione umana, il panel ha anche discusso l'uso di più di un modello perché strumenti diversi possono far emergere problemi differenti. I falsi positivi consumano comunque tempo di revisione, mentre la sensibilità del codice e i requisiti di calcolo influiscono sulla scelta tra un modello ospitato o eseguito localmente.

Il programma di bug bounty di Intersect deve far fronte a una carenza di fondi

Leathers ha quindi individuato un problema distinto per la divulgazione coordinata delle vulnerabilità. Ha affermato che il finanziamento delle bug bounty non è stato approvato nell'attuale ciclo di tesoreria. I ricercatori possono ancora inviare segnalazioni e il Security Council continua a esaminarle, ma al momento non può pagare nuove ricompense attraverso quella via di finanziamento. Ha detto che il consiglio sta lavorando con Intersect a delle alternative e che un prelievo dalla tesoreria approvato dalla comunità potrebbe fornire i fondi.

Intersect ha lanciato il suo programma di bug bounty nel 2025 per l'infrastruttura e gli strumenti che gestisce o sponsorizza. Gli smart contract rientrano nel suo ambito solo quando esplicitamente inclusi. Le osservazioni di Leathers riguardavano quel programma, la Cardano Foundation gestisce un accordo di bounty separato.

Un volume maggiore di segnalazioni generate dall'IA aumenta anche il costo della revisione degli invii. Leathers ha invocato un triage più rigoroso, così che le vulnerabilità riproducibili ricevano attenzione mentre i riscontri errati e i problemi di manutenzione ordinaria vengano classificati in modo appropriato. DiSarro ha inoltre esortato i singoli protocolli e bridge DeFi a stabilire proprie ricompense e procedure di gestione degli incidenti prima che si verifichi un exploit.

La tavola rotonda ha lasciato Intersect con una chiara questione di governance. Il suo canale di divulgazione rimane aperto e il Security Council sta ancora valutando le segnalazioni. Il finanziamento per le ricompense ai ricercatori dipende ora da un nuovo accordo o da una decisione della tesoreria. Tale decisione determinerà se una scoperta valida nell'ambito del programma di Intersect potrà nuovamente portare al pagamento che il programma è stato progettato per offrire.