samczsun: La sicurezza dei protocolli crypto dipende principalmente da una revisione proattiva degli audit

I programmi di ricompensa per la segnalazione di vulnerabilità sono misure passive, mentre la protezione della sicurezza richiede un approccio proattivo.

Autore: samczsun, fondatore di Security Alliance, ex partner di ricerca di Paradigm

Oggi il settore ha raggiunto un consenso: la protezione della sicurezza delle criptovalute deve seguire tre passaggi chiave: scrivere casi di test nella fase di sviluppo per individuare errori di base; condurre revisioni complete tramite audit e competizioni prima del deployment; istituire programmi di ricompensa per la segnalazione di vulnerabilità, premiando i ricercatori che segnalano responsabilmente le vulnerabilità per prevenire attacchi. La diffusione di queste best practice ha ridotto notevolmente il numero di vulnerabilità on-chain, costringendo gli attaccanti a rivolgersi a vulnerabilità off-chain come il furto di chiavi private e l'intrusione nelle infrastrutture.

Tuttavia, anche i protocolli sottoposti a audit completi e che offrono generose ricompense per le vulnerabilità subiscono occasionalmente attacchi hacker. Questi eventi non solo colpiscono il protocollo coinvolto, ma minano anche la fiducia dell'intero ecosistema. I recenti attacchi hacker a Yearn e Balancer V2, così come gli incidenti di sicurezza di Abracadabra e 1inch all'inizio dell'anno, dimostrano che anche i protocolli più collaudati non sono assolutamente sicuri. Il settore delle criptovalute avrebbe potuto evitare questi attacchi? O sono semplicemente il prezzo inevitabile della finanza decentralizzata?

I commentatori spesso sostengono che aumentare le ricompense per le vulnerabilità avrebbe potuto proteggere questi protocolli. Ma anche tralasciando le considerazioni economiche, la ricompensa per le vulnerabilità è essenzialmente una misura di sicurezza passiva, che affida il destino del protocollo agli hacker white hat, mentre l'audit rappresenta una misura proattiva di autodifesa da parte del protocollo. Aumentare le ricompense per le vulnerabilità non può fermare gli attacchi hacker, perché equivale a raddoppiare la scommessa, puntando sul fatto che gli hacker white hat scoprano le vulnerabilità prima dei black hat. Se un protocollo vuole davvero proteggersi, deve intraprendere attivamente nuovi audit.

Fondi del tesoro e valore totale bloccato (TVL)

A volte gli hacker accettano di restituire la maggior parte dei fondi rubati, trattenendo solo una piccola parte (di solito il 10%) come ricompensa. Purtroppo, il settore chiama questa parte "white hat bounty", il che solleva una domanda: perché il protocollo non offre direttamente la stessa cifra tramite un programma di ricompensa, evitando così la fatica delle trattative? Ma questo ragionamento confonde i fondi che un attaccante può rubare con quelli che il protocollo può effettivamente disporre.

Anche se in apparenza sembra che il protocollo possa utilizzare entrambi i tipi di fondi per la sicurezza, in realtà il protocollo ha il controllo legale solo sui fondi del proprio tesoro, non su quelli depositati dagli utenti. È altamente improbabile che gli utenti concedano in anticipo tale autorizzazione al protocollo; solo in situazioni di crisi (ad esempio, quando i depositanti devono scegliere tra perdere il 10% o il 100% dei loro depositi) permetterebbero al protocollo di utilizzare i depositi per negoziare. In altre parole, il rischio cresce insieme al TVL, ma il budget per la sicurezza non può aumentare di pari passo.

Efficienza del capitale

Anche se un protocollo dispone di fondi sufficienti (ad esempio, un grande tesoro, forte redditività o una politica di commissioni per la sicurezza già implementata), la questione di come allocare razionalmente questi fondi per la sicurezza rimane complessa. Rispetto all'investimento in nuovi audit, aumentare le ricompense per le vulnerabilità è, nella migliore delle ipotesi, estremamente inefficiente dal punto di vista del capitale e, nella peggiore, può portare a un disallineamento degli incentivi tra protocollo e ricercatori.

