Un audit de smart contract est essentiellement une revue de code effectuée par des spécialistes en sécurité. Les auditeurs examinent le code source du contrat à la recherche de vulnérabilités, d’erreurs de logique et d’écarts par rapport aux spécifications. Un audit typique pour un protocole DeFi prend de 2 à 6 semaines et coûte entre 50 000 $ et plus de 500 000 $ selon la complexité et le cabinet d’audit.
Ce que les audits détectent de manière fiable, ce sont les schémas de vulnérabilités connus. Les attaques par réentrance, les problèmes de dépassement et de sous-dépassement d’entiers, les mauvaises configurations de contrôle d’accès et les vulnérabilités de front-running ont tous des signatures bien documentées que les auditeurs expérimentés peuvent identifier. Ce sont les types de bugs pour lesquels il existe des cas de test et des outils de détection bien établis. Les outils d’analyse automatisée comme Slither et Mythril peuvent en détecter beaucoup avant même qu’un auditeur humain ne commence sa revue.
Là où les audits sont moins fiables, c’est dans la détection des erreurs de logique métier. Un contrat peut être techniquement sécurisé, sans vulnérabilités exploitables dans son code, tout en présentant une faille logique permettant une extraction de valeur d’une manière que les concepteurs n’avaient pas prévue. Ces bugs exigent que l’auditeur comprenne en profondeur ce que le protocole est censé faire, puis vérifie que le code le fait réellement. C’est plus difficile qu’il n’y paraît, surtout pour des protocoles complexes comportant plusieurs contrats en interaction.
Les risques de composabilité sont particulièrement difficiles à auditer. Un contrat peut se comporter parfaitement de manière isolée, mais créer des vulnérabilités lorsqu’il interagit avec d’autres protocoles. Les attaques par flash loan exploitent souvent ces schémas d’interaction. Le contrat audité peut ne comporter aucun bug. Le problème réside dans la façon dont il réagit à des entrées inattendues provenant d’autres contrats qui n’existaient pas au moment de l’audit.
Les attaques économiques représentent une autre catégorie que les audits traditionnels gèrent mal. La manipulation d’oracles, les attaques de gouvernance et les déséquilibres de pools de liquidité ne sont souvent pas des bugs de code. Ce sont des problèmes d’incitations économiques qui nécessitent une analyse de théorie des jeux plutôt qu’une revue de code. Certains cabinets d’audit ont commencé à ajouter une analyse économique à leurs services, mais cette pratique reste moins mature que l’audit de code traditionnel.
Le rapport d’audit lui-même mérite attention. La plupart des cabinets classent leurs conclusions par sévérité : critique, élevée, moyenne, faible et informative. Un audit propre ne signifie pas qu’il n’y a aucune conclusion. Il signifie que toutes les conclusions critiques et à sévérité élevée ont été traitées. Les conclusions faibles et informatives sont souvent reconnues mais non corrigées, ce qui est généralement raisonnable, mais qu’il est utile de comprendre en tant qu’utilisateur.
Plusieurs audits réalisés par différents cabinets offrent une meilleure couverture qu’un audit unique, aussi réputé soit-il. Différents cabinets utilisent des méthodologies différentes et disposent de domaines d’expertise distincts. Trail of Bits pourrait détecter quelque chose que OpenZeppelin aurait manqué, et inversement. Les protocoles les plus soucieux de la sécurité réalisent 2 à 3 audits et maintiennent en plus des programmes de bug bounty permanents.
Les programmes de bug bounty constituent un complément continu aux audits ponctuels. Immunefi héberge des primes pour des centaines de protocoles, avec des récompenses allant de quelques milliers à plusieurs millions de dollars. La logique économique est simple : payer 500 000 $ à un hacker white hat pour trouver un bug coûte beaucoup moins cher que de perdre 50 millions de dollars à cause d’un exploit. Les protocoles qui combinent audits et bug bounties généreux ont tendance à présenter les meilleurs historiques de sécurité.
Pour les utilisateurs, l’enseignement pratique est qu’un audit est nécessaire mais pas suffisant. Il réduit considérablement la probabilité de certains types d’exploits, mais n’élimine pas le risque. La présence d’un audit doit accroître votre confiance, mais ne doit pas être le seul facteur de votre évaluation du risque. Le temps passé en production sans incident, la taille et l’activité du programme de bug bounty, ainsi que les antécédents de l’équipe du protocole comptent tout autant.