Guide de sécurité DeFi : comment se défendre efficacement contre les attaques de hackers à l'ère de l'IA ?

Titre original : Comment arrêter de perdre de l’argent face aux hacks DeFi
Auteur original : sysls, openforage
Traduction originale : AididiaoJP, Foresight News

Auteur original :律动BlockBeats

Source originale :

Reproduction : 火星财经

Introduction

Après avoir étudié de nombreux incidents de piratage de protocoles DeFi, j’ai développé une crainte envers les « acteurs étatiques ». Ils sont techniquement compétents, disposent de ressources abondantes, et jouent à un jeu à très long terme ; ces super-vilains se concentrent à scruter chaque recoin de votre protocole et infrastructure pour trouver des vulnérabilités, alors que l’équipe de protocole ordinaire est dispersée sur six ou sept axes d’activité différents.

Je ne me prétends pas expert en sécurité, mais j’ai dirigé des équipes dans des environnements à haut risque (y compris dans l’armée et le secteur financier avec des fonds importants), et j’ai une grande expérience dans la réflexion et la planification de plans d’urgence.

Je crois sincèrement que seul le paranoïaque peut survivre. Aucune équipe ne commence en pensant « je vais adopter une attitude négligente et désinvolte envers la sécurité » ; pourtant, les attaques de hackers se produisent. Nous devons faire mieux.

L’IA signifie que cette fois, c’est vraiment différent

Les attaques de hackers ne sont pas rares, mais leur fréquence augmente nettement. Le premier trimestre 2026 a été le trimestre avec le plus grand nombre d’attaques DeFi enregistrées, et alors que le deuxième trimestre vient à peine de commencer, il semble déjà prêt à battre ce record.

Mon hypothèse centrale est : l’IA réduit considérablement le coût de recherche de vulnérabilités et étend énormément la surface d’attaque. Il faut plusieurs semaines à un humain pour analyser la configuration d’une centaine de protocoles à la recherche d’erreurs ; alors que les modèles de base les plus récents peuvent le faire en quelques heures.

Cela devrait changer radicalement notre façon de penser et de répondre aux attaques. Les protocoles anciens, habitués à des mesures de sécurité avant que l’IA ne devienne puissante, font face à un risque accru d’être « balayés » en un instant.

Penser en surface et en hiérarchie

La surface d’attaque de DeFi peut en réalité être réduite à trois : l’équipe du protocole, les contrats intelligents et l’infrastructure, la frontière de confiance des utilisateurs (DSN, médias sociaux, etc.).

Une fois ces surfaces identifiées, on superpose des couches de défense :

· Prévention : si elle est appliquée strictement, elle minimise la probabilité d’exploitation.

· Atténuation : en cas d’échec de la prévention, elle limite l’ampleur des dégâts.

· Pause : personne ne peut prendre la meilleure décision sous une pression énorme. Dès qu’une attaque est confirmée, on active immédiatement le bouton d’arrêt général. La suspension peut empêcher des pertes supplémentaires et donner du temps pour réfléchir…

· Récupération : si vous perdez le contrôle d’un composant toxique ou compromis, abandonnez-le et remplacez-le.

· Rétablissement : récupérez ce que vous avez perdu. Prévoyez à l’avance des partenaires capables de geler des fonds, d’annuler des transactions et d’aider à l’enquête.

Principes

Ces principes guident la mise en œuvre concrète de chaque couche de défense.

Utilisation intensive de l’IA de pointe

Utilisez massivement des modèles d’IA avancés pour analyser votre code et configuration, rechercher des vulnérabilités, et effectuer des tests de red team à grande échelle : essayez de trouver des failles côté frontend pour voir si elles peuvent atteindre le backend. Les attaquants font cela. Ce que vous pouvez détecter par des scans défensifs, ils l’ont déjà repéré par des scans offensifs.

Utilisez des compétences comme pashov, nemesis, ainsi que des plateformes IA telles que Cantina (Apex) et Zellic (V12), pour analyser rapidement votre code avant un audit complet.

Le temps et la friction sont de bonnes défenses

Ajoutez plusieurs étapes et verrouillages temporels à toute opération susceptible de causer des dommages. Vous avez besoin de suffisamment de temps pour intervenir et geler en cas d’anomalie.

Les raisons pour lesquelles on s’opposait aux verrouillages temporels et aux processus multi-étapes étaient qu’ils créaient de la friction pour l’équipe du protocole. Aujourd’hui, ce n’est plus un problème : l’IA peut facilement passer ces étapes en arrière-plan.

Invariables

