Bitcoin Core a mis à jour sa politique de sécurité pour gérer les vulnérabilités « facilement détectables », citant une hausse des signalements de bugs que les grands modèles de langage (LLM) ont « drastiquement abaissé le seuil » pour trouver. Pour ces failles, le projet appliquera désormais un correctif rétroactivement à toutes les versions maintenues et publiera une nouvelle version aussi rapidement que possible—accompagnée d'un avis de sécurité—plutôt que de maintenir le problème sous un long embargo, une correction discrète « apporterait peu » alors qu'un scan par IA peut la révéler de toute façon.

La mise à jour de la politique a été fusionnée jeudi, après que le développeur de Chaincode Labs Antoine Poinsot l'a ouverte plus tôt ce mois-ci dans une pull request sur le dépôt bitcoincore.org, citant une hausse des signalements de bugs « facilement (re)détectables ». La raison, a écrit Poinsot, est que les grands modèles de langage ont « drastiquement abaissé le seuil » pour trouver certaines classes de problèmes—ou pour repérer dans le code un correctif intégré discrètement. En pratique, ce changement reconnaît que l'IA a rendu certaines vulnérabilités si faciles à trouver que les garder secrètes n'a plus de sens.

Cette évolution cible une tension au cœur de toute politique de divulgation. Bitcoin Core, l'implémentation logicielle qui fait tourner la plupart des nœuds soutenant le réseau Bitcoin, a longtemps privilégié une longue période d'embargo—la convention open source consistant à garder les rapports de failles privés jusqu'à ce qu'un correctif soit prêt—en maintenant les correctifs de sécurité discrets et en les gardant souvent jusqu'à la prochaine version majeure. Cette approche prudente reflète la culture de mise à niveau notoirement lente de Bitcoin, où précipiter les opérateurs de nœuds dans une mise à jour comporte ses propres risques. Mais les développeurs ont conclu que pour les bugs qu'un attaquant peut révéler avec une seule requête IA, un long embargo « apporte peu mais retarde la disponibilité d'une version corrigée ». Une version corrigée qui arrive plus tôt réduit la durée pendant laquelle une faille connue reste exploitable sur les nœuds du réseau.

Selon la nouvelle politique, Bitcoin Core peut marquer une vulnérabilité signalée comme « facilement détectable », une étiquette qu'il s'attend à appliquer aux problèmes trouvables via une simple requête LLM. Pour ceux-ci, le projet appliquera un correctif rétroactivement à chaque version maintenue et publiera une nouvelle version aussi rapidement que possible, en publiant les détails dans un avis de sécurité—un document public décrivant la faille et son correctif—aux côtés du logiciel corrigé plutôt que de garder le changement secret. La logique, comme l'a formulé Poinsot dans la discussion, est que corriger discrètement un tel bug « apporterait peu », puisqu'un scan IA trivial peut le trouver et qu'un backport agressif le révèle de toute façon.

Ce changement témoigne de la profonde transformation du paysage de sécurité autour de Bitcoin par l'IA. Au cours de l'été, une « Bitcoin Red Team » bénévole a commencé à lancer dans une course pour trouver les failles détectables par l'IA avant les attaquants. Début août, un audit piloté par l'IA a recensé près de 5 000 constats sur des centaines de projets crypto, et les développeurs se sont employés à corriger les bugs révélés par l'IA dans les implémentations Lightning et les portefeuilles matériels. Un pont Bitcoin a même fermé après avoir conclu que l'IA trouvait les bugs plus vite qu'il ne pouvait les corriger. À l'avenir, les avis de sécurité du projet montreront à quelle fréquence l'étiquette « facilement détectable » est appliquée—et à quelle vitesse les versions corrigées correspondantes suivent.