Les leçons d'un milliard de dollars : la sécurité de la DeFi se concentre désormais sur la gestion opérationnelle plutôt que sur le code

Traduction : Communauté de la chaîne de validation

Résumé du contenu et introduction :

Près d’un milliard de dollars de pertes en DeFi au cours de la dernière année, les pertes importantes ne proviennent plus principalement de vulnérabilités dans le code des contrats intelligents, mais de risques liés à la gestion des permissions, aux processus de signature, aux attaques sociales, à l’infrastructure tierce et à la composabilité inter-chaînes. En s’inspirant de la résilience opérationnelle, des trois lignes de défense, du gel d’urgence, de la gouvernance des données de risque et de l’évaluation des accès aux actifs, couplé à une analyse de sécurité assistée par IA, on peut renforcer la sécurité des fonds utilisateurs tout en maintenant l’ouverture et la composabilité.

Nous n’aurions pas dû perdre ces milliards de dollars

Au cours des douze derniers mois, près d’un milliard de dollars ont été perdus à cause d’incidents en DeFi, mais la majorité aurait pu être évitée.

Commençons par le dernier exploit : le 18 avril, l’exploit de 292 millions de dollars de Kelp DAO.

AAVE a chuté de 15 %. Aave a gelé le marché rsETH déployé, puis a également gelé le prêt WETH par précaution. Le contrat d’Aave lui-même n’a jamais été exploité, mais en quelques heures, le taux d’utilisation du marché WETH d’Aave a atteint 100 %. Des fournisseurs de WETH, qui n’avaient jamais touché à rsETH, se sont soudainement retrouvés incapables de retirer leurs fonds.

Vint ensuite le discours classique sur Twitter : le pont est cassé. La DeFi est foutue. C’est pour cela que les vrais fonds ne rentrent pas.

Je pense que ces discours ne saisissent pas l’essentiel.

La majorité de ces pertes, ces 10 milliards de dollars, proviennent d’attaques dont les vecteurs avaient déjà été discutés et pour lesquels des solutions de réparation existaient. Les plus grosses pertes sont principalement dues à des accès privilégiés, des workflows de signature, des attaques sociales et à l’infrastructure tierce, et non à un bug isolé dans un smart contract. Cependant, ces solutions de réparation ne figurent pas dans la documentation DeFi, mais dans les manuels de gestion des risques bancaires, les études sur la résilience opérationnelle, et les playbooks opérationnels peaufinés au fil de dizaines d’années en finance traditionnelle.

Kelp en est l’exemple le plus clair.

Un vérificateur. Un point de défaillance.

L’exploit de Kelp n’est pas dû à un bug dans le contrat intelligent. La cause profonde réside dans le choix de @KelpDAO d’utiliser un réseau de validateurs décentralisés (DVN) en configuration 1-of-1 sur LayerZero. Selon les rapports, l’attaquant, lié au groupe Lazarus de la Corée du Nord, n’a pas compromis le DVN lui-même. Il a d’abord identifié quels RPC fournissaient le service pour LayerZero. Ensuite, il a compromis deux d’entre eux pour leur faire renvoyer de fausses données. Puis, il a lancé une attaque DDoS sur les autres, forçant le système à basculer vers ceux déjà compromis. Le DVN, en toute bonne foi, a signé un message cross-chain falsifié — faute d’autres vérificateurs pour valider le résultat, cette signature a suffi.

Un vérificateur. Un point de défaillance.

116 500 rsETH ont été libérés depuis l’OF T Adapter de LayerZero sur Ethereum (qui gère les tokens inter-chaînes), vers l’attaquant, ce qui a laissé les 16 autres OFTs sur Layer2 sans backing. L’attaquant a déposé en garantie du rsETH sur Ethereum dans Aave, Compound et Euler, puis a emprunté 236 millions de dollars en WETH, jusqu’à ce que la fraude soit découverte. Désormais, tous ceux qui détiennent du rsETH sur une Layer2 ne détiennent en réalité qu’une créance sur un coffre vidé.

