# Le macchine stanno leggendo il codice

> L'IA ha fatto crollare il costo della scoperta di vulnerabilità. Nell'ecosistema open source di Bitcoin quella collisione è arrivata questo mese — e Bruxelles ha messo un orologio su ciò che accadrà dopo.

Source: https://counterproof.io/it/notes/le-macchine-stanno-leggendo-il-codice/ · Published 14 August 2026 · CounterProof è una practice di Clavestra Capital Limited (Malta, C 113987).


Nella seconda settimana di agosto 2026, uno sviluppatore Bitcoin pseudonimo noto come Calle ha
pubblicato una frase che è rimbalzata per tutta l'industria: «Everything is broken, Bitcoin is
burning» — tutto è rotto, Bitcoin sta bruciando. Dietro l'iperbole c'era un dataset. Il Bitcoin
Red Team, squadra di volontari, aveva appena fatto passare Kimi K3 di Moonshot AI — un modello di
frontiera cinese a pesi aperti, pubblicato appena due settimane prima — su praticamente l'intero
ecosistema open source di Bitcoin: portafogli, applicazioni Lightning, librerie di pagamento e
gli strumenti attorno a essi. Dopo circa 108 ore — tempo di campagna trascorso, lavorato da una
squadra cresciuta fino a venticinque persone — su 501 progetti, la squadra aveva registrato 7 958
rilievi di sicurezza potenziali, 1 280 dei quali classificati alti o critici.

Quella singola campagna comprime tutto ciò di cui parla questo articolo: che cosa i modelli di IA
possono ormai fare a una base di codice, chi li sta puntando su Bitcoin, che cosa trovano — e
perché un regolamento europeo che comincia a mordere l'11 settembre 2026 trasforma tutto questo
da una storia di ingegneria in una storia legale.

## Gli attaccanti sono arrivati prima

Prima che i difensori si industrializzassero, lo hanno fatto gli attaccanti. La filiera open
source da cui dipendono Bitcoin e la più ampia industria degli asset digitali è da anni sotto un
assalto sostenuto e a movente economico — e l'ecosistema crypto ne è stato costantemente la
vittima designata.

Nel settembre 2025, degli attaccanti hanno phishato il maintainer di `chalk`, `debug` e altre
sedici utility npm — pacchetti con miliardi di download settimanali complessivi — e hanno
distribuito un crypto-clipper che agganciava le API del browser e sostituiva in silenzio gli
indirizzi di destinazione nell'istante esatto in cui l'utente di un portafoglio approvava una
transazione, arrivando a scegliere gli indirizzi dell'attaccante per somiglianza visiva per
eludere il rilevamento. Settimane dopo, il worm Shai-Hulud ha aggiunto l'autopropagazione,
trasformando compromissioni isolate di maintainer in reazioni a catena. Nel marzo 2026 la
libreria Axios — dell'ordine di cento milioni di download settimanali — è stata dotata di
backdoor per poco meno di tre ore tramite un account maintainer dirottato, in parallelo alla
campagna TeamPCP che ha compromesso quattro progetti open source molto usati in una sola
settimana. E nel luglio 2026 degli attaccanti hanno infilato una backdoor travestita da
«telemetria» nell'SDK della blockchain Injective, cablando l'esfiltrazione di seed phrase e
chiavi private direttamente nelle funzioni di derivazione delle chiavi dei portafogli; la
pubblicazione automatizzata l'ha propagata a diciotto pacchetti in pochi minuti.

La direzione di marcia è misurabile. Il rapporto State of the Software Supply Chain 2026 di
Sonatype ha contato oltre 454 600 nuovi pacchetti open source malevoli nel solo 2025 — un balzo
del 75 % su base annua, che spinge il totale cumulato dei blocchi oltre 1,2 milioni. E anche gli
strumenti sul lato offensivo evolvono: il Threat Intelligence Group di Google ha riferito nel
2026 di aver identificato, per la prima volta, un attore di minaccia che brandiva un exploit
zero-day che il gruppo ritiene sviluppato con l'IA, destinato a un evento di sfruttamento di
massa.

