16 août, l’équipe Dusk a de nouveau détecté une activité anormale liée à des portefeuilles de pontage. Elle a d’urgence suspendu le service de pont, récupéré les adresses concernées et ajouté une liste noire pour bloquer l’accès via le web wallet. L’équipe officielle a ensuite confirmé qu’aucun fonds utilisateur n’avait été affecté. Ma première réaction en le lisant n’a pas été « encore une fois, on a évité le pire », mais « c’est déjà la deuxième fois en l’espace de six mois ».

Je me souviens très bien de l’incident de janvier : là encore, c’était un portefeuille de signature côté équipe, et la couche principale elle-même n’avait rien. Le problème venait de ce « travail géré par des humains » autour du protocole, qui faisait tourner le tout. En août, cette fois encore, les détails semblaient presque sortis du même moule : le système de surveillance a détecté l’anomalie, a suspendu le service, a coordonné le blocage, sur les exchanges, des flux de fonds suspects, puis a ajouté une liste noire après coup. Les deux procédures de réponse aux incidents sont plutôt professionnelles et la réactivité n’est pas mauvaise. Mais ce qui m’importe davantage, c’est autre chose : le fait qu’un même type de problème se reproduise deux fois en six mois signifie que la « consolidation » réalisée après le premier incident n’était peut-être qu’un emplâtre, sans résoudre la cause profonde.

Je travaille dans ce secteur depuis des années : j’ai vu trop d’équipes, lors de la gestion d’un incident de sécurité, mettre toute l’attention sur « combien avons-nous perdu » et « à quelle vitesse avons-nous colmaté ». En revanche, très peu de gens sont prêts à répondre à une question plus gênante : pourquoi une vulnérabilité de même nature réapparaît-elle une deuxième fois dans le même système d’exploitation ? Dire une seule fois que « la couche protocolaire ne pose aucun problème » peut convaincre. Mais le dire deux fois devrait faire naître un doute. Ce n’est pas un doute sur la capacité technique de Dusk, c’est un doute sur l’ensemble des disciplines opérationnelles qui entourent le service de pont : gestion des clés, validation multi-signature, réponse de surveillance.

Cette fois, il n’y a eu aucune perte de fonds. C’est peut-être de la chance, ou alors les procédures ont vraiment été renforcées : pour l’instant, on ne peut pas encore le dire. Mais pour une chaîne qui cherche à attirer des capitaux institutionnels, le département de conformité n’observe jamais seulement « est-ce que quelque chose est arrivé ». Il regarde plutôt « combien de fois le même piège a été évité en marchant dedans ». Ce dossier, je vais continuer à le garder en mémoire.

Pensez-vous que, pour un même type d’incident de sécurité, le fait qu’il se reproduise deux fois en six mois relève d’une fluctuation normale due à une « consolidation opérationnelle continue », ou faut-il au contraire y voir un signal d’alarme ?
@Dusk $DUSK #dusk
A. 该敲警钟,复现本身就是信号
50%
B. 算正常,只要没损失就不算大问题
50%
C. 得看具体加固措施有没有真落地,不能只看有没有复现
0%
4 Votes • Vote fermé