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

Écrire : sysls

Compiler : 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 à un jeu à très long terme ; ces super-vilains se concentrent à scruter chaque recoin de votre protocole et infrastructure pour y déceler 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 la finance 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 se disant « 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 des données :

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 de hackers DeFi jamais enregistrées, et alors que le deuxième trimestre ne fait que 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, risquent de se faire « tuer en une seconde ».

Penser en surface et en hiérarchie

(Source des données :

La surface d’attaque réelle peut être réduite à trois éléments : 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. Dès qu’une attaque est confirmée, il faut activer 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, 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 telles que 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 des étapes et des verrouillages temporels à toute opération susceptible de causer des dommages. Il faut suffisamment de temps pour intervenir et geler en cas d’anomalie.

Les objections passées aux verrouillages temporels et aux processus à étapes multiples é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 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 remonter prudemment dans le 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 un multisig est attaqué, 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 sauvetage (qui restaure la stabilité gouvernable, sans pouvoir 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’ingénierie sociale, et une nouvelle 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 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 piraté. Codifiez autant que possible ces processus, et entraînez votre équipe. Avec l’ère de l’IA, cela implique de maîtriser des compétences et des algorithmes capables de produire rapidement une masse 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 d’être parfait, mais vous devez survivre. 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 de non-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 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 couronne que cette fonction doit maintenir. Beaucoup d’attaques par CEI (Checks-Effects-Interactions) (flash loans, liquidation via oracles, drainages inter-fonctions) peuvent être capturées par ces vérifications en fin de fonction.

De bons tests

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.

Utiliser des invariants pour affirmer que certaines 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 tiennent 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 le choix à l’utilisateur : qui ou 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éfaillance des oracles et 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 sur une infrastructure hors de leur audit.

Attaques de surface

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

Avoir une capacité native de sauvetage

Dans une gouvernance basée sur le vote, le pouvoir est initialement concentré dans le multisig 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éployer un « portefeuille gardien », avec des autorisations strictes : ils ne peuvent que suspendre le protocole, et en cas de seuil ≥4/7, ils peuvent, 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 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 topologies de clés

Les multisigs sont indispensables, avec un minimum de 4/7. Personne ne doit contrôler tous 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 de signature pour naviguer sur Internet, envoyer des mails ou ouvrir Slack, cela signifie que le signataire est compromis.

Avoir plusieurs multisigs, chacun pour une utilisation différente. Supposez qu’au moins un multisig sera compromis, et planifiez en conséquence. Personne 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 en rapport avec la TVL du protocole ; même pour