Gains :
- Capacité à comprendre que l’intelligence artificielle élargit le champ d’action de l’auditeur, mais ne le remplace pas, et qu’elle est utile pour l’analyse des catégories et la rédaction des conclusions.
- Être capable de reconnaître que l'intelligence artificielle a manqué la vulnérabilité d'origine et l'erreur de logique métier, et qu'une déclaration « sécurisée » fluide ne constitue pas une garantie
- Capacité à classer les constatations selon leur niveau de gravité et à comprendre que l'approbation finale et la responsabilité professionnelle incombent à l'auditeur compétent.
L'audit de sécurité (examen systématique d'un contrat intelligent pour détecter les vulnérabilités) est la tâche la plus importante de Web3. Une seule ligne manquée par un auditeur peut entraîner des millions de dollars de pertes. Dans cette unité, vous apprendrez à utiliser l'IA comme assistant d'audit ; Nous apprendrons en générant des indices pour rédiger un aperçu des résultats. Mais la phrase la plus critique est la suivante : l’IA ne contrôle pas ; C'est un assistant qui aiguise l'œil de l'auditeur. L'approbation finale revient à l'auditeur compétent qui assume la responsabilité professionnelle.
Pourquoi l'audit est critique pour la sécurité
Un rapport d'audit rassure le projet et les investisseurs sur le fait que « ce code a été révisé ». Si cette assurance est fausse, les conséquences sont désastreuses : protocole exploité, financement perdu, projet effondré. Par conséquent, l’utilisation de l’IA dans l’inspection est la partie la plus minutieuse de ce module. L’IA élargit le champ d’action de l’auditeur (rappelle plus de modèles, lit plus rapidement) mais ne remplace pas l’auditeur.
Pourquoi ça ne passe pas ? Parce que :
- L'IA ne peut pas voir la vulnérabilité unique/nouvelle qui ne figure pas dans les données d'entraînement.
- L’IA passe souvent à côté du défaut de la logique métier du protocole : le code est techniquement correct mais économiquement exploitable.
- L’IA peut donner une fausse assurance en disant « sûr » dans un langage courant ; C’est l’issue la plus dangereuse.
Niveaux d'utilisation de l'IA pour le contrôle
1. Scan initial et rappel de modèle. L'IA passe en revue des modèles de vulnérabilité connus comme une liste de contrôle : réentrance, contrôle d'accès, manipulation d'oracle, front-running. Cela garantit que l’auditeur ne manque aucune catégorie.
2. Explication du code. Expliquer une fonction complexe à l’IA dans un langage simple permet à l’auditeur d’en saisir rapidement la logique ; mais la description est toujours comparée au code.
3. Rédiger une ébauche de conclusions. Lorsque l’auditeur découvre une vulnérabilité, l’IA gagne du temps dans la rédaction du brouillon du rapport (description, impact, solution proposée).
4. Générer une contre-hypothèse. Demandez à l'IA "comment peut-on abuser de cette fonction ?" Demander " nous rappelle la perspective agressive.
Attention : Ce n'est pas parce que l'IA dit « Je n'ai trouvé aucune vulnérabilité dans ce code » que « ce code est sûr ». Une preuve d’absence n’est pas une absence de preuve. Le fait que l’IA ne puisse pas trouver quelque chose ne rend pas inutile l’examen de cette zone par l’auditeur.
Trouver des niveaux de gravité
Les constatations d’audit sont classées selon leur niveau de gravité. L'IA devrait utiliser ce cadre lors de la génération de brouillons :
Niveau
Signification
exemple
critique
Perte de fonds/blocage directement possible
Retirer des fonds avec réentrée
haut
Impact sérieux dans certaines conditions
Impression non autorisée (état neuf)
moyen
Impact limité ou condition difficile
Petite perte avec déviation Oracle
faible
Risque mineur, manquement aux bonnes pratiques
Diffusion d'un événement manquant
Informations
Non-sécurité, lisibilité
Manque de NatSpec
Invite faible/Invite forte
Invite faible :
Ce contrat est-il sûr ?
Cette question oblige l'IA à porter un jugement absolu et injustifié comme « oui/non » – exactement ce que nous ne voulons pas.
Invite puissante :
Votre rôle : assistant de l'auditeur principal des contrats intelligents. Scannez le contrat suivant pour plus de sécurité. Parcourez les catégories suivantes une par une : réentrée, contrôle d'accès, opérations sur les entiers, validation des entrées, oracle/données externes, front-running, limite de gaz. Pour chaque CONSTATATION : (1) ligne de code pertinente, (2) cause du risque, (3) gravité estimée (Critique/Élevée/Moyenne/Faible), (4) proposition de solution. Ce sont des HYPOTHÈSES À CONFIRMER ; Ne donnez pas de verdict « sûr ». Marquez les domaines dont vous n'êtes pas sûr en disant clairement « laissez l'auditeur confirmer ».
Quatre modèles copiables
1) Navigation basée sur les catégories :
Parcourez ce contrat pour les catégories suivantes : réentrance, contrôle d'accès, dépassement d'entier, validation des entrées, dépendance à Oracle, front-running, DoS/gas. Pour chaque catégorie, dites « il n'y a/il n'y a aucun risque/je ne suis pas sûr » et reliez votre justification à la ligne du code. Ne portez pas de jugement définitif.
2) Contre-hypothèse du point de vue de l'attaquant :
Pensez comme un attaquant : quels sont les moyens d’abuser de cette fonction ? Écrivez chaque scénario étape par étape et indiquez les conditions requises. Ces scénarios sont les hypothèses à tester ; NE générez PAS de code d’exploitation réel, décrivez simplement le risque.
3) Projet de rapport de conclusions :
Signalez le résultat vérifié suivant dans un langage d'audit formel : titre, gravité, description, impact, code affecté, étapes à reproduire, solution proposée. Utiliser un langage mesuré et technique ; exagération. Supposons que la constatation soit confirmée par l’auditeur, n’inventez pas une nouvelle constatation.
4) Corriger la vérification :
Vous trouverez ci-dessous une vulnérabilité et le correctif appliqué par le développeur. Vérifiez si le correctif corrige réellement la vulnérabilité ; indiquez si cela crée un nouvel effet secondaire ou une nouvelle vulnérabilité. Ne dites pas « fermé » avec certitude ; Terminez par "doit être confirmé par des tests".
Trois mini-cases (en chiffres)
Cas 1 – L’IA a empêché le saut de catégorie. Un auditeur était sur le point de se concentrer sur un contrat de 400 lignes et de sauter la catégorie Oracle. L'analyse des catégories d'AI a averti que "les données sur les prix proviennent d'une source unique, ouverte à la manipulation". L'auditeur l'a examiné et a constaté qu'il s'agissait effectivement d'un risque moyen. Leçon : L'IA maintient la discipline de couverture.
Cas 2 — Fausse assurance de « sécurité ». Une autre équipe a demandé à l’IA « est-ce sûr ? » il a demandé; "Il ne semble pas y avoir de problème majeur", a déclaré AI. L'inspection de l'équipage a été légère. L’auditeur indépendant a ensuite découvert une faille dans la logique métier : un calcul techniquement correct mais dont les incitations étaient exploitables. Leçon : l'IA rate une erreur de logique métier ; On ne peut pas lui faire confiance pour dire « en sécurité ».
Cas 3 — La rédaction du rapport a permis de gagner 3 heures. L'auditeur passait la moitié de la journée à rapporter manuellement 8 constatations. Une fois que j'ai donné les résultats vérifiés à l'IA et imprimé le projet officiel, le temps a diminué d'environ 3 heures ; L'auditeur a consacré du temps à l'approfondissement. Leçon : L'IA est sûre et efficace en matière de reporting car les résultats ont déjà été vérifiés humainement.
Vulnérabilité de la logique métier : le point mort de l'IA
Les vulnérabilités les plus coûteuses ne proviennent souvent pas d'une erreur technique dans le code, mais de l'exploitabilité de la logique métier : exploitation par arrondi d'un compte de récompense, détournement flash d'un vote, manipulation instantanée d'un prix. Ce sont des cas où le code fonctionne « correctement » mais où le protocole peut être trompé économiquement. L’IA manquera probablement de telles erreurs, en particulier celles spécifiques au protocole. Par conséquent, l’examen de la logique métier est le domaine le plus exigeant en ressources humaines de l’auditeur et le moins dépendant de l’IA.
Indice : demandez à l’IA « comment les incitations économiques de ce protocole peuvent-elles être exploitées ? » et utilisez les scénarios qui se présentent comme point de départ, mais rappelez-vous que vous et votre équipe devez faire la véritable analyse.
Erreurs courantes
- Demandez à l'IA "est-ce sûr ?" Demander et faire confiance à votre oui. Un jugement absolu n’est pas requis.
- Arrêter la revue lorsque l'IA dit "Je ne l'ai pas trouvé". L'absence n'est pas une preuve.
- Déléguer la révision de la logique métier à l’IA. C'est son plus grand angle mort.
- Ne pas utiliser d'outils indépendants (Slither etc.). L’IA seule ne suffit pas.
- Mettre le constat fait par l'IA dans le rapport sans le vérifier. Risque d'hallucinations.
- Essayer de confier la responsabilité du contrôle à l’IA. La responsabilité incombe à l'expert.
En résumé
- L'audit est essentiel à la sécurité ; L'IA élargit le champ d'action de l'auditeur mais ne le remplace pas.
- L'IA manque la vulnérabilité d'origine et le bug de logique métier ; Dire « sûr » n’est pas une assurance.
- Les résultats sont classés selon le niveau de gravité ; L'IA est utile pour générer des brouillons.
- Les contre-hypothèses et la sélection par catégories préservent la discipline de l’inclusion.
- L'approbation finale et la responsabilité professionnelle incombent toujours à l'auditeur compétent.
Tâche de candidature
Recherchez un exemple de contrat contenant une vulnérabilité connue (à des fins pédagogiques, des exemples de « contrats vulnérables » sont disponibles en open source). Appliquez l’invite « analyse basée sur les catégories » à l’IA. Notez si l’IA : (1) a trouvé la véritable vulnérabilité, (2) a produit des conclusions fabriquées/fausses, (3) a porté des jugements absolus tels que « sécurisé ». Comparez-le ensuite avec un outil d’analyse statique.
liste de contrôle
- [ ] Demandez à l'IA "est-ce sûr ?" Au lieu de cela, j'ai eu une analyse basée sur les catégories.
- [ ] J'ai traité chaque découverte comme une hypothèse.
- [ ] J'ai effectué l'examen de la logique métier moi-même/en équipe.
- [ ] Je l'ai validé de manière croisée avec un outil d'analyse statique indépendant.
- [ ] J'ai confirmé que l'IA ne fabrique pas de découvertes.
- [ ] J'ai classé les résultats selon le niveau de gravité.
- [ ] J'ai accepté que l'approbation finale revienne à l'auditeur compétent.