Les contrats intelligents peuvent se défendre en écrivant des « faits » immuables : si ces faits sont brisés, toute la logique du protocole s’effondre.

Il n’y a généralement que quelques invariants. Il faut les élever prudemment au niveau du code ; imposer plusieurs invariants dans chaque fonction devient difficile à gérer.

Équilibre des pouvoirs

Beaucoup d’attaques proviennent de portefeuilles compromis. Il faut une configuration permettant, même si une multi-signature est compromise, de limiter rapidement les dégâts et de ramener le protocole à un état gouvernable.

Cela nécessite un équilibre entre gouvernance (qui décide de tout) et sauvetage (capacité à restaurer une stabilité gouvernable, sans pouvoir remplacer ou renverser la gouvernance).

Il y aura toujours des problèmes

Partant du principe : peu importe votre intelligence, vous serez piraté. Vos contrats ou dépendances peuvent échouer. Vous pouvez être victime d’attaques d’ingénierie sociale, ou de nouvelles mises à jour introduisant des vulnérabilités inattendues.

En pensant ainsi, les limiteurs de dégâts et les disjoncteurs du protocole deviennent vos meilleurs alliés. Limitez les dégâts à 5-10 %, puis suspendez, et planifiez votre réponse. Personne ne peut prendre la meilleure décision sous un feu nourri.

Le meilleur moment pour planifier, c’est maintenant

Réfléchissez à votre réponse avant d’être attaqué. Encodez autant que possible vos processus et entraînez votre équipe, pour ne pas être pris au dépourvu lors d’une crise. À l’ère de l’IA, cela signifie maîtriser des compétences et algorithmes capables de présenter rapidement une grande quantité d’informations, puis de les résumer et de les partager en long ou en résumé avec votre cercle central.

Vous n’avez pas besoin de perfection, mais vous devez survivre. Aucun système n’est invulnérable dès le départ ; par itérations successives, vous deviendrez antifragile en tirant des leçons.

L’absence de preuve d’infection ne signifie pas que vous ne serez pas piraté. Le point de confort maximal est souvent le point de danger maximal.

Mesures préventives

Conception de contrats intelligents

Une fois que vous avez identifié des invariants, transformez-les en vérifications à l’exécution. Réfléchissez soigneusement à ceux qui méritent vraiment d’être imposés.

C’est le mode FREI-PI (Fonction Requirements, Effects, Interactions, Protocol Invariants) : à la fin de chaque fonction touchant à la valeur, vérifiez à nouveau que les invariants de la couronne que cette fonction doit maintenir sont respectés. Beaucoup d’attaques par CEI (Checks-Effects-Interactions) (flash loans, liquidation assistée par oracles, drain inter-fonctions) peuvent être capturées par ces vérifications en fin de fonction.

Bonnes pratiques de test

Les fuzzing stateful (fuzzing avec état) génèrent des séquences d’appels aléatoires sur la surface complète du protocole, en affirmant les invariants à chaque étape. La plupart des vulnérabilités en production sont multi-transactionnelles, et le fuzzing avec état est presque la seule méthode fiable pour découvrir ces chemins avant les attaquants.

Utilisez des tests d’invariants pour assurer que ces propriétés tiennent dans toutes les séquences d’appels générées par le fuzzing. Associé à la vérification formelle, cela peut prouver que ces propriétés sont valides dans tous les états accessibles. Vos invariants de couronne doivent absolument supporter cette approche.

Oracles et dépendances

La complexité est l’ennemi de la sécurité. Chaque dépendance externe augmente la surface d’attaque. Lors de la conception, donnez aux utilisateurs le choix de qui et quoi faire confiance. Si vous ne pouvez pas éliminer la dépendance, diversifiez-la pour qu’aucun point unique de défaillance ne puisse détruire votre protocole.

Étendez la portée des audits pour couvrir la simulation de défaillance des oracles et dépendances, et imposez des limites de taux sur les conséquences possibles de leur échec.

Le récent bug de KelpDAO en est un exemple : ils ont hérité de la configuration LayerZero default requiredDVNCount=1, hors de leur périmètre d’audit. La faille a été exploitée sur une infrastructure hors de leur audit.

Attaques superficielles

La majorité des surfaces d’attaque dans DeFi ont déjà été listées. Vérifiez chaque catégorie, demandez si cela s’applique à votre protocole, puis mettez en place des contrôles contre ces vecteurs. Développez des compétences en red team, et faites en sorte que votre IA cherche activement des vulnérabilités dans votre protocole ; c’est désormais une exigence de base.

Posséder une capacité native de sauvetage

