Gevinster:
- Evne til at forstå, at kunstig intelligens udvider auditorens omfang, men ikke erstatter det, og er nyttigt ved kategoriscanning og ved at finde udkast.
- At være i stand til at genkende, at kunstig intelligens har overset den oprindelige sårbarhed og forretningslogikfejl, og at en flydende 'sikker' erklæring ikke er sikkerhed
- Evne til at klassificere resultater efter deres seriøsitetsniveau og forstå, at den endelige godkendelse og faglige ansvar påhviler den kompetente revisor.
Sikkerhedsrevision (systematisk undersøgelse af en smart kontrakt for sårbarheder) er Web3s mest ansvarlige job. En enkelt linje savnet af en revisor kan resultere i millioner af dollars i tab. I denne enhed lærer du, hvordan du bruger AI som revisionsassistent; Vi vil lære fra at generere ledetråde til at skrive en konklusion. Men den mest kritiske sætning er denne: AI kontrollerer ikke; Det er en assistent, der skærper revisorens blik. Den endelige godkendelse ligger hos den kompetente revisor, som påtager sig det professionelle ansvar.
Hvorfor revision er sikkerhedskritisk
En revisionsrapport forsikrer projektet og investorerne om, at "denne kodeks er blevet gennemgået." Hvis denne forsikring er falsk, er konsekvenserne katastrofale: udnyttet protokol, tabt finansiering, kollapset projekt. Derfor er brugen af AI i inspektion den mest omhyggelige del af dette modul. AI udvider auditorens omfang (genkalder flere mønstre, læser hurtigere), men erstatter ikke auditoren.
Hvorfor går det ikke? Fordi:
- AI kan ikke se den unikke/nye sårbarhed, der ikke er i træningsdataene.
- AI savner ofte fejlen i protokollens forretningslogik - at koden er teknisk korrekt, men økonomisk udnyttelig.
- AI kan give falsk tryghed ved at sige "sikker" på et flydende sprog; Dette er det farligste resultat.
Lag af brug af AI i kontrol
1. Indledende scanning og mønsterpåmindelse. AI gennemgår kendte sårbarhedsmønstre som en tjekliste: reentrancy, adgangskontrol, orakelmanipulation, front-running. Dette sikrer, at revisor ikke går glip af nogen kategorier.
2. Kodeforklaring. Forklaring af en kompleks funktion til AI i almindeligt sprog giver auditoren mulighed for hurtigt at forstå logikken; men beskrivelsen sammenlignes altid med koden.
3. At skrive et udkast til resultater. Når revisor finder en sårbarhed, sparer AI tid på at skrive udkastet til rapporten (beskrivelse, effekt, foreslået løsning).
4. Generering af modhypotese. Spørg AI "hvordan kan denne funktion misbruges?" At spørge " minder os om det aggressive perspektiv.
Bemærk: Bare fordi AI siger "Jeg fandt ikke nogen sårbarheder i denne kode" betyder det IKKE "denne kode er sikker". Bevis for fravær er ikke fravær af beviser. Det faktum, at AI'en ikke kan finde noget, gør det ikke unødvendigt for revisoren at undersøge det område.
Finde sværhedsgrader
Revisionsresultater klassificeres efter deres sværhedsgrad. AI bør bruge denne ramme, når der genereres udkast:
Niveau
Betydning
eksempel
kritisk
Fondstab/lockout direkte muligt
Hævelse af midler med genindtræden
høj
Alvorlig påvirkning under visse forhold
Uautoriseret udskrivning (mint)
medium
Begrænset påvirkning eller vanskelig tilstand
Lille tab med Oracle-afvigelse
lav
Mindre risiko, brud på god skik
Manglende begivenhedsudsendelse
Information
Ikke-sikkerhed, læsbarhed
Mangel på NatSpec
Svag prompt / Stærk prompt
Svag prompt:
Er denne kontrakt sikker?
Dette spørgsmål tvinger AI til at foretage en absolut, uberettiget bedømmelse som "ja/nej" - præcis hvad vi ikke ønsker.
Kraftig prompt:
Din rolle: assistent for senior smart kontraktrevisor. Scan følgende kontrakt for sikkerhed. Gennemgå følgende kategorier én efter én: genindgang, adgangskontrol, heltalsoperationer, inputvalidering, orakel/eksterne data, frontløb, gasgrænse. For hvert FUND: (1) relevant kodelinje, (2) årsagsrisiko, (3) estimeret sværhedsgrad (Kritisk/Høj/Middel/Lav), (4) løsningsforslag. Disse er HYPOTESER, SOM SKAL BEKRÆFES; Giv ikke en "sikker" dom. Marker de områder, du ikke er sikker på, og sig tydeligt "lad revisor bekræfte".
Fire kopierbare skabeloner
1) Kategoribaseret browsing:
Scan denne kontrakt for følgende kategorier: reentrancy, adgangskontrol, heltalsoverløb, inputvalidering, orakelafhængighed, front-running, DoS/gas. For hver kategori skal du sige "der er/er ingen risiko/jeg er ikke sikker" og tilslut din begrundelse til linjen i koden. Lav ikke en endelig dom.
2) Modhypotese fra angriberens perspektiv:
Tænk som en angriber: hvad er måderne at misbruge denne funktion på? Skriv hvert scenarie trin for trin og angiv, hvilke betingelser der kræves. Disse scenarier er de hypoteser, der skal testes; Generer IKKE faktisk udnyttelseskode, beskriv blot risikoen.
3) Udkast til resultatrapport:
Rapportér følgende verificerede konstatering på formelt revisionssprog: titel, sværhedsgrad, beskrivelse, indvirkning, påvirket kode, trin til gengivelse, foreslået løsning. Brug afmålt og fagsprog; overdrivelse. Antag, at resultatet er bekræftet af revisor, lad være med at lave et nyt fund.
4) Ret bekræftelse:
Nedenfor er en sårbarhed og rettelsen anvendt af udvikleren. Undersøg om rettelsen faktisk lukker sårbarheden; markere, om det skaber en ny bivirkning eller sårbarhed. Sig ikke "lukket" med sikkerhed; Slut med "skal bekræftes ved test".
Tre minisager (i antal)
Tilfælde 1 — AI forhindrede kategorihop. En revisor var ved at fokusere på en kontrakt på 400 linjer og springe orakelkategorien over. AI's kategoriscanning gav en advarsel om, at "prisdata er fra en enkelt kilde, åben for manipulation". Revisoren undersøgte det og fandt, at det faktisk var en middel risiko. Lektion: AI opretholder dækningsdisciplin.
Tilfælde 2 — Falsk "sikker" forsikring. Et andet hold spurgte AI "er dette sikkert?" spurgte han; "Der ser ikke ud til at være et væsentligt problem," sagde AI. Besætningsinspektionen var let. Så fandt den uafhængige revisor en forretningslogisk fejl: en beregning, der var teknisk korrekt, men hvis incitamenter kunne udnyttes. Lektion: AI savner forretningslogikfejl; Han kan ikke stole på at sige "sikker".
Case 3 — Udarbejdelse af rapporten sparede 3 timer. Revisoren brugte halvdelen af dagen på manuelt at rapportere 8 fund. Da jeg gav de verificerede resultater til AI og udskrev det officielle udkast, faldt tiden med ~3 timer; Revisoren brugte tid på at uddybe. Lektion: AI er sikker og effektiv til rapportering, fordi resultaterne allerede er blevet menneskeligt verificeret.
Forretningslogiks sårbarhed: AI's blinde plet
De dyreste sårbarheder kommer ofte ikke fra en teknisk fejl i koden, men fra forretningslogikkens udnyttelighed: afrunding af en belønningskonto, flash-lånkapring af en stemme, øjeblikkelig manipulation af en pris. Det er tilfælde, hvor koden fungerer "korrekt", men protokollen kan snydes økonomisk. AI vil sandsynligvis savne sådanne fejl - især protokolspecifikke. Derfor er forretningslogikgennemgang det mest menneskeintensive område af revisoren og det mindst afhængige af AI.
Tip: Spørg AI "hvordan kan de økonomiske incitamenter fra denne protokol udnyttes?" og brug de scenarier, der kommer op som udgangspunkt - men husk, at du og dit team bør lave den rigtige analyse.
Almindelige fejl
- Spørg AI "er det sikkert?" Spørger og stoler på dit ja. Absolut dømmekraft er ikke påkrævet.
- Stopper anmeldelsen, når AI siger "Jeg kunne ikke finde den". Fravær er ikke bevis.
- Uddelegering af forretningslogikgennemgang til AI. Det er hans største blinde vinkel.
- Bruger ikke uafhængige værktøjer (Slither osv.). AI alene er ikke nok.
- At indsætte det fund, som AI’en har gjort, i rapporten uden at verificere det. Risiko for hallucinationer.
- Forsøger at lægge kontrolansvar på AI. Ansvaret ligger hos eksperten.
Sammenfattende
- Audit er sikkerhedskritisk; AI udvider revisors omfang, men erstatter det ikke.
- AI savner den oprindelige sårbarhed og forretningslogik-fejl; At sige "sikker" er ikke sikkerhed.
- Fund er klassificeret efter sværhedsgrad; AI er nyttig til at generere kladder.
- Modhypotese og kategoriscreening bevarer disciplinen inklusion.
- Den endelige godkendelse og det faglige ansvar ligger altid hos den kompetente revisor.
Ansøgningsopgave
Find en eksempelkontrakt, der indeholder en kendt sårbarhed (til uddannelsesformål er eksempler på "sårbare kontrakter" tilgængelige i open source). Anvend "kategoribaseret scanning"-prompten på AI'en. Bemærk, om AI'en: (1) fandt den reelle sårbarhed, (2) producerede fabrikerede/falske fund, (3) gjorde absolutte domme som "sikker". Sammenlign det derefter med et statisk analyseværktøj.
tjekliste
- [ ] Spørg AI "er det sikkert?" I stedet fik jeg en kategoribaseret scanning.
- [ ] Jeg behandlede hvert fund som en hypotese.
- [ ] Jeg lavede selv/teamet forretningslogikgennemgangen.
- [ ] Jeg krydsvaliderede det med et uafhængigt statisk analyseværktøj.
- [ ] Jeg har bekræftet, at AI ikke fremstiller resultater.
- [ ] Jeg klassificerede resultaterne efter sværhedsgraden.
- [ ] Jeg accepterede, at den endelige godkendelse ligger hos den kompetente revisor.