« Audité » est le mot le plus sur-interprété de ce secteur. On le traite comme une propriété binaire d’un projet, alors qu’il s’agit en réalité d’une affirmation portant sur un ensemble précis de fichiers, à un moment précis, formulée par une société précise, dans un périmètre convenu à l’avance par les deux parties.
Lire le rapport plutôt que le badge prend une dizaine de minutes et change ce que vous savez.
Commencez par le périmètre, pas par les conclusions
Tout rapport crédible comporte une section sur le périmètre, généralement dans les deux premières pages. Elle nomme le dépôt, l’empreinte du commit examiné et la liste des fichiers de contrat inclus dans le périmètre. C’est la partie la plus utile du document.
L’empreinte du commit compte parce qu’elle date l’examen avec précision. Tout code écrit après ce commit — y compris la correction des conclusions du rapport lui-même — ne faisait pas partie de ce qui a été examiné. Un projet audité en mars et qui a livré de nouvelles fonctionnalités en juin déploie ensemble du code audité et du code non audité, et seul le rapport vous dit lequel est lequel.
Lisez ce qui a été exclu
Les sections sur le périmètre indiquent aussi ce qui n’a pas été examiné, et cette liste est souvent plus intéressante que les conclusions. Exclusions courantes : l’interface, les scripts de déploiement, l’infrastructure hors chaîne, la configuration des oracles, la gestion des clés d’administration et tout contrat tiers dont le système dépend.
Ces exclusions recoupent presque exactement la manière dont les systèmes défaillent réellement. Une compromission de l’interface se produit dans une couche que les audits de contrats ne couvrent absolument pas, et le contrôle des clés d’administration — qui peut mettre à niveau ou mettre en pause — est fréquemment hors périmètre alors qu’il détermine précisément si des fonds peuvent être dérobés.
Conclusions : gravité, et ce qui s’est passé ensuite
Les conclusions sont généralement classées de « critique » à « informatif ». Deux questions comptent davantage que leur nombre :
- Chaque conclusion a-t-elle été corrigée, prise en compte ou contestée ? Les rapports consignent normalement la réponse du projet. « Pris en compte » signifie que le projet en a pris connaissance et a choisi de ne rien changer — ce qui peut être raisonnable, mais c’est une décision, pas une correction.
- La correction a-t-elle été réexaminée ? Une correction écrite après l’examen et jamais réexaminée constitue du code neuf et non audité dans la partie la plus sensible du système.
Ce qu’un audit ne peut structurellement pas détecter
Les auditeurs examinent le code au regard de l’intention. Lorsque l’intention elle-même est viciée, le code peut être correct et le système perdre tout de même de l’argent — c’est une faille de logique métier, et c’est la classe la plus susceptible de survivre à l’examen, car rien ne paraît anormal ligne à ligne. L’attaque par donation contre Euler Finance est un dossier de cette forme.
Les audits supposent également que le compilateur produit ce que dit le code source. Lorsque cette hypothèse est prise en défaut — une compromission de la chaîne d’outils — le code source examiné et le bytecode déployé divergent, comme dans les dossiers de réentrance Vyper de Curve Finance.
Une courte liste de contrôle
- Existe-t-il seulement un rapport, publié en intégralité — et non un résumé ou un logo ?
- Quel commit a été examiné, et le code déployé y correspond-il ?
- Qu’est-ce qui a été explicitement exclu du périmètre ?
- Les conclusions critiques et élevées ont-elles été corrigées, et les corrections ont-elles été réexaminées ?
- Existe-t-il également un programme de primes aux bogues, qui couvre le code au fil de ses évolutions plutôt qu’un instantané unique ?
Pas un conseil. Conisec publie à titre d'information uniquement. Rien dans cet article ne constitue un conseil financier, juridique, fiscal ou de sécurité. Vérifiez auprès des sources primaires indiquées ci-dessus avant d'agir.