Dans une gouvernance basée sur le vote, le pouvoir est initialement concentré dans la multi-signature de l’équipe, et il faut du temps pour le disséminer. Même si la distribution de tokens est large, la délégation tend à concentrer l’autorité dans quelques portefeuilles (parfois un seul). Lorsqu’ils sont compromis, c’est la fin du jeu.

Déployez un « portefeuille gardien », avec des autorisations strictes et limitées : il ne peut que suspendre le protocole, et en cas de seuil >=4/7, il peut, dans des situations extrêmes, remplacer le portefeuille compromis par un portefeuille de remplacement prédéfini. Les gardiens ne peuvent jamais proposer de gouvernance.

Ainsi, vous disposez d’une couche de sauvetage toujours capable de restaurer une stabilité gouvernable, sans pouvoir renverser la gouvernance. La probabilité que >=4/7 des gardiens soient compromis est très faible (en tenant compte de la diversité des détenteurs), et une fois la gouvernance mature et dispersée, cette couche pourra être progressivement éliminée.

Topologie des portefeuilles et clés

Les multi-signatures sont indispensables, avec un minimum de 4/7. Aucun individu ne doit contrôler tous les 7 clés. Faites des rotations fréquentes des signataires, en toute discrétion.

Les clés ne doivent jamais interagir avec des appareils utilisés au quotidien. Si vous utilisez un appareil de signature pour naviguer sur Internet, envoyer des mails ou ouvrir Slack, cela signifie que cette clé est compromise.

Ayez plusieurs multi-signatures, chacune pour un usage différent. Supposez qu’au moins une multi-signature sera compromise, et planifiez à partir de là. Aucun individu ne doit avoir un contrôle suffisant pour compromettre le protocole, même dans des scénarios extrêmes (kidnapping, torture, etc.).

Considérez la mise en place de bounties

Si vous avez des ressources, il est très judicieux de fixer une récompense de bug élevée par rapport à la TVL du protocole ; même pour un protocole plus petit, la récompense doit être aussi généreuse que possible (par exemple, au moins 7-8 chiffres).

Face à des acteurs étatiques, ils peuvent ne pas négocier, mais vous pouvez toujours participer à un programme « white hat bounty », en autorisant des white hats à agir en votre nom pour protéger les fonds, en leur versant un pourcentage des bugs trouvés (financé par les déposants).

Trouver de bons auditeurs

J’ai déjà écrit que, avec l’amélioration des grands modèles de langage, la valeur marginale de l’embauche d’auditeurs diminue. Je maintiens cette position, mais mon point de vue a évolué.

D’abord, de bons auditeurs restent en avance sur la courbe. Si vous faites quelque chose d’innovant, votre code et ses vulnérabilités peuvent ne pas être dans leur entraînement, et augmenter simplement le nombre de tokens n’a pas encore prouvé qu’il détecte efficacement de nouvelles vulnérabilités. Vous ne voulez pas être le premier à présenter une vulnérabilité unique.

Ensuite, un avantage sous-estimé est : embaucher un auditeur, c’est utiliser leur réputation comme garantie. S’ils approuvent en signant, et que vous êtes attaqué, ils ont une forte incitation à aider. Établir une relation avec des professionnels de la sécurité est un atout considérable.

Pratiquer la sécurité opérationnelle

Considérez la sécurité opérationnelle comme un indicateur de succès. Faites des exercices de phishing ; engagez (des red teams fiables) pour tester la résistance sociale de votre équipe. Préparez des portefeuilles matériels et appareils de secours pour remplacer tout le multi-signature en cas de besoin. Vous ne voulez pas devoir acheter tout cela en urgence le jour J.

Mesures d’atténuation

Votre voie de sortie est la limite de pertes

Toute limite maximale de valeur pouvant sortir du protocole lors d’une exploitation est la perte théorique maximale. En résumé : une fonction de mint sans limite par bloc, c’est un chèque en blanc pour toute vulnérabilité d’émission infinie. Une fonction de redemption sans limite hebdomadaire, c’est un chèque en blanc pour tout solde d’actifs corrompu.

Réfléchissez prudemment à la valeur précise de votre voie de sortie. Ce chiffre doit équilibrer la perte maximale acceptable et les besoins extrêmes des utilisateurs. En cas de problème, c’est ce qui peut vous éviter la destruction totale.

Liste blanche (et liste noire)

La plupart des protocoles disposent de listes de contrats ou comptes pouvant être appelés, échangés ou reçus, ainsi que de listes d’utilisateurs interdits. Même implicites, ce sont des frontières de confiance, qu’il faut formaliser.