Ce risque évident avait été identifié douze jours plus tôt.

Le 6 avril, l’ingénieure @liliangjya5, travaillant chez @get_truenorth, a publié un code open source nommé Claude Code skill, qui pointait le manque de transparence dans la configuration du DVN, identifiant la configuration monolithique à 16 chaînes comme le vecteur de risque principal, en la comparant à l’exploit du pont Ronin et Harmony en 2022. La date du commit est publique — tout le monde peut la voir.

[]

Kelp n’a jamais publié leur seuil de DVN. LayerZero recommande explicitement dans sa checklist d’intégration d’utiliser une configuration multi-DVN. Kelp a choisi le 1-of-1. Personne ne les a forcés à publier ou à modifier cette configuration.

Douze jours plus tard, 292 millions de dollars ont disparu.

Les douze derniers mois ne remettent pas en cause la DeFi

L’exploit de Kelp est le plus important, mais pas le seul.

• Il y a deux semaines, le 1er avril, Drift a perdu 285 millions de dollars après une attaque sociale qui a duré plusieurs mois. L’attaquant a utilisé des nonces durables de Solana pour obtenir des signatures d’administrateur valides, a mis en liste blanche un token sans valeur comme collatéral, et a ainsi siphonné des actifs réels. Au moins 20 autres protocoles ont signalé des impacts. Drift a lui-même intégré dans sa reconstruction post-incident des dispositifs de signature dédiés, un timelock pour les opérations administratives, et une gouvernance multisig reconstruite.

• Le 22 mars, Resolv a été attaqué via son infrastructure offchain. L’attaquant a pénétré le GitHub et l’environnement cloud d’un projet tiers, obtenant les droits de signature pour le minting, et a créé 80 millions de USR sans backing, volant 25 millions de dollars en ETH. Le contrat intelligent n’a pas été compromis, mais la faiblesse réside dans la clé privilégiée et la stack opérationnelle qui l’entoure.

• Le 10 mars, le tooling de risque d’Aave a déclenché environ 26 millions de dollars de liquidations suite à un décalage de configuration entre deux oracles, impliquant 34 comptes. Ce décalage a fait chuter le prix du wstETH de 2,85 %. Il n’y a pas eu d’acteur malveillant ni d’exploit dans ce cas. La perte provient d’une mise à jour de configuration bienveillante, mal testée en scénario hostile.

• Avant même 2026, on a connu Cetus sur Sui avec une perte de 223 millions de dollars, Cork qui a perdu 12 millions après plusieurs audits à cause de wstETH, Balancer qui a perdu plus de 120 millions en novembre, et Aerodrome qui a perdu plus d’un million à cause d’un DNS hijack du registrar, sans que le contrat lui-même ne soit compromis. La dernière attaque a été une attaque de phishing sur la page web.

Au total, cela représente presque 10 milliards de dollars de pertes. La cause immédiate de chaque incident diffère, mais un schéma se dessine.

Ces exploits ont migré hors chaîne

Le risque dans les contrats intelligents n’a pas disparu — Cetus, Cork et Balancer ont tous échoué sur la logique on-chain. Tout protocole qui considère encore que l’invariance, la simulation adversariale ou la vérification formelle sont optionnels finira par apprendre la leçon, mais ce n’est plus l’histoire principale.

Dans l’ensemble de la crypto, Chainalysis estime qu’en 2025, plus de 6,5 milliards de dollars auront été volés, dont 69 % par les trois plus grands hacks. Comme mentionné plus tôt, la majorité des pertes provient des accès privilégiés, des workflows de signature, des attaques sociales et de l’infrastructure tierce, et non de bugs isolés dans les smart contracts.

Je vois cela comme trois modes d’échec distincts : Couche code, Plan de contrôle, Composabilité.

