Winst:
- Het vermogen om te begrijpen dat kunstmatige intelligentie de reikwijdte van de auditor vergroot, maar deze niet vervangt, en nuttig is bij het scannen van categorieën en het opstellen van bevindingen.
- In staat zijn te onderkennen dat kunstmatige intelligentie de oorspronkelijke kwetsbaarheid en bedrijfslogische fout heeft gemist, en dat een vloeiende 'veilige' verklaring geen zekerheid biedt
- Vermogen om bevindingen te classificeren op basis van hun ernstniveau en te begrijpen dat de uiteindelijke goedkeuring en professionele verantwoordelijkheid bij de bevoegde auditor berusten.
Beveiligingsaudit (systematisch onderzoek van een slim contract op kwetsbaarheden) is de meest verantwoordelijke taak van Web3. Eén enkele regel die door een auditor wordt gemist, kan tot miljoenen dollars aan verliezen leiden. In deze unit leer je hoe je AI kunt gebruiken als auditassistent; We zullen leren van het genereren van aanwijzingen tot het schrijven van een bevindingenoverzicht. Maar de meest kritische zin is deze: AI heeft geen controle; Het is een assistent die de blik van de auditor scherpt. De uiteindelijke goedkeuring ligt bij de bevoegde auditor die de professionele verantwoordelijkheid op zich neemt.
Waarom auditing van cruciaal belang is voor de beveiliging
Een auditrapport verzekert het project en de investeerders dat “deze code is herzien.” Als deze verzekering vals is, zijn de gevolgen desastreus: uitgebuit protocol, verloren financiering, ingestort project. Daarom is het gebruik van AI bij inspectie het meest zorgvuldige onderdeel van deze module. AI vergroot de reikwijdte van de auditor (herinnert zich meer patronen, leest sneller) maar vervangt de auditor niet.
Waarom gaat het niet over? Omdat:
- AI kan de unieke/nieuwe kwetsbaarheid die niet in de trainingsgegevens zit niet zien.
- AI mist vaak de fout in de bedrijfslogica van het protocol: dat de code technisch correct is, maar economisch exploiteerbaar.
- AI kan valse geruststelling bieden door in vloeiende taal ‘veilig’ te zeggen; Dit is de gevaarlijkste uitkomst.
Lagen van het gebruik van AI in controle
1. Eerste scan en patroonherinnering. AI doorloopt bekende kwetsbaarheidspatronen zoals een checklist: herintreding, toegangscontrole, orakelmanipulatie, front-running. Dit zorgt ervoor dat de auditor geen categorieën overslaat.
2. Code-uitleg. Door een complexe functie in gewone taal aan de AI uit te leggen, kan de auditor de logica snel doorgronden; maar de beschrijving wordt altijd vergeleken met de code.
3. Schrijven van een concept van bevindingen. Wanneer de auditor een kwetsbaarheid vindt, bespaart AI tijd bij het schrijven van de conceptrapportage (beschrijving, impact, voorgestelde oplossing).
4. Het genereren van tegenhypotheses. Vraag de AI "hoe kan deze functie worden misbruikt?" Vragen stellen herinnert ons aan het agressieve perspectief.
Let op: alleen omdat de AI zegt "Ik heb geen kwetsbaarheden in deze code gevonden" betekent NIET dat "deze code veilig is". Bewijs van afwezigheid is geen afwezigheid van bewijs. Dat de AI iets niet kan vinden, maakt het niet onnodig dat de auditor dat gebied onderzoekt.
Ernstniveaus vinden
Auditbevindingen worden geclassificeerd op basis van hun ernstniveau. AI zou dit raamwerk moeten gebruiken bij het genereren van concepten:
Niveau
Betekenis
voorbeeld
kritisch
Fondsverlies/uitsluiting direct mogelijk
Geld opnemen met herintreding
hoog
Ernstige impact onder bepaalde omstandigheden
Ongeautoriseerd afdrukken (nieuwstaat)
middelmatig
Beperkte impact of moeilijke toestand
Klein verlies met Oracle-afwijking
laag
Klein risico, schending van goede praktijken
Uitzending van ontbrekende gebeurtenis
Informatie
Niet-beveiliging, leesbaarheid
Gebrek aan NatSpec
Zwakke prompt/sterke prompt
Zwakke prompt:
Is dit contract veilig?
Deze vraag dwingt de AI om een absoluut, ongerechtvaardigd oordeel te vellen, zoals “ja/nee” – precies wat we niet willen.
Krachtige prompt:
Jouw rol: assistent van senior smart contract auditor. Scan het volgende contract voor beveiliging. Doorloop de volgende categorieën één voor één: herintreding, toegangscontrole, gehele bewerkingen, invoervalidatie, orakel/externe gegevens, front-running, gaslimiet. Voor elke BEVINDING: (1) relevante coderegel, (2) risico veroorzaken, (3) geschatte ernst (kritiek/hoog/gemiddeld/laag), (4) oplossingsvoorstel. Dit zijn hypothesen die bevestigd moeten worden; Geef geen "veilig" oordeel. Markeer de gebieden waar u niet zeker van bent en zeg duidelijk "laat de auditor dit bevestigen".
Vier kopieerbare sjablonen
1) Categoriegebaseerd browsen:
Scan dit contract op de volgende categorieën: herintreding, toegangscontrole, integer-overflow, invoervalidatie, orakelafhankelijkheid, front-running, DoS/gas. Zeg voor elke categorie "er is/is geen risico/ik weet het niet zeker" en verbind uw rechtvaardiging met de regel in de code. Vorm geen definitief oordeel.
2) Tegenhypothese vanuit het perspectief van de aanvaller:
Denk als een aanvaller: wat zijn de manieren om deze functie te misbruiken? Schrijf elk scenario stap voor stap uit en geef aan welke voorwaarden nodig zijn. Deze scenario's zijn de hypothesen die moeten worden getest; Genereer GEEN daadwerkelijke exploitcode, beschrijf alleen het risico.
3) Conceptbevindingenrapport:
Rapporteer de volgende geverifieerde bevinding in formele audittaal: titel, ernst, beschrijving, impact, betrokken code, stappen om te reproduceren, voorgestelde oplossing. Gebruik afgemeten en technische taal; overdrijving. Ga ervan uit dat de bevinding door de auditor wordt bevestigd; kom niet met een nieuwe bevinding.
4) Verificatie repareren:
Hieronder vindt u een kwetsbaarheid en de oplossing die door de ontwikkelaar is toegepast. Onderzoek of de oplossing de kwetsbaarheid daadwerkelijk sluit; Geef aan of het een nieuwe bijwerking of kwetsbaarheid creëert. Zeg zeker niet "gesloten"; Eindig met "moet worden bevestigd door testen".
Drie minikoffers (in aantallen)
Geval 1 – AI verhinderde categoriehoppen. Een auditor stond op het punt zich te concentreren op een contract met 400 regels en de orakelcategorie over te slaan. De categoriescan van AI gaf een waarschuwing dat "prijsgegevens afkomstig zijn uit één enkele bron en vatbaar zijn voor manipulatie". De accountant heeft het onderzocht en vastgesteld dat er inderdaad sprake was van een middelmatig risico. Les: AI handhaaft dekkingsdiscipline.
Geval 2 – Valse ‘veilige’ zekerheid. Een ander team vroeg aan de AI “is dit veilig?” vroeg hij; "Er lijkt geen groot probleem te zijn", zei AI. De bemanningsinspectie was licht. Toen ontdekte de onafhankelijke auditor een fout in de bedrijfslogica: een berekening die technisch correct was, maar waarvan de prikkels exploiteerbaar waren. Les: AI mist bedrijfslogische fouten; Je kunt niet vertrouwen dat hij 'veilig' zegt.
Geval 3 — Het opstellen van het rapport bespaarde 3 uur. De auditor was een halve dag bezig met het handmatig rapporteren van 8 bevindingen. Nadat ik de geverifieerde bevindingen aan de AI had doorgegeven en het officiële concept had afgedrukt, daalde de tijd met ~3 uur; De auditor besteedde tijd aan verdieping. Les: AI is veilig en efficiënt in rapportage omdat de bevindingen al door mensen zijn geverifieerd.
Kwetsbaarheid van bedrijfslogica: de blinde vlek van AI
De duurste kwetsbaarheden komen vaak niet voort uit een technische fout in de code, maar uit de exploiteerbaarheid van de bedrijfslogica: het afronden van de exploitatie van een beloningsrekening, het kapen van een stem door een flitslening, de onmiddellijke manipulatie van een prijs. Dit zijn gevallen waarin de code "correct" werkt, maar het protocol economisch kan worden misleid. Het is waarschijnlijk dat AI dergelijke fouten over het hoofd ziet, vooral protocolspecifieke fouten. Daarom is de beoordeling van de bedrijfslogica het meest mensintensieve onderdeel van de auditor en het minst afhankelijk van AI.
Tip: Vraag de AI “hoe kunnen de economische prikkels van dit protocol worden uitgebuit?” en gebruik de scenario’s die naar voren komen als uitgangspunt – maar onthoud dat jij en je team de echte analyse moeten doen.
Veel voorkomende fouten
- Vraag de AI: "is het veilig?" Je ja vragen en vertrouwen. Een absoluut oordeel is niet vereist.
- Het stoppen van de beoordeling wanneer de AI zegt: "Ik kon het niet vinden". Afwezigheid is geen bewijs.
- Delegatie van bedrijfslogicabeoordeling aan AI. Het is zijn grootste blinde vlek.
- Geen gebruik maken van onafhankelijke tools (Slither enz.). AI alleen is niet genoeg.
- De bevinding van de AI in het rapport stoppen zonder deze te verifiëren. Risico op hallucinaties.
- Proberen de controleverantwoordelijkheid bij AI te leggen. De verantwoordelijkheid ligt bij de deskundige.
Samengevat
- Audit is van cruciaal belang voor de veiligheid; AI breidt de reikwijdte van de auditor uit, maar vervangt deze niet.
- AI mist de oorspronkelijke kwetsbaarheid en bedrijfslogica-bug; Zeggen ‘veilig’ is geen zekerheid.
- De bevindingen worden geclassificeerd op basis van ernstniveau; AI is nuttig bij het genereren van concepten.
- Tegenhypothese en categoriescreening behouden de discipline van inclusie.
- De uiteindelijke goedkeuring en professionele verantwoordelijkheid ligt altijd bij de bevoegde auditor.
Applicatie taak
Zoek een voorbeeldcontract dat een bekende kwetsbaarheid bevat (voor educatieve doeleinden zijn voorbeelden van "kwetsbare contracten" beschikbaar in open source). Pas de prompt 'Categoriegebaseerd scannen' toe op de AI. Merk op of de AI: (1) de echte kwetsbaarheid heeft gevonden, (2) verzonnen/valse bevindingen heeft geproduceerd, (3) absolute oordelen heeft geveld zoals ‘veilig’. Vergelijk het dan met een statische analysetool.
controlelijst
- [ ] Vraag de AI: "is het veilig?" In plaats daarvan had ik een op categorieën gebaseerde scan.
- [ ] Ik behandelde elke bevinding als een hypothese.
- [ ] Ik heb zelf/team de bedrijfslogica-review gedaan.
- [ ] Ik heb het kruisgevalideerd met een onafhankelijk hulpmiddel voor statische analyse.
- [ ] Ik heb bevestigd dat de AI geen bevindingen verzint.
- [ ] Ik heb de bevindingen geclassificeerd op basis van de mate van ernst.
- [ ] Ik heb aanvaard dat de uiteindelijke goedkeuring bij de bevoegde auditor ligt.