I repository open source sono presi di mira proprio perché sono lo strato di fiducia. Nessuno ha
bisogno di violare la vostra infrastruttura se può avvelenare una dipendenza che installate
volontariamente. E in nessun luogo quella leva è più grande che nel software che tocca chiavi e
denaro.

## La débâcle ColdCard

Poi, a fine luglio, il rischio astratto è diventato un rischio che cambia la vita. A partire dal
30 luglio 2026, un attaccante ha cominciato a svuotare quello che doveva essere il nascondiglio
più sicuro di Bitcoin: la conservazione a freddo. In ondate successive — la più grande ha
spazzato 1 082 BTC da 1 196 portafogli in soli 41 minuti, secondo il conteggio di Galaxy
Research — la perdita ha raggiunto 1 367 BTC — circa 88,6 milioni di dollari — su 4 585
indirizzi generati su portafogli hardware ColdCard di Coinkite, al checkpoint di Galaxy del
1º agosto. Conteggi successivi hanno superato i 1 800 BTC e puntato verso i 130 milioni di
dollari una volta inclusa una sospetta quarta ondata. (Correzione: una versione precedente di
questa nota indicava 116 milioni di dollari — ripreso dalla copertura circolante e, in seguito,
non riconducibile ad alcuna fonte che lo enunci, lo dati e lo definisca. I totali maggiori
includono un'ondata ancora descritta come non confermata settimane dopo, e la stessa avvertenza
di Galaxy merita di accompagnare la cifra — hanno abbinato gli indirizzi per pattern e non hanno
usato potenza di calcolo per dimostrare che quei seed fossero deboli.) Secondo il meccanismo
pubblicato, nulla di tutto ciò ha richiesto phishing, un dispositivo rubato o un accesso fisico
di alcun tipo — le chiavi sono state ricostruite offline. Quelle esclusioni discendono da come
funzionava il difetto; gli avvisi del produttore non affermano di aver indagato ed escluso
ciascuna. Migliaia di holder di lungo periodo che avevano fatto tutto ciò che l'ortodossia
dell'autocustodia prescrive — portafoglio hardware, chiavi offline, air gap intatto — hanno
visto i risparmi di una vita lasciare indirizzi che solo loro avrebbero dovuto controllare. La
causa radice era di una banalità devastante: un flag di build del firmware, distribuito nel
marzo 2021, faceva sì che i dispositivi interessati saltassero il loro chip hardware dedicato
alla casualità e ripiegassero su un debole PRNG software, facendo collassare l'entropia
effettiva — fino a circa 40 bit sui vecchi Mk3 — abbastanza da permettere la ricostruzione
offline delle seed phrase. La matematica di Bitcoin ha retto; il software che la avvolgeva no.
Coinkite ha distribuito firmware d'emergenza, distrutto l'inventario vulnerabile e implorato gli
utenti di migrare — ammettendo al contempo che nessuna patch può riparare un seed già generato
su firmware vulnerabile.

Poi è arrivata la guerra delle narrazioni. Il CEO di Coinkite, Rodolfo Novak, ha inquadrato
l'exploit come «a sober reality of the new AI paradigm» — una sobria realtà del nuovo paradigma
dell'IA: la revisione del codice assistita dall'IA farebbe ormai emergere i bug latenti più in
fretta persino degli esperti umani più navigati, e ogni firmware che sia o sia mai stato pubblico
andrebbe presunto sotto scrutinio delle macchine, da parte di attaccanti e difensori allo stesso
modo. Quell'affermazione è contestata, e l'onestà impone di dirlo. Nessun attaccante è stato
identificato. Nessuna prova è emersa che un modello abbia trovato il difetto — la formulazione
stessa di Coinkite è che «dobbiamo presumere» («we have to assume») che qualcuno abbia usato
l'IA sul firmware pubblicato, e nello stesso documento l'azienda rivela che la propria revisione
con IA, condotta settimane prima, «non ha trovato questo bug né nulla di serio» («did not find
this bug or anything serious»). Una versione precedente di questa nota scriveva inoltre che
specialisti di sicurezza avevano obiettato con durezza — che un flag di build che disattiva un
RNG hardware è un fallimento di ingegneria umana che la revisione convenzionale avrebbe dovuto
cogliere anni prima. Non siamo riusciti a sostenerlo alla riverifica: l'unico post che avevamo
tracciato sta su un account sospeso, e il commentatore con nome più vicino che abbiamo trovato
dava ragione a Coinkite anziché obiettare. L'argomento ci sembra ancora giusto — ma ora è
nostro, non attribuito. In un senso, però, la disputa è marginale. Che un'IA abbia trovato
*questo* bug oppure no, l'ecosistema ora sa che i modelli possono dimostrabilmente trovare bug
esattamente di questa classe esattamente a questa velocità — e ha reagito come se la minaccia
fosse reale. In pochi giorni, l'exchange Boltz ha sospeso le operazioni per giocare d'anticipo
sui tentativi di attacco guidati dall'IA. E una controforza di volontari si è radunata.

