Bitcoin Core met fin à un embargo d'un an pour les bogues facilement détectables

Bitcoin Core met fin à une attente d'un an pour des correctifs de sécurité qu'un modèle de langage peut retrouver en une seule requête. Une modification de la politique de divulgation de sécurité du projet, fusionnée le 22 octobre, crée une catégorie de vulnérabilités « facilement découvrables » et invite les maintainers à publier une version ponctuelle et un avis public « dans les plus brefs délais » — contournant l'embargo standard qui maintient un bogue de gravité moyenne ou élevée secret pendant environ un an.

Le déclencheur est direct. Les mainteneurs reçoivent davantage de signalements de bogues qui continuent d'être redécouverts, car les modèles linguistiques ont réduit l'effort nécessaire pour les trouver. Antoine Poinsot, contributeur à Bitcoin Core chez Chaincode Labs, a annoncé ce changement sur la liste de diffusion Bitcoin Development le même jour où la pull request a été fusionnée.

« Nous avons récemment observé une augmentation du nombre de signalements de vulnérabilités de sécurité facilement (ré-)détectables », a écrit Poinsot. « Cela est principalement dû au fait que les LLM ont considérablement abaissé la barrière pour découvrir certaines classes de problèmes ou identifier des correctifs discrets. »

La politique précédente de Bitcoin Core liait le moment de la divulgation à la gravité. Les bogues de faible gravité étaient rendus publics deux semaines après la sortie de la prochaine version majeure. Les bogues de gravité moyenne et élevée restaient privés jusqu'à deux semaines après la fin de vie de la dernière version affectée — une fenêtre que la politique elle-même décrit comme « environ un an après la première sortie d'une version majeure contenant le correctif ».

Ce calendrier existait pour une raison. Bitcoin Core est l’implémentation de référence qui fait fonctionner la majorité des nœuds de Bitcoin, et les opérateurs de nœuds effectuent les mises à jour lentement. Un long embargo avait pour but de donner au réseau le temps de corriger les failles avant que les détails ne soient rendus publics. Le compromis était que les correctifs n’étaient généralement pas rétroportés, donc un opérateur sur une version plus ancienne devait attendre la prochaine version majeure, que le projet vise à publier environ tous les six mois.

La prudence est structurelle et non accidentelle. Les changements de consensus, comme la mise à jour Taproot de Bitcoin, suivent un chemin lent et conservateur afin que les opérateurs puissent les adopter selon leur propre calendrier.

« En raison de la nature de notre projet, associée à une culture de mise à jour lente, notre politique de sécurité privilégie une période d'embargo plus longue », a écrit Poinsot. « Cela signifie généralement que les correctifs de sécurité ne peuvent pas être rétroportés et ne deviennent disponibles pour les utilisateurs qu'avec la prochaine version majeure. »

L'IA brise cet équilibre. Si un bogue peut être répertorié grâce à un balayage trivial par un LLM, le cacher ne sert à rien, car la faille est déjà à la portée de quiconque possède un chatbot. « Pour ces problèmes faciles à détecter, cet équilibre est erroné. La période de non-divulgation apporte peu, mais retarde la disponibilité d'une version corrigée », a écrit Poinsot.

Selon la politique révisée, le délai de divulgation dispose désormais d'un troisième paramètre. Une vulnérabilité peut être étiquetée comme « facilement découvrable » lors du triage — définie comme une vulnérabilité « qui peut être découverte avec un effort minimal, par exemple via une simple requête LLM ». Cette étiquette ne s'applique pas uniquement aux bogues trouvés par l'IA : elle indique le peu d'effort requis pour une redécouverte, et non l'outil qui a effectué la détection.

Pour ces bogues, la réponse varie sur chaque axe. Au lieu d’un correctif unique intégré dans la prochaine version majeure, les maintaineurs backporteront une correction à chaque version majeure actuellement prise en charge — trois branches selon la règle de Bitcoin Core consistant à soutenir ses trois dernières versions — et publieront des versions ponctuelles aussi rapidement que possible. Un avis de sécurité sera publié en parallèle du logiciel corrigé.

L'échelle de gravité continue de régir tout le reste. Les bogues de faible gravité restent sur le calendrier de deux semaines. Les bogues de gravité moyenne et élevée restent sur le cycle d'environ un an. Les bogues critiques — ceux qui pourraient voler des pièces au niveau du protocole, augmenter artificiellement l'offre ou diviser définitivement la chaîne — restent en dehors de la politique standard et sont traités cas par cas, comme toujours.

