All'inizio di questo mese ci siamo aggiudicati una bug bounty da 2,5 milioni di dollari—la più grande bounty mai ricevuta da un agente AI. Era un bug in una delle principali blockchain, che metteva a rischio fondi per oltre 100 milioni di dollari. Abbiamo trovato il bug in modo completamente autonomo usando V12, il nostro agente di sicurezza AI, e abbiamo collaborato con il team per risolvere il problema.
V12 non è un generico strumento di sicurezza agentico. Trova regolarmente bug critici come questo, tra innumerevoli 0day (incluse LPE Linux, QEMU escape, UXSS di Firefox, RCE bidirezionali su Postgres e Redis). Questo perché, mentre stiamo costruendo un prodotto, la nostra missione principale è ricercare e costruire strumenti di sicurezza offensiva pericolosamente potenti. Per rendere possibile tutto questo, abbiamo raccolto un seed round da 10 milioni di dollari guidato da Electric Capital, con la partecipazione di ZachXBT, samczsun, Walden Yan e altri.
Ti invitiamo a provare V12 di persona. È self-service: se ti registri nei prossimi sette giorni, riceverai 200 dollari di utilizzo gratuito.
Parte 1: Cosa stiamo facendo
Il nostro obiettivo è costruire una cyber nuke. Significa costruire qualcosa in grado di trovare tutti i bug di un sistema. La cosa è particolarmente interessante perché una capacità del genere permetterebbe di sfruttare software considerati sicuri fino a oggi. Finora non era stato possibile, ma l'AI di frontiera cambia le cose.
Non facciamo pentesting. Il pentesting black-box che simula un attaccante esterno non ci interessa. È un mercato saturo, e non vogliamo creare un altro prodotto che lancia payload XSS. Un pentest agentico è ottimo per trovare alcuni bug, ma quello che vogliamo noi è qualcosa che trovi tutti i bug. E questo non è possibile senza leggere e comprendere il codice. Dobbiamo concentrarci sull'audit del codice white box, che assomiglia molto di più alla vulnerability research.
meme credit: LiveOverflow
Più concretamente, parliamo di un sistema in grado di ragionare sul codice e su tutte le astrazioni sottostanti, creandone persino di nuove (ad esempio le weird machines). Vogliamo un sistema che non si limiti a trovare bug, ma che possa inventare classi di bug completamente nuove. Detto questo, è anche l'area della sicurezza che ha opposto la maggiore resistenza all'automazione. Gran parte della vulnerability research consiste nel ragionare con attenzione sul codice e dimostrare a sé stessi "no, qui non può esserci un bug", o in alternativa chiedersi "aspetta, e se...?". Tutto questo richiede un'intelligenza a livello umano, che fino a oggi non era stato possibile scalare.
In breve: vogliamo un sistema AI che prenda in input una codebase arbitrariamente grande e complessa, ragioni su come funziona davvero e usi quella comprensione per inventare—non solo scoprire—bug ed exploit.
Ovviamente, un sistema che trovi davvero tutti i bug non è realmente possibile: è il problema dell'arresto sotto mentite spoglie. Equivale a dimostrare che qualcosa non ha bug, dove gli exploit sono i controesempi. Si possono creare programmi arbitrariamente difficili da sfruttare. Per esempio, un programma vulnerabile se la congettura di Collatz è falsa. Ma intendiamo spingere i limiti e costruire l'approssimazione più vicina che sia praticamente possibile.
E nessuno a guidarci
Supponiamo di costruire davvero la cyber nuke. E poi?
Di fronte a un'esplosione delle capacità offensive, il mondo cambierà drasticamente. Tuttavia, è irrealistico aspettarsi che gli sviluppatori—soprattutto le aziende—si adattino improvvisamente da soli. Le organizzazioni mature non hanno la visione né le competenze per fare davvero il salto. Hanno bisogno di soluzioni, prodotti funzionanti e ben progettati, non solo di "sacchi di strumenti".
Riguardo alla capacità di adattamento delle organizzazioni: è facile indicare i nuovi modelli all'avanguardia e dichiarare che il cyber è un problema risolto. Ben diverso è per gli sviluppatori sfruttare davvero i modelli per mettere in sicurezza il proprio codice. Lo sviluppatore medio chiede ancora a Claude o a Codex di "rivedere la mia PR per trovare bug" e poi "ok, sistemali". Tutto questo è lontanissimo dall'essere sufficiente! Gli attaccanti usano già harness e pipeline complesse e aggressive per la ricerca di bug. C'è un'asimmetria. I difensori non hanno le risorse per creare queste pipeline, né possono ammortizzare il costo su molti obiettivi diversi. Hanno bisogno di qualcuno che sappia sfruttare, imbrigliare e distribuire questi modelli per liberarne tutto il potenziale.
Nel frattempo, le persone sono occupate. Sono sopraffatte nel tentativo di rispettare le scadenze e pubblicare le funzionalità in roadmap. Non hanno tempo per pensare alla sicurezza: vogliono che qualcuno—o qualcosa—intervenga e sistemi le cose al posto loro. Deve integrarsi direttamente nella loro organizzazione (ad esempio in Slack), capire il loro flusso di lavoro (usate GitHub? come vengono assegnati i bug? cosa usate per il tracciamento delle issue? quali agenti usate?) e sentirsi cucito su misura per il loro contesto.
Per lo stesso motivo, i difensori perdono se non hanno un prodotto utile fin da subito. Deve essere completamente self-service oppure prevedere un'implementazione white glove. Deve avere il form factor giusto (una CLI? un MCP? un agente in Slack? un bot per GitHub? tutto quanto?); deve essere piacevole da usare (niente lag, funzionare su mobile, bottoni dove te li aspetti...); deve avere senso (modello di fatturazione non aggressivo, controllo degli accessi che funziona come si deve, selezione logica dell'ambito di audit...). Ci sono un milione di dettagli da sistemare perché un prodotto del genere venga davvero adottato.
In breve: costruire qualcosa che prenda in input programmi arbitrariamente complessi, ci ragioni completamente sopra e trovi bug nuovi. Poi impacchettare questa capacità in un prodotto utile e prendere per mano gli sviluppatori perché possano davvero usarlo e trarne beneficio.
Parte 2: Le cose in cui crediamo
OK, come facciamo a realizzare tutto questo? Qualsiasi piano d'azione concreto è inutile (siamo una società in fase seed). Ha più senso esporre i nostri principi guida e come prevediamo che il mondo si evolverà.
Contro il "safetyism"
Prima di tutto, crediamo che il modo più efficiente per mettere in sicurezza il software del mondo sia dare a tutti la capacità di trovare bug. Non crediamo nel "contattateci" o nel "fate richiesta di accesso". Lo stato finale logico è un mondo in cui tutti i bug vengono trovati e corretti. Limitare l'accesso non fa che rallentare questo processo. Per i manutentori, adattarsi a un nuovo panorama di minacce è scomodo ma inevitabile, e pensiamo che l'approccio migliore sia semplicemente trovare tutti i bug adesso. In pratica, significa armare i difensori con capacità offensive perché possano blindare il proprio codice.
Per essere chiari: vogliamo che il software sia sicuro e affidabile. È irresponsabile scatenare capacità offensive per cui il mondo non è pronto. Ma gran parte dell'"accesso controllato" o della "verifica cyber" che vediamo ultimamente è solo posa e marketing. Si usano le preoccupazioni per la sicurezza come pretesto per non dare accesso a nessuno—e nel frattempo non si protegge nessuno su larga scala. Solo quest'anno, V12 ha protetto gli utenti con oltre 6.000 security review. Non siamo contro la sicurezza, siamo contro il safety LARP.
Divulgazione aperta
Crediamo nella divulgazione aperta. La responsible disclosure sarà vista come un modo antiquato di segnalare e correggere i bug. Embargo e divulgazione coordinata non hanno senso in un mondo in cui chiunque, con gli strumenti giusti, può trovare e weaponizzare una vulnerabilità con un intervento o una competenza umana minimi. Lo abbiamo visto quando abbiamo trovato e segnalato Fragnesia, Pintheft e DirtyDecrypt—0day LPE Linux che alla fine sono trapelate prima ancora che le patch arrivassero nei kernel mainline. Chiunque può monitorare i commit pubblici e ricreare banalmente un exploit weaponizzato. L'unica vera soluzione è eliminare del tutto il patch gap. In pratica, significa update più frequenti (e automatici) e vendor che pubblicano le patch lo stesso giorno (ora!) in cui viene trovato un bug. In particolare, significa che i difensori hanno bisogno di capacità straordinarie di generazione di PoC e fix.
Le bug bounty sono morte
Le bug bounty nella loro forma attuale saranno morte, a parte i programmi di acquisizione di vulnerabilità per bug eccezionalmente preziosi. Tutti gli altri bug saranno estratti da strumenti offensivi come V12 prima ancora che il codice venga rilasciato, cioè prima che gli attaccanti abbiano la possibilità di iniziare a cercare.
I manutentori stanno cedendo sotto il peso delle segnalazioni di bug bounty generate dall'AI. Molti hanno annunciato di voler chiudere del tutto le bug bounty. Ora che i bug sono diventati più economici che mai, le uniche soluzioni sono: (1) smettere di preoccuparsi della maggior parte dei bug, oppure (2) smettere di pubblicarne. In passato, entrambe erano insostenibili perché, sebbene praticamente tutto il codice sia imperfetto, analizzare tutti i possibili bug aveva costi di tempo e denaro proibitivi. Ma ora crediamo che non sia solo possibile, ma inevitabile.
La sicurezza crypto è interessante
I progetti crypto sono obiettivi interessanti e un cuneo importante per la nostra azienda. Siamo ossessionati dal trovare tutti i bug, e la crypto è oggi il posto dove conta di più. Più di 500 milioni di dollari sono stati rubati solo quest'anno in hack. Se V12 può avere successo nella crypto—se possiamo vincere in "modalità difficile"—allora possiamo vincere ovunque.
Con poche eccezioni (full chain iOS?), non esistono bug fuori dalla crypto che valgano bounty a sette o otto cifre. Fuori dalla crypto, 50.000 dollari sono ancora considerati un premio enorme. Nella crypto, una vulnerabilità critica che mette a rischio i fondi vale centinaia di milioni di dollari se sfruttata. In generale, nessuno vuole prendere sul serio la sicurezza, ma le aziende crypto sono costrette a farlo. Questo significa che quando scelgono i prodotti di sicurezza, privilegiano la capacità di trovare bug rispetto alle dashboard—cioè ciò per cui V12 è ottimizzato. Nel frattempo, fuori dalla crypto, la sicurezza ruota ancora intorno a una cultura della conformità, non della sostanza.
Tutto il software è vulnerabile, ma il mondo si comporta come se non fosse così. Finora ha funzionato solo perché gli attaccanti erano rari: la competenza tecnica era il collo di bottiglia. L'AI rimuove questo vincolo. Ora, se il software non è sicuro, verrà sfruttato. Di sicuro.
L'impatto è amplificato dal fatto che il mondo è sempre più online, e gran parte del mondo oggi esiste davvero "dentro un computer". Tutto dovrà diventare molto più sicuro in fretta, e questo significa che molti più team prenderanno la sicurezza sul serio come fanno le aziende crypto.
Tra l'altro, per sfatare un luogo comune: le codebase crypto non sono banali per dimensioni, complessità e diversità. Firedancer è 722k LoC di C altamente ottimizzato, Geth + Prysm sono 1,1M di LoC di Go, Zcash è 304k LoC di C++ e Python (solo Orchard è 44k LoC di circuiti e crittografia in Rust). Tutte contengono macchine virtuali, codice di sistema di basso livello e database distribuiti. Per dare un'idea, Postgres e CPython si aggirano entrambi intorno a ~1M di LoC.
È il momento della vera sicurezza
Il software del mondo è sempre stato vulnerabile, ma ora è impossibile ignorarlo. Il web moderno dipende da crittografia e browser sicuri, i modelli di frontiera si affidano ai TEE per proteggere i pesi, e le innovazioni in robotica e biologia renderanno la sicurezza solo più importante. In pratica, tutto il codice diventa prima o poi codice ad alta affidabilità.
Non dimentichiamo la crescente complessità delle supply chain del software. Molto codice a cui non pensiamo sarà (o è già) ad alta affidabilità. OpenSSH viene certamente in mente, ma che dire di tutti i pacchetti che abbiamo dimenticato? Internet dipende da software che nessuno guarda.
Il modo in cui la sicurezza viene gestita oggi non funzionerà. È un ripensamento, svolto in base al principio del "si fa quel che si può". I team si concentrano sullo sviluppo delle funzionalità e fanno ricadere la sicurezza sulle spalle di qualcun altro. La maggior parte dei prodotti di sicurezza sono come cerotti che gestiscono i sintomi dei bug, non vere soluzioni. Ma in un mondo con un'AI potente, se c'è anche un solo bug, qualcuno lo troverà e lo sfrutterà.
Invece, la sicurezza deve essere continua e completa: ogni PR mergiata deve essere priva di vulnerabilità. La strada per arrivarci non sarà facile, e non abbiamo tutte le risposte. Nessuno le ha. Ma il problema fondamentale a cui tutto questo si riduce—trovare bug—è ciò che ci ossessiona da 10 anni. Prima di V12, abbiamo fondato Zellic, una delle principali società di sicurezza al mondo, con oltre 1.500 security review per più di 500 clienti fortemente bersagliati (ad esempio exchange crypto, bridge, L1, wallet, sistemi operativi open source). E prima ancora, abbiamo fondato perfect blue, la squadra CTF numero 1 al mondo per 3 anni.
Ogni persona del team di V12 proviene dalle CTF o dalla vulnerability research. Guarda cosa abbiamo segnalato finora: molteplici LPE Linux, una QEMU escape, RCE wormabili in Redis e PostgreSQL (bidirezionali!), MariaDB e Anydesk. E la cosa ancora più promettente è che qualunque nuovo software contro cui lanciamo V12, i bug continuano a uscire fuori: l'emulatore Dolphin, il NAS di un dipendente, Signal messenger.
Considerazioni finali
Un buon seed round ti dà la cosa più bella del mondo: la possibilità di costruire qualcosa che ami con i tuoi amici.
Sogniamo di risolvere questo problema—trovare automaticamente tutti i bug—da quando eravamo adolescenti. Ora l'AI è finalmente abbastanza potente da permetterci di fare un tentativo serio. Siamo entusiasti. Se abbiamo ragione, quello che stiamo costruendo sarà pericolosamente capace, e il mondo si adatterà di conseguenza.
Vogliamo essere noi a fare accadere tutto questo. Se V12 ti sembra qualcosa di cui vorresti far parte: unisciti a noi, stiamo assumendo!
