samczsun : La sécurité des protocoles cryptographiques dépend principalement d'un ré-audit proactif

Les programmes de bug bounty sont des mesures passives, tandis que la protection de la sécurité nécessite une approche proactive.

Auteur : samczsun, fondateur de Security Alliance, ancien partenaire de recherche chez Paradigm

De nos jours, l'industrie est parvenue à un consensus : la protection de la sécurité des cryptomonnaies doit suivre trois étapes clés : rédiger des cas de test lors de la phase de développement pour détecter les erreurs de base ; effectuer un audit complet et organiser des compétitions avant le déploiement ; mettre en place un programme de bug bounty pour récompenser les chercheurs qui divulguent de manière responsable les vulnérabilités afin de prévenir les attaques. La généralisation de ces meilleures pratiques a considérablement réduit le nombre de failles on-chain, forçant les attaquants à cibler des vulnérabilités off-chain telles que le vol de clés privées ou l'intrusion dans les infrastructures.

Cependant, même les protocoles ayant subi des audits approfondis et offrant des bug bounties généreux subissent encore occasionnellement des attaques de hackers. De tels incidents affectent non seulement le protocole concerné, mais ébranlent également la confiance de l'ensemble de l'écosystème. Les récentes attaques contre Yearn, Balancer V2, ainsi que les incidents de sécurité d'Abracadabra et 1inch en début d'année, montrent que même les protocoles les plus éprouvés ne sont pas absolument sûrs. L'industrie crypto aurait-elle pu éviter ces attaques ? Ou bien cela fait-il simplement partie du prix à payer pour la finance décentralisée ?

Les commentateurs avancent souvent que l'augmentation des bug bounties aurait pu protéger ces protocoles. Mais même en mettant de côté la réalité économique, les bug bounties sont fondamentalement des mesures de sécurité passives, confiant le destin du protocole aux hackers white hat, tandis que l'audit est une action proactive de protection de la part du protocole. Augmenter les bug bounties ne peut pas empêcher les attaques de hackers, car cela revient à doubler la mise en pariant que les white hats découvriront les failles avant les black hats. Si un protocole souhaite réellement se protéger, il doit entreprendre de nouveaux audits de manière proactive.

Fonds de trésorerie et valeur totale verrouillée (TVL)

Parfois, les hackers acceptent de restituer la majeure partie des fonds volés, ne conservant qu'une petite partie (généralement 10 %) en guise de récompense. Malheureusement, l'industrie appelle cette récompense une « white hat bounty », ce qui soulève la question suivante : pourquoi le protocole ne propose-t-il pas directement un montant équivalent via un programme de bug bounty, évitant ainsi les négociations ? Mais cette idée confond les fonds que l'attaquant peut voler avec ceux que le protocole peut effectivement utiliser.

Bien qu'en apparence, le protocole semble pouvoir utiliser ces deux types de fonds pour la sécurité, il n'a légalement le droit de disposer que de ses propres fonds de trésorerie, et non des fonds déposés par les utilisateurs. Il est également très improbable que les utilisateurs accordent à l'avance ce type d'autorisation au protocole ; ce n'est qu'en cas de crise (par exemple, lorsque les déposants doivent choisir entre perdre 10 % ou 100 % de leurs dépôts) qu'ils permettront au protocole d'utiliser les dépôts pour négocier. En d'autres termes, le risque augmente avec la TVL, mais le budget de sécurité ne peut pas croître en conséquence.

Efficacité du capital

Même si un protocole dispose de fonds suffisants (par exemple, une grande trésorerie, une forte rentabilité ou une politique de frais de sécurité déjà en place), il reste difficile de répartir efficacement ces fonds pour la sécurité. Comparé à l'investissement dans de nouveaux audits, augmenter les bug bounties est, au mieux, très inefficace en termes de capital, et au pire, cela crée un désalignement des incitations entre le protocole et les chercheurs.

Si le montant du bug bounty est lié à la TVL, alors lorsque les chercheurs soupçonnent que la TVL du protocole va augmenter et que la probabilité d'apparition de failles similaires est faible, ils sont clairement plus motivés à dissimuler une faille critique. Cela finit par opposer directement les chercheurs au protocole, au détriment des utilisateurs. Augmenter simplement la récompense pour les failles critiques n'est pas non plus efficace : la communauté des chercheurs indépendants est vaste, mais très peu consacrent la majeure partie de leur temps aux bug bounties et possèdent les compétences nécessaires pour découvrir des failles dans des protocoles complexes. Ces chercheurs d'élite concentrent leur temps sur les programmes de bug bounty offrant le meilleur retour sur investissement. Pour les protocoles importants et éprouvés, qui sont supposés être constamment sous la surveillance de hackers et d'autres chercheurs, la probabilité de découvrir une faille est jugée extrêmement faible ; ainsi, peu importe le montant de la récompense, cela ne suffit pas à attirer leur attention.

Parallèlement, du point de vue du protocole, le bug bounty est un fonds réservé au paiement d'une seule faille critique. À moins que le protocole ne veuille parier qu'aucune faille critique n'apparaîtra jamais, tout en cachant sa situation de liquidité aux chercheurs, ce fonds ne peut pas être utilisé à d'autres fins. Plutôt que d'attendre passivement qu'un chercheur découvre une faille critique, il vaut mieux utiliser le même montant pour organiser plusieurs audits sur plusieurs années. Chaque réexamen garantit l'attention des meilleurs chercheurs, sans se limiter artificiellement à la découverte d'une seule faille, tout en alignant les intérêts des chercheurs et du protocole : si le protocole est exploité, les deux parties subissent un préjudice de réputation.

Précédents existants

Dans les secteurs du logiciel et de la finance, les audits annuels sont une pratique éprouvée et mature, et constituent le meilleur moyen d'évaluer si une entreprise peut faire face à un environnement de menaces en constante évolution. Le rapport SOC 2 Type II est utilisé par les clients B2B pour évaluer si un fournisseur maintient des contrôles de sécurité appropriés ; la certification PCI DSS indique qu'une entreprise a pris des mesures adéquates pour protéger les informations de paiement sensibles ; le gouvernement américain exige que les parties ayant accès à des informations gouvernementales obtiennent la certification FedRAMP afin de maintenir des normes de sécurité élevées.

Bien que les smart contracts soient eux-mêmes immuables, leur environnement d'exécution ne l'est pas. Les paramètres de configuration peuvent changer au fil du temps, les dépendances peuvent être mises à jour, et des modèles de code auparavant considérés comme sûrs peuvent en réalité présenter des risques. Un audit de protocole évalue la sécurité à un instant donné, mais ne garantit pas la sécurité future du protocole. La seule façon de mettre à jour cette évaluation est de procéder à un nouvel audit.

En 2026, l'industrie crypto devrait faire de l'audit annuel la quatrième étape de la protection de la sécurité des protocoles. Les protocoles existants avec une TVL importante devraient organiser de nouveaux audits de leurs déploiements ; les sociétés d'audit devraient proposer des services spécialisés dans l'évaluation globale des déploiements ; l'ensemble de l'écosystème devrait collectivement changer sa perception des rapports d'audit : ils ne sont qu'une évaluation de la sécurité à un moment donné, susceptibles de devenir obsolètes, et non une garantie de sécurité permanente.