Que s'est-il passé exactement ?
Bitcoin Core, l'implémentation logicielle la plus utilisée du réseau Bitcoin, a modifié sa politique de sécurité selon des rapports concordants de Decrypt, CoinDesk et Cointelegraph. Désormais, pour les vulnérabilités qualifiées de "facilement détectables" (easily discoverable), les développeurs intégreront immédiatement les correctifs (ce qu'on appelle le backport) et publieront de nouvelles versions, au lieu de les maintenir sous un long embargo.
L'embargo est une période durant laquelle les informations sur une faille restent secrètes, afin que les attaquants n'obtiennent pas un mode d'emploi avant que les utilisateurs ne soient protégés. Cette logique ne fonctionne que si la faille est difficile à découvrir. Selon CoinDesk et Cointelegraph, Bitcoin Core fait valoir que pour une partie des failles, le secret n'apporte plus une grande protection.
Pourquoi les développeurs font-ils cela maintenant ?
Le déclencheur clé est l'arrivée d'outils d'IA capables de chercher des failles dans le code. Selon CoinDesk, l'IA a révélé au cours de l'été des centaines de bugs Bitcoin avant les humains. Decrypt décrit le cœur du problème ainsi : si un attaquant peut redécouvrir une faille avec un simple prompt adressé à un chatbot, alors un long secret ne fait que prolonger la période pendant laquelle les utilisateurs sont vulnérables, sans réellement les aider.
Autrement dit, l'avantage dont bénéficiaient autrefois les défenseurs (le fait que la faille soit "cachée") se réduit avec les outils d'IA. Lorsque la découverte d'une faille devient triviale pour quiconque a accès au modèle, publier rapidement un correctif est plus sûr que d'attendre.
Que signifie exactement "facilement détectable" ?
Ici, il faut être précis. Les sources décrivent une nouvelle approche pour les failles classées comme facilement détectables, dont on suppose qu'un attaquant peut les retrouver avec un effort minimal. La manière exacte dont Bitcoin Core classera chaque faille dans cette catégorie et qui en décide ne ressort pas clairement des sources disponibles. Cela reste pour l'instant flou.
De même, il n'apparaît pas clairement dans les sources citées si la procédure change pour les vulnérabilités plus complexes, que l'IA ne détecte pas encore couramment. Pour celles-ci, la divulgation coordonnée et l'embargo peuvent conserver leur sens.
Comment cela s'inscrit-il dans le tableau plus large de la sécurité ?
Le contexte plus large de l'année est tendu. The Block a rapporté sur la même période que le réseau Initia avait suspendu son activité après un incident de sécurité, l'attaquant ayant prétendument frappé des tokens, et les données on-chain ayant montré un transfert d'ether d'une valeur d'environ 2,7 millions de dollars. Il s'agit d'un autre projet et d'un autre type d'incident que le changement de politique de Bitcoin Core, mais cela illustre l'environnement dans lequel se décide la rapidité de réaction face aux vulnérabilités.
Attention à la causalité : rien dans les sources ne relie directement l'incident d'Initia au changement des règles de Bitcoin Core. Ce sont deux événements distincts survenus la même semaine.
Ce qu'il faut surveiller ensuite pour ce type de changement
- Comment fonctionnera en pratique la classification des failles "facilement détectables" et avec quelle transparence les développeurs la rendront publique.
- Si une publication plus rapide des correctifs entraînera des mises à jour plus fréquentes des nœuds et comment les opérateurs y réagiront.
- Si d'autres grands projets (pas seulement Bitcoin) adapteront leurs politiques de divulgation dans un sens similaire à cause de l'IA.
Charliedesk ne donne aucune recommandation sur ce qu'il faut faire avec un quelconque actif. Ceci est une description de ce qui s'est passé et de la raison pour laquelle, selon les sources, les développeurs l'ont fait.