## L'ascesa del red team in Bitcoin

Il Bitcoin Red Team si è formato in pochi giorni dopo il drenaggio ColdCard: una controforza
d'emergenza, volontaria, di sedici ricercatori guidati da Calle insieme al CEO di AnchorWatch
Rob Hamilton, sostenuta da circa 40 000 dollari di calcolo IA e appoggiata da OpenSats, il cui
nuovo programma di grant Code RED ora premia la divulgazione responsabile delle vulnerabilità
nell'ecosistema. Il metodo abbina analisi guidata dall'IA e verifica umana — i modelli passano
al setaccio portafogli, implementazioni Lightning e librerie; i ricercatori riproducono e
valutano; i rilievi credibili vanno in privato ai maintainer prima che qualsiasi cosa venga
pubblicata.

La traiettoria dei suoi numeri racconta che cosa fa l'IA all'economia della scoperta di
vulnerabilità. Il primo sprint ha depositato 4 962 rilievi su 390 progetti in 27,5 ore — 85
critici e 635 alti, in media, secondo l'aritmetica di Calle al lancio, dell'ordine di un exploit
critico per ricercatore all'ora. Giorni dopo, la scansione ampliata era a 7 958 rilievi su 501
progetti. La sintesi di Calle: la scansione di base di praticamente l'intero ecosistema open
source di Bitcoin è completa, e i frutti a portata di mano sono stati colti.

I rilievi arrivano con una trama che conta più dei totali. Le vulnerabilità si concentravano
nelle basi di codice più vecchie e poco riviste. Il software legato a Lightning —
strutturalmente complesso, sensibile alle prestazioni, difficile da verificare — portava
un'esposizione sproporzionata. La prevalenza di implementazioni in C è stata segnalata come
rischio strutturale persistente. E la rapidità con cui un progetto rispondeva a una divulgazione
privata si è rivelata una diagnosi in sé: la velocità di risposta, ha osservato la squadra, è un
indicatore visibile della salute di un progetto. I progetti non mantenuti, hanno avvertito, non
andrebbero considerati affidabili.

La campagna ha già prodotto un impatto reale e verificato. BTCPay Server — uno dei processori di
pagamento Bitcoin self-hosted più diffusi — ha rilasciato la versione 2.4.2 il 7 agosto,
correggendo un bypass critico dell'autenticazione a due fattori accreditato in parte ai
ricercatori del Bitcoin Red Team — e ha poi confermato che il difetto era già stato sfruttato in
natura per estrarre credenziali di portafogli Lightning. È l'intera tesi in un solo incidente:
la vulnerabilità era reale, veniva usata, e la revisione assistita dalle macchine l'ha raggiunta
prima di quanto avrebbe fatto la maggior parte degli umani.

Vale la pena dire direttamente che cosa è servito. Sedici volontari, circa 40 000 dollari di
calcolo, poche settimane — e una disciplina che la maggior parte dei programmi di sicurezza
finanziati non raggiunge mai: prima la divulgazione privata, la pubblicazione solo quando i
maintainer avevano i rilievi, e il proprio tasso di riproduzione dichiarato in pubblico anziché
sepolto. Hanno mappato un ecosistema rimasto non mappato per un decennio e hanno regalato i
risultati. Qualunque cosa segua in questo articolo, quello è lo standard di riferimento per come
questo lavoro va condotto, e l'ecosistema Bitcoin questo mese è più sicuro del mese scorso —
grazie a loro.

