Guadagni:
- Capacità di comprendere che l'intelligenza artificiale amplia il campo d'azione del revisore, ma non lo sostituisce, ed è utile nella scansione delle categorie e nella ricerca di redazioni.
- Essere in grado di riconoscere che l'intelligenza artificiale non ha colto la vulnerabilità originale e l'errore della logica aziendale e che una dichiarazione fluida e "sicura" non è una garanzia
- Capacità di classificare i risultati in base al loro livello di gravità e comprendere che l'approvazione finale e la responsabilità professionale spetta all'auditor competente.
L'audit di sicurezza (esame sistematico di un contratto intelligente per individuare le vulnerabilità) è il lavoro più responsabile di Web3. Una singola riga persa da un revisore dei conti può comportare perdite per milioni di dollari. In questa unità imparerai come utilizzare l'intelligenza artificiale come assistente all'audit; Impareremo dalla generazione di indizi alla stesura di uno schema dei risultati. Ma la frase più critica è questa: l’intelligenza artificiale non controlla; È un assistente che affina l'occhio dell'auditor. L'approvazione finale spetta al revisore competente che se ne assume la responsabilità professionale.
Perché il controllo è fondamentale per la sicurezza
Un rapporto di audit rassicura il progetto e gli investitori che “questo codice è stato rivisto”. Se questa assicurazione è falsa, le conseguenze sono disastrose: protocollo sfruttato, finanziamenti persi, progetto fallito. Pertanto, l'uso dell'intelligenza artificiale nell'ispezione è la parte più attenta di questo modulo. L’intelligenza artificiale amplia l’ambito dell’auditor (ricorda più schemi, legge più velocemente) ma non sostituisce l’auditor.
Perché non passa? Perché:
- L'intelligenza artificiale non può vedere la vulnerabilità unica/nuova che non è presente nei dati di addestramento.
- L'intelligenza artificiale spesso non coglie il difetto nella logica aziendale del protocollo: il codice è tecnicamente corretto ma economicamente sfruttabile.
- L’intelligenza artificiale può dare false rassicurazioni dicendo “sicuro” in un linguaggio fluente; Questo è il risultato più pericoloso.
Livelli di utilizzo dell'intelligenza artificiale sotto controllo
1. Scansione iniziale e promemoria del modello. L’intelligenza artificiale attraversa modelli di vulnerabilità noti come una lista di controllo: rientro, controllo degli accessi, manipolazione degli oracoli, front-running. Ciò garantisce che il revisore non tralasci nessuna categoria.
2. Spiegazione del codice. Spiegare una funzione complessa all'IA in un linguaggio semplice consente all'auditor di coglierne rapidamente la logica; ma la descrizione va sempre confrontata con il codice.
3. Scrivere una bozza dei risultati. Quando l’auditor rileva una vulnerabilità, l’AI risparmia tempo nella stesura della bozza del report (descrizione, impatto, soluzione proposta).
4. Generazione di controipotesi. Chiedi all'IA "come si può abusare di questa funzione?" Chiedere" ci ricorda la prospettiva aggressiva.
Attenzione: solo perché l'IA dice "non ho trovato alcuna vulnerabilità in questo codice" NON significa "questo codice è sicuro". La prova dell’assenza non è assenza di prova. Il fatto che l’IA non riesca a trovare qualcosa non rende superfluo l’esame di quell’area da parte dell’auditor.
Trovare i livelli di gravità
I risultati dell’audit sono classificati in base al loro livello di gravità. L'intelligenza artificiale dovrebbe utilizzare questo framework durante la generazione di bozze:
Livello
Significato
esempio
critico
Perdita/blocco del fondo direttamente possibile
Prelevare fondi con rientro
alto
Impatto grave in determinate condizioni
Stampa non autorizzata (nuovo)
medio
Impatto limitato o condizione difficile
Piccola perdita con deviazione Oracle
basso
Rischio minore, violazione delle buone pratiche
Trasmissione dell'evento mancante
Informazioni
Non sicurezza, leggibilità
Mancanza di specifiche nazionali
Prompt debole / Prompt forte
Suggerimento debole:
Questo contratto è sicuro?
Questa domanda costringe l’IA a dare un giudizio assoluto e ingiustificato come “sì/no” – esattamente quello che non vogliamo.
Suggerimento potente:
Il tuo ruolo: assistente del revisore senior dei contratti intelligenti. Scansiona il seguente contratto per sicurezza. Passare attraverso le seguenti categorie una per una: rientro, controllo degli accessi, operazioni su numeri interi, convalida dell'input, dati oracle/esterni, front-running, limite di gas. Per ciascun RISULTATO: (1) riga di codice pertinente, (2) causa rischio, (3) gravità stimata (Critico/Alto/Medio/Basso), (4) proposta di soluzione. Si tratta di IPOTESI DA CONFERMARE; Non dare un verdetto "sicuro". Segna le aree di cui non sei sicuro dicendo chiaramente "lascia che sia l'auditor a confermare".
Quattro modelli copiabili
1) Navigazione per categorie:
Analizza questo contratto per le seguenti categorie: rientro, controllo degli accessi, overflow di numeri interi, convalida dell'input, dipendenza da Oracle, front-running, DoS/gas. Per ogni categoria, dì "non c'è/non c'è rischio/non sono sicuro" e collega la tua giustificazione alla riga nel codice. Non dare un giudizio definitivo.
2) Controipotesi dal punto di vista dell'attaccante:
Pensa come un malintenzionato: quali sono i modi per abusare di questa funzione? Scrivi ogni scenario passo dopo passo e indica quali condizioni sono richieste. Questi scenari sono le ipotesi da testare; NON generare codice exploit vero e proprio, descrivi semplicemente il rischio.
3) Progetto di relazione sui risultati:
Riportare il seguente risultato verificato nel linguaggio formale dell'audit: titolo, gravità, descrizione, impatto, codice interessato, passaggi da riprodurre, soluzione proposta. Utilizzare un linguaggio misurato e tecnico; esagerazione. Supporre che il risultato sia confermato dal revisore, non inventare un nuovo risultato.
4) Correggi la verifica:
Di seguito è riportata una vulnerabilità e la correzione applicata dallo sviluppatore. Esaminare se la correzione risolve effettivamente la vulnerabilità; segnare se crea un nuovo effetto collaterale o vulnerabilità. Non dire "chiuso" di sicuro; Termina con "deve essere confermato mediante test".
Tre mini custodie (in numeri)
Caso 1: l’IA ha impedito il salto di categoria. Un revisore stava per concentrarsi su un contratto di 400 righe e saltare la categoria dell'oracolo. La scansione delle categorie di AI ha avvertito che "i dati sui prezzi provengono da un'unica fonte, aperta alla manipolazione". Il revisore lo ha esaminato e ha riscontrato che si trattava effettivamente di un rischio medio. Lezione: l’intelligenza artificiale mantiene la disciplina della copertura.
Caso 2 – Falsa garanzia “sicura”. Un altro team ha chiesto all’IA “è sicuro?” chiese; "Non sembra esserci un problema significativo", ha detto AI. L'ispezione dell'equipaggio è stata leggera. Poi il revisore indipendente ha riscontrato un errore nella logica aziendale: un calcolo tecnicamente corretto ma i cui incentivi erano sfruttabili. Lezione: l’intelligenza artificiale non rileva un errore di logica aziendale; Non ci si può fidare che dica "sicuro".
Caso 3 — La stesura del rapporto ha consentito di risparmiare 3 ore. L'auditor trascorreva metà della giornata riportando manualmente 8 risultati. Una volta forniti i risultati verificati all'IA e stampata la bozza ufficiale, il tempo è diminuito di circa 3 ore; Il revisore ha dedicato tempo all'approfondimento. Lezione: l’intelligenza artificiale è sicura ed efficiente nel reporting perché i risultati sono già stati verificati da esseri umani.
Vulnerabilità della logica aziendale: il punto cieco dell'intelligenza artificiale
Le vulnerabilità più costose spesso non derivano da un errore tecnico nel codice, ma dalla sfruttabilità della logica aziendale: sfruttamento arrotondato di un conto premio, dirottamento del prestito flash di un voto, manipolazione istantanea di un prezzo. Questi sono casi in cui il codice funziona "correttamente" ma il protocollo può essere ingannato economicamente. È probabile che l’intelligenza artificiale non riesca a cogliere tali errori, in particolare quelli specifici del protocollo. Pertanto, la revisione della logica aziendale è l’area del revisore ad alta intensità umana e quella meno dipendente dall’intelligenza artificiale.
Suggerimento: chiedere all’AI “come si possono sfruttare gli incentivi economici di questo protocollo?” e utilizza gli scenari che si presentano come punto di partenza, ma ricorda che tu e il tuo team dovreste fare la vera analisi.
Errori comuni
- Chiedi all'IA "è sicuro?" Chiedere e confidare nel tuo sì. Non è richiesto un giudizio assoluto.
- Interrompere la revisione quando l'IA dice "Non sono riuscito a trovarlo". L'assenza non è una prova.
- Delegare la revisione della logica aziendale all'intelligenza artificiale. È il suo più grande punto cieco.
- Non utilizzare strumenti indipendenti (Slither ecc.). L’intelligenza artificiale da sola non è sufficiente.
- Inserire nel report il rilievo elaborato dall’IA senza verificarlo. Rischio di allucinazioni.
- Cercare di attribuire la responsabilità del controllo all’intelligenza artificiale. La responsabilità è dell'esperto.
In sintesi
- L'audit è fondamentale per la sicurezza; L'intelligenza artificiale amplia il campo d'azione del revisore ma non lo sostituisce.
- L’intelligenza artificiale non rileva la vulnerabilità originale e il bug della logica aziendale; Dire "sicuro" non è una garanzia.
- I risultati sono classificati in base al livello di gravità; L'intelligenza artificiale è utile per generare bozze.
- Le controipotesi e lo screening delle categorie preservano la disciplina dell’inclusione.
- L'approvazione finale e la responsabilità professionale spettano sempre all'auditor competente.
Compito dell'applicazione
Trova un contratto di esempio che contenga una vulnerabilità nota (per scopi didattici, esempi di "contratti vulnerabili" sono disponibili in open source). Applicare la richiesta "scansione basata su categorie" all'IA. Notare se l’IA: (1) ha trovato la vera vulnerabilità, (2) ha prodotto risultati inventati/falsi, (3) ha espresso giudizi assoluti come “sicuro”. Quindi confrontalo con uno strumento di analisi statica.
lista di controllo
- [] Chiedi all'IA "è sicuro?" Invece, ho avuto una scansione basata su categorie.
- [ ] Ho trattato ogni scoperta come un'ipotesi.
- [ ] Ho effettuato la revisione della logica aziendale da solo/con il team.
- [] L'ho convalidato in modo incrociato con uno strumento di analisi statica indipendente.
- [ ] Ho confermato che l'IA non fabbrica risultati.
- [ ] Ho classificato i risultati in base al livello di gravità.
- [ ] Ho accettato che l'approvazione finale spetta al revisore competente.