Gevinster:
- Evne til å forstå at kunstig intelligens utvider omfanget av revisor, men ikke erstatter det, og er nyttig i kategoriskanning og finne utkast.
- Å være i stand til å gjenkjenne at kunstig intelligens har gått glipp av den opprinnelige sårbarheten og forretningslogikkfeilen, og at en flytende "sikker" uttalelse ikke er en sikkerhet
- Evne til å klassifisere funn i henhold til deres seriøsitetsnivå og forstå at den endelige godkjenningen og det faglige ansvaret ligger hos den kompetente revisoren.
Sikkerhetsrevisjon (systematisk undersøkelse av en smart kontrakt for sårbarheter) er Web3s mest ansvarlige jobb. En enkelt linje savnet av en revisor kan resultere i millioner av dollar i tap. I denne enheten lærer du hvordan du bruker AI som revisjonsassistent; Vi vil lære fra å generere ledetråder til å skrive en funnoversikt. Men den mest kritiske setningen er denne: AI kontrollerer ikke; Det er en assistent som skjerper blikket til revisor. Den endelige godkjenningen ligger hos den kompetente revisor som påtar seg det faglige ansvaret.
Hvorfor revisjon er sikkerhetskritisk
En revisjonsrapport forsikrer prosjektet og investorene om at "denne koden har blitt gjennomgått." Hvis denne forsikringen er falsk, er konsekvensene katastrofale: utnyttet protokoll, tapt finansiering, kollapset prosjekt. Derfor er bruken av AI i inspeksjon den mest forsiktige delen av denne modulen. AI utvider omfanget til revisor (minner flere mønstre, leser raskere), men erstatter ikke revisor.
Hvorfor går det ikke over? Fordi:
- AI kan ikke se den unike/nye sårbarheten som ikke er i treningsdataene.
- AI savner ofte feilen i protokollens forretningslogikk – at koden er teknisk korrekt, men økonomisk utnyttelig.
- AI kan gi falsk forsikring ved å si «trygt» på et flytende språk; Dette er det farligste resultatet.
Lag med bruk av AI i kontroll
1. Innledende skanning og mønsterpåminnelse. AI går gjennom kjente sårbarhetsmønstre som en sjekkliste: reentrancy, tilgangskontroll, orakelmanipulasjon, front-running. Dette sikrer at revisor ikke går glipp av noen kategorier.
2. Kodeforklaring. Å forklare en kompleks funksjon til AI på vanlig språk lar revisor raskt forstå logikken; men beskrivelsen sammenlignes alltid med koden.
3. Skrive et utkast til funn. Når revisor finner en sårbarhet, sparer AI tid på å skrive utkastet til rapporten (beskrivelse, innvirkning, foreslått løsning).
4. Generer mothypotese. Spør AI "hvordan kan denne funksjonen misbrukes?" Å spørre "minner oss om det aggressive perspektivet.
Oppmerksomhet: Bare fordi AI sier "Jeg fant ingen sårbarheter i denne koden" betyr IKKE "denne koden er trygg". Bevis på fravær er ikke fravær av bevis. Det faktum at AI ikke kan finne noe gjør det ikke unødvendig for revisor å undersøke det området.
Finne alvorlighetsnivåer
Revisjonsfunn er klassifisert etter alvorlighetsgrad. AI bør bruke dette rammeverket når du genererer utkast:
Nivå
Mening
eksempel
kritisk
Fondstap/lockout direkte mulig
Uttak av midler med reentrancy
høy
Alvorlig påvirkning under visse forhold
Uautorisert utskrift (mynt)
medium
Begrenset påvirkning eller vanskelig tilstand
Lite tap med Oracle-avvik
lav
Mindre risiko, brudd på god praksis
Manglende hendelsessending
Informasjon
Ikke-sikkerhet, lesbarhet
Mangel på NatSpec
Svak forespørsel / Sterk forespørsel
Svak melding:
Er denne kontrakten trygg?
Dette spørsmålet tvinger AI til å foreta en absolutt, uberettiget vurdering som "ja/nei" - akkurat det vi ikke vil ha.
Kraftig ledetekst:
Din rolle: assistent for senior smart kontraktsrevisor. Skann følgende kontrakt for sikkerhet. Gå gjennom følgende kategorier en etter en: reentrancy, tilgangskontroll, heltallsoperasjoner, inputvalidering, orakel/eksterne data, front-running, gas limit. For hvert FUNN: (1) relevant kodelinje, (2) årsak til risiko, (3) estimert alvorlighetsgrad (Kritisk/Høy/Middels/Lav), (4) løsningsforslag. Dette er HYPOTESER SOM SKAL BEKREFTES; Ikke gi en "sikker" dom. Merk de områdene du ikke er sikker på og si tydelig «la revisor bekrefte».
Fire kopierbare maler
1) Kategoribasert nettlesing:
Skann denne kontrakten for følgende kategorier: reentrancy, tilgangskontroll, heltallsoverløp, inputvalidering, orakelavhengighet, front-running, DoS/gass. For hver kategori, si "det er/er ingen risiko/jeg er ikke sikker" og koble begrunnelsen din til linjen i koden. Ikke ta en endelig dom.
2) Mothypotese fra angriperens perspektiv:
Tenk som en angriper: hva er måtene å misbruke denne funksjonen på? Skriv hvert scenario trinn for trinn og angi hvilke forhold som kreves. Disse scenariene er hypotesene som skal testes; IKKE generer faktisk utnyttelseskode, beskriv bare risikoen.
3) Utkast til funnrapport:
Rapporter følgende bekreftede funn på formelt revisjonsspråk: tittel, alvorlighetsgrad, beskrivelse, innvirkning, berørt kode, trinn for å reprodusere, foreslått løsning. Bruk avmålt og fagspråk; overdrivelse. Anta at funnet er bekreftet av revisor, ikke gjør opp et nytt funn.
4) Rett opp bekreftelse:
Nedenfor er en sårbarhet og rettelsen brukt av utvikleren. Undersøk om rettelsen faktisk lukker sårbarheten; markere om det skaper en ny bivirkning eller sårbarhet. Ikke si "stengt" helt sikkert; Avslutt med "må bekreftes ved testing".
Tre minietuier (i antall)
Tilfelle 1 – AI forhindret kategorihopping. En revisor var i ferd med å fokusere på en 400-linjers kontrakt og hoppe over orakelkategorien. AIs kategoriskanning ga en advarsel om at "prisdata er fra en enkelt kilde, åpen for manipulering". Revisor undersøkte det og fant at det faktisk var en middels risiko. Leksjon: AI opprettholder dekningsdisiplin.
Tilfelle 2 – Falsk «trygg» forsikring. Et annet team spurte AI "er dette trygt?" spurte han; "Det ser ikke ut til å være et betydelig problem," sa AI. Mannskapsinspeksjonen var lett. Så fant den uavhengige revisoren en forretningslogisk feil: en beregning som var teknisk korrekt, men hvis insentiver kunne utnyttes. Leksjon: AI savner forretningslogikkfeil; Han kan ikke stole på å si "trygt".
Tilfelle 3 — Utarbeiding av rapporten sparte 3 timer. Revisor brukte halve dagen på å manuelt rapportere 8 funn. Når jeg ga de bekreftede funnene til AI og trykket det offisielle utkastet, sank tiden med ~3 timer; Revisor viet tid til utdyping. Leksjon: AI er trygg og effektiv i rapportering fordi funnene allerede er verifisert på menneskelig måte.
Forretningslogikksårbarhet: AIs blindsone
De dyreste sårbarhetene kommer ofte ikke fra en teknisk feil i koden, men fra utnyttelsen av forretningslogikken: avrunding av utnyttelse av en belønningskonto, flash-lånkapring av en stemme, øyeblikkelig manipulering av en pris. Dette er tilfeller der koden fungerer "riktig", men protokollen kan lures økonomisk. AI vil sannsynligvis savne slike feil – spesielt protokollspesifikke. Derfor er gjennomgang av forretningslogikk det mest menneskeintensive området til revisor og det minst avhengige av AI.
Hint: Spør AI "hvordan kan de økonomiske insentivene til denne protokollen utnyttes?" og bruk scenariene som kommer opp som et utgangspunkt - men husk at du og teamet ditt bør gjøre den virkelige analysen.
Vanlige feil
- Spør AI "er det trygt?" Spør og stoler på ditt ja. Absolutt dømmekraft er ikke nødvendig.
- Stopper anmeldelsen når AI-en sier "Jeg kunne ikke finne den". Fravær er ikke bevis.
- Delegering av forretningslogikkgjennomgang til AI. Det er hans største blindsone.
- Bruker ikke uavhengige verktøy (Slither etc.). AI alene er ikke nok.
- Sette funnet gjort av AI i rapporten uten å verifisere det. Risiko for hallusinasjoner.
- Prøver å legge kontrollansvar på AI. Ansvaret ligger hos eksperten.
Oppsummert
- Revisjon er sikkerhetskritisk; AI utvider revisors virkeområde, men erstatter det ikke.
- AI savner den opprinnelige sårbarheten og forretningslogikkfeilen; Å si "trygt" er ikke forsikring.
- Funn er klassifisert etter alvorlighetsgrad; AI er nyttig for å generere utkast.
- Mothypotese og kategoriscreening bevarer disiplinen inkludering.
- Endelig godkjenning og faglig ansvar ligger alltid hos den kompetente revisor.
Søknadsoppgave
Finn en eksempelkontrakt som inneholder en kjent sårbarhet (for utdanningsformål er eksempler på "sårbare kontrakter" tilgjengelig i åpen kildekode). Bruk "kategoribasert skanning"-ledeteksten på AI. Legg merke til om AI: (1) fant den virkelige sårbarheten, (2) produserte fabrikkerte/falske funn, (3) gjorde absolutte vurderinger som «sikker». Sammenlign det så med et statisk analyseverktøy.
sjekkliste
- [ ] Spør AI "er det trygt?" I stedet hadde jeg en kategoribasert skanning.
- [ ] Jeg behandlet hvert funn som en hypotese.
- [ ] Jeg gjorde forretningslogikkgjennomgangen selv/teamet.
- [ ] Jeg kryssvaliderte det med et uavhengig statisk analyseverktøy.
- [ ] Jeg har bekreftet at AI ikke lager funn.
- [ ] Jeg klassifiserte funnene etter alvorlighetsgrad.
- [ ] Jeg godtok at den endelige godkjenningen ligger hos den kompetente revisoren.