Formaliser permet d’établir un processus à deux étapes pour la modification, créant une friction significative. L’attaquant doit d’abord ajouter à la liste blanche (ou retirer de la liste noire), puis agir. Avoir les deux en même temps oblige l’attaquant à compromettre deux processus : le marché doit permettre (listing / listing), et l’action ne doit pas être interdite (examen de sécurité).

Récupération

Surveillance algorithmique

Sans surveillance, le bouton d’arrêt est inutile. Les moniteurs hors chaîne doivent surveiller en permanence les invariants, et en cas de problème, alerter de façon algorithmique. La dernière étape doit revenir à une multi-signature de gardiens, avec suffisamment de contexte pour qu’ils puissent décider en quelques minutes.

Recalibrer en arrêtant

En cas d’attaque, il faut d’abord arrêter l’hémorragie, pas prendre de décisions dans la précipitation. Pour le protocole, cela correspond au bouton d’arrêt (qui doit aussi apparaître dans l’UI) : un bouton permettant de suspendre toutes les voies de transfert de valeur en une seule transaction. Préparez un script auxiliaire « tout suspendre », qui énumère tous les composants pouvant être suspendus et les suspend de façon atomique.

Seul la gouvernance peut lever la suspension, donc le bouton d’arrêt ne doit pas suspendre le contrat de gouvernance lui-même. Si la couche de gardiens peut suspendre le contrat de gouvernance, la couche compromise peut bloquer à jamais la restauration.

Lancez votre salle de crise

Figez, arrêtez l’hémorragie, puis rassemblez toutes vos personnes de confiance (petite équipe, préalablement coordonnée) dans un canal de communication. La communication doit rester limitée pour éviter la fuite d’informations aux attaquants, au public ou à des acteurs malveillants.

Jouez des rôles précis : un décideur ; un opérateur expérimenté pour exécuter les scripts de défense et suspendre ; une personne pour analyser la faille et en identifier la cause racine ; un communicant avec les parties clés ; une personne pour enregistrer observations, événements et décisions dans une chronologie.

Quand chacun connaît son rôle et a répété, vous pouvez réagir selon le plan, plutôt que paniquer à la dernière minute.

Considérer la réaction en chaîne

Supposez que votre attaquant soit très expérimenté. La première vulnérabilité peut être un leurre ou une graine pour une attaque ultérieure. L’attaque peut consister à vous faire faire une erreur totale, déclenchant une vulnérabilité réelle.

La suspension doit être pleinement contrôlée, totalement maîtrisée, et elle ne doit pas elle-même être exploitable. La suspension doit figer tout le protocole : vous ne voulez pas être induit en erreur et suspendre un composant, tout en ouvrant une autre faille. Une fois la cause racine et la vecteur d’attaque identifiés, explorez toutes les surfaces exposées et réactions en chaîne, et corrigez tout en une seule fois.

Rotation anticipée des successeurs

Seul un successeur connu à l’avance peut assurer une rotation sécurisée. J’aime l’idée d’un registre de successeurs préenregistrés : cela complique la tâche de l’attaquant pour remplacer un gardien ou un portefeuille de gouvernance compromis. Cela rejoint la philosophie des listes blanches/noires dans les mesures d’atténuation.

Enregistrez une adresse de successeur pour chaque rôle critique. La seule opération d’urgence autorisée pour la rotation est « remplacer le rôle X par son successeur ». Cela permet aussi d’évaluer le successeur en temps calme : faire une due diligence, rencontrer la personne, etc.

Testez prudemment avant la mise à jour

Une fois la cause racine et l’impact compris, vous devez déployer la mise à jour. C’est souvent le code le plus risqué que vous allez déployer : écrit sous pression, pour un attaquant qui connaît déjà votre protocole et ses vulnérabilités.

Ne déployez pas sans tests suffisants. Si vous manquez de temps pour un audit, utilisez des relations avec des white hats, ou organisez une course de 48 heures avant le déploiement pour un dernier examen adversarial.

Rétablissement

Action rapide

Les fonds volés ont une demi-vie : une fois la faille exploitée, ils entrent rapidement dans des circuits de blanchiment. Préparez à l’avance des partenaires comme Chainalysis pour analyser en temps réel les adresses des attaquants, et alerter les plateformes lors de leur transfert inter-chaînes.

Préparez une liste centralisée de contacts : services de conformité, gestionnaires de ponts cross-chain, custodians, et autres tiers pouvant geler des messages cross-chain ou des dépôts en transit.

Négociation

