Sécurité Web3Élevé

Comment lire un rapport d’audit de sécurité crypto

Avant le badge, lisez le périmètre, le hash du commit, les contrats déployés, les niveaux de gravité, les constats non résolus et les limites des tests.

Méthode pour lire et évaluer un rapport d’audit de sécurité crypto

Avant de regarder le badge d’audit, lisez le périmètre, le hash du commit, les adresses déployées, la définition des niveaux de gravité, les constats non résolus et les limites des tests. Un audit n’est utile que s’il couvre le code et la configuration que vous allez réellement utiliser.

Comprendre les éléments en jeu#

Un rapport est une revue réalisée à un moment donné. Il peut exclure le front-end, les oracles, les ponts, les opérations administrateur et les hypothèses économiques qui dominent pourtant le risque réel.

Le cadre de décision#

Créez une cartographie d’une page couvrant les défauts de code, les rôles privilégiés, les dépendances externes, l’évolutivité et la réponse aux incidents. Le rapport alimente cette carte, mais ne la remplace pas.

Procéder dans un ordre contrôlé#

  1. Faites correspondre le commit du dépôt et les adresses de contrats. Vérifiez le réseau, le proxy éventuel et l’implémentation réellement déployée au lieu de vous fier au nom du projet.
  1. Identifiez les composants et chaînes exclus du périmètre. Relevez les oracles, bibliothèques, interfaces, bridges, scripts de déploiement et paramètres non examinés.
  1. Lisez chaque constat critique ou élevé ainsi que son état de correction. Comprenez l’impact, les conditions d’exploitation et la réponse exacte de l’équipe.
  1. Confirmez que les corrections ont été retestées, pas seulement reconnues. Une réponse « corrigé » du projet ne prouve pas que l’auditeur a examiné le nouveau code ni que celui-ci est déployé.
  1. Examinez les remarques sur la centralisation, les mises à niveau et la gestion des clés. Les constats classés informatifs peuvent révéler un pouvoir de gel, de création ou de modification déterminant.

Les pièges courants#

  • Compter les audits au lieu de lire leur périmètre. Plusieurs rapports peuvent couvrir les mêmes anciens composants et manquer la version actuelle.
  • Prendre la mention « résolu » pour la preuve que le correctif déployé correspond. Comparez le commit retesté avec le bytecode ou l’adresse utilisés aujourd’hui.
  • Ignorer les constats informatifs révélant des pouvoirs administrateur. Leur gravité technique faible n’enlève pas leur importance dans le modèle de confiance.
  • Supposer qu’une absence de constat signifie une absence de vulnérabilité. Les tests sont limités par le temps, le périmètre, les méthodes et les informations disponibles.

Un résultat fiable n’est pas simplement un rapport terminé ou un badge publié. Il doit pouvoir être relié indépendamment au code et au déploiement que vous utilisez.

Confirmer le résultat#

Ne jugez pas l’audit au seul message du projet. Conservez des éléments vérifiables après la fermeture de la page et notez les incertitudes restantes.

Point de contrôlePreuve à obtenirCondition d’arrêt
Faire correspondre commit et adresses de contratsCommit, réseau, adresses et version rapprochés de la documentation officielleNombre d’audits utilisé à la place de leur périmètre
Identifier les composants et chaînes exclusListe datée des exclusions et dépendances« Résolu » accepté sans vérifier le correctif déployé
Lire les constats critiques et élevés ainsi que leur correctionStatut défini par l’auditeur et preuve de retestConstat informatif sur un pouvoir administrateur ignoré

Conservez les adresses, hashes de commit, versions de rapport et captures datées utiles pour documenter l’évaluation, mais excluez les phrases de récupération, clés privées et codes d’authentification.

Questions fréquentes#

Que signifie « acknowledged » dans un rapport ?

Cela signifie généralement que l’équipe reconnaît le risque sans le modifier. Lisez la définition exacte des statuts donnée par l’auditeur, car les termes peuvent varier.

Un programme de bug bounty est-il préférable à un audit ?

Ils sont complémentaires : l’audit est une revue ciblée et datée, tandis que le bug bounty encourage des recherches externes continues sur les versions admissibles.

À partir de quand un audit est-il trop ancien ?

L’âge compte moins que les changements intervenus après le commit examiné. Une modification du code, de la configuration ou des dépendances peut rendre un rapport récent partiellement obsolète.

Guides associés#

Sources#

Avertissement sur les risques : les opérations en cryptomonnaies peuvent être irréversibles. Ne communiquez jamais votre phrase de récupération, votre clé privée, votre mot de passe ou un code d’authentification, et vérifiez indépendamment chaque domaine et chaque demande affichée par votre portefeuille.

Règles éditoriales

Ce guide est éducatif et fondé sur des sources. Les mesures de sécurité, règles des plateformes et exigences légales peuvent évoluer ; vérifiez les étapes importantes auprès des sources officielles.