Il crollo da 763,9 milioni di dollari: perché gli audit degli smart contract non sono riusciti a impedire il peggior trimestre del Web3

Analisi della sicurezza nel secondo trimestre del 2026

Il secondo trimestre del 2026 è stato il periodo più critico per la sicurezza del Web3 dal secondo trimestre del 2025, con gli autori delle minacce che hanno sottratto 763,9 milioni di dollari in 67 incidenti di sicurezza. Il cambiamento determinante del trimestre è stato un mutamento fondamentale nei profili di vulnerabilità: il codice non è più la principale superficie di attacco; lo sono invece i controlli operativi e la gestione delle chiavi.

Oltre l’88% delle perdite totali è derivato da compromissioni operative piuttosto che da difetti nella logica degli smart contract. Il capitale istituzionale si sta già adeguando, spostando le priorità della due diligence dagli audit puntuali verso il monitoraggio continuo, la governance degli accessi privilegiati e i modelli di autorizzazione multipartecipanti.

Secondo il rapporto trimestrale di Hacken sulla sicurezza e la conformità, le violazioni relative alle chiavi e alle infrastrutture hanno rappresentato l’88,3% di tutti i fondi sottratti, pari a circa 674,5 milioni di dollari. I bug degli smart contract sono rimasti il tipo di attacco più comune — 44 su 67 incidenti — ma hanno rappresentato solo circa l’11% delle perdite totali. Circa il 75,5% di tutte le perdite è derivato da soli due incidenti attribuiti ad attori malintenzionati nordcoreani, mentre solo il 9% dei progetti monitorati mantiene un monitoraggio continuo e il 4% combina audit, programmi di bug bounty e monitoraggio in tempo reale.

Un risultato fondamentale emerso dal secondo trimestre è che 14 protocolli sottoposti ad audit sono stati violati: un chiaro indicatore del divario crescente tra ciò che un audit degli smart contract valuta effettivamente e i punti in cui gli autori delle minacce colpiscono realmente. Per gli esperti di sicurezza, queste violazioni mettono a nudo il difetto fatale di considerare una revisione del codice in un determinato momento come uno scudo di sicurezza onnicomprensivo.

«L’errore più diffuso è pensare che un audit sia un certificato di sicurezza», ha affermato Leo Fan, fondatore di Cysic. «In realtà si tratta di una valutazione circoscritta di un particolare codice in un determinato momento. Un audit non copre automaticamente i dispositivi dei firmatari, l’infrastruttura cloud, le autorizzazioni operative, il bytecode distribuito, gli aggiornamenti successivi, le dipendenze di terze parti o i vecchi contratti che rimangono richiamabili.” Eric Swartz, socio fondatore e consulente legale di Panther Hollow Ventures, ha ribadito che considerare gli audit come un traguardo finale lascia i protocolli esposti. "Un audit descrive lo stato di un sistema in un determinato momento", ha affermato Swartz. "Non garantisce che futuri aggiornamenti, cambiamenti operativi o nuovi metodi di attacco non introducano rischi. I team più competenti considerano gli audit come una parte di un programma di sicurezza molto più ampio".

Samuel Videau, CTO di Genius, ha osservato che la sezione relativa all’ambito di applicazione di un rapporto di audit spesso rivela ciò che non è stato valutato. "Quasi il 90% delle perdite del secondo trimestre è derivato da chiavi, firmatari e infrastruttura, tutti elementi al di fuori di quella sezione, e 14 progetti sottoposti ad audit sono stati comunque svuotati", ha affermato Videau. "Il rapporto di audit non è il programma di sicurezza." Himanshu Sahay, CTO e cofondatore di Arch, ha sottolineato che gli audit non possono essere considerati a sé stanti. «Un audit è un’importante valutazione puntuale del codice e dell’architettura esaminati, ma non può tenere conto di ogni rischio operativo o di ogni futuro cambiamento al sistema», ha affermato Sahay. «La sicurezza deve essere considerata come un processo continuo».

Aggirare il codice: il punto debole dell’infrastruttura off-chain

Nel frattempo, man mano che le difese degli smart contract maturano e la logica on-chain diventa sempre più difficile da compromettere, gli autori delle minacce hanno cambiato strategia in modo decisivo. Anziché sfondare porte d’ingresso pesantemente sorvegliate, gli aggressori stanno sistematicamente aggirando completamente il codice per sfruttare il punto debole dell’infrastruttura off-chain.

"La superficie più sottovalutata è il piano di controllo off-chain: dispositivi di firma, procedure di generazione e rotazione delle chiavi, identità cloud, pipeline CI/CD, servizi di backend, validatori di bridge e percorsi amministrativi di emergenza", ha affermato Fan. «Spesso i team proteggono l’archiviazione delle chiavi, ma prestano meno attenzione a come queste vengono effettivamente utilizzate… una volta compromesse, gli aggressori possono generare transazioni tecnicamente valide on-chain, rendendo la prevenzione e il rilevamento molto più difficili». Il perimetro del cloud stesso offre un falso senso di sicurezza a molti sviluppatori Web3.