2. Code est la couche où la DeFi est en réalité la plus compétente pour se défendre, mais même là, ce n’est pas encore totalement résolu. Nous disposons de fuzzing, d’analyses statiques et dynamiques, de vérification formelle, de bug bounty, d’audits, d’invariance — chaque équipe sérieuse sait comment faire tout cela.

3. Plan de contrôle est la partie où la DeFi accuse au moins dix ans de retard sur la finance traditionnelle. Dispositifs de signature, rotation des clés, revue des accès privilégiés, provenance CI/CD, sécurisation DNS, sécurité des registraires. La plupart des protocoles n’ont même pas inventorié ces surfaces, encore moins les contrôler.

4. Composabilité est l’un des plus grands atouts de la DeFi, mais elle introduit aussi le risque le plus récent et sous-estimé : lorsqu’un marché de prêt liste un actif wrapped, il transforme le mode de défaillance du pont en défaillance propre. Lorsqu’un position de dette collatéralisée accepte un token de staking liquide, il hérite du retard de gouvernance de l’émetteur. Aave n’a pas écrit une seule ligne de code de Kelp, mais a subi les conséquences de son échec — ce qui révèle aussi ses propres problèmes de gouvernance.

Si un protocole liste un actif dont il ne peut pas évaluer, geler, appliquer un haircut ou liquider de façon indépendante en situation de stress, il transfère en réalité le tail risk de cet actif dans son bilan, que le treasury ait signé ou non.

La finance traditionnelle a déjà écrit le playbook

Sur le débat pour rendre la DeFi “plus comme la TradFi”, la tendance est souvent à la déviation. L’intuition dans la crypto est que devenir plus comme la TradFi signifie plus lent, plus custodial, plus permissionné, plus réglementé.

[]

Je pense que c’est faux.

Bien que la TradFi ne soit pas parfaite, elle a inventé des outils bien plus utiles que le permissioning. Elle a conçu des frameworks pour faire fonctionner des systèmes critiques en cas de disruption — ces cadres existent déjà. Ils ont été éprouvés par des décennies de faillites bancaires, d’interruptions de marché, d’attaques cyber et d’incidents opérationnels.

Exemples :

• NIST Cybersecurity Framework 2.0 élève la gouvernance au même niveau que l’identification, la protection, la détection, la réponse et la récupération.

• Basel Committee on Banking Supervision définit la résilience opérationnelle comme la capacité à assurer les opérations critiques en cas de disruption.

• Financial Conduct Authority (FCA) du Royaume-Uni exige que les entreprises identifient leurs services essentiels, fixent des tolérances d’impact, et testent si une disruption dépasse ces seuils.

• Institute of Internal Auditors, via son modèle des Trois Lignes, sépare la gestion, la gestion des risques et l’assurance indépendante.

Tout cela ne nécessite pas de bilan, ni de permission. Tout cela peut être transposé en DeFi. Un DeFi sécurisé ne signifie pas devenir une banque, mais adopter une discipline bancaire au niveau du contrôle tout en maintenant l’ouverture et la composabilité pour l’utilisateur.

Lorsque Lazarus s’attaque aux RPC providers de LayerZero, ils utilisent le même playbook que pour attaquer SWIFT ou la supply chain des logiciels d’entreprise. La finance traditionnelle a trente ans d’expérience dans ce domaine. Pourtant, la DeFi semble penser qu’elle n’a rien à apprendre de l’histoire de la finance.

Le pouvoir privilégié est une utilité systémique critique

Les privilèges doivent être plus difficiles à utiliser que les fonctions classiques du protocole. Toute clé, multisig ou compte de service capable de déposer des collatéraux, déplacer des réserves, mettre à jour un oracle, changer un pair de pont ou modifier la logique de liquidation, constitue une utilité financière systémique. Le minimum :

• Portefeuilles matériels

• Authentification anti-phishing

• Machines de signature indépendantes

• Décodage hors bande des transactions

• Quorum séparé

• Mise en place d’un timelock pour toutes les opérations non urgentes