Un vincolo di quel lavoro merita di essere enunciato chiaramente, perché viene abitualmente
frainteso come una scelta metodologica. La squadra ha riferito che le restrizioni d'uso dei
modelli statunitensi per la ricerca in sicurezza li hanno bloccati ripetutamente — spingendoli
verso modelli a pesi aperti come Kimi K3 e GLM 5.2 di Z.ai, eseguibili in locale senza
guardiani di policy. Kimi K3 non era un ripiego; per quel lavoro, in quel momento, era tra i
migliori strumenti che avessero effettivamente il permesso di usare.

Quello è un fallimento di policy, non un fallimento di ricerca. La scelta degli strumenti nella
ricerca in sicurezza è ormai plasmata meno dalla qualità dei modelli che da chi permette il
lavoro tout court — e una squadra che allunga la mano verso il modello che il lavoro lo esegue
davvero si comporta correttamente. Dovrebbe far riflettere i laboratori occidentali: la ricerca
difensiva avviene comunque. L'unica domanda è sui modelli di chi — e se chi la conduce sia
costretto in una cassetta degli attrezzi più stretta di quella che affrontano gli attaccanti.

## Che cosa significano davvero 7 958 rilievi

Qui è dovuta onestà — e la squadra è stata la prima a doverla. Dei 7 958 rilievi, il 24,7 %
aveva una proof of concept riproducibile — l'espressione è della squadra stessa — e il 29,4 %
era stato segnalato upstream all'ultimo conteggio, cifre che la squadra ha pubblicato da sé
invece di arrotondarle via. (Una versione precedente di questa nota scriveva «riprodotti
dinamicamente»; era una nostra glossa, non loro, e il tasso di segnalazione indica rilievi
inviati ai maintainer, non rilievi accettati dai maintainer.) Una valutazione congiunta
dell'AI Security Institute britannico e del CAISI statunitense ha giudicato Kimi K3 capace ma
lontano dall'infallibile — 32 % sui benchmark di sviluppo di exploit, davanti a GLM-5.2 ma ben
dietro i più forti modelli chiusi, e senza ottenere esecuzione di codice arbitrario su nessuno
dei 41 campioni testati.

Questo dunque non è un elenco di 7 958 falle sfruttabili in Bitcoin, e nessuno dei coinvolti lo
ha sostenuto. L'inquadramento di Calle è stato schietto: i candidati costano poco, e se non
riuscite a gestire il sovraccarico informativo che ne deriva, usate l'IA per smistarlo. È la
lettura giusta, e indica il vero spostamento. L'IA ha reso la *generazione di candidati* quasi
gratuita. Ciò che non ha reso gratuito è il giudizio che separa una vulnerabilità confermata,
riproducibile e correttamente classificata da un'allucinazione dall'aria plausibile — lo stesso
problema dell'«AI slop» in cui i maintainer open source, da curl in poi, stanno annegando.

La risorsa scarsa nella sicurezza si è spostata in silenzio dal rilevamento alla valutazione. È
una proprietà della tecnologia, non un difetto di qualcuno — e una scansione che mappa un intero
ecosistema e una valutazione firmata di una singola base di codice sono semplicemente mestieri
diversi. La prima vi dice dove guardare. La seconda è ciò che un regolatore, un acquirente o un
assicuratore accetteranno davvero. Ogni attore serio in questo campo — attaccante, difensore,
maintainer, regolatore — sta ormai a valle di quel collo di bottiglia.

## Bruxelles mette l'orologio

In questa collisione entra il Cyber Resilience Act dell'UE, e il suo tempismo difficilmente
potrebbe essere più tagliente.

Dall'**11 settembre 2026**, l'articolo 14 del CRA obbliga i fabbricanti di prodotti con elementi
digitali venduti nell'UE a notificare ogni vulnerabilità attivamente sfruttata di cui vengano a
conoscenza — entro 24 ore per l'allerta precoce, 72 ore per la notifica completa e 14 giorni per
la relazione finale — simultaneamente all'ENISA e al proprio CSIRT nazionale designato, tramite
la piattaforma unica di notifica. Punto cruciale: questo si applica ai prodotti già sul mercato,
non solo alle nuove versioni. Il regolamento si applica poi integralmente
dall'**11 dicembre 2027**, portando con sé requisiti vincolanti di sicurezza fin dalla
progettazione, il dovere dell'allegato I di effettuare prove e riesami di sicurezza efficaci e
*periodici*, una documentazione tecnica contenente le relazioni di quelle prove, e obblighi di
conservazione che si estendono per un decennio. Le sanzioni dell'articolo 64 arrivano a 15
milioni di euro o al 2,5 % del fatturato annuo mondiale totale, **se superiore**.