Se la ricompensa per le vulnerabilità è legata al TVL, quando i ricercatori sospettano che il TVL del protocollo aumenterà e che la probabilità di vulnerabilità ripetute sia molto bassa, avranno chiaramente più motivazione a nascondere vulnerabilità critiche. Questo finisce per mettere i ricercatori in diretta opposizione al protocollo, danneggiando gli interessi degli utenti. Aumentare semplicemente la ricompensa per le vulnerabilità critiche difficilmente raggiunge l'effetto desiderato: la comunità dei ricercatori freelance è ampia, ma pochissimi dedicano la maggior parte del loro tempo alle ricompense per le vulnerabilità e hanno le competenze necessarie per scoprire vulnerabilità in protocolli complessi. Questi ricercatori d'élite concentrano il loro tempo sui programmi di ricompensa che offrono il miglior ritorno sull'investimento. Per i protocolli di grandi dimensioni e collaudati, poiché si presume siano sempre sotto l'occhio attento di hacker e altri ricercatori, la probabilità di scoprire una vulnerabilità è considerata minima, quindi nessuna ricompensa sarà sufficiente ad attirare la loro attenzione.

Nel frattempo, dal punto di vista del protocollo, la ricompensa per le vulnerabilità è una somma riservata per pagare una singola vulnerabilità critica. A meno che il protocollo non sia disposto a scommettere che non si verificheranno mai vulnerabilità critiche e a nascondere la propria situazione di liquidità ai ricercatori, questi fondi non possono essere utilizzati per altri scopi. Invece di aspettare passivamente che i ricercatori scoprano vulnerabilità critiche, è meglio utilizzare la stessa cifra per condurre più audit nel corso degli anni. Ogni revisione garantisce l'attenzione dei migliori ricercatori e non limita artificialmente la scoperta a una sola vulnerabilità, mantenendo anche allineati gli interessi tra ricercatori e protocollo: se il protocollo viene sfruttato, entrambe le parti subiscono un danno reputazionale.

Precedenti esistenti

Nel settore del software e della finanza, l'audit annuale è una pratica consolidata e comprovata, nonché il modo migliore per valutare se un'azienda è in grado di affrontare un ambiente di minacce in continua evoluzione. Il rapporto SOC 2 Type II viene utilizzato dai clienti B2B per valutare se i fornitori mantengono adeguati controlli di sicurezza; la certificazione PCI DSS dimostra che un'azienda ha adottato misure adeguate per proteggere le informazioni di pagamento sensibili; il governo degli Stati Uniti richiede che le parti che accedono alle informazioni governative ottengano la certificazione FedRAMP per mantenere elevati standard di sicurezza.

Sebbene gli smart contract siano di per sé immutabili, l'ambiente in cui operano non è statico. Le impostazioni di configurazione possono cambiare nel tempo, le dipendenze possono essere aggiornate e schemi di codice ritenuti sicuri potrebbero in realtà essere rischiosi. L'audit di un protocollo valuta la sicurezza al momento dell'audit, ma non garantisce la sicurezza futura del protocollo. L'unico modo per aggiornare questa valutazione è condurre un nuovo audit.

Nel 2026, il settore delle criptovalute dovrebbe adottare l'audit annuale come quarto passaggio per la protezione della sicurezza dei protocolli. I protocolli esistenti con un alto TVL dovrebbero condurre nuovi audit sulle proprie implementazioni; le società di audit dovrebbero offrire servizi specializzati di revisione focalizzati sulla valutazione dell'intera implementazione; l'intero ecosistema dovrebbe cambiare collettivamente la percezione dei rapporti di audit: sono solo valutazioni della sicurezza in un momento specifico, possono scadere e non rappresentano una garanzia di sicurezza permanente.