Audits de smart contracts : ce qu’ils détectent, ce qui leur échappe

Un audit de smart contract est souvent traité comme un gage de sécurité : audité signifierait sûr, non audité signifierait risqué. La réalité est plus étroite, et plus utile une fois qu’on la comprend. Un audit est un examen structuré qui détecte des catégories précises et connues d’erreurs — ce n’est pas une garantie, et des protocoles audités ont tout de même perdu des fonds d’utilisateurs à cause d’exploits. Cet article explique ce que fait réellement un audit, et où se situent ses limites.

Ce qu’un audit vérifie réellement

Un audit de smart contract est un examen manuel et automatisé du code d’un contrat, généralement réalisé avant son déploiement, à la recherche de schémas de vulnérabilité connus : bugs de réentrance, dépassements et sous-dépassements d’entiers (integer overflow/underflow), erreurs de contrôle d’accès permettant à une mauvaise adresse d’appeler une fonction privilégiée, et erreurs de logique qui s’écartent de l’intention déclarée du contrat. Les auditeurs comparent également le contrat à la documentation propre du projet, à la recherche d’endroits où le code fait autre chose que ce qu’il prétend faire.

Comme les smart contracts s’exécutent exactement tels qu’ils sont écrits et sont difficiles à modifier une fois déployés, cette catégorie de bug a des conséquences inhabituellement lourdes — une faille qu’une application classique pourrait corriger discrètement peut, sur un contrat en production détenant une valeur réelle, être exploitée dès l’instant où elle est découverte. C’est la raison fondamentale pour laquelle les audits existent en tant que pratique distincte plutôt que d’être intégrés à la revue de code ordinaire.

Ce que les audits détectent de façon fiable

Les classes de vulnérabilités établies et bien comprises sont là où les audits font leurs preuves. La réentrance — lorsqu’un contrat malveillant rappelle le contrat audité avant que son premier appel ne se termine, vidant des fonds via des retraits répétés — est un cas d’école que les auditeurs expérimentés vérifient systématiquement, précisément parce qu’elle a causé certains des exploits les plus anciens et les plus coûteux du secteur. Les failles de contrôle d’accès, les appels externes non vérifiés et les problèmes d’aléa prévisible relèvent de la même catégorie : des modes de défaillance connus, avec des méthodes de détection connues.

Pour ces catégories, un audit compétent réduit sensiblement le risque. Un contrat passé en revue par un cabinet reconnu a, de manière mesurable, moins de chances d’échouer face à un schéma d’attaque connu qu’un contrat qui ne l’a pas été.

Ce qui échappe aux audits

Les audits sont beaucoup moins fiables face aux exploits inédits, aux interactions complexes entre plusieurs contrats, et aux défauts de conception économique qui n’ont rien à voir avec une erreur de codage. Un contrat peut être implémenté exactement conformément à ses spécifications et rester néanmoins exploitable parce que la spécification elle-même comporte un défaut — un oracle de prix manipulable, une structure d’incitations qui récompense un comportement que ses concepteurs n’avaient pas anticipé, ou un mécanisme de gouvernance qu’un attaquant disposant de moyens suffisants peut capturer temporairement. Rien de tout cela ne constitue un bug au sens traditionnel, et aucune revue de code, aussi poussée soit-elle, ne détecte un défaut de conception que l’auditeur ne recherche pas spécifiquement.

Les audits ne sont en outre qu’un instantané. Un contrat peut être audité, puis modifié par la suite sans nouvel examen, ou combiné à d’autres contrats de manières que l’audit initial n’a jamais envisagées. La caractéristique centrale de la DeFi — la composabilité sans permission, où n’importe quel contrat peut en appeler un autre — est aussi la raison pour laquelle l’audit d’un contrat isolé ne peut garantir sa sécurité dès lors qu’il commence à interagir avec des contrats que personne n’a examinés conjointement.

Ce que cela signifie en pratique

Il convient de considérer un audit comme une réduction significative du risque face à des catégories connues de bugs, et non comme une preuve de sécurité. Un rapport d’audit publié mérite d’être lu, pas seulement cité : il faut vérifier quel périmètre il a réellement couvert, si les constats ont été corrigés ou simplement pris acte, et depuis combien de temps il a été réalisé par rapport au code actuel, potentiellement modifié. Un audit réduit le risque ; il ne l’élimine pas, et aucun projet légitime ne devrait laisser entendre le contraire.