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

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 à long terme ; ces super-vilains se concentrent à scruter chaque recoin de vos protocoles et infrastructures pour trouver des vulnérabilités, alors que les équipes de protocoles ordinaires sont dispersées 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 en réflexion stratégique et en planification 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 ont lieu. Nous devons faire mieux.

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

(Source des données : https://defillama.com/hacks)

Les attaques de piratage 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 ne fait que commencer, il semble déjà prêt à battre le record du trimestre précédent.

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 de cent protocoles à la recherche d’erreurs ; alors que les modèles de base les plus récents peuvent le faire en quelques heures.

Cela doit changer radicalement notre façon de penser et de répondre aux attaques. Les protocoles anciens, habitués à la sécurité avant que l’IA ne devienne puissante, risquent de se faire « éclater » en quelques secondes.

Penser en surface et en hiérarchie

(Source des données : https://defillama.com/hacks)

La surface d’attaque réelle peut être réduite à trois catégories : 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, superposez des couches de défense :

· Prévention : en appliquant strictement, vous maximisez la réduction des risques d’exploitation.

· Mitigation : en cas d’échec de la prévention, limitez l’étendue des dégâts.

· Pause : personne ne peut prendre la meilleure décision sous une pression extrême. Dès qu’une attaque est confirmée, activez immédiatement le bouton d’arrêt général. La suspension peut empêcher des pertes supplémentaires et vous donner le temps de 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 nos actions concrètes pour 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 en front-end pour voir si elles peuvent atteindre le back-end. Les attaquants le font. Ce que vous pouvez détecter par des scans défensifs, ils l’ont déjà repéré par des scans offensifs.

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

Le temps et la friction sont de bonnes défenses

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

Les objections passées aux verrouillages temporels et aux processus multi-étapes étaient que cela créait de la friction pour l’équipe du protocole. Désormais, avec l’IA, cela devient beaucoup plus simple : elle peut facilement passer ces étapes en arrière-plan.

Invariants

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.

Vous n’avez généralement que quelques invariants. Il faut les remonter prudemment dans le code ; en faire respecter plusieurs dans chaque fonction devient difficile à gérer.

Équilibre des pouvoirs

De nombreuses attaques proviennent de portefeuilles compromis. Il faut une configuration permettant, même si une multi-signature est attaquée, de limiter rapidement les dégâts et de ramener le protocole à un état de gouvernabilité contrôlable.

Cela nécessite un équilibre entre gouvernance (qui décide de tout) et secours (qui peut restaurer la stabilité gouvernable sans pouvoir renverser la gouvernance).

Il y aura toujours des problèmes

Partons 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, et les nouvelles mises à jour peuvent introduire des vulnérabilités inattendues.

En adoptant cette mentalité, les limiteurs de dégâts et les disjoncteurs de protocole deviennent vos meilleurs alliés. Limitez les dégâts à 5-10 %, puis figez, et planifiez votre réponse. Personne ne peut prendre la meilleure décision sous le feu.

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’un incident. À l’ère de l’IA, cela implique de maîtriser des compétences et des algorithmes capables de présenter rapidement une grande quantité d’informations, puis de les partager sous forme de résumés ou de rapports détaillés à votre cercle central.

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

L’absence de preuve d’un piratage 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, remontez-les en vérifications à l’exécution. Réfléchissez soigneusement à ceux qui méritent d’être strictement appliqués.

C’est le principe FREI-PI (Fonction Requirements, Effects, Interactions, Protocol Invariants) : à la fin de chaque fonction touchant à la valeur, vérifiez à nouveau que les invariants essentiels sont maintenus. Beaucoup d’attaques par déduction via CEI (Checks-Effects-Interactions) — comme les sandwichs flash loans, les liquidations assistées par oracles, ou les défaillances inter-fonction — peuvent être détectées par ces vérifications en fin de fonction.

Bonnes pratiques de test

Les tests de fuzzing étatful 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 étatful 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 générées par le fuzzing. Associé à la vérification formelle, cela prouve que ces propriétés sont valides dans tous les états accessibles. Vos invariants de souveraineté 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 faire confiance à qui et à quoi. Si vous ne pouvez pas éliminer une dépendance, diversifiez-la pour qu’aucun point de défaillance unique ne puisse détruire votre protocole.

Étendez la portée des audits pour couvrir la simulation des échecs d’oracles et de dépendances, et imposez des limites de taux pour les risques potentiels liés à leur défaillance.

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 dans l’infrastructure hors chaîne non auditée.

Attaques superficielles

La majorité des surfaces d’attaque en DeFi ont déjà été listées. Vérifiez chaque catégorie, demandez si elle 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 secours

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

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

Ainsi, vous disposez d’une couche de secours toujours capable de restaurer la 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 une exigence minimale, avec au moins 4/7. Aucun individu ne doit contrôler seul les 7 clés. Faites des rotations fréquentes des signataires, discrètement.

Les clés ne doivent jamais interagir avec des appareils utilisés quotidiennement. Si vous utilisez un appareil pour signer en naviguant sur Internet, envoyer des mails ou ouvrir Slack, considérez que cette clé est compromise.

Déployez plusieurs multi-signatures, chacune pour un usage différent. Supposez qu’au moins une multi-sig 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 en proportion de la TVL du protocole ; même pour un protocole plus petit, la récompense doit être aussi généreuse que possible (par exemple, à 7-8 chiffres minimum).

Face à des acteurs étatiques, ils peuvent ne pas négocier, mais vous pouvez toujours participer à un programme « white hat » : autoriser des white hats à agir en votre nom pour protéger les fonds, en leur versant un pourcentage des bugs trouvés (en réalité, une prime payée 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 avec une nuance.

D’abord, un bon auditeur sera toujours en avance sur la courbe. Si vous faites quelque chose d’innovant, votre code et ses vulnérabilités ne seront peut-être pas dans leur entraînement, et augmenter le nombre de tokens ne garantit pas de découvrir de nouvelles vulnérabilités. Vous ne voulez pas être le premier à exploiter une faille unique.

Ensuite, un avantage sous-estimé est : engager un auditeur, c’est aussi utiliser leur réputation comme garantie. S’ils signent et que vous êtes attaqué, ils ont tout intérêt à aider. Établir une relation avec des professionnels de la sécurité est un atout considérable.

Pratiques opérationnelles

Considérez la sécurité opérationnelle comme un indicateur de succès. Faites des exercices de phishing ; engagez (de façon fiable) une red team pour tester votre équipe contre l’ingénierie sociale. Préparez des hardware wallets et appareils de secours, pour pouvoir remplacer tout le multi-sig si nécessaire. Vous ne voulez pas faire cela en urgence le jour J.

Mesures d’atténuation

Votre voie de sortie, c’est la limite de perte

Le montant maximal que vous pouvez perdre via une voie donnée, en cas d’exploitation, doit être connu. En termes simples : une fonction de mint sans plafond par bloc, c’est un chèque en blanc pour toute émission infinie. Une fonction de redemption sans limite hebdomadaire, c’est un chèque en blanc pour tout solde.

Réfléchissez soigneusement à ces chiffres : ils doivent équilibrer votre tolérance au dommage maximal et l’expérience utilisateur extrême. En cas de problème, c’est ce qui vous évitera la catastrophe totale.

Listes blanches (et noires)

La plupart des protocoles disposent de listes de comptes pouvant être appelés, échangés ou recevant des fonds, ainsi que de listes d’interdiction pour certains utilisateurs. Même implicites, ces frontières de confiance doivent être formalisées.

Formaliser ces listes permet de mettre en place des mécanismes à deux étapes, 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 à franchir deux processus : l’intégration / la cotation sur le marché, et la validation de l’action par une vérification de sécurité.

Récupération

Surveillance algorithmique

Sans surveillance, le bouton d’arrêt est inutile. Des moniteurs hors chaîne doivent suivre en permanence les invariants, et en cas de problème, alerter de façon automatisée. La dernière étape doit revenir à une équipe humaine, avec suffisamment de contexte pour décider en quelques minutes.

Recalibrage

En cas d’attaque, la priorité est de stopper l’hémorragie, pas de prendre des décisions dans la précipitation. Pour un protocole, cela signifie un bouton d’arrêt (également visible dans l’UI) : une simple pression peut suspendre toutes les voies de transfert de valeur. Préparez un script auxiliaire pour tout mettre en pause 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, un gardien compromis pourrait bloquer la restauration indéfiniment.

Lancement de la salle de crise

Figez, arrêtez l’hémorragie, puis rassemblez toutes les personnes de confiance (petit cercle, préalablement convenu) 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.

Attribuez des rôles précis à chaque membre : un décideur, un opérateur capable d’exécuter rapidement des scripts de défense et de suspension, une personne pour analyser et identifier la cause racine, un interlocuteur pour communiquer avec les parties clés, et un archiviste pour documenter observations, événements et décisions.

Quand chaque personne connaît son rôle et a été entraînée, vous pouvez réagir selon un plan, plutôt que paniquer dans l’urgence.

Considérez la réaction en chaîne

Supposez que votre attaquant soit très expérimenté. La première vulnérabilité pourrait être un leurre ou une étape préparatoire à une attaque plus grande. L’attaque pourrait consister à vous faire faire une erreur fatale, déclenchant la vraie faille.

Le bouton de pause doit faire l’objet d’une étude approfondie, être totalement contrôlable, et ne doit pas lui-même être exploitable. La pause doit couvrir tout le protocole : vous ne voulez pas qu’un composant soit mis en pause pour en ouvrir un autre. 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 des successeurs prévus

Seuls ceux dont la succession est connue à l’avance peuvent assurer une transition sûre. J’aime l’idée d’un registre de successeurs préenregistrés : cela complique la tâche de l’attaquant qui voudrait remplacer un gardien ou un portefeuille de gouvernance sain par un 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 est « remplacer le rôle X par son successeur ». Cela vous permet aussi d’évaluer les successeurs en temps calme : faire du due diligence, rencontrer ceux qui proposent, etc.

Testez prudemment avant la mise à jour

Une fois que vous avez identifié la cause racine et l’étendue, vous devez déployer une mise à jour. C’est peut-être le code le plus risqué que vous ayez à déployer : écrit sous pression, pour un attaquant qui connaît déjà votre protocole et ses vulnérabilités.

N’attendez pas pour déployer si vous n’avez pas suffisamment testé. Si le temps manque pour un audit complet, utilisez des relations avec des white hats, ou organisez un concours de 48 heures pour un dernier test adversarial.

Récupération

Réagir rapidement

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 suivre en temps réel les clusters d’adresses des attaquants, et alerter les plateformes d’échange lors de leurs mouvements cross-chain.

Préparez une liste centralisée de contacts : régulateurs, 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 tenter de dialoguer avec l’attaquant. Beaucoup de situations peuvent se résoudre par la négociation. Offrez une prime blanche limitée dans le temps, et annoncez publiquement qu’en cas de restitution intégrale avant la date limite, aucune action légale ne sera engagée.

Si vous faites face à un acteur étatique, vous n’aurez peut-être pas de chance, mais vous pouvez toujours participer à un programme « white hat » : autoriser des white hats à agir en votre nom pour protéger les fonds, en leur versant un pourcentage des bugs trouvés (en réalité, une prime payée 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 avec une nuance.

D’abord, un bon auditeur sera toujours en avance sur la courbe. Si vous faites quelque chose d’innovant, votre code et ses vulnérabilités ne seront peut-être pas dans leur entraînement, et augmenter le nombre de tokens ne garantit pas de découvrir de nouvelles vulnérabilités. Vous ne voulez pas être le premier à exploiter une faille unique.

Ensuite, un avantage sous-estimé est : engager un auditeur, c’est aussi utiliser leur réputation comme garantie. S’ils signent et que vous êtes attaqué, ils ont tout intérêt à aider. Établir une relation avec des professionnels de la sécurité est un atout considérable.

Pratiques opérationnelles

Considérez la sécurité opérationnelle comme un indicateur de succès. Faites des exercices de phishing ; engagez (de façon fiable) une red team pour tester votre équipe contre l’ingénierie sociale. Préparez des hardware wallets et appareils de secours, pour pouvoir remplacer tout le multi-sig si nécessaire. Vous ne voulez pas faire cela en urgence le jour J.

Mesures d’atténuation

Votre voie de sortie, c’est la limite de perte

Le montant maximal que vous pouvez perdre via une voie donnée, en cas d’exploitation, doit être connu. En termes simples : une fonction de mint sans plafond par bloc, c’est un chèque en blanc pour toute émission infinie. Une fonction de redemption sans limite hebdomadaire, c’est un chèque en blanc pour tout solde.

Réfléchissez soigneusement à ces chiffres : ils doivent équilibrer votre tolérance au dommage maximal et l’expérience utilisateur extrême. En cas de problème, c’est ce qui vous évitera la catastrophe totale.

Listes blanches (et noires)

La plupart des protocoles disposent de listes de comptes pouvant être appelés, échangés ou recevant des fonds, ainsi que de listes d’interdiction pour certains utilisateurs. Même implicites, ces frontières de confiance doivent être formalisées.

Formaliser ces listes permet de mettre en place des mécanismes à deux étapes, 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 à franchir deux processus : l’intégration / la cotation sur le marché, et la validation de l’action par une vérification de sécurité.

Récupération

Surveillance algorithmique

Sans surveillance, le bouton d’arrêt est inutile. Des moniteurs hors chaîne doivent suivre en permanence les invariants, et en cas de problème, alerter de façon automatisée. La dernière étape doit revenir à une équipe humaine, avec suffisamment de contexte pour décider en quelques minutes.

Recalibrage

En cas d’attaque, la priorité est de stopper l’hémorragie, pas de prendre des décisions dans la précipitation. Pour un protocole, cela signifie un bouton d’arrêt (également visible dans l’UI) : une simple pression peut suspendre toutes les voies de transfert de valeur. Préparez un script auxiliaire pour tout mettre en pause 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, un gardien compromis pourrait bloquer la restauration indéfiniment.

Lancement de la salle de crise

Figez, arrêtez l’hémorragie, puis rassemblez toutes les personnes de confiance (petit cercle, préalablement convenu) 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.

Attribuez des rôles précis à chaque membre : un décideur, un opérateur capable d’exécuter rapidement des scripts de défense et de suspension, une personne pour analyser et identifier la cause racine, un interlocuteur pour communiquer avec les parties clés, et un archiviste pour documenter observations, événements et décisions.

Quand chaque personne connaît son rôle et a été entraînée, vous pouvez réagir selon un plan, plutôt que paniquer dans l’urgence.

Considérez la réaction en chaîne

Supposez que votre attaquant soit très expérimenté. La première vulnérabilité pourrait être un leurre ou une étape préparatoire à une attaque plus grande. L’attaque pourrait consister à vous faire faire une erreur fatale, déclenchant la vraie faille.

Le bouton de pause doit faire l’objet d’une étude approfondie, être totalement contrôlable, et ne doit pas lui-même être exploitable. La pause doit couvrir tout le protocole : vous ne voulez pas qu’un composant soit mis en pause pour en ouvrir un autre. 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 des successeurs prévus

Seuls ceux dont la succession est connue à l’avance peuvent assurer une transition sûre. J’aime l’idée d’un registre de successeurs préenregistrés : cela complique la tâche de l’attaquant qui voudrait remplacer un gardien ou un portefeuille de gouvernance sain par un 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 est « remplacer le rôle X par son successeur ». Cela vous permet aussi d’évaluer les successeurs en temps calme : faire du due diligence, rencontrer ceux qui proposent, etc.

Testez prudemment avant la mise à jour

Une fois que vous avez identifié la cause racine et l’étendue, vous devez déployer une mise à jour. C’est peut-être le code le plus risqué que vous ayez à déployer : écrit sous pression, pour un attaquant qui connaît déjà votre protocole et ses vulnérabilités.

N’attendez pas pour déployer si vous n’avez pas suffisamment testé. Si le temps manque pour un audit complet, utilisez des relations avec des white hats, ou organisez un concours de 48 heures pour un dernier test adversarial.

Récupération

Réagir rapidement

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 suivre en temps réel les clusters d’adresses des attaquants, et alerter les plateformes d’échange lors de leurs mouvements cross-chain.

Préparez une liste centralisée de contacts : régulateurs, 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 tenter de dialoguer avec l’attaquant. Beaucoup de situations peuvent se résoudre par la négociation. Offrez une prime blanche limitée dans le temps, et annoncez publiquement qu’en cas de restitution intégrale avant la date limite, aucune action légale ne sera engagée.

Si vous faites face à un acteur étatique, vous n’aurez peut-être pas de chance, mais vous pouvez toujours participer à un programme « white hat » : autoriser des white hats à agir en votre nom pour protéger les fonds, en leur versant un pourcentage des bugs trouvés (en réalité, une prime payée 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 avec une nuance.

D’abord, un bon auditeur sera toujours en avance sur la courbe. Si vous faites quelque chose d’innovant, votre code et ses vulnérabilités ne seront peut-être pas dans leur entraînement, et augmenter le nombre de tokens ne garantit pas de découvrir de nouvelles vulnérabilités. Vous ne voulez pas être le premier à exploiter une faille unique.

Ensuite, un avantage sous-estimé est : engager un auditeur, c’est aussi utiliser leur réputation comme garantie. S’ils signent et que vous êtes attaqué, ils ont tout intérêt à aider. Établir une relation avec des professionnels de la sécurité est un atout considérable.

Pratiques opérationnelles

Considérez la sécurité opérationnelle comme un indicateur de succès. Faites des exercices de phishing ; engagez (de façon fiable) une red team pour tester votre équipe contre l’ingénierie sociale. Préparez des hardware wallets et appareils de secours, pour pouvoir remplacer tout le multi-sig si nécessaire. Vous ne voulez pas faire cela en urgence le jour J.

Mesures d’atténuation

Votre voie de sortie, c’est la limite de perte

Le montant maximal que vous pouvez perdre via une voie donnée, en cas d’exploitation, doit être connu. En termes simples : une fonction de mint sans plafond par bloc, c’est un chèque en blanc pour toute émission infinie. Une fonction de redemption sans limite hebdomadaire, c’est un chèque en blanc pour tout solde.

Réfléchissez soigneusement à ces chiffres : ils doivent équilibrer votre tolérance au dommage maximal et l’expérience utilisateur extrême. En cas de problème, c’est ce qui vous évitera la catastrophe totale.

Listes blanches (et noires)

La plupart des protocoles disposent de listes de comptes pouvant être appelés, échangés ou recevant des fonds, ainsi que de listes d’interdiction pour certains utilisateurs. Même implicites, ces frontières de confiance doivent être formalisées.

Formaliser ces listes permet de mettre en place des mécanismes à deux étapes, 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 à franchir deux processus : l’intégration / la cotation sur le marché, et la validation de l’action par une vérification de sécurité.

Récupération

Surveillance algorithmique

Sans surveillance, le bouton d’arrêt est inutile. Des moniteurs hors chaîne doivent suivre en permanence les invariants, et en cas de problème, alerter de façon automatisée. La dernière étape doit revenir à une équipe humaine, avec suffisamment de contexte pour décider en quelques minutes.

Recalibrage

En cas d’attaque, la priorité est de stopper l’hémorragie, pas de prendre des décisions dans la précipitation. Pour un protocole, cela signifie un bouton d’arrêt (également visible dans l’UI) : une simple pression peut suspendre toutes les voies de transfert de valeur. Préparez un script auxiliaire pour tout mettre en pause 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, un gardien compromis pourrait bloquer la restauration indéfiniment.

Lancement de la salle de crise

Figez, arrêtez l’hémorragie, puis rassemblez toutes les personnes de confiance (petit cercle, préalablement convenu) 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.

Attribuez des rôles précis à chaque membre : un décideur, un opérateur capable d’exécuter rapidement des scripts de défense et de suspension, une personne pour analyser et identifier la cause racine, un interlocuteur pour communiquer avec les parties clés, et un archiviste pour documenter observations, événements et décisions.

Quand chaque personne connaît son rôle et a été entraînée, vous pouvez réagir selon un plan, plutôt que paniquer dans l’urgence.

Considérez la réaction en chaîne

Supposez que votre attaquant soit très expérimenté. La première vulnérabilité pourrait être un leurre ou une étape préparatoire à une attaque plus grande. L’attaque pourrait consister à vous faire faire une erreur fatale, déclenchant la vraie faille.

Le bouton de pause doit faire l’objet d’une étude approfondie, être totalement contrôlable, et ne doit pas lui-même être exploitable. La pause doit couvrir tout le protocole : vous ne voulez pas qu’un composant soit mis en pause pour en ouvrir un autre. 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 des successeurs prévus

Seuls ceux dont la succession est connue à l’avance peuvent assurer une transition sûre. J’aime l’idée d’un registre de successeurs préenregistrés : cela complique la tâche de l’attaquant qui voudrait remplacer un gardien ou un portefeuille de gouvernance sain par un 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 est « remplacer le rôle X par son successeur ». Cela vous permet aussi d’évaluer les successeurs en temps calme : faire du due diligence, rencontrer ceux qui proposent, etc.

Testez prudemment avant la mise à jour

Une fois que vous avez identifié la cause racine et l’étendue, vous devez déployer une mise à jour. C’est peut-être le code le plus risqué que vous ayez à déployer : écrit sous pression, pour un attaquant qui connaît déjà votre protocole et ses vulnérabilités.

N’attendez pas pour déployer si vous n’avez pas suffisamment testé. Si le temps manque pour un audit complet, utilisez des relations avec des white hats, ou organisez un concours de 48 heures pour un dernier test adversarial.

Récupération

Réagir rapidement

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 suivre en temps réel les clusters d’adresses des attaquants, et alerter les plateformes d’échange lors de leurs mouvements cross-chain.

Préparez une liste centralisée de contacts : régulateurs, 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 tenter de dialoguer avec l’attaquant. Beaucoup de situations peuvent se résoudre par la négociation. Offrez une prime blanche limitée dans le temps, et annoncez publiquement qu’en cas de restitution intégrale avant la date limite, aucune action légale ne sera engagée.

Si vous faites face à un acteur étatique, vous n’aurez peut-être pas de chance, mais vous pouvez toujours participer à un programme « white hat » : autoriser des white hats à agir en votre nom pour protéger les fonds, en leur versant un pourcentage des bugs trouvés (en réalité, une prime payée 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 avec une nuance.

D’abord, un bon auditeur sera toujours en avance sur la courbe. Si vous faites quelque chose d’innovant, votre code et ses vulnérabilités ne seront peut-être pas dans leur entraînement, et augmenter le nombre de tokens ne garantit pas de découvrir de nouvelles vulnérabilités. Vous ne voulez pas être le premier à exploiter une faille unique.

Ensuite, un avantage sous-estimé est : engager un auditeur, c’est aussi utiliser leur réputation comme garantie. S’ils signent et que vous êtes attaqué, ils ont tout intérêt à aider. Établir une relation avec des professionnels de la sécurité est un atout considérable.

Pratiques opérationnelles

Considérez la sécurité opérationnelle comme un indicateur de succès. Faites des exercices de phishing ; engagez (de façon fiable) une red team pour tester votre équipe contre l’ingénierie sociale. Préparez des hardware wallets et appareils de secours, pour pouvoir remplacer tout le multi-sig si nécessaire. Vous ne voulez pas faire cela en urgence le jour J.

Mesures d’atténuation

Votre voie de sortie, c’est la limite de perte

Le montant maximal que vous pouvez perdre via une voie donnée, en cas d’exploitation, doit être connu. En termes simples : une fonction de mint sans plafond par bloc, c’est un chèque en blanc pour toute émission infinie. Une fonction de redemption sans limite hebdom