Ora mettete insieme le due metà di questo articolo. Le campagne assistite dall'IA stanno facendo
emergere migliaia di vulnerabilità candidate negli ecosistemi open source nel giro di
settimane — e alcune, come il difetto di BTCPay, vengono *attivamente sfruttate*, che è
esattamente il grilletto di notifica del CRA. Un fabbricante il cui prodotto incorpora una
dipendenza compromessa, o un difetto che una scansione IA fa emergere e un attaccante raggiunge
per primo, non affronta più una tranquilla correzione ingegneristica. Affronta un orologio
legale di 24 ore. E un fabbricante del tutto privo di un processo di scoperta potrebbe violare
l'articolo 14 non per mancata notifica, ma per non aver mai saputo che c'era qualcosa da
notificare.

Il corollario scomodo: molto del codice che oggi viene spedito dentro quei prodotti è scritto
dalle macchine, e molta della revisione che gli viene applicata è svolta dagli stessi modelli
che lo hanno scritto. Un codice scritto da un modello e revisionato dallo stesso modello non è
stato revisionato da nessuno. Regolatori, acquirenti, assicuratori e team di sicurezza aziendali
stanno convergendo sulla stessa domanda — e «il nostro modello ha controllato il proprio output»
non è una risposta che qualcuno di loro accetti.

## La confutazione come disciplina: il metodo CounterProof

Una scansione e una valutazione rispondono a domande diverse, e la seconda è dove siede la
nostra practice. CounterProof non è stato progettato in un workshop come prodotto; si è
accresciuto mentre mettevamo in sicurezza la nostra stessa infrastruttura di pagamento a
crittografia a soglia — dove un difetto che sfugge non costa una relazione con un cliente: costa
all'operatore i propri fondi.

Il vincolo che l'ha plasmato era l'opposto di quello del Red Team. A loro serviva ampiezza: 501
progetti, in fretta, su qualunque modello eseguisse il lavoro. A noi serviva che un singolo
rilievo sopravvivesse all'avere torto in pubblico, su codice che custodisce il nostro stesso
denaro. L'ampiezza perdona un falso positivo; una valutazione firmata no. Problema diverso,
metodo diverso — e noi avevamo il lusso di scegliere gli strumenti, che è esattamente ciò che le
restrizioni di policy descritte sopra negava a loro.

CounterProof affronta il collo di bottiglia della valutazione di petto, con un protocollo
plasmato dalle modalità di guasto descritte sopra. Ogni valutazione è una revisione avversariale
multi-lignaggio: *famiglie* di modelli indipendenti — non una seconda passata dello stesso —
attaccano ogni rilievo e cercano di confutarlo, e i disaccordi si risolvono leggendo il codice
sorgente, non votando.

Quest'ultimo punto non è una pretesa di modelli migliori. È un'affermazione su una proprietà
misurata di tutti: il verdetto di un revisore è un campione, non una misura. Date allo stesso
modello gli stessi byte due volte e non restituirà sempre la stessa risposta; ponete una domanda
a più famiglie e falliranno in direzioni diverse — l'unica ragione per cui far girare più
famiglie vale il costo. Abbiamo visto un modello «correggere» con sicurezza un riferimento
regolatorio e sbagliare, mentre un modello senza accesso alle fonti rifiutava, correttamente, di
rispondere. La lezione non è che un lignaggio sia superiore. È che un singolo lignaggio —
qualunque — non può controllare sé stesso. Nulla viene spedito senza essere passato per la
confutazione. Ogni rilievo che sopravvive viene poi confermato contro il codice sorgente reale —
file e riga esatti, percorso di riproduzione, classificazione d'impatto, con citazioni risolte
meccanicamente contro la revisione precisa esaminata — oppure etichettato esplicitamente come
*solo plausibile*. Ogni rilievo nomina il gradino di evidenza effettivamente raggiunto — traccia
nel sorgente, prova di compilazione, test o riproduzione dal vivo — e non ne lascia mai
intendere uno superiore. E ogni rapporto porta un impegno permanente di ritrattazione: se un
rilievo è dimostrato errato, viene ritrattato per iscritto.

