Gran parte dei consigli di sicurezza per gli utenti cripto si concentra sulle superfici che puoi vedere: la tua frase seme, i link che tocchi, i siti su cui accedi. Sono importanti. Ma c'è un rischio più silenzioso sotto tutto questo: il software stesso, e tutto ciò con cui è stato costruito. Un wallet può essere scritto alla perfezione e distribuire comunque una backdoor, perché le applicazioni moderne sono assemblate a partire da centinaia di blocchi di terze parti e da una pipeline di build che trasforma il codice sorgente nel binario che installi. Comprometti un anello qualsiasi di quella catena e comprometti ogni utente a valle.
Questa è la catena di fornitura del software, e gli attaccanti hanno capito che è uno dei bersagli a più alta leva nel mondo cripto. Questo articolo spiega cos'è davvero un attacco alla catena di fornitura, perché i wallet sono bersagli così attraenti, le difese che reggono nella pratica e cosa ti offrono le build deterministiche, compreso come SSP applica tutto questo.
Cos'è un attacco alla catena di fornitura
Un attacco alla catena di fornitura non irrompe direttamente nell'applicazione. Compromette invece qualcosa di cui l'applicazione si fida: una dipendenza che importa, l'account di un manutentore o la pipeline di build che assembla l'artefatto finale. Il codice malevolo entra tramite un aggiornamento legittimo, firmato e consegnato attraverso i canali normali, quindi appare esattamente come il software che intendevi installare.
Quell'indirezione è tutto il punto. Attaccare una libreria molto usata — o un server di build — può raggiungere migliaia di progetti a valle e milioni di utenti in una sola volta. Per un wallet cripto il guadagno è diretto: il codice che gira dentro il tuo wallet ha già accesso al momento che conta, quando una transazione viene firmata e gli indirizzi vengono mostrati. Una sola dipendenza manomessa può sostituire un indirizzo di destinazione o esfiltrare materiale delle chiavi senza mai raggiungerti tramite phishing o una debole igiene della frase seme. Ecco perché questa classe di attacco merita un posto nel tuo modello mentale.
Due casi che colpiscono da vicino
Due incidenti reali mostrano come si svolge tutto questo: uno mirato direttamente alla cripto, uno che ha quasi colpito l'intera internet.
event-stream e il wallet Copay
Nel 2018 un popolare pacchetto npm chiamato event-stream fu ceduto a un nuovo manutentore volontario che si era offerto di aiutare. Fu un passaggio di routine, dall'aria ben intenzionata, del tipo che accade di continuo nell'open source. Il nuovo manutentore aggiunse poi una nuova dipendenza, flatmap-stream, che conteneva codice malevolo offuscato.
Il payload era insolitamente mirato. Invece di attivarsi per tutti, si attivava solo dentro un progetto a valle specifico: il wallet Bitcoin Copay. Lì era stato costruito per rubare il materiale del seme e i fondi degli utenti di quell'applicazione. La maggior parte degli sviluppatori che avevano importato event-stream non fu mai colpita: il codice sapeva esattamente quale vittima stava cercando.
È il promemoria canonico che "ho installato solo una piccola libreria" non è mai la storia completa. Hai installato anche tutto ciò di cui quella libreria si fida.
La backdoor di XZ Utils
L'incidente di XZ Utils del 2024 (CVE-2024-3094) fu ancora più paziente. XZ Utils è una libreria di compressione presente in sordina sulla maggior parte dei sistemi Linux. Nel corso di anni un attaccante ha costruito fiducia come collaboratore disponibile, ha gradualmente ottenuto responsabilità di manutenzione e poi ha inserito una backdoor progettata per interferire con OpenSSH, il software che protegge gli accessi remoti ai server ovunque.
Fu scoperta quasi per caso, da un ingegnere che notò un ritardo di una frazione di secondo. Se si fosse diffusa ampiamente, avrebbe potuto consegnare accesso remoto a innumerevoli macchine.
La lezione per la cripto è dura: l'attacco non ha sfruttato un bug ingegnoso, ha sfruttato il modello di fiducia dell'open source stesso, giocando una partita di ingegneria sociale durata anni per diventare la persona su cui tutti facevano affidamento.
Le difese che funzionano davvero
Nessun controllo isolato ferma gli attacchi alla catena di fornitura. Ciò che funziona è una pila di controlli, ciascuno dei quali restringe le opzioni dell'attaccante:
- Dipendenze bloccate e lockfile. Bloccare versioni esatte e versionare un lockfile significa che una build non può tirare in silenzio una release più recente e manomessa. Gli aggiornamenti diventano eventi deliberati e revisionabili, non automatici.
- Dipendenze minime. Ogni pacchetto che aggiungi è una parte di cui ti fidi. Meno dipendenze significano una superficie di attacco più piccola e meno manutentori che potrebbero essere compromessi.
- Sandboxing delle dipendenze. Strumenti come LavaMoat limitano ciò che ogni pacchetto può fare a runtime, così una dipendenza compromessa non può raggiungere liberamente la rete o API sensibili.
- Firma del codice. Le release firmate consentono agli utenti di verificare che un binario provenga dal vero editore e non sia stato alterato in transito.
- Audit di terze parti. Società di sicurezza indipendenti esaminano il codice e le dipendenze con occhio avversario, cogliendo ciò che i team interni normalizzano.
- Build riproducibili e deterministiche. La difesa strutturale più forte, e quella che vale la pena capire nel dettaglio.
Build deterministiche, spiegate
Normalmente, compilare due volte lo stesso codice sorgente può produrre due binari leggermente diversi: vi si insinuano marche temporali, ordine dei file e dettagli della macchina di build. Quella variabilità è un problema, perché significa che non puoi distinguere una differenza benigna da una malevola.
Una build deterministica (o riproducibile) elimina quella variabilità. Dato lo stesso codice sorgente, chiunque, ovunque, su qualsiasi macchina, produce un artefatto identico byte per byte. L'implicazione è potente: persone indipendenti possono ricompilare il wallet dal suo codice sorgente pubblico e confermare che il binario che hai scaricato corrisponde, bit per bit, a ciò che il codice sorgente produce. Se un attaccante ha manomesso la pipeline di build o vi ha inserito qualcosa dopo, gli hash non combaceranno e la manomissione diventa subito visibile.
Questo ribalta il modello di fiducia. Non devi più credere all'editore sulla parola; la verifica diventa qualcosa che l'intera comunità può eseguire e incrociare. Il progetto Reproducible Builds documenta questa pratica in tutto l'ecosistema, e framework come SLSA definiscono livelli di garanzia di integrità della build che puoi pretendere da un progetto.
Come SSP applica tutto questo
SSP tratta la pipeline di build come parte del proprio modello di minaccia, non come un ripensamento. Il wallet viene distribuito con una build deterministica basata su Dockerfile: lo stesso ambiente definito da Docker produce lo stesso artefatto ogni volta, così una release pubblicata può essere ricompilata dal codice sorgente pubblico e confrontata, bit per bit, con ciò che hai scaricato. SSP si è inoltre sottoposto a revisioni di sicurezza indipendenti da parte di Halborn, i cui audit esaminano sia il codice sia le dipendenze su cui si basa.
C'è un ulteriore strato, specifico di come è costruito SSP, e qui conta. SSP è un wallet multisig 2 di 2: ogni transazione richiede un'approvazione indipendente di una seconda chiave, la SSP Key, su un dispositivo separato. Sii preciso su ciò che questo fa e non fa. Le build deterministiche e gli audit riducono la probabilità che una build manomessa venga distribuita in primo luogo; sono la prima linea. Ma anche nel caso peggiore — una build che in qualche modo sia passata — la seconda chiave è una superficie di approvazione separata che deve comunque firmare ogni transazione.
Non è uno scudo magico, e non rende accettabile una build compromessa. Significa semplicemente che un singolo componente manomesso su un dispositivo non muove da solo i tuoi fondi. La difesa in profondità è il punto.
Cosa puoi verificare da solo
Non devi essere un ingegnere della sicurezza per trarre beneficio da tutto questo. Poche abitudini fanno molta strada:
- Scarica solo da fonti ufficiali. Prendi il wallet dal suo sito ufficiale o dalla scheda dello store, mai da un link in un messaggio o in un annuncio di ricerca. È la stessa disciplina trattata nell'igiene delle estensioni del browser.
- Preferisci progetti che pubblicano build deterministiche e audit. Un progetto che lascia alla comunità la verifica delle proprie release — e paga per una revisione indipendente — ti dice qualcosa su come ragiona.
- Verifica firme e hash quando vengono offerti. Se una release include una firma o un checksum, dedica il minuto a controllarli. Le build riproducibili ti proteggono solo se qualcuno fa davvero il confronto.
- Mantieni salda la tua opsec complessiva. Le difese della catena di fornitura stanno dentro un quadro più ampio; ripassa regolarmente la tua checklist di opsec così nessuno strato porta tutto il peso.
Niente di tutto questo richiede di fidarsi di una sola parte. È esattamente la proprietà che vuoi da un software di auto-custodia.
Continua così
Un wallet è affidabile solo quanto la catena che lo ha costruito. La buona notizia è che questo è uno dei pochi problemi di sicurezza con una risposta netta e strutturale: build deterministiche più audit indipendenti trasformano il "fidati di noi" nel "verificalo tu stesso".
Continua a costruire le tue difese con la consapevolezza del phishing, le buone pratiche della frase seme, l'igiene delle estensioni del browser e una checklist di opsec periodica. Ognuna chiude una porta; insieme sono ciò a cui assomiglia davvero la sicurezza in auto-custodia.