Cette dérogation existe pour une bonne raison. Dans l’historique de Bitcoin Core, le bug d’inflation divulgué sous la référence CVE-2018-17144 en septembre 2018 était du type de faille qui justifiait un traitement particulier : il aurait pu permettre la création de pièces en dehors du calendrier d’émission. La nouvelle voie « facilement identifiable » ne touche pas à ce niveau — une faille critique recevra toujours une réponse ad hoc adaptée au risque pour l’ensemble du réseau.

Le changement est le plus facile à lire comme une réduction dans la fenêtre de divulgation. Un bogue de gravité moyenne corrigé aujourd'hui resterait normalement privé pendant environ 52 semaines, divulgué seulement deux semaines après la fin de vie de la dernière version affectée. Le même bogue, une fois identifié comme facilement détectable, est publié en version ponctuelle « dès que possible » accompagné de son avis. C'est la différence entre une année et, selon la propre formulation des mainteneurs, le temps nécessaire pour écrire, examiner et tester un correctif ciblé.

L'engagement de rétroportage constitue l'autre moitié. Avant ce changement, un correctif n'atteignait généralement pas les utilisateurs sur une branche ancienne maintenue ; il arrivait avec la prochaine version majeure. Désormais, un opérateur sur une version ancienne prise en charge peut effectuer une mise à jour ciblée sans adopter toutes les fonctionnalités et modifications de comportement de la dernière version majeure. Pour un réseau où les mises à niveau sont lentes et réfléchies, il s'agit d'un changement significatif concernant la rapidité avec laquelle un correctif peut réellement être déployé.

La voie plus rapide a un coût, et Poinsot l'a dit clairement dans la pull request. « Cela est particulièrement important car, selon cette politique, les correctifs n'auront pas autant de temps de « cuisson » dans les branches de développement avant d'être publiés aux utilisateurs », a-t-il écrit. Une correction publiée en quelques jours passe moins de temps en revue et en tests qu'une correction qui attendait depuis des mois.

La discussion s'est également divisée sur la question de savoir si la divulgation devrait être encore plus rapide. Certains contributeurs ont soutenu que l'ouverture d'une demande de tirage pour un correctif pourrait elle-même alerter les attaquants, car il est peu coûteux de surveiller automatiquement le dépôt ; la divulgation devrait donc intervenir au plus tard avec le correctif, ou même avant, accompagnée de conseils d'atténuation. Un autre contributeur a proposé de déployer les correctifs avec un avis discrétionnaire ou retardé. Poinsot a rejeté cette proposition, affirmant que prévenir les utilisateurs sans détails pourrait déclencher une migration précipitée parmi les opérateurs qui n'ont jamais été affectés.

La plateforme d'échange importe, car elle montre que la nouvelle politique est un compromis délibéré, et non une évidence évidente. Le texte fusionné conserve l'avis simultanément à la correction et inclut tous les détails, plutôt qu'un avertissement vague.

Aucune vulnérabilité n'a encore été placée dans la nouvelle classe, il s'agit donc d'un changement de processus, et non de la divulgation d'un bug actif. Le premier vrai test intervient lorsque les mainteneurs signalent un élément « facilement découvrable » lors du triage et publient des mises à jour ponctuelles sur toutes les branches maintenues avec un avis simultané.

Le signal plus large est que la recherche de bogues assistée par l'IA a déjà forcé l'écosystème Bitcoin à évoluer. Core Lightning a demandé plus tôt cette année aux opérateurs de nœuds de mettre à jour ou se déconnecter après que des rapports de vulnérabilités générés par l'IA se soient révélés corrects. Le changement de politique de Bitcoin Core est l'implémentation de référence effectuant le même calcul au niveau de base du protocole : lorsque la redécouverte est peu coûteuse, le secret apporte peu, et le seul thing qu'un embargo prolongé retarde, c'est la sortie fixe.

Pour les opérateurs de nœuds, rien ne change aujourd'hui. Le rythme de mise à niveau reste le même. La différence intervient la prochaine fois qu'un bogue est qualifié de facilement détectable, lorsqu'un correctif et son avis sont publiés ensemble avec moins d'avis que le réseau n'en a jamais eu.