• Rejet explicite des fonctionnalités facilitant la signature dormante, pouvant être exploitées à terme

La reconstruction post-incident de Drift constitue une bonne référence minimale.

L’infrastructure offchain fait aussi partie du protocole. La gestion du code source, le CI/CD, l’IAM cloud, les registres de packages, les domaines, le DNS, la surface WalletConnect, et le front-end livré par navigateur, sont tous dans la zone de menace réelle. Les standards d’ingénierie incluent le principe du moindre privilège, l’authentification hardware, le déploiement sans secret, la construction reproductible avec un software bill of materials, et le pinning des dépendances. À la frontière, le verrouillage du registrar, le durcissement DNS et le miroir décentralisé du front-end peuvent assurer la continuité en cas d’incident.

Le cas du DNS hijack d’Aerodrome nous rappelle que la frontière de sécurité est bien plus large que ce que la plupart des équipes pensent.

Chaque changement doit être testé dans un scénario hostile. Le vérificateur inter-chaînes doit vérifier la preuve, pas l’attestation. La bridge canonique doit valider la preuve de merkle signée dans les block headers — une garantie cryptographique : un nœud compromis peut refuser de fournir des données, mais ne peut pas en falsifier. La vérification de preuve est plus forte que l’attestation, mais le pont basé sur l’attestation hérite du risque de consensus, d’implémentation et de mise à jour. La question est : quels échecs sont exclus, lesquels sont conservés ?

Les vérificateurs basés sur l’attestation ne garantissent pas la même sécurité. Ils signent tout ce que renvoient les endpoints RPC, ce qui en fait une surface d’attaque. Si l’attestation est utilisée pour la rapidité ou la compatibilité chaîne, alors le quorum doit représenter l’indépendance, pas le nombre. Cinq validateurs lisant la même RPC empoisonnée signeront la même fausse information cinq fois. La sécurité n’est assurée que si les membres du quorum disposent de sources de données réellement indépendantes, idéalement en mélangeant nœuds privés et publics de confiance. Kelp exploite cette faille.

Tous les collatéraux ne méritent pas d’entrer dans un bilan partagé. Les actifs de pont, tokens de restaking liquide, parts de vault, dollars synthétiques et tokens wrappers doivent être traités comme des produits structurés. Ils nécessitent un mémo d’intégration indépendant, avec une évaluation complète des risques et des limites prudentes. La majorité du temps, ils doivent être isolés dans des marchés séparés, plutôt que dans un pool central partagé.

Déjà en avril 2025, Aave avait suspendu le rsETH suite à une erreur d’over-minting de Kelp. Un an plus tard, le rsETH est revenu sur le marché partagé, ce qui mérite une analyse plus rigoureuse.

La détection et la réponse doivent fonctionner à la vitesse machine. Lorsqu’un protocole peut être vidé en quelques minutes, la seule intervention humaine est une mise en scène de gouvernance. L’automatisation limitée doit être la norme : détection d’anomalies sur les opérations administratives, mint et burn, utilisation excessive, défaillance d’oracle, trafic pont, couplée à des rate limits natifs, des throttles de prêt, et des déclencheurs conditionnels prévus à l’avance, révisables par gouvernance, avec un périmètre restreint et une auto-activation en cas d’incident.

Il faut commencer à prioriser la sécurité des fonds utilisateurs. Le léger inconfort causé par ces automatisations ponctuelles est bien moindre que le coût initial de leur absence.

La gouvernance doit définir ce qui ne peut pas échouer

Pour aider les équipes à définir leurs objectifs de sécurité, la gouvernance doit préciser ce qui ne doit absolument pas échouer. Le conseil d’administration, la fondation ou le DAO doivent clairement lister leurs services essentiels : dépôts et retraits, liquidations, mise à jour des oracles, exécution de la gouvernance, ponts entrants et sortants, accès front-end, communication en cas d’incident.

