Bitcoin Core ha ragione: se un'IA trova il bug, la segretezza è solo teatro

A cosa serve un segreto che qualsiasi chatbot può rigenerare con un solo prompt? È, in sostanza, la domanda a cui Bitcoin Core ha appena risposto, e secondo noi ha risposto bene.

Giovedì 22 ottobre il progetto ha integrato una modifica alla propria policy di sicurezza, scritta da Antoine Poinsot, sviluppatore di Chaincode Labs. Finora Core classificava ogni vulnerabilità in base alla gravità e programmava la divulgazione di conseguenza. Le falle di bassa gravità venivano rivelate due settimane dopo il rilascio della versione principale successiva. Quelle di gravità media e alta potevano restare nascoste fino a due settimane dopo la fine del supporto dell'ultima versione interessata, un'attesa che può arrivare a circa un anno. Ora i maintainer possono etichettare un bug come «facilmente individuabile» durante il triage. L'etichetta riguarda un bug che si può trovare con un semplice prompt a un LLM. Per un bug di questo tipo, la correzione viene retroportata su tutte le versioni mantenute, viene rilasciata il prima possibile una point release e viene pubblicato un avviso di sicurezza con alcuni dettagli. I bug critici restano fuori dalla policy standard e sono gestiti caso per caso.

L'embargo era una scommessa sulla difficoltà, e le probabilità sono cambiate

Un lungo embargo funziona solo se è improbabile che gli aggressori trovino la falla da soli. Correggere in silenzio dà ai gestori dei nodi il tempo di aggiornarsi prima che qualcuno sappia dove si trova il punto debole. La diagnosi di Poinsot stesso, citata da CoinDesk, è che gli LLM hanno abbassato «drasticamente» la soglia per trovare certe classi di problemi o per individuare correzioni nascoste. Quest'ultimo punto è il più sottovalutato. Una patch silenziosa è già di per sé un indizio, e un modello sa leggere un diff.

Per questo tipo di bug, quindi, l'embargo non protegge nessuno tranne l'aggressore, che già sa. Intanto gli utenti onesti restano su vecchie versioni non corrette in attesa di una versione principale. La policy lo dice chiaramente: «Il periodo di embargo ottiene poco, ma ritarda la disponibilità di una versione corretta».

Le prove dicono che non è un'ipotesi

Pensa a quanto è successo quest'estate. Un gruppo di volontari di 16 sviluppatori, il Bitcoin Red Team, ha fatto girare modelli di IA su 390 progetti Bitcoin in circa un giorno e ha registrato 4.962 risultati, 85 dei quali critici, secondo CoinDesk. Non tutti sono stati riprodotti (un rapporto sostiene che solo circa un quinto lo fosse a quel punto), quindi il numero va letto con questa cautela. Eppure, nel giro di pochi giorni una falla in BTCPay Server, che il gruppo aveva segnalato in privato, veniva sfruttata su server reali di commercianti. La segnalazione privata non ha anticipato gli aggressori.

Il quadro più ampio va nella stessa direzione. Una nota di ricerca della Cloud Security Alliance sostiene che il modello classico di divulgazione coordinata, con la sua tipica finestra di 90 giorni, è stato pensato per ricercatori umani che lavorano a ritmo umano. Leggiamo la decisione di Bitcoin come un caso concreto di questa tesi.

La trasparenza ha un prezzo, e vale la pena pagarlo

Il cambiamento non è gratis. Poinsot ammette che le correzioni più rapide hanno meno «tempo di maturazione» nei test. È un rischio reale, perché una patch frettolosa su un software che protegge una rete enorme può andare storta. L'alternativa proposta dallo sviluppatore Antoine Riard, rilasciare in alcuni casi le correzioni senza avviso, è stata respinta, e siamo d'accordo con il rifiuto. Poinsot ha sostenuto che avvisare gli utenti senza dettagli potrebbe provocare migrazioni affrettate da parte di persone che non sarebbero nemmeno coinvolte. La segretezza a metà ti dà il panico senza l'informazione.

C'è anche una preoccupazione legittima sulla linea di confine stessa. Nessun bug è ancora stato segnalato con la nuova regola, quindi, come nota Crypto Briefing, resta da vedere con quanta coerenza i maintainer decideranno cosa sia «facilmente individuabile». Un'etichetta vaga potrebbe diventare una scappatoia in entrambe le direzioni. Secondo noi il criterio è onesto, perché dipende da quanto è facile trovare una falla e non dallo strumento che l'ha trovata.

Cosa dovrebbero imparare gli altri progetti

La lezione non è «divulgare tutto subito». I bug difficili da trovare meritano ancora tempo, e Core mantiene per loro il calendario in base alla gravità. La lezione è che l'ipotesi di partenza si è capovolta. I progetti dovrebbero ora chiedersi se un bug possa essere riscoperto a basso costo e, in tal caso, mettere la velocità della patch davanti alla discrezione. I progetti open source critici con una cultura lenta degli aggiornamenti hanno più da guadagnare, perché hanno più da perdere con una lunga finestra di esposizione.

Il nostro verdetto: Bitcoin Core ha fatto una mossa pragmatica e un po' scomoda, ed è quella giusta. Gli operatori dovrebbero tenere d'occhio point release e avvisi ed essere pronti ad aggiornare in fretta. Tutti gli altri che mantengono codice molto diffuso dovrebbero rivedere le proprie regole di embargo e chiedersi quali proteggano ancora gli utenti e quali proteggano solo l'abitudine.