Audit di sicurezza: cosa ti dice davvero un report di audit

«Verificato da» è uno dei badge più comuni nel mondo cripto. Compare sui siti web, nelle presentazioni agli investitori e nei lanci di token, spesso come se chiudesse la questione se qualcosa sia sicuro. Non è così, ma un vero report di audit, letto nel modo giusto, ti dice moltissimo. Il trucco è sapere cosa cercare.

Che cos'è un audit

Un audit di sicurezza è una revisione, limitata nel tempo, di un codice specifico condotta da una società esterna. Gli auditor leggono il codice, lo testano, cercano di romperlo e mettono per iscritto ciò che trovano. Per gli smart contract, di solito significa revisione manuale più strumenti automatici; per i wallet, può includere le app, la crittografia, i server con cui comunicano e il modo in cui tutto si incastra.

Il risultato è un report: cosa è stato esaminato, quando, cosa è stato trovato, quanto era grave ogni rilievo e se il team lo ha corretto.

Tre espressioni di questa descrizione contano più delle altre: codice specifico, limitata nel tempo e cosa è stato trovato.

Leggi prima il perimetro

Il perimetro (scope) dice esattamente cosa hanno esaminato gli auditor: di solito repository, contratti o componenti con un nome preciso, spesso legati a un commit specifico.

È qui che crolla la maggior parte delle dichiarazioni fuorvianti di «verificato». Un progetto potrebbe aver sottoposto ad audit un solo piccolo contratto e pubblicizzare l'intero protocollo come verificato. Un wallet potrebbe aver fatto esaminare i propri smart contract mentre l'app che costruisce e firma davvero le tue transazioni non è mai stata analizzata. Se ciò di cui ti fidi non rientra nel perimetro, l'audit non dice nulla al riguardo.

Chiediti: il perimetro copre le parti che toccano i miei fondi?

Controlla la data e la versione

Un audit descrive il codice com'era il giorno in cui è stato esaminato. Tutto ciò che è stato rilasciato dopo (nuove funzionalità, nuove chain, refactoring) ne resta fuori, a meno che non sia stato esaminato di nuovo.

È normale: il software cambia di continuo. Ma significa che un audit di due anni fa su un progetto in rapida evoluzione è un documento storico. Le domande utili sono quando è stato fatto, quale versione copriva e se le modifiche importanti successive hanno avuto una revisione propria.

Per gli smart contract c'è un'ulteriore complicazione: se un contratto è aggiornabile, il codice in esecuzione oggi potrebbe non essere quello sottoposto ad audit. Chi controlla gli aggiornamenti conta quanto l'audit stesso.

Leggi i rilievi, non solo il riepilogo

I report classificano i rilievi per gravità (in genere critica, alta, media, bassa e informativa) e indicano se ciascuno è stato corretto, riconosciuto o lasciato com'è.

• I rilievi critici e alti sono quelli che potrebbero far perdere fondi. Ce n'erano? Sono stati corretti e ricontrollati?
• «Riconosciuto» non significa «corretto». Vuol dire che il team ha accettato il rischio. A volte è ragionevole; leggi il perché.
• Zero rilievi non è automaticamente una buona notizia. Può significare codice eccellente, oppure un perimetro ristretto e un incarico breve.
• Il nuovo test è importante. Un buon report dice che gli auditor hanno verificato le correzioni, non solo che il team ha dichiarato di averle fatte.

Cosa un audit non può dirti

Anche un audit approfondito ha limiti che vale la pena dichiarare apertamente:

• È un campione di attenzione, non una dimostrazione. Gli auditor trovano molti bug, ma non tutti. Protocolli sottoposti ad audit sono stati sfruttati.
• Copre il codice, non le operazioni. Come vengono conservate le chiavi, chi può effettuare il deploy, come il team gestisce un incidente: di solito è tutto fuori perimetro.
• Non copre il design economico, a meno che non fosse esplicitamente nel perimetro. Un contratto può funzionare esattamente come è scritto ed essere comunque sfruttabile tramite prezzi, incentivi o altri protocolli.
• Non copre ciò che installi. Un audit del codice sorgente non dice nulla su un'app falsa con lo stesso nome. Sono le build riproducibili a collegare il codice pubblicato al software che esegui davvero.

Campanelli d'allarme nelle dichiarazioni di «verificato»

• Nessun link al report vero e proprio, o un report ospitato solo dal progetto stesso.
• Un auditor che non riesci a trovare, o il cui sito non elenca l'incarico.
• Un perimetro che non corrisponde a ciò che viene pubblicizzato.
• Rilievi di gravità alta non corretti descritti come «gestiti».
• Un unico audit di anni fa, su un prodotto che da allora è cambiato completamente.

L'approccio di SSP

Il codice di SSP è open source, quindi chiunque può leggerlo; ma codice aperto e codice sottoposto ad audit non sono la stessa cosa, e li trattiamo separatamente.

Halborn, una società di sicurezza indipendente, ha sottoposto ad audit gli smart contract ERC-4337 di SSP e, insieme, l'estensione SSP Wallet, l'app SSP Key e SSP Relay. Entrambi i report sono pubblici sul sito di Halborn, senza rilievi critici o alti, e i rilievi bassi e informativi sono stati gestiti. Il nostro riepilogo degli audit 2025 riporta il perimetro e le date di ciascun incarico.

Le stesse avvertenze valgono per noi come per chiunque altro. Quegli audit coprono il codice com'era quando è stato esaminato; le funzionalità e le chain aggiunte in seguito non ne fanno parte, quindi diciamo che tipo di revisione ha avuto il codice più recente invece di estendere un vecchio badge per coprirlo.

Il riepilogo onesto

Un audit è una prova, non una garanzia. Ti dice che un codice specifico, in un momento specifico, è stato esaminato da una società specifica, e cosa ha trovato.

Leggi il perimetro, controlla la data e la versione, guarda le gravità e come sono state risolte, e cerca il report sul sito dell'auditor stesso. Fallo, e «verificato» smette di essere un badge e diventa un'informazione.