Câștiguri:
- Capacitatea de a înțelege că inteligența artificială extinde domeniul de aplicare al auditorului, dar nu îl înlocuiește și este utilă în scanarea categoriei și găsirea redactării.
- A fi capabil să recunoască faptul că inteligența artificială a ratat vulnerabilitatea inițială și eroarea logicii de afaceri și că o declarație „sigură” fluentă nu este o asigurare
- Capacitatea de a clasifica constatările în funcție de nivelul lor de seriozitate și de a înțelege că aprobarea finală și responsabilitatea profesională revin auditorului competent.
Auditul de securitate (examinarea sistematică a unui contract inteligent pentru vulnerabilități) este munca cea mai responsabilă a Web3. O singură linie ratată de un auditor poate duce la pierderi de milioane de dolari. În această unitate veți învăța cum să utilizați AI ca asistent de audit; Vom învăța de la generarea de indicii până la scrierea unei schițe a constatărilor. Dar cea mai critică propoziție este aceasta: AI nu controlează; Este un asistent care ascuți ochiul auditorului. Aprobarea finală revine auditorului competent care își asumă responsabilitatea profesională.
De ce auditarea este critică pentru securitate
Un raport de audit asigură proiectul și investitorii că „acest cod a fost revizuit”. Dacă această asigurare este falsă, consecințele sunt dezastruoase: protocol exploatat, finanțare pierdută, proiect prăbușit. Prin urmare, utilizarea AI în inspecție este cea mai atentă parte a acestui modul. AI extinde domeniul de aplicare al auditorului (amintește mai multe modele, citește mai repede), dar nu îl înlocuiește pe auditor.
De ce nu trece? Pentru ca:
- AI nu poate vedea vulnerabilitatea unică/nouă care nu se află în datele de antrenament.
- Inteligența artificială ratează adesea defectul din logica de afaceri a protocolului - că codul este corect din punct de vedere tehnic, dar exploatabil din punct de vedere economic.
- AI poate oferi o falsă reasigurare spunând „în siguranță” într-un limbaj fluent; Acesta este rezultatul cel mai periculos.
Straturi de utilizare a AI în control
1. Scanare inițială și memento de model. AI trece prin modele de vulnerabilitate cunoscute, cum ar fi o listă de verificare: reintrare, control acces, manipulare oracol, avansare. Acest lucru asigură că auditorul nu pierde nicio categorie.
2. Explicația codului. Explicarea unei funcții complexe către AI într-un limbaj simplu permite auditorului să înțeleagă rapid logica; dar descrierea este întotdeauna comparată cu codul.
3. Redactarea unui proiect de constatări. Atunci când auditorul găsește o vulnerabilitate, AI economisește timp în scrierea schiței raportului (descriere, impact, soluție propusă).
4. Generarea de contra-ipoteze. Întrebați AI „cum poate fi abuzată această funcție?” Întrebarea „ne amintește de perspectiva agresivă.
Atenție: Doar pentru că AI spune „Nu am găsit vulnerabilități în acest cod” NU înseamnă „acest cod este sigur”. Dovada absenței nu este absența dovezilor. Faptul că AI nu poate găsi ceva nu face ca auditorul să fie inutil să examineze acea zonă.
Găsirea nivelurilor de severitate
Constatările auditului sunt clasificate în funcție de nivelul lor de severitate. AI ar trebui să utilizeze acest cadru atunci când generează schițe:
Nivel
Înțeles
exemplu
critică
Pierderea/blocarea fondului direct posibilă
Retragerea de fonduri cu reintrare
înalt
Impact grav în anumite condiții
Imprimare neautorizată (mentă)
mediu
Impact limitat sau stare dificilă
Pierdere mică cu deviația Oracle
scăzută
Risc minor, încălcarea bunelor practici
Lipsește evenimentul difuzat
Informații
Non-securitate, lizibilitate
Lipsa NatSpec
Prompt slab / Prompt puternic
Prompt slab:
Este acest contract sigur?
Această întrebare obligă AI să emită o judecată absolută, nejustificată, precum „da/nu” – exact ceea ce nu ne dorim.
Solicitare puternică:
Rolul dvs.: asistent al auditorului senior smart contract. Scanați următorul contract pentru securitate. Parcurgeți următoarele categorii una câte una: reintrare, control acces, operațiuni întregi, validare de intrare, date oracol/externe, front-running, limită de gaz. Pentru fiecare CONSTATARE: (1) linie relevantă de cod, (2) cauza riscului, (3) severitatea estimată (Critic/Ridicat/Mediu/Scăzut), (4) propunere de soluție. Acestea sunt IPOTEZE DE CONFIRMAT; Nu da un verdict „sigur”. Marcați zonele pe care nu sunteți sigur că spun clar „lăsați auditorul să confirme”.
Patru șabloane copiabile
1) Navigare pe categorii:
Scanați acest contract pentru următoarele categorii: reintrare, control acces, depășire de numere întregi, validare de intrare, dependență de oracle, front-running, DoS/gaz. Pentru fiecare categorie, spuneți „nu există/nu există risc/Nu sunt sigur” și conectați justificarea la rândul din cod. Nu face o judecată finală.
2) Contra-ipoteză din perspectiva atacatorului:
Gândește-te ca un atacator: care sunt modalitățile de a abuza de această funcție? Scrieți fiecare scenariu pas cu pas și indicați ce condiții sunt necesare. Aceste scenarii sunt ipotezele de testat; NU generați cod de exploatare real, doar descrieți riscul.
3) Proiect de raport privind constatările:
Raportați următoarea constatare verificată într-un limbaj oficial de audit: titlu, gravitate, descriere, impact, cod afectat, pași de reproducere, soluție propusă. Folosește un limbaj măsurat și tehnic; exagerare. Să presupunem că constatarea este confirmată de auditor, nu inventați o nouă constatare.
4) Verificarea corectă:
Mai jos este o vulnerabilitate și remedierea aplicată de dezvoltator. Examinați dacă remedierea închide de fapt vulnerabilitatea; marcați dacă creează un nou efect secundar sau o vulnerabilitate. Nu spune „închis” cu siguranță; Încheiați cu „trebuie confirmat prin testare”.
Trei mini cutii (în cifre)
Cazul 1 – AI a împiedicat saltul de categorii. Un auditor era pe cale să se concentreze pe un contract de 400 de linii și să sară peste categoria oracol. Scanarea categoriei AI a dat un avertisment că „datele de preț sunt dintr-o singură sursă, deschise manipulării”. Auditorul a examinat-o și a constatat că era într-adevăr un risc mediu. Lecție: AI menține disciplina de acoperire.
Cazul 2 – Asigurare falsă „sigură”. O altă echipă a întrebat AI „este sigur?” a întrebat el; „Nu pare să existe o problemă semnificativă”, a spus AI. Inspecția echipajului a fost ușoară. Apoi, auditorul independent a găsit un defect al logicii de afaceri: un calcul corect din punct de vedere tehnic, dar ale cărui stimulente erau exploatabile. Lecție: AI ratează o eroare de logica de afaceri; Nu poate fi de încredere că spune „în siguranță”.
Cazul 3 — Întocmirea raportului a salvat 3 ore. Auditorul petrecea jumătate din zi raportând manual 8 constatări. Odată ce am dat AI constatările verificate și am tipărit schița oficială, timpul a scăzut cu ~3 ore; Auditorul a dedicat timp aprofundării. Lecție: AI este sigură și eficientă în raportare, deoarece constatările au fost deja verificate uman.
Vulnerabilitatea logicii de afaceri: punctul mort al AI
Cele mai scumpe vulnerabilități provin adesea nu dintr-o eroare tehnică a codului, ci din exploatarea logicii afacerii: exploatarea rotunjirii unui cont de recompensă, deturnarea unui împrumut rapid a unui vot, manipularea instantanee a unui preț. Acestea sunt cazurile în care codul funcționează „corect”, dar protocolul poate fi păcălit din punct de vedere economic. Este posibil ca AI să rateze astfel de erori, în special cele specifice protocolului. Prin urmare, revizuirea logicii de afaceri este cea mai intensivă zonă a auditorului și cea mai puțin dependentă de AI.
Sugestie: Întrebați AI „cum pot fi exploatate stimulentele economice ale acestui protocol?” și utilizați scenariile care apar ca punct de plecare - dar amintiți-vă că dvs. și echipa dvs. ar trebui să faceți analiza reală.
Greșeli comune
- Întrebați AI „este sigur?” Întreabă și ai încredere în da. Judecata absolută nu este necesară.
- Oprirea revizuirii atunci când AI spune „Nu l-am putut găsi”. Absența nu este o dovadă.
- Delegarea revizuirii logicii de afaceri către AI. Este cel mai mare punct mort al lui.
- Nu folosiți instrumente independente (Slither etc.). Numai AI nu este suficient.
- Introducerea constatării realizate de AI în raport fără a o verifica. Risc de halucinații.
- Încercarea de a pune responsabilitatea controlului asupra AI. Responsabilitatea revine expertului.
Pe scurt
- Auditul este critic din punct de vedere al siguranței; AI extinde domeniul de aplicare al auditorului, dar nu îl înlocuiește.
- AI ratează vulnerabilitatea originală și bug-ul logicii de afaceri; A spune „în siguranță” nu este o asigurare.
- Constatările sunt clasificate în funcție de nivelul de severitate; AI este utilă în generarea de schițe.
- Contra-ipotezele și screening-ul categoriei păstrează disciplina incluziunii.
- Aprobarea finală și responsabilitatea profesională revin întotdeauna auditorului competent.
Sarcina de aplicare
Găsiți un exemplu de contract care conține o vulnerabilitate cunoscută (în scopuri educaționale, exemple de „contracte vulnerabile” sunt disponibile în sursă deschisă). Aplicați promptul „scanare bazată pe categorii” la AI. Observați dacă AI: (1) a găsit vulnerabilitatea reală, (2) a produs constatări fabricate/false, (3) a făcut judecăți absolute, cum ar fi „sigur”. Apoi comparați-l cu un instrument de analiză statică.
lista de verificare
- [ ] Întrebați AI „este sigur?” În schimb, am avut o scanare bazată pe categorii.
- [ ] Am tratat fiecare constatare ca pe o ipoteză.
- [ ] Am revizuit singur/echipa logica de afaceri.
- [ ] L-am validat încrucișat cu un instrument independent de analiză statică.
- [ ] Am confirmat că AI nu fabrică constatări.
- [ ] Am clasificat constatările în funcție de nivelul de severitate.
- [ ] Am acceptat că aprobarea finală revine auditorului competent.