Bitcoin Core a révisé sa politique de divulgation de sécurité afin d'accélérer les correctifs pour les vulnérabilités que les grands modèles de langage peuvent découvrir avec un effort minimal, mettant fin aux embargos de plusieurs mois qu'effectuaient auparavant ces bugs.

Les mainteneurs ont fusionné jeudi la modification de la politique de sécurité du projet. Le développeur de Chaincode Labs Antoine Poinsot, auteur de la proposition, l'a annoncée le même jour dans un message adressé à la Bitcoin Development Mailing List.

« Nous avons récemment constaté une augmentation du nombre de rapports de vulnérabilités de sécurité facilement (re)découvrables », a écrit Poinsot. « Cela est largement dû au fait que les LLM réduisent considérablement la barrière pour trouver certaines classes de problèmes ou identifier des correctifs discrets. »

Cette révision fait de la découvrabilité, et pas seulement de la gravité, un facteur déterminant de la rapidité avec laquelle le logiciel exécutant la majorité des nœuds Bitcoin reçoit un correctif public.

Fonctionnement antérieur de la politique

Dans le cadre précédent, Bitcoin Core — le logiciel exécuté sur la plupart des nœuds du réseau Bitcoin — classait chaque vulnérabilité signalée selon sa gravité et calait sa divulgation en conséquence. Les failles de faible gravité étaient rendues publiques deux semaines après la sortie de la prochaine version majeure. Les problèmes de gravité moyenne et élevée restaient sous embargo jusqu'à deux semaines après la fin de vie de la dernière version concernée, une période pouvant s'étendre jusqu'à un an.

Ces longs délais visaient à donner aux opérateurs de nœuds, dont beaucoup effectuent leurs mises à jour lentement, le temps de passer au logiciel corrigé avant que les détails ne soient rendus publics. En pratique, cette approche signifiait que les correctifs n'étaient pas publiés pour les anciennes versions maintenues et n'arrivaient qu'avec la prochaine version majeure.

Poinsot a fait valoir que ce compromis échoue pour les bugs faciles à redécouvrir. « La période d'apporte peu mais retarde la disponibilité d'une version corrigée », indique la politique.

Ce qui change

Lors du triage, Bitcoin Core peut désormais signaler une vulnérabilité comme « facilement découvrable », une catégorie que la politique définit comme des problèmes trouvables « avec un effort minimal, par exemple via un simple prompt LLM ». Cette étiquette s'applique également aux failles découvertes par d'autres moyens.

Pour ces problèmes, le projet rétropotertera un correctif vers chaque version majeure maintenue, publiera des versions ponctuelles dès que possible et publiera un avis de sécurité avec certains détails en même temps que le logiciel corrigé. Poinsot a reconnu que ces correctifs bénéficieront de moins de temps de test avant d'arriver aux utilisateurs. Pour les opérateurs sur d'anciennes versions maintenues, cela signifie que les correctifs arrivent désormais sous forme de versions ponctuelles plutôt que d'attendre la prochaine version majeure, avec des détails publiés dès la sortie du correctif.

Les vulnérabilités hors de cette catégorie conservent le calendrier existant fondé sur la gravité. Les critiques — ceux qui pourraient permettre un vol de pièces au niveau du protocole, gonfler l'offre ou provoquer une scission permanente de la chaîne — restent hors de la politique standard et seront traités au cas par cas.

Le développeur Antoine Riard a plaidé pour une option permettant de publier un correctif sans avis et de retenir les détails au cas par cas. Poinsot a refusé, écrivant qu'alerter les utilisateurs sans détails « pourrait créer inutilement plus de risques » en incitant à une migration précipitée parmi des utilisateurs qui, autrement, ne seraient pas concernés.

Un été de rapports dopés à l'IA

Ce changement de politique fait suite à des mois de pression accrue sur les projets open source de Bitcoin. Fin juillet, un groupe bénévole de 16 développeurs connu sous le nom de Bitcoin Red Team a fait tourner des modèles d'IA sur 390 dépôts bitcoin en environ une journée et a recensé 4 962 conclusions, dont 85 jugées critiques.

Quelques jours plus tard, une faille de BTCPay Server signalée en privé par le groupe a été exploitée sur des serveurs marchands en production, vidant des nœuds Lightning.

En août, les développeurs de Core Lightning ont demandé aux opérateurs de mettre à jour ou de se déconnecter après que des rapports générés par IA adressés au projet se sont révélés exacts.

L'initiative du Red Team faisait suite à une exploitation du portefeuille matériel Coldcard au cours de laquelle des attaquants ont vidé 594 BTC en 25 minutes le 30 juillet. Les pertes sur quatre prélèvements ont approché 114 millions de dollars.

La fréquence d'application de l'étiquette « facilement découvrable » — et la rapidité des correctifs qui suivront — seront visibles dans les avis et les versions ponctuelles de Bitcoin Core à l'avenir.

Source : Bitcoin Magazine | Rédigé par Micah Zimmerman