Ce qu’un audit de smart contract vous dit, et ce qu’il ne dit pas

“Audité” apparaît sur les pages de destination comme s’il s’agissait d’une certification au sens défini. Ce n’est pas le cas. C’est une prestation professionnelle au périmètre variable, et la différence entre un examen approfondi et un examen sommaire est invisible depuis le badge.

Ce qu’est réellement un audit

Une entreprise est mandatée pour examiner un ensemble défini de contrats, à un commit défini, sur une période définie, en recherchant des défauts au regard d’un modèle de menace défini. Elle produit un rapport listant les constats par gravité, le projet y répond, et un rapport final consigne généralement ce qui a été corrigé.

Chaque occurrence de “défini” ici a son importance. Le périmètre est négocié, et un rapport portant sur trois contrats ne dit rien du quatrième, celui qui détient les fonds.

Lisez d’abord la section sur le périmètre

Le périmètre indique quels fichiers ont été examinés et à quel hash de commit. Deux questions en découlent, et les deux trouvent réponse en quelques minutes.

Le périmètre inclut-il les contrats qui détiennent ou déplacent réellement de la valeur, ou seulement des contrats périphériques ? Et le commit examiné correspond-il à ce qui est déployé ? Le code évolue après un audit, et un rapport portant sur un commit antérieur à plusieurs mises à jour décrit un logiciel qui n’existe plus. Vérifier le bytecode déployé par rapport au code source audité est la vérification qui referme cet écart, et elle est rarement effectuée par quiconque se contente de lire le badge.

Les constats et leur résolution

Les rapports classent les constats par gravité. Ce qui compte davantage que le nombre, c’est la résolution : corrigé, reconnu, ou contesté.

“Reconnu” signifie que le projet a pris connaissance du constat et a choisi de ne rien changer. Cela peut être parfaitement raisonnable — le constat peut décrire un compromis accepté — mais cela signifie qu’un problème connu est actif en production, et il n’apparaîtra pas dans un résumé qui se contente de mentionner le badge.

Un rapport ne relevant aucun constat n’est pas un triomphe. Cela signifie généralement un périmètre étroit ou un examen superficiel. Des examens compétents de systèmes non triviaux trouvent des choses.

Ce que les audits font structurellement mal

Certaines catégories de problèmes sont difficiles à détecter par la seule relecture du code :

• Les défauts de conception économique. Un code qui se comporte exactement comme écrit, mais dont les incitations créées sont exploitables. Cela nécessite de modéliser l’économie du système, ce qui relève d’une autre discipline et sort fréquemment du périmètre.
• La composabilité. Un contrat peut être sain isolément et dangereux une fois combiné à un autre protocole que personne n’avait anticipé.
• Les hypothèses sur les oracles. Les contrats qui s’appuient sur des données de prix externes héritent de la fiabilité de ces données, et l’oracle est généralement hors périmètre.
• La gouvernance et les clés. Un contrat évolutif contrôlé par un petit multisig comporte un risque qu’aucune relecture de code ne traite, car le code autorise la mise à jour par conception.

Ce dernier point mérite d’être souligné. Si un contrat peut être mis à jour, l’audit décrit l’implémentation actuelle, et les détenteurs des clés de mise à jour peuvent la remplacer. Ce qui compte alors, c’est qui sont ces détenteurs et quel processus les encadre — une question de gouvernance déguisée en badge technique.

À quoi ressemble un bon rapport

Publié dans son intégralité plutôt que résumé. Un périmètre indiqué avec les hash de commit. Des constats assortis de leur gravité, description et résolution. Une section méthodologie décrivant ce qui a été examiné et ce qui ne l’a pas été. Et une date, pour pouvoir le comparer à l’historique des déploiements.

Un projet qui publie tout cela fait quelque chose de sensiblement différent d’un projet qui affiche simplement un logo. Le logo est la partie qui coûte le moins cher.

Comment s’en servir

Considérez un audit comme la preuve qu’un projet a dépensé de l’argent pour se faire examiner et a accepté d’en publier le résultat, ce qui est un signal réel sur sa façon de fonctionner. Ne le considérez pas comme une garantie de sécurité, car le rapport ne prétend pas en être une — l’avertissement qu’il contient le dit généralement explicitement, dans la section que personne ne cite.

Les questions pratiques demeurent : quelle proportion de vos avoirs est exposée à ce contrat, pourriez-vous tolérer de la perdre, et le rendement proposé constitue-t-il une compensation plausible pour ce risque ? Ces questions ne changent en rien avec la présence d’un rapport, ce qui explique précisément pourquoi le badge est utilisé de cette façon.

Tous les examens n’ont pas la même profondeur

“Audit” recouvre un éventail d’activités au coût et à la rigueur très différents, et le rapport ne rend pas toujours cette distinction évidente.

Un examen manuel par des ingénieurs expérimentés qui lisent le code est l’option la plus onéreuse. L’analyse automatisée détecte à moindre coût des schémas connus mais rate tout ce qui est inédit. La vérification formelle prouve mathématiquement qu’un code satisfait une spécification, ce qui est puissant mais ne vaut que ce que vaut la spécification. Les plateformes d’audit compétitives externalisent l’examen à la foule, ce qui trouve un large éventail de problèmes mais produit une couverture moins homogène.

Chacune a son rôle. Ce qui compte, c’est de savoir laquelle on a sous les yeux, et la section méthodologie le précise. Un rapport qui ne décrit pas sa méthode demande à être pris au sérieux sur la seule foi du logo.

Les bug bounties disent ce qu’un rapport ne peut pas dire

Un audit est un instantané ; un bug bounty est continu. Un projet qui fait tourner un bounty substantiel et bien délimité, avec un historique de paiements public, est exposé à un examen permanent d’une façon qu’un examen ponctuel ne peut offrir.

Le montant compte. Un plafond de paiement très inférieur à ce que rapporterait une exploitation n’est pas une incitation, c’est un geste symbolique — un chercheur qui trouve une faille critique dans un contrat détenant une somme importante se heurte à un problème arithmétique évident si le bounty est dérisoire en comparaison. Des bounties proportionnés à la valeur en jeu constituent un signal réel du sérieux avec lequel un projet envisage la possibilité de s’être trompé.

Le temps passé en production est aussi une preuve

Les contrats qui ont détenu une valeur importante pendant une longue période sans incident ont été soumis à l’examen le plus rigoureux qui soit : l’attention soutenue de personnes financièrement motivées à les casser.

Ce n’est pas une preuve — des failles dormantes existent, et plusieurs protocoles de longue date ont fini par échouer tardivement. Mais un contrat récemment déployé, muni d’un rapport et sans historique d’exploitation, n’a été examiné que par une seule entreprise pendant quelques semaines. Un contrat plus ancien avec le même rapport a en plus survécu à des années d’intérêt hostile, et c’est là une qualité de preuve différente.

Combiner les deux est l’approche pratique : lire le rapport pour savoir ce qui a été examiné, et évaluer l’historique de déploiement pour ce que le rapport n’a pas pu couvrir.