Oui, c’est douloureux, mais il faut essayer de dialoguer avec l’attaquant. Beaucoup de situations peuvent se résoudre par la négociation. Offrez une récompense white hat à durée limitée, et annoncez publiquement qu’en cas de restitution totale avant la date limite, aucune action légale ne sera engagée.

Face à des acteurs étatiques, ils peuvent ne pas négocier, mais vous pouvez toujours participer à un programme « white hat bounty », en autorisant des white hats à agir en votre nom pour protéger les fonds, en leur versant un pourcentage des bugs trouvés (financé par les déposants).

Trouver de bons auditeurs

J’ai déjà écrit que, avec l’amélioration des grands modèles de langage, la valeur marginale de l’embauche d’auditeurs diminue. Je maintiens cette position, mais mon point de vue a évolué.

D’abord, de bons auditeurs restent en avance sur la courbe. Si vous faites quelque chose d’innovant, votre code et ses vulnérabilités peuvent ne pas être dans leur entraînement, et augmenter simplement le nombre de tokens n’a pas encore prouvé qu’il détecte efficacement de nouvelles vulnérabilités. Vous ne voulez pas être le premier à présenter une vulnérabilité unique.

Ensuite, un avantage sous-estimé est : embaucher un auditeur, c’est utiliser leur réputation comme garantie. S’ils approuvent en signant, et que vous êtes attaqué, ils ont une forte incitation à aider. Établir une relation avec des professionnels de la sécurité est un atout considérable.

Pratiquer la sécurité opérationnelle

Considérez la sécurité opérationnelle comme un indicateur de succès. Faites des exercices de phishing ; engagez (des red teams fiables) pour tester la résistance sociale de votre équipe. Préparez des portefeuilles matériels et appareils de secours pour remplacer tout le multi-signature en cas de besoin. Vous ne voulez pas devoir acheter tout cela en urgence le jour J.

Mesures d’atténuation

Votre voie de sortie est la limite de pertes

Toute limite maximale de valeur pouvant sortir du protocole lors d’une exploitation est la perte théorique maximale. En résumé : une fonction de mint sans limite par bloc, c’est un chèque en blanc pour toute vulnérabilité d’émission infinie. Une fonction de redemption sans limite hebdomadaire, c’est un chèque en blanc pour tout solde d’actifs corrompu.

Réfléchissez prudemment à la valeur précise de votre voie de sortie. Ce chiffre doit équilibrer la perte maximale acceptable et les besoins extrêmes des utilisateurs. En cas de problème, c’est ce qui peut vous éviter la destruction totale.

Liste blanche (et liste noire)

La plupart des protocoles disposent de listes de contrats ou comptes pouvant être appelés, échangés ou reçus, ainsi que de listes d’utilisateurs interdits. Même implicites, ce sont des frontières de confiance, qu’il faut formaliser.

Formaliser permet d’établir un processus à deux étapes pour la modification, créant une friction significative. L’attaquant doit d’abord ajouter à la liste blanche (ou retirer de la liste noire), puis agir. Avoir les deux en même temps oblige l’attaquant à compromettre deux processus : le marché doit permettre (listing / listing), et l’action ne doit pas être interdite (examen de sécurité).

Récupération

Surveillance algorithmique

Sans surveillance, le bouton d’arrêt est inutile. Les moniteurs hors chaîne doivent surveiller en permanence les invariants, et en cas de problème, alerter de façon algorithmique. La dernière étape doit revenir à une multi-signature de gardiens, avec suffisamment de contexte pour qu’ils puissent décider en quelques minutes.

Recalibrer en arrêtant

En cas d’attaque, il faut d’abord arrêter l’hémorragie, pas prendre de décisions dans la précipitation. Pour le protocole, cela correspond au bouton d’arrêt (qui doit aussi apparaître dans l’UI) : un bouton permettant de suspendre toutes les voies de transfert de valeur en une seule transaction. Préparez un script auxiliaire « tout suspendre », qui énumère tous les composants pouvant être suspendus et les suspend de façon atomique.

Seul la gouvernance peut lever la suspension, donc le bouton d’arrêt ne doit pas suspendre le contrat de gouvernance lui-même. Si la couche de gardiens peut suspendre le contrat de gouvernance, la couche compromise peut bloquer à jamais la restauration.

Lancez votre salle de crise

Figez, arrêtez l’hémorragie, puis rassemblez toutes vos personnes de confiance (petite équipe, préalablement coordonnée) dans un canal de communication. La communication doit rester limitée pour éviter la fuite d’informations aux attaquants, au public ou à des acteurs malveillants.

