Giovanni Vignone, CEO e Fondatore di Octane Security – Serie di Interviste

Giovanni Vignone, CEO e Fondatore di Octane Security, ha lanciato l’azienda nel 2022 per affrontare la crescente necessità di cybersecurity proattiva nel Web3. Con soli 22 anni, ha iniziato a costruire una piattaforma alimentata da AI che funziona come un ingegnere della sicurezza 24/7—analizzando in tempo reale i codebase dei contratti intelligenti, integrandosi direttamente nei pipeline CI/CD e rilevando vulnerabilità che gli audit tradizionali spesso non individuano.

In questa conversazione, esploriamo la missione di Octane di integrare il rilevamento continuo e spiegabile delle vulnerabilità nel ciclo di vita dello sviluppo software—e cosa serve per proteggere il futuro dei smart contracts.

Cosa ha ispirato la decisione di lasciare Duke e costruire Octane a tempo pieno? C’è stato un momento particolare che ha chiarito l’opportunità?

Durante il mio terzo anno a Duke, ho ottenuto l’accesso beta anticipato alla piattaforma di OpenAI e ho iniziato a sperimentare con grandi modelli linguistici sui contratti intelligenti nel crypto. I risultati mi hanno davvero aperto gli occhi su ciò che era possibile.

C’è stato un momento specifico che spicca. Ho inserito un contratto intelligente nell’interfaccia chat e gli ho chiesto di trovare eventuali problemi. I risultati necessitavano di lavoro, ma ho potuto vedere immediatamente l’enorme potenziale dell’uso di LLM per individuare vulnerabilità difficili da trovare. Questo è avvenuto nel marzo 2023.

Questo è accaduto nello stesso periodo in cui vedevo tutti questi hack e exploit diffondersi nell’industria. Ho capito che c’era un bisogno urgente di risolvere questi problemi di sicurezza, e questi modelli ci hanno offerto un modo unico per affrontarli. È stato chiaro che era il momento giusto per puntare tutto su Octane.

Quali sono state alcune delle più grandi sfide tecniche o operative nel portare Octane dal concetto all’adozione da parte delle principali aziende crypto?

La più grande sfida tecnica è stata capire come identificare le vulnerabilità e mostrarle agli utenti in modo che potessero effettivamente usarle. È stato davvero difficile perché le vulnerabilità non sono in bianco e nero – hanno molteplici dimensioni.

Quando esaminiamo una potenziale vulnerabilità, dobbiamo considerare diverse cose: qual è l’impatto (qualcuno potrebbe perdere denaro o stato importante?), quanto è facile da sfruttare, cosa si può fare per correggerla e qual è la causa del problema. Gestire tutti questi aspetti contemporaneamente e presentarli in modo chiaro ha richiesto molto lavoro.

Abbiamo dedicato enormi sforzi a trasformare in prodotto ciascuno di questi componenti affinché i clienti potessero usare Octane per trovare vulnerabilità, comprendere rapidamente la loro gravità e iniziare a correggerle subito. Costruire sistemi in grado di individuare costantemente questi problemi su diversi codebase ha richiesto sia competenze tecniche sia una grande quantità di dati su tutti i tipi di vulnerabilità.

Octane mira a funzionare come un ingegnere della sicurezza AI integrato in ogni team di sviluppo. Quali traguardi sono necessari per realizzare pienamente questo obiettivo nell’intera industria?

Il nostro primo grande traguardo è cambiare il modo in cui gli sviluppatori pensano alla sicurezza – farli integrarla fin dal primo giorno invece di aggiungerla poche settimane prima del lancio. Questo significa dimostrare loro che partire con la sicurezza in realtà fa risparmiare tempo, permettendo di correggere i problemi prima.

Dobbiamo anche aiutare gli utenti a vedere e comprendere cosa succede quando individuano le vulnerabilità in anticipo, così da poter sperimentare i benefici direttamente.

Dal punto di vista del prodotto, dobbiamo supportare più linguaggi oltre a Solidity – altri linguaggi per contratti intelligenti e, in futuro, anche linguaggi di programmazione tradizionali. Lavoriamo costantemente per migliorare i nostri modelli in termini di precisione e per rilevare più tipologie di vulnerabilità.

Come evolverà la piattaforma per affrontare minacce complesse non basate sul codice, come phishing o exploit basati su malware?

In realtà gestiamo già alcune di queste minacce oggi. Segnalamo i rischi di centralizzazione, aiutando i team a sapere quali chiavi private e ruoli sono particolarmente sensibili.

Rileviamo anche i pattern di phishing comuni nei contratti intelligenti, come quando qualcuno utilizza tx.origin per la logica di verifica del chiamante, che può portare ad attacchi di phishing. Ci assicuriamo di evidenziare questi aspetti agli utenti.

Attualmente, Octane funziona principalmente come uno strumento di sicurezza pre-distribuzione, piuttosto che come qualcosa che rileva le minacce in tempo reale. Il nostro piano è continuare ad ampliare ciò che possiamo rilevare prima che il codice venga messo in produzione, fornendo agli sviluppatori gli strumenti per correggere i potenziali problemi prima che diventino attacchi reali.

Cosa rende l’apprendimento automatico non supervisionato – in particolare il clustering – un approccio più efficace per classificare le vulnerabilità dei contratti intelligenti rispetto ai tradizionali sistemi basati su regole?

L’apprendimento automatico non supervisionato ci ha davvero aiutato a mappare i tipi di bug presenti. Sebbene continuiamo a utilizzare tecniche basate su regole per costruire i nostri modelli supervisionati, l’apprendimento non supervisionato, in particolare il clustering, ci aiuta a capire quali modelli dovremmo costruire e come priorizzarli.