In altre parole: dove la revisione dell'era IA genera rumore su scala industriale, l'output di
CounterProof è deliberatamente l'opposto di una coda di triage. È una valutazione firmata,
graduata per evidenza, sotto un identificatore di incarico persistente — strutturata per essere
consegnata a un team di due diligence o a un assicuratore, o inclusa nella documentazione
tecnica CRA come relazione di prova nella forma dell'allegato VII, punto 6), a riprova
dell'obbligo di prova. L'indipendenza è strutturale: non emettiamo alcuna valutazione su codice
scritto da CounterProof o da qualsiasi società del nostro gruppo — e la nostra stessa base di
codice, in gran parte scritta dalle macchine, passa continuamente per lo stesso registro
avversariale. Siamo stati il nostro primo cliente, e restiamo il più esigente.

Lanceremo a breve un nuovo servizio su **CounterProof.io**, che estende questa practice ai team
che affrontano esattamente la convergenza descritta in questo articolo: codice scritto dalle
macchine, avversari a velocità di macchina e l'orologio di un regolatore. Presto maggiori
dettagli.

## Dove va a finire

Tre previsioni, tenute con presa leggera.

Primo: il divario di triage si allarga prima di chiudersi. I modelli a pesi aperti continueranno
a migliorare, scansioni come quella del Bitcoin Red Team verranno ripetute in altri ecosistemi,
e il rapporto tra rilievi candidati e verificati peggiorerà prima che gli strumenti di
valutazione e i metodi disciplinati recuperino. I progetti saranno sempre più giudicati — da
utenti, assicuratori e acquirenti allo stesso modo — sulla loro velocità di risposta alle
divulgazioni, esattamente come ha osservato Calle.

Secondo: il CRA diventa la funzione di forzatura che i bug bounty non sono mai stati. Le norme
di divulgazione volontaria hanno prodotto per un decennio una copertura a macchia di leopardo;
un obbligo di notifica in 24 ore con sanzioni scalate sul fatturato farà in diciotto mesi ciò
che la buona volontà non ha fatto — e la domanda di prove di sicurezza periodiche, indipendenti
e di qualità documentale ristrutturerà il mercato dell'audit attorno all'evidenza anziché ai
distintivi.

Terzo, e più fondamentale per Bitcoin: un ecosistema il cui modello di sicurezza poggia sulla
revisione aperta sta per scoprire se la revisione delle macchine conta. La risposta onesta: conta
solo quando una parte indipendente è disposta a verificare il rilievo, graduare l'evidenza e
firmare. Il rilevamento è stato automatizzato. La responsabilità no — e non può esserlo. È lì
che vivono ora il valore, e la responsabilità.

---

*CounterProof è una practice indipendente di revisione avversariale di Clavestra Capital Limited
(Malta). Proof attesta; CounterProof confuta. counterproof.io — Questa pagina è una traduzione
dell'originale inglese; in caso di divergenza prevale l'originale.*

---

**Fonti:** avviso di sicurezza di Coinkite e copertura di Forbes, Bloomberg, CBC e Galaxy
Research sull'exploit ColdCard (lug–ago 2026); divulgazioni del Bitcoin Red Team via Bitcoin
Magazine, Decrypt, crypto.news, Coinpaper e Metaverse Post (ago 2026); note di rilascio di
BTCPay Server 2.4.2; valutazione congiunta dei modelli UK AISI / US CAISI; Sonatype State of the
Software Supply Chain 2026; Google Threat Intelligence Group, rapporto sull'attività di minaccia
assistita dall'IA (2026); analisi StepSecurity della compromissione dell'SDK Injective
(lug 2026); copertura degli incidenti della filiera npm (set 2025 – mar 2026); regolamento (UE)
2024/2847 (Cyber Resilience Act), artt. 13–14, 16, 69, allegati I e VII.