Jouez des rôles précis : un décideur ; un opérateur expérimenté pour exécuter les scripts de défense et suspendre ; une personne pour analyser la faille et en identifier la cause racine ; un communicant avec les parties clés ; une personne pour enregistrer observations, événements et décisions dans une chronologie.

Quand chacun connaît son rôle et a répété, vous pouvez réagir selon le plan, plutôt que paniquer à la dernière minute.

Considérer la réaction en chaîne

Supposez que votre attaquant soit très expérimenté. La première vulnérabilité peut être un leurre ou une graine pour une attaque ultérieure. L’attaque peut consister à vous faire faire une erreur totale, déclenchant une vulnérabilité réelle.

La suspension doit être pleinement contrôlée, totalement maîtrisée, et elle ne doit pas elle-même être exploitable. La suspension doit figer tout le protocole : vous ne voulez pas être induit en erreur et suspendre un composant, tout en ouvrant une autre faille. Une fois la cause racine et la vecteur d’attaque identifiés, explorez toutes les surfaces exposées et réactions en chaîne, et corrigez tout en une seule fois.

Rotation anticipée des successeurs

Seul un successeur connu à l’avance peut assurer une rotation sécurisée. J’aime l’idée d’un registre de successeurs préenregistrés : cela complique la tâche de l’attaquant pour remplacer un gardien ou un portefeuille de gouvernance compromis. Cela rejoint la philosophie des listes blanches/noires dans les mesures d’atténuation.

Enregistrez une adresse de successeur pour chaque rôle critique. La seule opération d’urgence autorisée pour la rotation est « remplacer le rôle X par son successeur ». Cela permet aussi d’évaluer le successeur en temps calme : faire une due diligence, rencontrer la personne, etc.

Testez prudemment avant la mise à jour

Une fois la cause racine et l’impact compris, vous devez déployer la mise à jour. C’est souvent le code le plus risqué que vous allez déployer : écrit sous pression, pour un attaquant qui connaît déjà votre protocole et ses vulnérabilités.

Ne déployez pas sans tests suffisants. Si vous manquez de temps pour un audit, utilisez des relations avec des white hats, ou organisez une course de 48 heures avant le déploiement pour un dernier examen adversarial.

Rétablissement

Action rapide

Les fonds volés ont une demi-vie ; une fois la faille exploitée, ils entrent rapidement dans des circuits de blanchiment. Préparez à l’avance des partenaires comme Chainalysis pour analyser en temps réel les adresses des attaquants, et alerter les plateformes lors de leur transfert inter-chaînes.

Préparez une liste centralisée de contacts : services de conformité, gestionnaires de ponts cross-chain, custodians, et autres tiers pouvant geler des messages cross-chain ou des dépôts en transit.

Négociation

Oui, c’est douloureux, mais il faut essayer de dialoguer avec l’attaquant. Beaucoup de situations peuvent se résoudre par la négociation. Offrez une récompense white hat à durée limitée, et annoncez publiquement qu’en cas de restitution totale avant la date limite, aucune action légale ne sera engagée.

Face à des acteurs étatiques, ils peuvent ne pas négocier, mais vous pouvez toujours participer à un programme « white hat bounty », en autorisant des white hats à agir en votre nom pour protéger les fonds, en leur versant un pourcentage des bugs trouvés (financé par les déposants).

Trouver de bons auditeurs

J’ai déjà écrit que, avec l’amélioration des grands modèles de langage, la valeur marginale de l’embauche d’auditeurs diminue. Je maintiens cette position, mais mon point de vue a évolué.

D’abord, de bons auditeurs restent en avance sur la courbe. Si vous faites quelque chose d’innovant, votre code et ses vulnérabilités peuvent ne pas être dans leur entraînement, et augmenter simplement le nombre de tokens n’a pas encore prouvé qu’il détecte efficacement de nouvelles vulnérabilités. Vous ne voulez pas être le premier à présenter une vulnérabilité unique.

Ensuite, un avantage sous-estimé est : embaucher un auditeur, c’est utiliser leur réputation comme garantie. S’ils approuvent en signant, et que vous êtes attaqué, ils ont une forte incitation à aider. Établir une relation avec des professionnels de la sécurité est un atout considérable.

Pratiquer la sécurité opérationnelle

Considérez la sécurité opérationnelle comme un indicateur de succès. Faites des exercices de phishing ; engagez (des red teams fiables) pour tester la résistance sociale de votre équipe. Préparez des portefeuilles matériels et appareils de secours pour remplacer tout le multi-signature en cas de besoin. Vous ne voulez pas devoir acheter tout cela en urgence le jour J.

Mesures d’atténuation

Votre voie de sortie est la limite de pertes

