Audit de smart contract

Un document de cadrage fige un dépôt, une branche et un hash de commit, et liste les contrats, bibliothèques et scripts de déploiement inclus. La liste des éléments hors périmètre compte autant: frontends, indexeurs, keepers off-chain, procédure d'exploitation du multisig de gouvernance et tout protocole auquel les contrats s'intègrent restent normalement en dehors, et leur absence explique pourquoi un protocole audité peut encore perdre des fonds par un composant que personne n'a examiné.

La stabilité du code pendant la mission en est la condition pratique. La description du processus par Sherlock situe le bon moment pour un audit après que la conception s'est stabilisée et que les contrats sont testés, l'équipe pouvant maintenir une version stable pendant toute la durée. Un périmètre qui bouge en cours de revue allonge le calendrier et laisse des parties examinées selon des hypothèses qui ne tiennent plus. Des contrats simples prennent une à deux semaines; un protocole complexe avec des intégrations externes en prend trois à six, plus la vérification des correctifs ensuite.

Une revue compétente passe deux fois sur le même code. La première passe établit ce que le code est censé faire: le comportement voulu, les hypothèses du développeur et les invariants qui doivent toujours tenir; la seconde passe attaque ces hypothèses. Dedaub décrit cette division comme une analyse de l'usage légitime suivie d'une analyse adverse, et l'ordre compte, car on ne peut pas contourner une hypothèse qu'on n'a pas écrite.

Quatre techniques portent le travail, et chacune trouve une autre classe de défauts. L'analyse statique applique des algorithmes de motifs au code et détecte les formes connues: un modificateur d'accès manquant, une valeur de retour non vérifiée, un motif arithmétique qui dérive. Le fuzzing génère de grands volumes d'entrées et pousse le contrat dans des états qu'un test écrit à la main n'atteint jamais, et le fuzzing avec état sur de longues séquences d'appels trouve les bugs qui n'apparaissent que dans un ordre particulier. La vérification formelle prouve mathématiquement un petit nombre d'invariants critiques, ce qui coûte cher et se réserve donc aux garanties dont l'échec serait total. La revue manuelle par des experts trouve ce qu'aucune des trois ne trouve: une erreur de logique métier, où le code fait exactement ce qu'il dit et où ce qu'il dit est faux.

Les techniques ne se remplacent pas entre elles, et la lacune laissée par chacune est prévisible. L'analyse statique s'arrête à tout ce qui exige de comprendre l'intention. Le fuzzing ne trouve que la violation d'une propriété que quelqu'un a énoncée, si bien qu'un invariant non énoncé n'est jamais testé. La vérification formelle prouve la propriété spécifiée sur le modèle construit, et une spécification fausse se vérifie sans erreur.

Un rapport sur lequel on peut s'appuyer nomme quatre éléments. Le périmètre: dépôt, hash de commit et les limites, y compris ce qui a été exclu. La méthode: quelles techniques ont été appliquées, quels outils, combien de relecteurs. Les constats: chacun avec une gravité, une explication de l'impact en termes de ce qu'obtient un attaquant, et un chemin assez reproductible pour qu'un développeur puisse le confirmer. Et la mesure corrective de chaque constat, assez précise pour qu'on puisse agir.

Vient ensuite la vérification des correctifs, la partie que les cabinets sautent sous la pression des délais. Les auditeurs retestent les correctifs au lieu d'accepter l'affirmation qu'ils fonctionnent, et confirment que le code finalement déployé correspond au code examiné. Un rapport sans cette section documente un ensemble de problèmes et non une résolution. Lorsqu'un constat a été accepté comme risque au lieu d'être corrigé, la justification a sa place dans le document, car le lecteur suivant doit savoir que la décision était délibérée.

