Perché la sicurezza in DeFi decide tutto
La DeFi cresce rapidamente e, insieme a essa, crescono anche gli attacchi. Dai bug negli smart contract alla compromissione di interfacce e bridge: le vulnerabilità emergono sia nel codice sia nell'economia dei protocolli e nel comportamento degli utenti. Per questo l'approccio “speriamo bene” non funziona più: la sicurezza non è un evento, ma un processo.
Obiettivo del materiale: innanzitutto strutturare i rischi principali (tecnici, economici e sociali); poi analizzare casi emblematici; infine dare pratiche concrete di protezione per team e utenti.
Da cosa è composta la sicurezza DeFi
Codice: smart contract, librerie, compilatori, proxy di upgrade.
Economia del protocollo: tokenomics, regole di liquidazione, oracoli, parametri dei mercati.
Interfacce e DevOps: sito/frontend, chiavi admin, CI/CD, fornitori di infrastruttura.
Livello umano: utenti, moderatori, sviluppatori, controparti, procedure operative.
Metriche e SLO di sicurezza
| 🧭 Metrica | 🎯 Obiettivo (SLO) | 📐 Come calcolarla | 🛠️ Cosa fare se devia |
|---|---|---|---|
| ⏱️ Time-to-Patch (TTP) | ≤ 48 h (critici) | Δ tra report e release del fix |
|
| 🔎 Copertura degli audit | ≥ 95% del codice critico | LOC dei moduli critici nella release |
|
| 🚨 MTTD / 🧯 MTTR | MTTD ≤ 10 min; MTTR ≤ 2 h | Log di alert/eventi di stop |
|
| 🏴 Salute del bug bounty | ≥ 1 critico/trimestre da white-hat | Report Immunefi/Code4rena |
|
| ⏸️ Copertura pause | 100% delle funzioni critiche pausabili | Indice pause() per mercati |
|
Indicatori chiave di maturità
- TVL e dinamica: non solo valore assoluto, ma anche stabilità. Picchi o deflussi improvvisi sono un motivo per indagare le fonti.
- Audit e bug bounty: report pubblici, SLA di remediation, attività dei white-hat.
- Governance e permessi: timelock, composizione dei multisig, vesting di team/investitori, quorum DAO.
- Riserve e assicurazione: pool/polizze assicurative, fondi di emergenza, riserve trasparenti.
- Track record: età, qualità dei post-mortem, come il progetto attraversa gli stress.
Modello di maturità della sicurezza
| 🪜 Livello | 📌 Caratteristiche | ➡️ Passo successivo |
|---|---|---|
| ❌ L0 “Alla buona” |
|
Multisig, audit base, bug bounty |
| 🟡 L1 “Base” |
|
2 audit, meccanismi di pause, monitoraggio on-chain |
| 🟢 L2 “Avanzato” |
|
Simulazioni red-team, IR-runbook |
| 🏆 L3 “Secure by default” |
|
Pentest indipendenti, mantenimento del livello |
Mappa delle minacce (sintesi)
| 🧩 Categoria | 🔎 Sottotipo | ⚠️ Rischio | 🎯 Cosa rompono | 🛡️ Protezione di base |
|---|---|---|---|---|
| ⚙️ Tecniche | Reentrancy, overflow, accessi | 🔴 Alto | Logica dei contratti |
|
| ⚙️ Tecniche | Flash loan, MEV/front-running | 🔴 Alto | Invarianti in un blocco |
|
| 📉 Economiche | Manipolazione di prezzi/oracoli | 🔴 Alto | Valutazione del collaterale |
|
| 📉 Economiche | Attacchi di governance | 🟠 Medio-alto | Tesoreria/impostazioni |
|
| 🎭 Sociali | Phishing, siti falsi, token airdrop | 🔴 Alto | Chiavi/firme |
|
| 🛠️ Infrastruttura | Compromissione UI/DNS/CDN, chiavi | 🔴 Alto | Frontend/accessi |
|
| 🔗 Cross-chain | Exploit dei bridge | 🔴 Critico | Custodie/validatori |
|
| 🧨 Scam | Rug pull, exit scam, honeypot | 🔴 Alto | Liquidità/permessi |
|
Vulnerabilità tecniche degli smart contract
Reentrancy ed errori di stato
Il classico del settore: il contratto permette a una chiamata esterna di rientrare nella funzione prima che i saldi siano aggiornati. Il risultato è che l'attaccante “svuota” ripetutamente i fondi. Per questo si usa il pattern Checks-Effects-Interactions, si aggiunge ReentrancyGuarde, ancora meglio, si riducono al minimo le chiamate esterne nelle parti critiche.
Controlli di accesso e proxy di upgrade
Ruoli admin/operator configurati male, così come proxy contract “bucati”, spesso portano a una compromissione totale. Da qui il principio del minimo privilegio, la separazione dei ruoli (admin/operator/pauser), i timelock sugli update e l'audit di tutti i percorsi di upgrade.
Flash loan e invarianti “in un blocco”
I prestiti istantanei sono neutrali di per sé; tuttavia amplificano gli attacchi quando gli invarianti vengono controllati solo sullo stato finale. Aiutano quindi prezzi TWAP, post-condizioni e controlli “sanitari” dopo una serie di operazioni, oltre a limiti sulla “forza” di una singola transazione.
MEV e front-running
Il mempool aperto crea la possibilità di “sandwich” sui DEX. Per le operazioni grandi hanno senso mempool/relay privati; lato protocollo servono meccaniche difensive (aste batch, ritardi casuali nella pubblicazione).
Threat modeling degli smart contract: modello rapido
Attori: utente, liquidatore, arbitraggista, admin/DAO, oracolo, bridge, contratti esterni.
Invarianti: chi e a quali condizioni può muovere un saldo/parametro? esistono post-condizioni?
Superficie: chiamate esterne, upgrade/proxy, ruoli, oracoli, pause/no-pause, limiti per blocco.
Abusi: reentrancy, composizioni con flash loan, MEV, liquidità sottile.
Difesa: CEI, ReentrancyGuard, timelock, multisig, TWAP/fonti multiple, limiti, pause.
Attacchi economici e manipolazioni
Manipolazione dei prezzi e oracoli
Se la “fonte della verità” può essere spostata, verrà spostata. Bassa liquidità, pool propri usati come oracolo, assenza di TWAP/fonti multiple: tutto questo è un invito all'attacco. Perciò si scelgono oracoli affidabili, si limita l'uso di token esotici come collaterale e si introduce un “limite di deviazione”.
Attacchi alla governance
Flash loan + quorum istantaneo = cattura di una DAO nello stesso blocco. Per non ripetere gli errori altrui, si introduce un timelock sull'esecuzione delle decisioni, si escludono i voti presi a flash loan e si richiede un quorum reale con periodo di discussione.
MEV: come viene sfruttato il mempool
- Attacchi sandwich: un bot compra l'asset prima del tuo ordine, spinge il prezzo e vende subito dopo: tu paghi peggio.
- Front-run/back-run: intercettazione di arbitraggi e liquidazioni vantaggiosi grazie alla priorità di inclusione.
- Back-running di TWAP/oracoli: spinta del prezzo verso il livello desiderato nella “finestra” di aggiornamento.
Bridge e rischi cross-chain
- Verifica dei messaggi: vulnerabilità di verifica/state proof → sostituzione del destinatario/proprietario.
- Centralizzazione delle firme: quorum M-su-N piccoli e sicurezza operativa debole dei validatori.
- Errori operativi: update errati, parametri non inizializzati, dipendenze obsolete.
Hardening di frontend e DevOps
- CSP + SRI: Content-Security-Policy rigorosa e Subresource Integrity su tutti gli script.
- HSTS/DNSSEC: HTTPS forzato e zone DNS protette.
- 2FA/SSO per gli admin: accesso a CDN/Git/CI tramite SSO, chiavi solo hardware (FIDO2).
- Gestione dei secret: rotazione dei token, “minimo privilegio”, deny-by-default.
- Monitoraggio dei diff del frontend: alert su modifiche di bundle/DOM; whitelist dei domini RPC.
Casi: dove e come la protezione è stata perforata
Curve Finance (2023): un bug nel compilatore Vyper ha rotto il reentrancy guard e ha permesso di svuotare pool con chiamate ripetute.
Ronin Bridge (2022): compromissione di 5 validatori su 9 (phishing + accessi eccessivi) che ha permesso di autorizzare prelievi enormi.
Mango Markets (2022): la manipolazione del prezzo poco liquido del token nativo ha aumentato il “valore” del collaterale e permesso il prelievo di tutti i fondi.
Euler (2023): un bug logico intorno a donateToReserves ha permesso di creare “bad debt” e sottrarre collaterali con una cascata di operazioni via flash loan.
Beanstalk (2022): voto istantaneo con voti ottenuti tramite flash loan che ha trasferito le riserve all'indirizzo dell'attaccante nello stesso blocco.
BadgerDAO (2021): compromissione del frontend che proponeva un Approveextra, dopo il quale i fondi sono stati prelevati in massa.
bZx (2021): phishing di uno sviluppatore → furto del seed → rifirma dei contratti e prelievo di asset su più reti.
Poly Network (2021): errore nella verifica dei messaggi cross-chain che ha permesso di sostituire il proprietario dello storage.
Metodi di protezione: approccio multilivello
Audit, test e bug bounty
Prima si eliminano i bug “a portata di mano” con audit e verifica; poi si modellano gli attacchi; infine si coinvolge la community tramite bug bounty.
- Audit in più fasi: società esterne + review interne; versioni fissate di compilatore/librerie; blocklist delle release vulnerabili.
- Verifica formale: bridge, tesoreria, circuiti di upgrade; simulazioni di attacchi tipici (reentrancy, flash loan, MEV).
- Bug bounty: programma pubblico con ricompense elevate come seconda linea di difesa e segnale di maturità del progetto.
Architettura dei permessi: timelock, multisig, minimo privilegio
Bisogna fare in modo che un solo errore o una sola chiave non portino a perdite totali.
- Timelock: ritardo su tutte le modifiche che influenzano i fondi degli utenti.
- Multisig: tesoreria e funzioni admin tramite M-su-N; chiavi separate per ruoli (admin/operator/pauser).
- Limiti e cap: volumi per transazione/blocco, cap di emissione/prestito, divieto di “riaperture” immediate dopo una pausa.
Monitoraggio e “stop di emergenza”
Ridurre TTD/MTTR: notare rapidamente, fermare rapidamente, correggere rapidamente.
- Alert on-chain: saldi anomali, Approvedi massa, tranche grandi, picchi di TVL/prezzo.
- Pausa: meccanismi di pause a livello di mercati/contratti; “Emergency pauser” nominato in anticipo.
- Osservazione del mempool: signature di exploit/MEV e procedura di risposta (chi e quando aziona lo “stop”).
Assicurazione e servizi di difesa esterni
Anche con protezioni forti il rischio zero non esiste: servono quindi un cuscinetto e processi di ripristino.
- Assicurazione decentralizzata: Nexus Mutual, InsurAce, Sherlock e altri: copertura per protocollo e utenti.
- Risk analytics e riserve: provider esterni di rischio, fondi di emergenza, post-mortem pubblici e policy di compensazione.
Quick win (per il team):
- Attivare timelock e multisig su tutte le modifiche critiche.
- Pubblicare bug bounty e contatto per white-hat.
- Configurare alert on-chain e procedura di “stop di emergenza”.
- Limitare tutti gli infinite approve nell'interfaccia e rivedere le autorizzazioni vecchie.
Runbook di risposta a un incidente
- Detect: trigger di alert/report → assegnare on-call e registrare la timeline.
- Limitare il danno: chiamare
pause()/limitare i mercati; avvisare community/exchange. - Analisi: snapshot degli stati, isolamento dei moduli, riproduzione dell'exploit su fork.
- Comunicazione: messaggio on-chain all'hacker, proposta bug bounty, update pubblico ogni N ore.
- Fix e release: hot patch tramite percorso emergency del timelock; verifica indipendente della patch.
- Restart e post-mortem: unpause graduale, report, compensazioni/pagamenti assicurativi, miglioramento degli SLO.
Modello: “Detect a T+7 min → pause a T+18 min → fix v1.1 dopo T+4 h → unpause dei mercati dopo 24 h con limiti”.
Stack di monitoraggio e alert
| 🔔 Segnale | 🧰 Strumento | 🎚️ Soglia | 🛟 Azione |
|---|---|---|---|
| 🧾 Autorizzazioni Approve | Bot on-chain | ≥ X in 5 min |
|
| 📈 Salto di prezzo/TVL | Oracolo + TWAP | Δ > Y% / 1 min |
|
| 🧪 Deploy sospetti | Audit CI/Git | Diff fuori dal branch di release |
|
| ⚡ Signature MEV | Watcher del mempool | Match del pattern |
|
Anti-MEV: cosa funziona e quando
| 🧩 Tecnica | 🛡️ Come aiuta | 📌 Quando applicarla |
|---|---|---|
| 🔒 Mempool/relay privati | Nascondono le tx dai “sandwich” | Operazioni grandi/sensibili |
| 🧮 Aste batch / modello CoW | Aggregano gli ordini, neutralizzando il front-run | DEX/aggregatori ad alta attività |
| ⚙️ Slippage basso + TWAP | Restringono la finestra per il sandwich | Swap/strategie dell'utente |
| 🎲 Randomized delay | Riduce la prevedibilità | Protocolli con vulnerabilità “di picco” |
Stablecoin e difetti di tokenomics
Il crollo UST/LUNA ha mostrato quanto rapidamente una stablecoin algoritmica possa perdere il peg e trascinare l'ecosistema in una “spirale della morte”. Un altro dolore sono gli APY “magici” senza fonte di ricavo sostenibile.
- Cosa controllare: riserve e loro composizione, regole di redemption, stress test.
- Pratica per i protocolli: cap sull'uso di stable rischiose come collaterale; disattivazione in caso di depeg.
- Pratica per l'utente: diversificazione delle stable e limiti su una singola posizione.
Liquidità e “bank run”
- Sintomi: spread/slippage anomali, pool che si “asciugano”, code lunghe per i prelievi.
- Contromisure: limiti sui prelievi una tantum, commissioni variabili in caso di squilibrio, linee di credito esterne, fondi assicurativi.
- Consiglio per l'utente: spezza le operazioni grandi, monitora TVL e coefficienti di collateralizzazione.
APY piramidali e rug pull
- Red flag: team anonimo, marketing aggressivo, nessun vesting/audit, controllo della liquidità in mano al creatore.
- Pratica: iniziare con importi piccoli, leggere smart contract/audit, controllare la distribuzione dei token.
Insider e concentrazione dei permessi
- Rischi: chiavi admin singole, multisig stretti, “super diritto” di upgrade/pause, backdoor nel codice.
- Protezione: quorum multisig distribuiti, separazione dei ruoli, timelock sulle operazioni sensibili, post-mortem pubblici.
Rischi regolatori e reputazionali
- Precauzioni: frontend alternativi, codice aperto, riserve trasparenti, dipendenza moderata da provider centralizzati.
- Comunicazione: report regolari, analisi oneste degli incidenti, politica di compensazione comprensibile.
Checklist di sicurezza per l'utente DeFi
- Usa un hardware wallet e un PIN; conserva il seed offline.
- Apri solo link ufficiali; meglio ancora, dai preferiti.
- Leggi ogni transazione: soprattutto Approve e chiamate sospette.
- Limita le autorizzazioni e revocale regolarmente (servizi Revoke).
- Diversifica: wallet separati per lungo termine e operazioni attive.
- Non tenere somme grandi su bridge e protocolli nuovi senza audit.
- Iscriviti agli alert: il tuo indirizzo/protocollo in un bot di monitoraggio.
- Ricorda: “troppo conveniente” è quasi sempre rischioso.
Matrice “minaccia → protezione”
| ⚠️ Minaccia | 📌 Esempio | 🔓 Vulnerabilità | 🛡️ Protezione |
|---|---|---|---|
| ♻️ Reentrancy | Curve (2023) | Richiamo prima dell'aggiornamento dei saldi | Pattern CEI, ReentrancyGuard, divieto di chiamate esterne |
| ⚡ Flash loan | Euler (2023) | Gli invarianti si rompono in un blocco | TWAP/cap limit, post-condizioni, limite alla “forza” della tx |
| 🎯 Manipolazione del prezzo | Mango (2022) | Liquidità sottile, oracolo “fatto in casa” | Oracoli affidabili, fonti multiple, divieto di esotici come collaterale |
| 🗳️ Attacco di governance | Beanstalk (2022) | Esecuzione istantanea, voti da flash loan | Timelock, filtro dei voti da flash loan, quorum/discussione |
| 🎭 Phishing/ingegneria sociale | bZx (2021) | Furto del seed → accesso alle chiavi admin | Sicurezza operativa, multisig, ruoli/dispositivi separati |
| 🖥️ Compromissione UI | BadgerDAO (2021) | Script malevolo che propone un Approve | 2FA/SSO, monitoraggio diff, revoca degli approve “infiniti” |
| 🔗 Exploit del bridge | Poly (2021), Ronin (2022) | Verifica debole dei messaggi/centralizzazione delle firme | Multisig, limiti, verifiche formali, audit degli update |
| 💸 Depeg di stablecoin | UST/LUNA (2022) | Peg algoritmico, tokenomics fragile | Riserve/stress test, cap sul collaterale, policy di auto-disattivazione |
| 🏦 Crisi di liquidità | Pool sbilanciati | Concentrazione dei prelievi/liquidità sottile | Limiti ai prelievi, commissioni variabili, linee esterne |
| 🕵️ Insider/chiave admin | — | Permessi singoli/multisig troppo stretti | Separazione dei ruoli, timelock, quorum distribuiti |
| 🏛️ Shock regolatorio | Blocco del frontend | Dipendenza da servizi centralizzati | UI alternative, RPC decentralizzati, trasparenza |
| 🧨 Rug pull / honeypot | AnubisDAO e altri | Controllo della liquidità/permessi del creatore | Audit, trasparenza del pool, non investire “alla cieca” |
Domande e risposte (FAQ)
Basta un solo audit per sentirsi tranquilli?
Un hardware wallet garantisce la sicurezza?
Si possono usare i bridge in sicurezza?
Come ridurre il rischio MEV/“sandwich” su DEX?
Bisogna revocare regolarmente le autorizzazioni (approve)?
Multisig o MPC: cosa è più affidabile per le chiavi admin?
Conviene sempre limitare l'importo di Approve invece di usare quello “infinito”?
Come scegliere un auditor per un progetto?
Conclusione
Le tecnologie DeFi evolvono rapidamente; tuttavia la resilienza non nasce da “una misura”, ma da un insieme di discipline: codice di qualità, processi rigorosi, monitoraggio, assicurazione e, naturalmente, formazione. Quindi prima un progetto incorpora la sicurezza “by default”, più alte sono le sue possibilità di superare le crisi e guadagnare fiducia.
In breve: la sicurezza è un ciclo continuo: prevenire → rilevare → reagire → migliorare. Più velocemente attraversi questo ciclo, più piccolo è il tuo “raggio di esplosione” e più solido diventa il tuo prodotto DeFi.
🎭 Ingegneria sociale, UI e infrastruttura
Phishing, siti falsi e trappole airdrop
Token “gratis”, cloni di siti e falso supporto nei messenger sono trucchi tipici. Non condividere mai seed/chiavi, controlla il dominio e non firmare Approvepoco chiari. Soprattutto, revoca regolarmente le autorizzazioni vecchie.
Compromissione del frontend e delle chiavi
Anche un contratto perfetto è impotente se il sito viene sostituito e la chiave admin rubata. Di conseguenza i team devono usare 2FA/SSO, limitare i permessi, monitorare le modifiche del frontend e conservare le chiavi critiche in multisig.
Bridge e cross-chain
I bridge uniscono i rischi di due o più reti. Servono quindi alta decentralizzazione dei validatori, verifica rigorosa dei messaggi, limiti ai prelievi e audit di ogni aggiornamento. Per gli utenti è ragionevole non lasciare grandi somme sui bridge “tanto per”.