Questo approccio ci consente di suddividere i nostri modelli in pipeline di analisi più specializzate per diversi tipi di vulnerabilità.

Utilizziamo effettivamente sia l’ML supervisionato che quello non supervisionato insieme – l’apprendimento non supervisionato per comprendere il panorama e i metodi supervisionati per costruire capacità di rilevamento precise. Questa combinazione funziona meglio rispetto al semplice affidamento ai tradizionali sistemi basati su regole.

Puoi condividere un esempio in cui il clustering ha evidenziato una nuova classe di vulnerabilità non riconosciuta in precedenza negli audit o nelle revisioni di sicurezza?

Il clustering non crea realmente nuove categorie di vulnerabilità da zero – prende i dati esistenti e li raggruppa in modi significativi. I nostri dati provengono da exploit on-chain del mondo reale, report di vulnerabilità pubblici e altre fonti di bug nei contratti intelligenti.

Ciò che l’apprendimento non supervisionato fa davvero bene è aiutarci a perfezionare la comprensione delle categorie di vulnerabilità esistenti. Individua pattern e connessioni tra diverse vulnerabilità che altrimenti potrebbero passare inosservate, permettendoci di costruire metodi di rilevamento migliori.

Attraverso questo riconoscimento di pattern e raggruppamento dei dati, abbiamo creato modelli più sfumati che possono rilevare variazioni sottili dei tipi di vulnerabilità conosciuti, piuttosto che scoprire classi completamente nuove di vulnerabilità.

Come gestisce Octane i casi limite in cui una vulnerabilità non rientra chiaramente nelle categorie esistenti della tassonomia?

Cerchiamo di bilanciare quanto specifica o generale sia la nostra tassonomia. Più generiche sono le nostre categorie e modelli, più facilmente possiamo catturare casi limite strani che non si adattano perfettamente a nessuna categoria. Tuttavia, categorie più specifiche forniscono agli utenti spiegazioni migliori e ci permettono di rilevare i tipi di bug noti in modo più coerente.

Quando incontriamo vulnerabilità che Octane non rileva o che non corrispondono chiaramente alle nostre categorie esistenti, valutiamo se aggiungere più dati su quella vulnerabilità a un modello esistente, o se è necessario creare un modello completamente nuovo per rilevare quel tipo di bug in futuro.

Questo approccio flessibile ci consente di migliorare continuamente le nostre capacità di rilevamento mantenendo una struttura che abbia senso per gli utenti.

Dopo aver analizzato migliaia di bug, quali pattern ricorrenti o cause radice si sono distinti nelle vulnerabilità dei contratti intelligenti?

Abbiamo osservato diversi pattern difficili ripresentarsi più volte. La reentrancy è ancora un problema importante nei contratti intelligenti. Un’altra grande categoria deriva dal fatto che le transazioni sono pubblicamente visibili nel mempool, creando vulnerabilità in cui gli aggressori possono vedere le transazioni in sospeso e rubare informazioni o far fallire le transazioni – quello che la gente chiama front-running, anche se avviene in molti modi diversi.

Abbiamo anche riscontrato molte vulnerabilità critiche derivanti da semplici errori dei sviluppatori. In passato venivano chiamate genericamente “errori di logica”, ma è troppo vago. Un errore comune che vediamo è che gli sviluppatori dimenticano di aggiornare le variabili di stato in alcuni percorsi di codice dove è davvero necessario.

Questi sono solo alcuni esempi – disponiamo di una suddivisione privata molto più dettagliata di tutti i bug che abbiamo sviluppato attraverso i nostri sforzi di analisi dei dati.

I contratti intelligenti variano notevolmente tra ecosistemi e linguaggi. Come fa Octane a garantire che i suoi modelli rimangano efficaci in questi ambienti diversi?

Molte vulnerabilità seguono pattern comuni indipendentemente dal linguaggio o ecosistema specifico. Questo ci consente di costruire modelli che possono individuare efficacemente queste vulnerabilità su diversi codebase.

Progettiamo i nostri modelli per concentrarci sui principi di sicurezza di base che si applicano in modo ampio ai sistemi di contratti intelligenti, tenendo conto delle caratteristiche specifiche dei diversi linguaggi. Questo approccio ci aiuta a rimanere efficaci in vari ambienti senza dover ricostruire tutto per ogni nuovo linguaggio.

Concentrandoci sui pattern fondamentali delle vulnerabilità anziché sui dettagli superficiali, abbiamo costruito modelli che possono adattarsi al variegato mondo dello sviluppo di contratti intelligenti.

Gli strumenti di sicurezza basati su AI spesso incontrano scetticismo riguardo alla spiegabilità. Come fa Octane a garantire che le classificazioni delle vulnerabilità e gli avvisi siano azionabili per gli sviluppatori?

Abbiamo dedicato molto lavoro al nostro processo di validazione back-end per verificare le vulnerabilità tramite controlli aggiuntivi.

Ordiniamo attentamente i nostri risultati per separare le vulnerabilità critiche (che potrebbero effettivamente impattare il codebase) da problemi meno gravi o avvisi che rappresentano le migliori pratiche. Questa categorizzazione aiuta gli sviluppatori a concentrarsi su ciò che conta di più.

La nostra UI è progettata per essere semplice e chiara, evidenziando i problemi più gravi in modo che ricevano attenzione immediata anziché essere sepolti tra una serie di avvisi meno importanti. Fornendo spiegazioni chiare e concentrandoci su ciò che è azionabile, ci assicuriamo che gli sviluppatori possano comprendere rapidamente e correggere le vulnerabilità che troviamo.

Grazie per la fantastica intervista, i lettori che desiderano saperne di più dovrebbero visitare Octane Security.