Gains :
- Capacité à reconnaître les modèles de vulnérabilité courants tels que la réentrée, le contrôle d'accès, la manipulation d'oracle et le front-running et à les analyser avec un outil d'analyse statique + intelligence artificielle + humain
- Capacité à distinguer les points forts de l'IA pour expliquer les résultats des outils et hiérarchiser les faux positifs et les faiblesses du MEV et de la logique métier
- Comprendre qu'une « analyse propre » n'est pas un certificat de sécurité, que l'analyse n'est qu'un niveau de contrôle
Nous avons vu la discipline holistique de l’audit dans l’unité précédente. Dans cette unité, nous nous concentrons sur un sujet plus technique : l'analyse des vulnérabilités — la recherche systématique de modèles de vulnérabilité connus dans le code. Ici, nous utiliserons l’IA, ainsi que des outils d’analyse statique, comme assistant qui analyse et décrit les modèles de vulnérabilité connus. L’objectif : connaître en profondeur les vulnérabilités les plus courantes et distinguer où l’IA est fiable et où elle est inadéquate pour les analyser.
Analyse statique et dynamique
La numérisation est de deux types. Analyse statique : examiner le code sans l'exécuter : des outils tels que Slither et Mythril analysent le code du contrat et signalent les modèles connus. L'analyse dynamique/symbolique (exécuter le code avec différentes entrées ou l'explorer mathématiquement) : le fuzzing (bombardement avec une entrée aléatoire) et l'exécution symbolique (explorer tous les chemins possibles) entrent dans ce groupe.
L'IA ne remplace pas ces outils, elle les complète : lorsque le véhicule émet un avertissement, l'IA explique l'avertissement en langage clair ; L'IA peut rappeler quand l'outil manque un modèle ; Mais l’IA ne peut à elle seule garantir la quantité de données analysées. Le bon workflow : outil + IA + humain.
Astuce : donnez à l'IA le résultat d'un outil d'analyse statique (par exemple, le rapport Slither) et demandez "Expliquez chaque alerte en langage simple, quels sont les risques réels et lesquels pourraient être des faux positifs ?" demander. L’IA est inestimable pour rendre les résultats bruts des outils compréhensibles et prioritaires pour les humains.
Modèles de vulnérabilité les plus courants
1. Réentrée. Si une fonction appelle un contrat externe sans mettre à jour son état, le contrat appelé peut revenir en arrière, déclencher à nouveau la même fonction et retirer le fonds plusieurs fois. Solution : ordre de contrôles-effets-interactions et garde de réentrée.
2. Manque de contrôle d'accès. Une fonction critique (retrait, retrait, mise à niveau) est accidentellement rendue publique. C’est l’une des erreurs les plus courantes et les plus coûteuses.
3. Manipulation d'Oracle. La dépendance aveugle du contrat à une source de prix externe (oracle). L'attaquant manipule le prix instantanément et trompe le protocole. Solution : prix moyen pondéré dans le temps (TWAP), multi-sources.
4. Dépassement/sous-dépassement entier. Lorsqu'un nombre dépasse la valeur maximale autorisée et revient au début. Modern Solidity en détecte automatiquement la majeure partie, mais le risque reste dans le code (assembleur) de bas niveau.
5. En tête. Les transactions apparaissent dans le pool public (mempool) avant d'être confirmées ; L'attaquant peut voir votre transaction et insérer sa propre transaction devant celle-ci. MEV (Maximal Extractable Value — la valeur extraite de la séquence de transaction) est le nom général de ce sujet.
6. Déni de service (DoS). Une boucle devient trop coûteuse et rend la fonction inutilisable, ou une dépendance sur une adresse devient verrouillée.
7. Mettre à niveau les risques. Collision de stockage et abus d’autorité dans les contrats évolutifs.
vulnérabilité
Confiance dans l'analyse de l'IA
Pourquoi
réentrée
haut
Modèle clair et connu
contrôle d'accès
haut
La moisissure peut être scannée
Opérations entières
haut
contrôle standard
Manipulation des oracles
moyen
Nécessite un contexte
Avant-gardiste/MEV
Moyen-Faible
spécifique au protocole
erreur de logique métier
faible
Authentique, contextuel
Invite faible/Invite forte
Invite faible :
Y a-t-il une faille dans ce code ?
Invite puissante :
Votre rôle : assistant au contrôle de sécurité. Parcourez le contrat ci-dessous pour rechercher les modèles connus suivants et "à risque/non/incertain" pour chacun : réentrance, contrôle d'accès, opérations sur les entiers, dépendance à Oracle, front-running, DoS, mise à niveau de la sécurité. Reliez chaque détermination à la ligne correspondante et expliquez pourquoi il existe un risque. Ce sont des hypothèses qui SERONT VÉRIFIÉES avec un outil d’analyse statique et un auditeur. Notez qu'il peut y avoir des faux positifs.
Quatre modèles copiables
1) Description de la sortie de l'outil :
Ci-dessous le rapport d'un outil d'analyse statique (Slither). Expliquez chaque alerte en langage clair : qu'est-ce que cela signifie, s'agit-il d'un risque réel ou d'un éventuel faux positif, quelle doit être sa priorité ? Ne prenez pas de décision ferme ; Donnez la priorité à la confirmation de l’auditeur.
2) Dépistage axé sur la réentrée :
Retrouvez toutes les fonctions qui effectuent des appels externes dans ce contrat. Examinez si l'ordre contrôles-effets-interactions est suivi pour chacun d'eux et s'il existe un garde de réentrée. Montrez les plus risqués avec une ligne. Marquez si vous n'êtes pas sûr ; Génération de code d'exploitation.
3) Plan de contrôle d'accès :
Répertoriez toutes les fonctions externes/publiques dans ce contrat et précisez « qui peut appeler » (tout le monde/propriétaire/rôle) pour chacune. Effectuez les opérations critiques (retrait, impression, mise à niveau) et marquez celles dont le contrôle d'accès est faible. Présentez-le avec un tableau.
4) Élimination des faux positifs :
Considérez pourquoi cet avertissement d'analyse pourrait ne pas constituer un risque RÉEL (faux positif) : quel contexte ou condition de code invaliderait cet avertissement ? Mais ne dites pas « il n’y a absolument aucun problème » ; Énumérez les points qui nécessitent une confirmation.
Trois mini-cases (en chiffres)
Cas 1 — Véhicule + IA a doublé l'efficacité. Une équipe a exécuté Slither sur un projet de 12 contrats et a reçu 140 avertissements. Une fois que l’IA a expliqué et hiérarchisé les alertes, il s’est avéré que 95 des 140 alertes étaient des faux positifs ; L'équipe s'est concentrée sur 45 vrais candidats. Le temps de triage est passé de 2 jours à 5 heures. Leçon : L'IA est puissante pour humaniser la production des véhicules.
Cas 2 – L’IA a détourné le MEV. Dans un contrat DEX (échange décentralisé), l'IA a trouvé les modèles standards propres mais n'a pas réussi à détecter une vulnérabilité frontale ; parce que cela était spécifique à l’ordre des opérations du protocole. Auditeur humain et simulation capturées. Leçon : les risques spécifiques aux protocoles tels que MEV/front-running sont le point faible de l'IA.
Cas 3 – Évitement de perdre du temps sur un faux positif. L’équipe a évité une réécriture inutile lorsque l’IA a expliqué qu’un avertissement de réentrée était en fait un faux positif (la fonction était déjà gardée). Mais l’équipe l’a quand même confirmé avec un seul test. Leçon : l'IA donne des priorités ; La confirmation vient encore une fois avec les tests.
Limites de la numérisation
L'analyse trouve des modèles connus. Ni l'outil ni l'IA ne sont garantis pour détecter une vulnérabilité nouvelle, unique ou spécifique au protocole. Par conséquent, le contrôle fait partie de l’audit ; pas lui-même. L’idée selon laquelle « le scan est propre, donc cela signifie qu’il est sûr » est l’une des idées fausses les plus dangereuses dans ce domaine. Le dragage ramasse les fruits les plus faciles à trouver ; Pour les risques profonds et uniques, l’expertise humaine, les tests, le fuzzing et l’audit formel sont essentiels.
Attention : un rapport « propre » d'un outil d'analyse ou d'une IA n'est pas un certificat de sécurité. Le présenter de cette façon – en particulier aux investisseurs – est trompeur et contraire à l’éthique.
Erreurs courantes
- Remplacer le contrôle par l'inspection. La numérisation n’est qu’une seule couche, pas la totalité.
- Utiliser l'IA sans outils. Analyse statique + IA + travail humain ensemble.
- Élimination des faux positifs sans confirmation. Chaque écran est testé/vérifié par un humain.
- Contourner les risques spécifiques au protocole (MEV) en s'appuyant sur l'IA. Le point faible de l’IA.
- Penser « analyse propre » = « sûr ». Il ne peut pas trouver l'inconnu.
- Génération de code d'exploitation. Seule la description défensive du risque est légitime.
En résumé
- L'analyse des vulnérabilités recherche les modèles de vulnérabilité connus avec véhicule + IA + humain.
- L’IA est puissante pour expliquer et hiérarchiser les résultats des outils d’analyse statique.
- Fiable dans des modèles clairs tels que la réentrée et le contrôle d'accès ; Faible en MEV et en logique métier.
- Même l’élimination des faux positifs nécessite une confirmation.
- Une « analyse propre » n'est pas un certificat de sécurité ; Cela ne remplace pas la supervision.
Tâche de candidature
Exécutez un outil d'analyse statique sur un exemple de contrat (si possible) ou recherchez un rapport Slither prêt à l'emploi. Appliquez l’invite « description de la sortie de l’outil » à l’IA. Évaluez si l'IA : (1) explique correctement les avertissements, (2) a du sens pour faire la distinction entre les faux positifs et (3) manque un risque spécifique au protocole. Remplissez les colonnes « véhicule trouvé / IA expliquée / humain confirmé » dans un tableau.
liste de contrôle
- [ ] J'ai positionné les hachures comme un calque du contrôle.
- [ ] J'ai utilisé ensemble un outil d'analyse statique + IA + humain.
- [ ] J'ai recherché catégorie par catégorie les modèles connus.
- [ ] J'ai éliminé les faux positifs avec confirmation.
- [ ] Je me suis appuyé sur les humains dans les domaines faibles tels que la logique MEV/business.
- [ ] Je n'ai pas proposé de « table rase » comme assurance.
- [ ] Je travaillais uniquement à des fins de défense ; Je n'ai pas créé d'exploits.