"Il presupposto principale è che l’utilizzo di un grande provider cloud renda un’applicazione sicura per impostazione predefinita", ha affermato Jerald David, CEO di Lynq. "I provider cloud proteggono l’infrastruttura sottostante, ma i team sono comunque responsabili di come vengono configurati i sistemi, di come vengono gestite le credenziali e di chi ha accesso".

Videau, dal canto suo, ha avvertito che un’architettura inadeguata può vanificare la protezione multisig. “L’intera operazione si basa su ruoli di servizio con autorizzazioni eccessive e pipeline CI/CD che possono accedere alle chiavi di produzione; se un account di servizio è in grado di leggere la vostra chiave di firma, la vostra multisig è solo una farsa”, ha affermato Videau. «I contratti obsoleti che detengono ancora diritti di amministratore rappresentano un altro vettore di attacco: il codice che avete distribuito due anni fa è una porta aperta, e agli aggressori non interessa cosa voi consideriate all’interno dell’ambito di applicazione».

Man mano che gli allocatori istituzionali ricalibrano i propri modelli di rischio, la soglia per l’impiego del capitale si è alzata in modo significativo. L’idoneità per gli investitori istituzionali non è più definita da un rapporto di audit ineccepibile, ma dalla dimostrazione di maturità operativa, governance di livello aziendale e controlli resilienti sulla gestione delle chiavi.

«Io guardo innanzitutto alla maturità operativa», ha detto David. «Il team è in grado di spiegare chiaramente come il capitale si muove all’interno del sistema, dove si trovano i punti chiave di controllo e come vengono monitorati i rischi? Gli investitori istituzionali hanno bisogno di prevedibilità e trasparenza».

Sahay ha osservato che nessun singolo controllo garantisce di per sé il sostegno istituzionale. «Gli investitori istituzionali vogliono capire come si accede ai sistemi critici, come vengono gestite le autorizzazioni, come viene monitorata l’attività e quali processi esistono nel caso in cui qualcosa vada storto», ha affermato Sahay. «È la combinazione di controlli rigorosi, trasparenza e disciplina operativa che, in ultima analisi, crea fiducia».

Nel valutare i protocolli, Fan si concentra sulla mappa dei privilegi: chi può trasferire asset, sostituire i firmatari o modificare le misure di sicurezza. «Se dovessi identificare un controllo che più di ogni altro è associato alla fiducia delle istituzioni, sarebbe l’autorizzazione multiparte in ogni percorso di trasferimento di asset e di aggiornamento», ha affermato Fan. «Le istituzioni vogliono la prova che un’azione unilaterale sia impossibile».

Swartz ha aggiunto che le istituzioni danno priorità al modo in cui i team gestiscono le avversità. "Le istituzioni sanno che nessun protocollo è completamente privo di rischi", ha affermato Swartz. "Ciò che conta è se il team dispone di una buona governance, di solidi controlli interni, di trasparenza sui rischi e di un piano chiaro per reagire quando qualcosa va storto".

I cinque esperti concordano sul fatto che il Web3 debba adottare sistemi di difesa a più livelli che includano monitoraggio in tempo reale, gestione disciplinata delle chiavi e programmi di bug bounty reattivi per proteggersi dalle minacce in continua evoluzione.

«Gli asset digitali operano 24 ore su 24, ma alcune parti dell’infrastruttura che li supporta funzionano ancora secondo i tradizionali orari finanziari», ha osservato David. «Man mano che il mercato diventa più istituzionale, anche l’infrastruttura che supporta il movimento e il regolamento dei capitali deve diventare più resiliente».

Prospettive per il secondo semestre del 2026: riallineamento delle strutture di difesa

Gli esperti, nel frattempo, avvertono che la seconda metà del 2026 porterà un’ulteriore continuazione di questa tendenza. Anziché sprecare risorse nel tentativo di decodificare smart contract già sottoposti a revisione, si prevede che gli autori delle minacce continueranno a perseguire la via della minima resistenza: controlli operativi, bersagli umani e infrastrutture chiave.

«Mi aspetto che gli attacchi operativi al controllo degli accessi continuino a dominare le perdite: ingegneria sociale, furto di credenziali, compromissione dei firmatari, intrusioni nel cloud o nei sistemi CI/CD e attacchi alle infrastrutture dei validatori off-chain», ha previsto Fan. «I singoli bug negli smart contract continueranno a verificarsi, ma gli aggressori continueranno a puntare sul percorso più breve per ottenere l’autorità».

Videau ha concluso con un appello a riallineare la spesa per la sicurezza al rischio effettivo: «Investite dove si verificano le perdite. Quasi il 90% dei fondi rubati è transitato attraverso chiavi, firmatari e infrastrutture, eppure i budget continuano a essere destinati alle revisioni dei contratti. Gli attacchi peggiori saranno quelli che nessuno ha previsto, quindi costruite la vostra difesa come se il vostro perimetro fosse già stato violato».