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

Écrire par : sysls

Compiler : AididiaoJP, Foresight News

Lien vers l’article original :

Déclaration : Cet article est une reproduction, les lecteurs peuvent obtenir plus d’informations via le lien original. Si l’auteur a des objections concernant la reproduction, veuillez nous contacter, nous modifierons selon ses demandes. La reproduction est uniquement destinée au partage d’informations, ne constitue pas un conseil en investissement et ne reflète pas le point de vue ou la position de Wu.

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 à examiner chaque recoin de votre protocole et infrastructure 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 dans 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, des attaques ont lieu. Nous devons faire mieux.

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

(Source :

Les attaques de pirates 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 de piratage DeFi jamais enregistrées, et alors que le deuxième trimestre ne fait que commencer, il semble déjà prêt à battre ce record.

Ma 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 examiner 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 qui comptaient sur des mesures de sécurité avant que l’IA ne devienne puissante sont de plus en plus exposés au risque d’être « balayés en une seconde ».

Penser en surface et en hiérarchie

(Source :

La surface d’attaque réelle peut ê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’étendue des dégâts.

Pause : personne ne peut prendre la meilleure décision sous une pression extrême. En cas d’attaque confirmée, il faut activer immédiatement le « kill switch » 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, il faut l’abandonner et le remplacer.

Rétablissement : récupérer ce qui a été perdu. Prévoir à 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.

Utiliser massivement l’IA de pointe

Utiliser massivement des modèles d’IA avancés pour scanner votre code et configuration, rechercher des vulnérabilités, et effectuer des tests de red team à grande échelle : essayer 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.

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

Le temps et la friction sont de bonnes défenses

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

Les objections passées à l’utilisation de verrous temporels et de processus multi-étapes étaient que cela créait de la friction pour l’équipe du protocole. Aujourd’hui, ce n’est plus un problème : l’IA peut facilement passer outre ces frictions 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 faire remonter prudemment au niveau du code ; imposer plusieurs invariants dans chaque fonction devient difficile à gérer.

Équilibre du pouvoir

Beaucoup d’attaques proviennent de portefeuilles compromis. Il faut une configuration permettant, même si un multi-sig est compromis, de rapidement limiter 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 secours (qui permet de restaurer la stabilité gouvernable, sans pouvoir renverser la gouvernance elle-même).

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’ingénierie sociale, et une mise à jour peut introduire des vulnérabilités inattendues.

En pensant ainsi, les limiteurs de dégâts, les verrouillages et les disjoncteurs deviennent vos meilleurs alliés. Limitez les dégâts à 5-10 %, puis suspendez, puis 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 les processus, et entraînez votre équipe pour ne pas être pris au dépourvu lors de l’impact. À l’ère de l’IA, cela signifie maîtriser des compétences et des algorithmes capables de présenter rapidement une grande quantité d’informations, puis de les résumer et de les partager en long et en large 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 des itérations successives, vous deviendrez résilient en tirant des leçons.

L’absence de preuve de 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, faites-en des vérifications à l’exécution. Réfléchissez soigneusement à ceux qui méritent d’être réellement imposés.

C’est le mode FREI-PI (Fonction Requirements, Effects, Interactions, Protocol Invariants) : à la fin de chaque fonction touchant à la valeur, revérifiez l’invariant de la couronne que cette fonction doit maintenir. 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 fuzz tests à état (Stateful fuzzing) génèrent des séquences d’appels aléatoires sur la surface publique du protocole, en affirmant les invariants à chaque étape. La plupart des vulnérabilités en production sont multi-transactionnelles, et le fuzzing à état est presque la seule méthode fiable pour découvrir ces chemins avant les attaquants.

Utiliser 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. Couplé à 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 étend 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 de défaillance unique ne puisse détruire votre protocole.

Étendez la portée des audits pour couvrir la simulation de défaillances d’oracles et de dépendances, et imposez des limites de taux pour les scénarios où leur défaillance pourrait causer des catastrophes.

Le récent bug de KelpDAO en est un exemple : ils ont hérité de la configuration LayerZero requiredDVNCount=1, hors de leur périmètre d’audit. La faille a été exploitée dans l’infrastructure hors chaîne qui n’était pas auditée.

Attaques de surface

La majorité des surfaces d’attaque dans la 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.

Avoir une capacité native de secours

Dans une gouvernance basée sur le vote, le pouvoir est initialement concentré dans le multi-sig de l’équipe, ce qui prend du temps à se diffuser. Même si la distribution de tokens est large, 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éployer 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 exécuter de propositions 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 peut être progressivement éliminée.

Portefeuilles et topologie des clés

Les multi-sigs sont indispensables, avec un seuil minimum de 4/7. Aucun individu ne doit contrôler tous les 7 clés. Effectuez des rotations fréquentes des signataires, discrètement.

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

Avoir plusieurs multi-sigs, chacun pour une utilisation différente. Supposez qu’au moins un multi-sig complet sera compromis, 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 primes

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

Face à des acteurs étatiques, ils ne négocieront peut-être pas, mais vous pouvez 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 (en réalité, une prime payée par les déposants).

Trouver de bons auditeurs

J’ai déjà écrit que, avec l’avènement 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 permet de découvrir efficacement de nouvelles vulnérabilités. Vous ne voulez pas être le premier à laisser une vulnérabilité unique.

Ensuite, un avantage sous-estimé est : engager un auditeur, c’est aussi utiliser leur réputation comme garantie. S’ils signent et approuvent, et que vous êtes attaqué, ils ont un fort intérêt à 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 (de confiance) une red team pour tester votre équipe en ingénierie sociale. Préparez des hardware wallets et appareils de secours pour remplacer tout le multi-sig si nécessaire. Vous ne voulez pas devoir acheter tout cela dans l’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 en cas de vulnérabilité est la perte théorique maximale. En clair : une fonction de mint sans limite par bloc, c’est un chèque en blanc pour toute vulnérabilité de mint infini. 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 l’expérience utilisateur extrême. En cas de problème, c’est ce qui vous évitera la destruction totale.

Liste blanche (et liste noire)

La plupart des protocoles disposent de listes de comptes autorisés à appeler, échanger ou recevoir, et de listes d’interdiction pour certains utilisateurs. Même implicites, ces frontières de confiance doivent être formalisées.

Formaliser permet de mettre en place un mécanisme à 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 signifie que pour introduire un vecteur d’attaque, il faut compromettre deux processus : le marché doit autoriser (listing / listing), et l’action ne doit pas être interdite (examen de sécurité).

Récupération

Surveillance algorithmique

Sans surveillance, le kill switch est inutile. Les moniteurs hors chaîne doivent surveiller en continu les invariants, et en cas de problème, déclencher une alerte automatisée. La dernière étape doit revenir à l’humain, via un multi-sig de gardiens, avec suffisamment de contexte pour qu’ils puissent décider en quelques minutes.

Se recalibrer

En cas d’attaque, il faut d’abord arrêter l’hémorragie, pas prendre de décisions dans la précipitation. Pour un protocole, cela correspond au kill switch (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 « tout suspendre » qui énumère tous les composants pouvant être suspendus et les met en pause de façon atomique.

Seul la gouvernance peut lever la suspension, donc le kill switch ne doit pas pouvoir suspendre le contrat de gouvernance lui-même. Si la couche de gardiens peut suspendre le contrat de gouvernance, un gardien compromis pourrait le bloquer définitivement.

Lancez votre 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. Limitez la taille pour éviter la fuite d’informations vers l’extérieur, les attaquants ou les arbitrages 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 suspendre ; une personne pour analyser la vulnérabilité et en identifier la cause ; un interlocuteur pour communiquer avec les parties clés ; une personne 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é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 un prélude à une attaque plus large. L’attaque peut viser à vous faire faire une erreur fatale, déclenchant la vraie faille.

La suspension doit être pleinement contrôlée, et l’ensemble du protocole doit être gelé. Vous ne souhaitez pas être induit en erreur pour suspendre un composant, tout en laissant une autre vulnérabilité ouverte. Une fois la cause et la vecteur 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

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 des attaquants pour remplacer un gardien ou un portefeuille de gouvernance sain par un compromis. Cela rejoint la philosophie de la liste blanche / liste noire 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 permet aussi d’évaluer en amont la qualité du successeur : prendre le temps, faire une due diligence, rencontrer la personne.

Tester prudemment avant la mise à jour

Une fois la cause et l’impact compris, il faut déployer la mise à jour. C’est souvent la partie la plus risquée : écrire du code sous pression, en ciblant un attaquant qui a déjà prouvé sa connaissance de 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 pour un dernier examen adversaire.

Rétablissement

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 outils comme Chainalysis pour suivre en temps réel les adresses des attaquants, et alerter les exchanges lors de leur transfert inter-chaînes.

Préparez une liste de partenaires tiers capables de geler des fonds ou de bloquer des messages cross-chain : exchanges, gestionnaires de ponts, custodians, etc.

Négociation

Oui, c’est douloureux, mais il faut tenter de dialoguer avec l’attaquant. Beaucoup de choses dans la vie peuvent se régler par la négociation. Offrez une prime blanche limitée dans le temps, et publiez une déclaration indiquant qu’en cas de restitution totale avant la date limite, aucune action légale ne sera engagée.

Face à des acteurs étatiques, la négociation peut être difficile, mais si l’attaquant est moins expérimenté, il cherche simplement à exploiter votre protocole pour en tirer profit à moindre coût.

Avant cela, consultez un conseiller juridique.

Conclusion

Les attaques ne cesseront pas, et avec l’IA plus intelligente, elles deviendront plus nombreuses. Se contenter de rendre les défenseurs « plus vigilants » n’est pas suffisant. Nous devons utiliser les mêmes outils que les attaquants, faire du red team sur nos protocoles, surveiller en permanence, et imposer des limites strictes aux dégâts pour survivre dans le pire des cas.