Pour chaque service, il faut définir une tolérance d’impact, incluant le maximum de dommages utilisateur tolérables, la perte de capacité de paiement, le temps d’indisponibilité et l’incertitude des données, puis tester si ces seuils restent valides dans des scénarios graves mais plausibles.

C’est la définition même de la résilience opérationnelle en banque, et cela peut être directement transposé à la DeFi.

La DeFi doit adopter un vrai modèle des Trois Lignes :

• La première ligne : produits, ingénierie, trésorerie et opérations responsables des risques qu’ils créent et des contrôles pour les atténuer.

• La deuxième ligne : fonctions indépendantes de gestion des risques et de sécurité, avec des pouvoirs clairs, qui challengent la liste des actifs, paramètres, upgrades et contreparties, et ralentissent ou bloquent les changements non sécurisés.

• La troisième ligne : un audit indépendant qui vérifie que la première et la deuxième ligne jouent leur rôle.

L’indépendance est la clé pour empêcher la croissance de l’incitation à se donner des autorisations en auto.

L’onboarding d’actifs doit ressembler davantage à une souscription de crédit qu’au développement commercial. Le mémo de listing doit couvrir la liquidité, la centralisation de la gouvernance, le chemin du pont et la capacité d’upgrader, le mécanisme de rachat, le circuit breaker, la construction de l’oracle, et l’aspect juridique. Si l’un de ces aspects est compromis, le mémo doit prévoir une procédure claire de dégradation.

Les permissions d’urgence doivent être limitées, préalablement définies, avec une date de sunset. Les votes de récupération sur Cetus ou Sui illustrent deux aspects : une intervention d’urgence peut sauver plusieurs centaines de millions de dollars. Mais cela soulève aussi une question cruciale : qui peut intervenir pour couvrir ces systèmes théoriquement invulnérables, et selon quels critères ? La réponse doit être définie avant la crise, en précisant les conditions de déclenchement, les acteurs autorisés, les preuves requises, la durée maximale, la transparence, et la procédure de retour à la gouvernance normale.

Chaque protocole doit prévoir un plan de résolution en cas de crise. Drift construit un recovery pool après coup. Aave a commencé à indemniser les utilisateurs après le décalage d’oracle. Resolv a remboursé en 1:1 les détenteurs avant l’attaque. Ce sont des réponses raisonnables, mais la norme supérieure consiste à prévoir à l’avance une hiérarchie d’intervention : priorité à la protection des utilisateurs, puis à la réserve du treasury, puis à l’assurance ou au module de sécurité, puis à la responsabilité du prestataire, avec des seuils clairs pour la perte socialisée.

Il faut distinguer les protocoles qui prennent la gouvernance au sérieux de ceux qui ne la prennent pas. Trois questions : qui peut bloquer un lancement non sécurisé ? Qui peut geler un marché sous conditions prédéfinies ? Et quand un prestataire délégué cause une perte, qui paie ?

Un protocole incapable d’identifier ses responsables, ses conditions de déclenchement et ses responsabilités n’a pas vraiment défini sa gouvernance, il prie simplement pour que l’exploit ne se produise jamais.

Les données de risque déterminent la réussite ou l’échec des contrôles

Une DeFi sûre nécessite un data plane en temps réel : des signaux onchain et offchain qui pilotent chaque gel, plafond et liquidation. Le control plane agit, le data plane indique s’il doit agir.

Les standards de données et leur qualité sont tout aussi cruciaux. Les données alimentant oracles, gels ou paramètres doivent avoir une fenêtre de fraîcheur claire, une provenance enregistrée, un score de confiance, et faire l’objet d’une validation croisée avec des feeds indépendants. En cas de divergence, le comportement de secours doit être défini à l’avance, pas improvisé.

Aave a proposé un oracle géré par risque pour USDe, ainsi qu’un Risk Oracle Slope2 pondéré dans le temps, qui vont dans la bonne direction. L’incident wstETH nous rappelle que chaque boucle de contrôle automatique doit avoir des garde-fous contre ses propres erreurs de configuration.