L'échelle habituelle est critique, élevée, moyenne, faible et informative, et le libellé informe moins qu'il n'y paraît. Les cabinets placent les limites différemment: l'un classe selon l'argent en jeu, un autre selon la probabilité que le chemin soit atteignable, un troisième selon une matrice des deux. Un constat qu'un cabinet qualifie d'élevé apparaît comme moyen dans le rapport d'un autre cabinet sur le même code.

Cela rend les nombres de constats inutiles pour comparer des rapports. Deux audits du même protocole par des cabinets différents produisent des totaux différents parce qu'ils ont compté différemment, et non parce que l'un a trouvé davantage. Le signal utilisable est le contenu: ce que chaque constat coûterait s'il était exploité, si le chemin est atteignable par un appelant sans privilèges et ce que l'équipe a fait à ce sujet. Un rapport avec trois constats qui expliquent chacun l'impact concrètement vous en dit plus qu'un rapport avec trente notes informatives.

L'OWASP Smart Contract Top 10 recense ce qui cause réellement des pertes, et ses premières entrées ont peu changé depuis des années. Les défaillances du contrôle d'accès viennent en premier: une fonction privilégiée accessible à un appelant qui ne devrait pas y accéder, en général un modificateur manquant ou une initialisation qui peut être exécutée deux fois. La réentrance suit, quand un appel externe permet à l'appelé de rentrer à nouveau avant que la première exécution ait terminé ses mises à jour d'état.

La manipulation des oracles de prix arrive en troisième position, et c'est là que la limite de l'audit pèse le plus, car le contrat peut être correct et l'entrée fausse. Un contrat qui lit un prix spot dans un seul pool peut être attaqué en faisant bouger ce pool, et aucune revue du contrat ne corrige une conception qui fait confiance à une source manipulable. Viennent ensuite les erreurs de logique dans les flux d'argent, où le code compile et produit un mauvais résultat sous une condition précise, et les appels externes non vérifiés, où une valeur de retour que personne n'a inspectée signifie un échec que le contrat traite comme un succès.

L’arrondi est le cas discret. Une division qui tronque en faveur du protocole ne pose pas de problème; la même troncature en faveur de l'utilisateur, répétée, vide un pool un wei à la fois. Finance Loop traite du volet forensique avec la forensique blockchain et de la pratique de développement avec le développement logiciel blockchain.

Il y a quatre raisons, et toutes les quatre se trouvent hors du rapport. Le code déployé diffère du code examiné, par une modification tardive ou un build différent. Les paramètres de déploiement diffèrent, si bien qu'un contrat examiné est initialisé avec une configuration que personne n'a modélisée. Une dépendance arrive après coup: un nouvel oracle, un nouveau token avec des frais de transfert, un bridge. Ou bien le contrat est mis à niveau, et la nouvelle implémentation n'a jamais été examinée.

Le cas de la composabilité mérite une mention à part, car il met en échec des équipes soigneuses. Deux protocoles, chacun correctement audité isolément, peuvent produire une interaction exploitable quand l'un lit une valeur que l'autre peut déplacer dans la même transaction; le périmètre de personne ne couvrait la paire. C'est l'argument en faveur d'une surveillance en temps réel et d'un bug bounty sur le code en production, qui ne remplace pas un audit et n'est pas remplacé par lui: un audit regarde un instantané, un bounty paie des attaquants pour regarder ce qui tourne.

Trois modèles répondent à des questions différentes. Un audit privé place un petit nombre de relecteurs seniors sur le code pendant une période fixe, ce qui produit de la profondeur, une contrepartie nommée et un rapport qu'un régulateur ou un investisseur peut lire. Un concours d'audit ouvre le code en parallèle à un grand nombre de chercheurs, ce qui produit de l'étendue: cent personnes qui regardent trouvent vite les problèmes superficiels et parfois le problème profond que l'angle mort d'une petite équipe cachait. Un bug bounty tourne en continu sur le code déployé et paie par constat valide.