Toute limite maximale de valeur pouvant sortir du protocole lors d’une exploitation est la perte théorique maximale. En résumé : une fonction de mint sans limite par bloc, c’est un chèque en blanc pour toute vulnérabilité d’émission infinie. Une fonction de redemption sans limite hebdomadaire, c’est un chèque en blanc pour tout solde d’actifs corrompu.

Réfléchissez prudemment à la valeur précise de votre voie de sortie. Ce chiffre doit équilibrer la perte maximale acceptable et les besoins extrêmes des utilisateurs. En cas de problème, c’est ce qui peut vous éviter la destruction totale.

Liste blanche (et liste noire)

La plupart des protocoles disposent de listes de contrats ou comptes pouvant être appelés, échangés ou reçus, ainsi que de listes d’utilisateurs interdits. Même implicites, ce sont des frontières de confiance, qu’il faut formaliser.

Formaliser permet d’établir un processus à deux étapes pour la modification, créant une friction significative. L’attaquant doit d’abord ajouter à la liste blanche (ou retirer de la liste noire), puis agir. Avoir les deux en même temps oblige l’attaquant à compromettre deux processus : le marché doit permettre (listing / listing), et l’action ne doit pas être interdite (examen de sécurité).

Récupération

Surveillance algorithmique

Sans surveillance, le bouton d’arrêt est inutile. Les moniteurs hors chaîne doivent surveiller en permanence les invariants, et en cas de problème, alerter de façon algorithmique. La dernière étape doit revenir à une multi-signature de gardiens, avec suffisamment de contexte pour qu’ils puissent décider en quelques minutes.

Recalibrer en arrêtant

En cas d’attaque, il faut d’abord arrêter l’hémorragie, pas prendre de décisions dans la précipitation. Pour le protocole, cela correspond au bouton d’arrêt (qui doit aussi apparaître dans l’UI) : un bouton permettant de suspendre toutes les voies de transfert de valeur en une seule transaction. Préparez un script auxiliaire « tout suspendre », qui énumère tous les composants pouvant être suspendus et les suspend de façon atomique.

Seul la gouvernance peut lever la suspension, donc le bouton d’arrêt ne doit pas suspendre le contrat de gouvernance lui-même. Si la couche de gardiens peut suspendre le contrat de gouvernance, la couche compromise peut bloquer à jamais la restauration.

Lancez votre salle de crise

Figez, arrêtez l’hémorragie, puis rassemblez toutes vos personnes de confiance (petite équipe, préalablement coordonnée) dans un canal de communication. La communication doit rester limitée pour éviter la fuite d’informations aux attaquants, au public ou à des acteurs malveillants.

Jouez des rôles précis : un décideur ; un opérateur expérimenté pour exécuter les scripts de défense et suspendre ; une personne pour analyser la faille et en identifier la cause racine ; un communicant avec les parties clés ; une personne pour enregistrer observations, événements et décisions dans une chronologie.

Quand chacun connaît son rôle et a répété, vous pouvez réagir selon le plan, plutôt que paniquer à la dernière minute.

Considérer la réaction en chaîne

Supposez que votre attaquant soit très expérimenté. La première vulnérabilité peut être un leurre ou une graine pour une attaque ultérieure. L’attaque peut consister à vous faire faire une erreur totale, déclenchant une vulnérabilité réelle.

La suspension doit être pleinement contrôlée, totalement maîtrisée, et elle ne doit pas elle-même être exploitable. La suspension doit figer tout le protocole : vous ne voulez pas être induit en erreur et suspendre un composant, tout en ouvrant une autre faille. Une fois la cause racine et la vecteur d’attaque identifiés, explorez toutes les surfaces exposées et réactions en chaîne, et corrigez tout en une seule fois.

Rotation anticipée des successeurs

Seul un successeur connu à l’avance peut assurer une rotation sécurisée. J’aime l’idée d’un registre de successeurs préenregistrés : cela complique la tâche de l’attaquant pour remplacer un gardien ou un portefeuille de gouvernance compromis. Cela rejoint la philosophie des listes blanches/noires dans les mesures d’atténuation.

Enregistrez une adresse de successeur pour chaque rôle critique. La seule opération d’urgence autorisée pour la rotation est « remplacer le rôle X par son successeur ». Cela permet aussi d’évaluer le successeur en temps calme : faire une due diligence, rencontrer la personne, etc.

Testez prudemment avant la mise à jour

Une fois la cause racine et l’impact compris, vous devez déployer la mise à jour. C’est souvent le code le plus risqué que vous allez déployer : écrit sous pression, pour un attaquant qui connaît déjà votre protocole et ses vulnérabilités.