La transparence est aussi une forme de contrôle. Les utilisateurs doivent disposer d’une page de statut publique, d’une watchlist d’adresses d’attaquants, d’un journal d’incidents en temps réel, d’un communiqué initial rapide et factuel, et d’un rapport post-mortem distinguant faits avérés et hypothèses, quantifiant précisément les pertes, listant les contrôles modifiés, et expliquant la voie de compensation. Les mises à jour de Drift, le post-mortem de Resolv et la documentation d’Aave sur l’oracle sont déjà bien meilleures que les tweets flous et silencieux d’autrefois. La norme de l’industrie doit être un playbook de communication testé en amont.

Les données de risque ont pour but de déclencher l’action. Limiter les prêts, réduire les plafonds, suspendre un marché, faire une mise à jour manuelle, prouver qu’un marché peut continuer à fonctionner en toute sécurité. Les analyses qui ne peuvent pas alimenter le control, le limit ou l’assurance ne méritent pas leur nom d’infrastructure de risque.

La menace de l’IA a changé

En avril 2026, le modèle de menace de l’IA a évolué. Claude Mythos Preview d’Anthropic a été prouvé capable d’identifier et d’exploiter toutes les vulnérabilités zero-day dans les principaux systèmes d’exploitation et navigateurs. Plus de 99 % des vulnérabilités découvertes ne sont pas encore publiques, car personne ne leur a encore appliqué de patch. Les banques et régulateurs britanniques, américains et allemands considèrent désormais que le niveau de menace Mythos est une réalité cybernétique.

Les protocoles DeFi doivent faire pareil.

D’un point de vue pratique, le spear-phishing est moins cher, le développement d’exploits plus rapide, la reconnaissance plus autonome, et les cas marginaux à faible signalement seront détectés plus tôt. La défense doit inclure :

• Des stations de travail renforcées comme des endpoints privilégiés

• Des revues de code sous contrôle avec analyse adversariale assistée par IA

• Des workflows de signature par défaut avec protection anti-phishing

• La détection d’anomalies et la réponse automatique limitée, en supposant que l’attaquant peut agir plus vite qu’une équipe humaine

L’histoire de Kelp illustre une version optimiste de cette réalité. La même IA capable de menacer un protocole peut aussi le défendre. Un outil d’audit open source tournant sur Claude Code a identifié, douze jours avant l’attaque, le risque précis de Kelp. Cet outil n’est pas parfait : il a classé le risque comme moyen, alors qu’il aurait dû être critique ; il ne peut pas analyser la configuration sans vérification onchain ; et il a aussi omis une possibilité : la configuration du DVN peut être consultée via les contrats EndpointV2 de LayerZero.

Mais il a posé les bonnes questions que d’autres n’ont pas envisagées.

C’est le modèle qu’il faut adopter. L’IA comme couche de sécurité indépendante, que tout LP, tout protocole ou tout auditeur peut utiliser pour devancer l’argent.

La DeFi sûre ne signifie pas une DeFi lente

Après l’incident Kelp, la vision dominante est que la DeFi a un problème de sécurité. Je pense que ce cadre est erroné.

La DeFi souffre de problèmes de plan de contrôle, de tarification de la composabilité, et de discipline de gouvernance. La plupart de ces solutions existent déjà dans les manuels de gestion des risques bancaires depuis trente ans. La seule barrière à une sécurité accrue est la volonté des fondateurs de les mettre en œuvre.

Une DeFi sûre ne signifie pas une DeFi lente. “Slow” et “safe” sont deux attributs distincts. L’accès ouvert pour l’utilisateur, la composabilité, la compensation 24/7 mondiale ; la discipline bancaire, le challenge indépendant, la vitesse machine, et l’assurance continue — ces éléments peuvent coexister.

Les outils existent. Les playbooks existent. Les capitaux pour une DeFi sûre existent déjà.

La DeFi ne fait que commencer. Assurons-nous qu’elle sera encore là dans dix ans.