Ce dont un émetteur réglementé a besoin, c'est l'audit privé, car le livrable doit nommer qui a examiné quoi et s'engager sur son contenu. Un protocole avec une valeur substantielle en jeu finit généralement avec les trois à la suite: la revue privée avant le lancement, un concours pour l'étendue et le bounty permanent ensuite.

Lorsqu'un smart contract porte un titre financier, l'audit cesse d'être un choix du développeur. Le registre d'un titre tokenisé doit avoir un effet juridique, si bien que l'émetteur doit prouver qui peut déplacer une position, qui peut en geler ou en récupérer une, et sous quelle autorité une mise à niveau change cette réponse. L'audit est le document qui montre que les rôles privilégiés ont été identifiés et le chemin de mise à niveau examiné, et Finance Loop traite de l'instrument avec les titres tokenisés.

Ailleurs, des autorités de surveillance ont mis l'exigence par écrit. La VARA de Dubaï et la SFC de Hong Kong fixent toutes deux des attentes pour le smart contract qui sous-tend une activité réglementée, et les exigences du projet de Data Act de l'UE pour les smart contracts dans les accords de partage de données ont fait l'objet d'un débat public avant d'être restreintes. La direction est la même dans chaque cas: un contrat qui exerce une fonction réglementée a besoin d'un chemin de résiliation ou d'interruption examiné, afin que quelque chose puisse être arrêté. Finance Loop traite du volet résilience opérationnelle avec la cybersécurité dans la finance en Allemagne.

Un audit de smart contract est une revue de sécurité structurée du code qui contrôlera les fonds des utilisateurs et la logique du protocole sur une blockchain, réalisée sur une version figée de ce code et livrée sous forme de rapport de constats avec gravités et corrections. Un audit de smart contract est une revue et non une certification: les auditeurs indiquent ce qu'ils ont examiné et ce qu'ils ont trouvé, et la responsabilité du système déployé reste à l'équipe qui le déploie.

Une à deux semaines pour un contrat simple, trois à six pour un protocole complexe avec des intégrations externes, plus une vérification des correctifs une fois que l'équipe a corrigé. Le facteur qui allonge le plus un calendrier n'est pas la taille du code mais son instabilité: un périmètre qui bouge sans cesse oblige à refaire des parties de la revue. Une équipe qui gèle la branche avant la mission obtient le calendrier qu'on lui a annoncé.

Tout ce qui est hors du document de périmètre, ce qui signifie en général le frontend, les services off-chain, la gestion des clés des comptes privilégiés, le processus de gouvernance et tout protocole auquel les contrats s'intègrent. Un audit ne couvre pas non plus l'avenir: une mise à niveau ultérieure, une nouvelle dépendance ou un paramètre modifié est du code non examiné, quoi qu'ait dit le rapport précédent. Il ne couvre pas non plus la conception économique, sauf si la mission l'incluait expressément, si bien qu'un mécanisme exploitable alors que chaque ligne se comporte comme écrit passe un audit.

Un analyseur statique sur le code source et le bytecode pour les formes de défauts connues, un fuzzer basé sur les propriétés comme Echidna ou Medusa, où l'équipe énonce des invariants que le fuzzer tente ensuite de casser avec des entrées aléatoires et de longues séquences d'appels, un outil de vérification formelle pour la poignée d'invariants qui valent d'être prouvés, et un framework de test et de simulation pour reproduire un constat sur un fork de la chaîne en production. Les outils produisent des candidats; les relecteurs décident lesquels sont réels, et c'est pourquoi un rapport composé de sorties d'outils n'est pas un audit.

Aucune loi générale ne l'exige, et en pratique ce sont les contreparties qui l'exigent. Une plateforme de cotation, un dépositaire, un assureur et un investisseur institutionnel demandent chacun le rapport avant de prendre l'exposition, et un émetteur réglementé d'un titre tokenisé en a besoin pour sa propre documentation de l'intégrité du registre. L'exigence arrive par la voie commerciale avant d'arriver par la voie légale.