En l’absence de tests suffisants, ne déployez pas. Si vous manquez de temps pour un audit, utilisez des relations avec des white hats, ou organisez une course de 48 heures avant le déploiement pour un dernier examen adversarial.

Rétablissement

Action rapide

Les fonds volés ont une demi-vie ; une fois la faille exploitée, ils entrent rapidement dans des circuits de blanchiment. Préparez à l’avance des partenaires comme Chainalysis pour analyser en temps réel les adresses des attaquants, et alerter les plateformes lors de leur transfert inter-chaînes.

Préparez une liste centralisée de contacts : services de conformité, gestionnaires de ponts cross-chain, custodians, et autres tiers pouvant geler des messages cross-chain ou des dépôts en transit.

Négociation

Oui, c’est douloureux, mais il faut essayer de dialoguer avec l’attaquant. Beaucoup de situations peuvent se résoudre par la négociation. Offrez une récompense white hat à durée limitée, et annoncez publiquement qu’en cas de restitution totale avant la date limite, aucune action légale ne sera engagée.

Face à des acteurs étatiques, ils peuvent ne pas négocier, mais vous pouvez toujours participer à un programme « white hat bounty », en autorisant des white hats à agir en votre nom pour protéger les fonds, en leur versant un pourcentage des bugs trouvés (financé par les déposants).

Trouver de bons auditeurs

J’ai déjà écrit que, avec l’amélioration des grands modèles de langage, la valeur marginale de l’embauche d’auditeurs diminue. Je maintiens cette position, mais mon point de vue a évolué.

D’abord, de bons auditeurs restent en avance sur la courbe. Si vous faites quelque chose d’innovant, votre code et ses vulnérabilités peuvent ne pas être dans leur entraînement, et augmenter simplement le nombre de tokens n’a pas encore prouvé qu’il détecte efficacement de nouvelles vulnérabilités. Vous ne voulez pas être le premier à présenter une vulnérabilité unique.

Ensuite, un avantage sous-estimé est : embaucher un auditeur, c’est utiliser leur réputation comme garantie. S’ils approuvent en signant, et que vous êtes attaqué, ils ont une forte incitation à aider. Établir une relation avec des professionnels de la sécurité est un atout considérable.

Pratiquer la sécurité opérationnelle

Considérez la sécurité opérationnelle comme un indicateur de succès. Faites des exercices de phishing ; engagez (des red teams fiables) pour tester la résistance sociale de votre équipe. Préparez des portefeuilles matériels et appareils de secours pour remplacer tout le multi-signature en cas de besoin. Vous ne voulez pas devoir acheter tout cela en urgence le jour J.

Mesures d’atténuation

Votre voie de sortie est la limite de pertes

Toute limite maximale de valeur pouvant sortir du protocole lors d’une exploitation est la perte maximale théorique. En résumé : une fonction de mint sans limite par bloc, c’est un chèque en blanc pour toute vulnérabilité d’émission infinie. Une fonction de redemption sans limite hebdomadaire, c’est un chèque en blanc pour tout solde d’actifs corrompu.

Réfléchissez prudemment à la valeur précise de votre voie de sortie. Ce chiffre doit équilibrer la perte maximale acceptable et les besoins extrêmes des utilisateurs. En cas de problème, c’est ce qui peut vous éviter la destruction totale.

Liste blanche (et liste noire)

La plupart des protocoles disposent de listes de contrats ou comptes pouvant être appelés, échangés ou reçus, ainsi que de listes d’utilisateurs interdits. Même implicites, ce sont des frontières de confiance, qu’il faut formaliser.

Formaliser permet d’établir un processus à deux étapes pour la modification, créant une friction significative. L’attaquant doit d’abord ajouter à la liste blanche (ou retirer de la liste noire), puis agir. Avoir les deux en même temps oblige l’attaquant à compromettre deux processus : le marché doit permettre (listing / listing), et l’action ne doit pas être interdite (examen de sécurité).

Récupération

Surveillance algorithmique

Sans surveillance, le bouton d’arrêt est inutile. Les moniteurs hors chaîne doivent surveiller en permanence les invariants, et en cas de problème, alerter de façon algorithmique. La dernière étape doit revenir à une multi-signature de gardiens, avec suffisamment de contexte pour qu’ils puissent décider en quelques minutes.

Recalibrer en arrêtant

En cas d’attaque, il faut d’abord arrêter l’hémorragie, pas prendre de décisions dans la précipitation. Pour le protocole, cela correspond au bouton d’arrêt (qui doit aussi apparaître