Bitcoin Core a raison : quand une IA trouve la faille, le secret n’est que du théâtre

À quoi sert un secret qu’un chatbot peut reconstituer en une seule requête ? C’est, en substance, la question à laquelle Bitcoin Core vient de répondre, et nous pensons qu’il y a bien répondu.

Jeudi 22 octobre, le projet a fusionné une modification de sa politique de sécurité, rédigée par Antoine Poinsot, développeur chez Chaincode Labs. Jusqu’ici, Core classait chaque vulnérabilité selon sa gravité et calait la divulgation en conséquence. Les failles de faible gravité étaient révélées deux semaines après la sortie de la version majeure suivante. Les failles de gravité moyenne ou élevée pouvaient rester cachées jusqu’à deux semaines après la fin de vie de la dernière version concernée, une attente qui peut atteindre environ un an. Désormais, les mainteneurs peuvent qualifier un bug de « facilement découvrable » lors du tri. Cette étiquette recouvre un bug que l’on peut trouver avec une simple requête à un LLM. Pour un tel bug, le correctif est rétroporté sur toutes les versions maintenues, une version mineure est publiée dès que possible et un avis de sécurité comportant quelques détails est émis. Les bugs critiques restent hors de la politique standard et sont traités au cas par cas.

L’embargo était un pari sur la difficulté, et les probabilités ont changé

Un long embargo ne fonctionne que si les attaquants ont peu de chances de trouver la faille seuls. Corriger discrètement laisse aux opérateurs de nœuds le temps de mettre à jour avant que quiconque sache où se trouve la faiblesse. Le diagnostic d’Antoine Poinsot lui-même, cité par CoinDesk, est que les LLM ont « considérablement » abaissé la barre pour trouver certaines catégories de problèmes ou repérer des correctifs dissimulés. Ce second point est le plus sous-estimé. Un correctif silencieux est lui-même un indice, et un modèle sait lire un diff.

Pour cette catégorie de bug, l’embargo ne protège donc personne, hormis l’attaquant, qui est déjà au courant. Pendant ce temps, les utilisateurs honnêtes restent sur d’anciennes versions non corrigées en attendant une version majeure. La politique le dit sans détour: « La période d’embargo n’apporte pas grand-chose, mais elle retarde la disponibilité d’une version corrigée. »

Les faits montrent que ce n’est pas hypothétique

Regardez ce qui s’est passé cet été. Un groupe bénévole de 16 développeurs, le Bitcoin Red Team, a fait tourner des modèles d’IA sur 390 projets Bitcoin en environ une journée et consigné 4 962 résultats, dont 85 critiques, selon CoinDesk. Tous n’ont pas été reproduits (un rapport indique qu’environ un cinquième seulement l’avaient été à ce stade): ce chiffre est donc à lire avec cette réserve. Reste que, en quelques jours, une faille de BTCPay Server que le groupe avait signalée en privé était exploitée sur des serveurs de commerçants en production. Le signalement privé n’a pas devancé les attaquants.

Le tableau d’ensemble va dans le même sens. Une note de recherche de la Cloud Security Alliance soutient que le modèle classique de divulgation coordonnée, avec sa fenêtre habituelle de 90 jours, a été conçu pour des chercheurs humains travaillant à vitesse humaine. Nous voyons dans la décision de Bitcoin un cas concret de cet argument.

La transparence a un prix, et il vaut la peine d’être payé

Le changement n’est pas gratuit. Antoine Poinsot admet que des correctifs plus rapides bénéficient de moins de « temps de maturation » lors des tests. C’est un risque réel, car un correctif précipité sur un logiciel qui sécurise un immense réseau peut mal tourner. L’alternative proposée par le développeur Antoine Riard, publier dans certains cas des correctifs sans avis, a été rejetée, et nous approuvons ce rejet. Antoine Poinsot a fait valoir qu’alerter les utilisateurs sans détails pourrait déclencher des migrations précipitées de la part de personnes qui ne seraient même pas concernées. Le demi-secret donne la panique sans l’information.

La ligne de partage elle-même suscite aussi une inquiétude légitime. Aucun bug n’a encore été signalé selon la nouvelle règle; comme le note Crypto Briefing, la question ouverte est donc de savoir avec quelle cohérence les mainteneurs décideront de ce qui est « facilement découvrable ». Une étiquette floue pourrait devenir une échappatoire dans un sens comme dans l’autre. À notre avis, le critère est honnête, car il dépend de la facilité avec laquelle une faille se trouve, et non de l’outil qui l’a trouvée.

Ce que les autres projets devraient en retenir

La leçon n’est pas « tout divulguer immédiatement ». Les bugs difficiles à trouver méritent toujours du temps, et Core conserve pour eux son calendrier selon la gravité. La leçon, c’est que l’hypothèse par défaut s’est inversée. Les projets devraient désormais se demander si un bug peut être redécouvert à peu de frais et, si oui, faire de la rapidité du correctif la priorité plutôt que la discrétion. Les projets open source critiques dont la culture de mise à jour est lente ont le plus à gagner, car ils ont le plus à perdre d’une longue fenêtre d’exposition.

Notre verdict: Bitcoin Core a fait un choix pragmatique et un peu inconfortable, et c’est le bon. Les opérateurs doivent guetter les versions mineures et les avis, et être prêts à mettre à jour rapidement. Tous les autres qui maintiennent du code très utilisé devraient examiner leurs règles d’embargo et se demander lesquelles protègent encore les utilisateurs, et lesquelles ne protègent que l’habitude.