«La situazione è estremamente grave.»
Non è il commento di una società di cybersecurity che deve vendere un prodotto.
È il modo in cui Calle, sviluppatore Bitcoin conosciuto come CalleBTC, descrive ciò che un gruppo di ricercatori sta osservando dopo aver iniziato a puntare agenti di intelligenza artificiale contro una vasta quantità di software dell’ecosistema Bitcoin.
- Wallet.
- Librerie crittografiche.
- Infrastrutture Lightning.
- Servizi.
Repository open source sui quali, direttamente o indirettamente, transitano bitcoin reali.
Il risultato delle prime ore di lavoro è difficile da ignorare.
Secondo Calle, il gruppo avrebbe raggiunto un ritmo nell’ordine di una vulnerabilità critica all’ora per persona impegnata nelle analisi e avrebbe già comunicato problemi gravi a diversi progetti.
Rob Hamilton, che sta coordinando parte dello sforzo, ha successivamente fornito numeri più precisi: oltre 150 repository sottoposti a scansione, più di una dozzina di disclosure e circa 20.000 dollari già spesi tra modelli e servizi necessari per eseguire gli agenti.
Non conosciamo ancora pubblicamente i dettagli delle vulnerabilità.
Ed è giusto così.
Una responsible disclosure serve precisamente a permettere ai manutentori di correggere un problema prima che venga spiegato al resto del mondo.
Ma se anche soltanto una parte dei risultati dichiarati sarà confermata, Bitcoin potrebbe trovarsi davanti a uno dei primi grandi esempi di come l’intelligenza artificiale stia cambiando radicalmente l’economia della sicurezza del software.
La stessa arma usata contro Boltz
Il tempismo non potrebbe essere più significativo.
Ieri Boltz ha deciso di disabilitare a tempo indefinito il proprio servizio di swap spiegando di aver osservato una forte accelerazione delle attività automatiche e AI-assisted dirette contro la propria infrastruttura.
Il problema denunciato dal team non era un singolo incidente.
Era l’asimmetria.
Gli attaccanti potevano analizzare, modificare e riprovare un attacco più velocemente di quanto un piccolo gruppo di sviluppatori riuscisse a individuare le vulnerabilità e distribuirne le correzioni.
Ora la community Bitcoin sta provando a rovesciare quell’equazione.
Se un agente AI può leggere un repository e cercare un modo per romperlo, allora un difensore può puntare lo stesso tipo di macchina contro il proprio software prima dell’attaccante.
È la nascita di una corsa agli armamenti nella quale entrambi i lati utilizzano gli stessi modelli.
La differenza la farà chi riuscirà a costruire il sistema migliore intorno al modello.
Non basta chiedere a ChatGPT di trovare un bug
È qui che entra in gioco il concetto di harness.
Un modello linguistico, lasciato semplicemente davanti a centinaia di migliaia di righe di codice con il prompt “trova una vulnerabilità”, ha capacità molto più limitate di quanto possa suggerire la narrativa sull’AI.
Il lavoro interessante avviene nell’infrastruttura che lo circonda.
Un harness può decidere quali parti del repository analizzare, fornire strumenti al modello, eseguire codice, compilare il progetto, osservare crash, creare test, verificare se un problema sia riproducibile, scartare falsi positivi e assegnare compiti differenti ad agenti differenti.
In altre parole, il modello è il cervello.
L’harness è il laboratorio.
Hamilton afferma di avere già costruito una prima versione di un Bitcoin Red Team Agent Harness, progettata per coordinare più modelli e assegnare a ciascuno un ruolo differente.
Kimi K3 viene utilizzato per parte del lavoro più pesante, mentre altri modelli — tra cui sistemi OpenAI e modelli della famiglia Claude e GLM — vengono utilizzati per attività complementari e per la documentazione dei risultati.
Il progetto è ancora alla prima versione.
Ma avrebbe già trovato problemi classificati come critici.
OpenAI entra nel red team Bitcoin
La parte forse più interessante dell’aggiornamento di Hamilton è il coinvolgimento di OpenAI.
Il gruppo sarebbe infatti entrato in contatto con OpenAI per ottenere assistenza nell’esecuzione del suo Cyber Harness, un sistema più costoso ma destinato alle analisi più profonde sulle parti considerate “load bearing” dell’ecosistema Bitcoin.
Secondo Hamilton, i primi utilizzi avrebbero già prodotto risultati interessanti.
Non si tratta di un contesto completamente nuovo per OpenAI.
I più recenti sistemi dell’azienda vengono esplicitamente valutati sulla capacità di svolgere ricerca sulle vulnerabilità reali. La system card di GPT-5.6 descrive, per esempio, una valutazione chiamata VulnLMP nella quale i modelli vengono messi al lavoro per periodi prolungati contro software reale e devono passare dal semplice crash alla dimostrazione riproducibile di un impatto sulla sicurezza.
È una distinzione fondamentale.
Trovare qualcosa che manda in crash un programma è relativamente facile.
Dimostrare che quel crash può diventare un exploit reale, comprendere la causa, produrre una prova ripetibile e spiegare come correggerlo è un’altra cosa.
Ed è proprio il secondo tipo di capacità che inizia a diventare economicamente accessibile.
20.000 dollari per attaccare Bitcoin
La sicurezza AI ha però ancora un costo importante.
Hamilton parla di circa 20.000 dollari di spesa accumulata attraverso diversi servizi.
Calle aveva precedentemente indicato un burn rate che poteva raggiungere i 10.000 dollari al giorno durante le campagne più aggressive.
Sono cifre enormi per un singolo sviluppatore.
Molto meno impressionanti se confrontate con il valore che alcuni di questi software proteggono.
Una vulnerabilità critica in un wallet utilizzato da decine di migliaia di utenti può mettere a rischio somme enormemente superiori.
Un bug in una libreria condivisa può propagarsi silenziosamente in decine di applicazioni.
Un problema in un’infrastruttura Lightning può trovarsi anni all’interno dell’ecosistema prima che qualcuno scopra come sfruttarlo.
Spendere 20.000 dollari per tentare di rompere preventivamente centinaia di repository può quindi essere una delle assicurazioni più economiche mai acquistate dall’ecosistema.
La parte economica, inoltre, al momento sarebbe già coperta.
Calle ha ringraziato OpenSats per aver sostenuto i costi della campagna, mentre Kimi avrebbe fornito account e accesso alle proprie risorse. Hamilton ha successivamente precisato che il finanziamento necessario è assicurato e che non sono necessarie ulteriori donazioni.
OpenSats è una non profit che finanzia sviluppatori e progetti Bitcoin open source e dichiara di aver allocato complessivamente oltre 27 milioni di dollari a progetti FOSS.
Il denaro che normalmente finanzia la costruzione di Bitcoin sta quindi iniziando a finanziare anche qualcosa di altrettanto importante:
provare a distruggerlo in laboratorio.
150 repository sono soltanto l’inizio
Hamilton afferma che il gruppo abbia già passato al setaccio circa 150 repository.
Il vero collo di bottiglia, sorprendentemente, non sarebbe più trovare i problemi.
Sarebbe comunicarli.
Una volta individuata una potenziale vulnerabilità serve capire chi mantiene realmente il progetto, trovare un canale privato appropriato, verificare che il report raggiunga una persona competente, fornire una riproduzione sufficientemente chiara e coordinare tempi e modalità della correzione.
Il computer può trovare cento problemi.
Ma qualcuno deve telefonare a cento persone.
Hamilton descrive precisamente questo problema distinguendo il “primo miglio” e l’“ultimo miglio”.
Il primo è la preparazione del target.
Il secondo è la consegna del risultato agli esseri umani.
Nel mezzo, invece, una quantità crescente del lavoro può essere automatizzata.
L’obiettivo dichiarato per le prossime iterazioni è proprio questo: togliere gli esseri umani dal lavoro pesante, automatizzando l’intero ciclo dalla scansione iniziale fino alla produzione di un report utilizzabile.
L’essere umano rimane dove continua ad avere maggior valore:
decidere cosa analizzare e coordinare responsabilmente la disclosure.
Un agente che non dorme mai
La conseguenza è facile da immaginare.
Fino a pochi anni fa una security review importante richiedeva sviluppatori estremamente specializzati che lavoravano per giorni o settimane su un singolo progetto.
Queste persone rimarranno fondamentali.
Ma potranno essere affiancate da centinaia di agenti che lavorano in parallelo.
Uno analizza la gestione della memoria.
Uno studia l’autenticazione.
Uno cerca race condition.
Uno confronta il codice con vulnerabilità storiche.
Uno modifica gli input.
Uno prova a costruire un exploit.
Uno verifica che il primo agente non abbia semplicemente allucinato.
Uno prepara il report.
Tutto contemporaneamente.
Tutto per ore.
Poi si passa al repository successivo.
È così che diventa comprensibile l’affermazione di Calle secondo cui il gruppo starebbe osservando vulnerabilità critiche a un ritmo vicino a una all’ora per ricercatore.
Non significa necessariamente che Bitcoin sia improvvisamente diventato software insicuro.
Significa che la quantità di attenzione che possiamo concentrare sul software è aumentata di ordini di grandezza.
L’open source diventa un campo di battaglia
Bitcoin possiede una caratteristica che contemporaneamente lo protegge e lo espone.
Il codice è aperto.
Un difensore può scaricarlo e analizzarlo.
Un attaccante può fare esattamente la stessa cosa.
Per decenni l’argomento principale a favore dell’open source è stato che “molti occhi rendono superficiali i bug”.
Ma gli occhi sono sempre stati una risorsa scarsa.
Gli sviluppatori hanno tempo limitato.
I revisori veramente competenti sono pochissimi.
Leggere codice di sicurezza è faticoso, costoso e spesso poco gratificante.
L’intelligenza artificiale cambia la quantità di occhi disponibili.
Non sono necessariamente occhi affidabili.
Possono sbagliare, inventare problemi e seguire piste inutili.
Ma costano denaro invece che tempo umano.
E possono essere moltiplicati.
L’open source potrebbe quindi entrare in una nuova fase nella quale il vantaggio non deriva semplicemente dal fatto che chiunque può leggere il codice, ma dal fatto che chiunque può mettere migliaia di agenti a leggerlo.
Questo vale per il difensore.
E vale per il nemico.
La situazione “estremamente grave”
L’affermazione di Calle merita quindi di essere interpretata correttamente.
Quando scrive che “la situazione è estremamente grave”, non sappiamo ancora quali siano i progetti interessati, quanto siano sfruttabili le vulnerabilità trovate o se ogni classificazione “critical” sopravviverà alla revisione dei rispettivi maintainer.
Sarebbe irresponsabile trasformare una campagna di responsible disclosure nella conclusione che “Bitcoin è pieno di falle”.
Bitcoin Core, inoltre, è soltanto una parte dell’enorme quantità di software che chiamiamo genericamente “Bitcoin”.
Esistono centinaia di wallet, librerie, implementazioni Lightning, server, plugin, bridge e applicazioni.
La qualità varia enormemente.
La superficie di attacco è enorme.
E ogni repository non rappresenta il protocollo Bitcoin.
Ma il segnale rimane importante.
Software che ieri veniva sottoposto a qualche audit umano occasionale può oggi essere martellato sistematicamente da agenti capaci di lavorare per ore su ogni possibile punto debole.
Gli errori che potevano sopravvivere per anni possono iniziare ad avere una vita molto più breve.
Open source anche il red team
Hamilton vuole fare un passo ulteriore.
L’obiettivo è rendere open source anche l’harness utilizzato dal red team.
Questo permetterebbe a un progetto Bitcoin non soltanto di analizzare il proprio codice pubblico, ma di puntare lo stesso sistema sui repository interni prima di una release.
È una prospettiva importante.
La difesa non rimarrebbe concentrata nelle mani del piccolo gruppo che oggi sta eseguendo queste scansioni.
Ogni wallet potrebbe installare il proprio red team.
Ogni società potrebbe farlo girare sulla propria infrastruttura.
Ogni nuova release potrebbe essere attaccata automaticamente prima di raggiungere gli utenti.
Il fuzzing è già diventato parte standard dello sviluppo di software sicuro.
La scansione continua tramite agenti potrebbe diventare il prossimo livello.
Non un audit una volta all’anno.
Un avversario artificiale permanentemente collegato alla pipeline di sviluppo.
Dal “move fast” al “break yourself first”
Per vent’anni la Silicon Valley ha vissuto sulla filosofia del “move fast and break things”.
Bitcoin non può permetterselo.
Quando un’applicazione social ha un bug, qualcuno perde un post.
Quando un software finanziario non-custodial ha un bug, qualcuno può perdere denaro irreversibile.
L’intelligenza artificiale potrebbe quindi imporre una nuova filosofia allo sviluppo Bitcoin:
break yourself first.
Attacca il tuo wallet prima che lo facciano gli altri.
Tenta di svuotare il tuo protocollo.
Rompi il tuo parser.
Manda input impossibili.
Cerca di aggirare ogni controllo.
E fallo continuamente, utilizzando le stesse macchine che dall’altra parte potrebbero essere impiegate contro di te.
Il caso Boltz ci aveva mostrato il lato offensivo della nuova asimmetria.
Gli attaccanti automatici aumentano la velocità fino al punto in cui un piccolo team fatica a tenere il passo.
Il Bitcoin Red Team rappresenta la prima risposta naturale:
automatizzare anche la difesa.
La guerra delle macchine è già iniziata
Non servono computer quantistici.
Non serve una superintelligenza.
Non serve aspettare dieci anni.
Il cambiamento è già qui.
Un gruppo relativamente piccolo di sviluppatori è riuscito a spendere qualche decina di migliaia di dollari e concentrare capacità di analisi su almeno 150 repository dell’ecosistema Bitcoin.
Secondo i suoi partecipanti, ne stanno emergendo vulnerabilità reali e alcune sono critiche. Hamilton afferma che sono già state effettuate più di dodici disclosure.
Il dato più importante non è però il numero di bug trovati oggi.
È il costo per trovarne uno domani.
Quel costo sta crollando.
Gli attaccanti lo sanno.
Ora lo sanno anche i difensori.
Bitcoin è nato assumendo che nessuno debba essere considerato affidabile.
Forse la sicurezza del suo software dovrà iniziare ad applicare la stessa filosofia al codice stesso.
Non fidarti che funzioni.
Non fidarti che l’audit dell’anno scorso sia sufficiente.
Non fidarti del fatto che nessuno abbia ancora trovato il bug.
Attaccalo continuamente.
E assicurati che, prima che arrivi l’agente del nemico, sia già passato il tuo.
