Vinster:
- Förmåga att förstå att artificiell intelligens utökar auditörens omfattning, men inte ersätter den, och är användbar vid kategoriskanning och att hitta utkast.
- Att kunna känna igen att artificiell intelligens har missat den ursprungliga sårbarheten och affärslogikfelet, och att ett flytande "säkert" uttalande inte är en garanti.
- Förmåga att klassificera fynden efter deras allvarlighetsgrad och förstå att det slutliga godkännandet och professionella ansvaret ligger hos den behöriga revisorn.
Säkerhetsrevision (systematisk granskning av ett smart kontrakt för sårbarheter) är Web3:s mest ansvarsfulla jobb. En enda rad som en revisor missar kan resultera i miljontals dollar i förluster. I den här enheten kommer du att lära dig hur du använder AI som revisionsassistent; Vi kommer att lära oss från att generera ledtrådar till att skriva en resultatöversikt. Men den mest kritiska meningen är denna: AI kontrollerar inte; Det är en assistent som skärper revisorns blick. Det slutliga godkännandet ligger hos den behöriga revisorn som tar det professionella ansvaret.
Varför revision är säkerhetskritiskt
En revisionsrapport försäkrar projektet och investerarna om att "denna kod har granskats." Om denna försäkran är falsk blir konsekvenserna katastrofala: utnyttjat protokoll, förlorad finansiering, kollapsat projekt. Därför är användningen av AI vid inspektion den mest noggranna delen av denna modul. AI utökar revisorns omfattning (återkallar fler mönster, läser snabbare) men ersätter inte revisorn.
Varför går det inte över? Eftersom:
- AI kan inte se den unika/nya sårbarheten som inte finns i träningsdatan.
- AI missar ofta bristen i protokollets affärslogik – att koden är tekniskt korrekt men ekonomiskt exploaterad.
- AI kan ge falsk trygghet genom att säga "säker" på ett flytande språk; Detta är det farligaste resultatet.
Lager av att använda AI i kontroll
1. Första skanning och mönsterpåminnelse. AI går igenom kända sårbarhetsmönster som en checklista: återinträde, åtkomstkontroll, orakelmanipulation, front-running. Detta säkerställer att revisorn inte missar några kategorier.
2. Kodförklaring. Att förklara en komplex funktion för AI:n på ett enkelt språk gör det möjligt för revisorn att snabbt förstå logiken; men beskrivningen jämförs alltid med koden.
3. Skriva ett utkast till resultat. När revisorn hittar en sårbarhet, sparar AI tid på att skriva utkastet till rapporten (beskrivning, påverkan, föreslagen lösning).
4. Generera mothypoteser. Fråga AI:en "hur kan den här funktionen missbrukas?" Att fråga " påminner oss om det aggressiva perspektivet.
Observera: Bara för att AI:n säger "Jag hittade inga sårbarheter i den här koden" betyder det INTE "den här koden är säker". Bevis på frånvaro är inte frånvaro av bevis. Det faktum att AI:n inte kan hitta något gör det inte onödigt för revisorn att undersöka det området.
Hitta svårighetsgrader
Granskningsresultat klassificeras efter deras svårighetsgrad. AI bör använda detta ramverk när du skapar utkast:
Nivå
Mening
exempel
kritiska
Fondförlust/lockout direkt möjligt
Uttag av pengar med återinträde
hög
Allvarlig påverkan under vissa förhållanden
Otillåten utskrift (mint)
medium
Begränsad påverkan eller svårt tillstånd
Liten förlust med Oracle-avvikelse
låg
Mindre risk, brott mot god sed
Saknas händelsesändning
Information
Icke-säkerhet, läsbarhet
Brist på NatSpec
Svag prompt / Stark prompt
Svag uppmaning:
Är detta kontrakt säkert?
Denna fråga tvingar AI att göra en absolut, obefogad bedömning som "ja/nej" - precis vad vi inte vill ha.
Kraftfull uppmaning:
Din roll: assistent till senior smart kontraktsrevisor. Skanna följande kontrakt för säkerhet. Gå igenom följande kategorier en efter en: återinträde, åtkomstkontroll, heltalsoperationer, ingångsvalidering, orakel/extern data, front-running, gasgräns. För varje FYND: (1) relevant kodrad, (2) orsaksrisk, (3) uppskattad svårighetsgrad (Kritisk/Hög/Medel/Låg), (4) lösningsförslag. Dessa är HYPOTESER SOM SKALL BEKRÄFTS; Ge inte en "säker" dom. Markera de områden du inte är säker på och säg tydligt "låt revisorn bekräfta".
Fyra kopierbara mallar
1) Kategoribaserad surfning:
Skanna detta kontrakt för följande kategorier: återinträde, åtkomstkontroll, heltalsspill, ingångsvalidering, orakelberoende, front-running, DoS/gas. För varje kategori, säg "det finns/finns ingen risk/jag är inte säker" och koppla din motivering till raden i koden. Gör inte en slutgiltig bedömning.
2) Mothypotes ur angriparens perspektiv:
Tänk som en angripare: vad är sätten att missbruka den här funktionen? Skriv varje scenario steg för steg och ange vilka förutsättningar som krävs. Dessa scenarier är de hypoteser som ska testas; Generera INTE faktisk exploateringskod, beskriv bara risken.
3) Utkast till resultatrapport:
Rapportera följande verifierade fynd på formellt revisionsspråk: titel, svårighetsgrad, beskrivning, påverkan, påverkad kod, steg för att återskapa, föreslagen lösning. Använd uppmätt och tekniskt språk; överdrift. Anta att fyndet bekräftas av revisorn, gör inte ett nytt fynd.
4) Åtgärda verifiering:
Nedan finns en sårbarhet och korrigeringen som tillämpas av utvecklaren. Undersök om fixen faktiskt stänger sårbarheten; markera om det skapar en ny bieffekt eller sårbarhet. Säg inte "stängt" med säkerhet; Avsluta med "måste bekräftas genom testning".
Tre minifodral (i antal)
Fall 1 — AI förhindrade kategorihoppning. En revisor var på väg att fokusera på ett kontrakt på 400 rader och hoppa över orakelkategorin. AI:s kategoriskanning gav en varning om att "prisdata är från en enda källa, öppen för manipulation". Revisorn granskade det och fann att det verkligen var en medelrisk. Lektion: AI upprätthåller täckningsdisciplin.
Fall 2 — Falsk "säker" försäkran. Ett annat team frågade AI: "är det här säkert?" frågade han; "Det verkar inte finnas ett betydande problem," sa AI. Besättningsinspektionen var lätt. Sedan fann den oberoende revisorn ett affärslogiskt fel: en beräkning som var tekniskt korrekt men vars incitament var exploaterande. Lektion: AI missar affärslogikfel; Det går inte att lita på att han säger "säker".
Fall 3 — Att utarbeta rapporten sparade 3 timmar. Revisorn ägnade halva dagen åt att manuellt rapportera 8 fynd. När jag väl gav de verifierade resultaten till AI och skrivit ut det officiella utkastet sjönk tiden med ~3 timmar; Revisorn ägnade tid åt fördjupning. Lärdom: AI är säker och effektiv i rapportering eftersom resultaten redan har verifierats mänskligt.
Affärslogiks sårbarhet: AI:s blinda fläck
De dyraste sårbarheterna kommer ofta inte från ett tekniskt fel i koden, utan från affärslogikens exploatering: avrundande utnyttjande av ett belöningskonto, kapning av ett flashlån av en röst, omedelbar manipulation av ett pris. Det är fall där koden fungerar "korrekt" men protokollet kan luras ekonomiskt. AI kommer sannolikt att missa sådana fel – särskilt protokollspecifika. Därför är granskning av affärslogik det mest människointensiva området för revisorn och det minst beroende av AI.
Tips: Fråga AI: "hur kan de ekonomiska incitamenten för detta protokoll utnyttjas?" och använd scenarierna som kommer upp som utgångspunkt – men kom ihåg att du och ditt team bör göra den verkliga analysen.
Vanliga misstag
- Fråga AI:n "är det säkert?" Frågar och litar på ditt ja. Absolut bedömning krävs inte.
- Avbryter recensionen när AI:n säger "Jag kunde inte hitta den". Frånvaro är inget bevis.
- Delegera affärslogikgranskning till AI. Det är hans största döda fläck.
- Använder inte oberoende verktyg (Slither etc.). Enbart AI räcker inte.
- Att lägga in fyndet som gjorts av AI i rapporten utan att verifiera det. Risk för hallucinationer.
- Försöker lägga kontrollansvar på AI. Ansvaret ligger hos experten.
Sammanfattningsvis
- Revision är säkerhetskritisk; AI utökar revisorns omfattning men ersätter den inte.
- AI missar den ursprungliga sårbarheten och affärslogiken; Att säga "säkert" är ingen garanti.
- Fynden klassificeras efter svårighetsgrad; AI är användbart för att generera utkast.
- Mothypotes och kategoriscreening bevarar disciplinen inkludering.
- Slutligt godkännande och professionellt ansvar ligger alltid hos den behöriga revisorn.
Applikationsuppgift
Hitta ett exempelkontrakt som innehåller en känd sårbarhet (för utbildningsändamål finns exempel på "sårbara kontrakt" i öppen källkod). Tillämpa "kategoribaserad skanning"-prompten på AI. Notera om AI:n: (1) hittade den verkliga sårbarheten, (2) producerade tillverkade/falska fynd, (3) gjorde absoluta bedömningar som "säkert". Jämför det sedan med ett statiskt analysverktyg.
checklista
- [ ] Fråga AI:n "är det säkert?" Istället hade jag en kategoribaserad skanning.
- [ ] Jag behandlade varje fynd som en hypotes.
- [ ] Jag gjorde affärslogikgranskningen själv/teamet.
- [ ] Jag korsvaliderade det med ett oberoende statiskt analysverktyg.
- [ ] Jag har bekräftat att AI:n inte tillverkar fynd.
- [ ] Jag klassificerade fynden efter svårighetsgraden.
- [ ] Jag accepterade att det slutliga godkännandet ligger hos den behöriga revisorn.