Résumé

  • Un avis de sécurité public n’est déclenché qu’à partir d’un score CVSS de 7 ou plus, classé élevé ou critique. En dessous, la politique n’impose aucune notification.
  • La politique de divulgation ne couvre que les produits en cours de prise en charge et uniquement la dernière version mensuelle de chaque branche de maintenance. Les branches en fin de vie en sont explicitement exclues.
  • Des relevés indépendants de l’ISC, tenus par Debian, montrent à la fois une prolongation de la réparation au-delà de la frontière amont et un décalage mesurable entre le correctif amont et le paquet réellement distribué.

Trois frontières, et non une seule

La politique de prise en charge et de numérotation des versions distingue quatre familles de versions majeures de BIND 9 : Développement, Stable, Extended Support (ESV) et Supported Preview, également appelée abonnement ou -S. Les versions stables, à numérotation paire, sont prises en charge quatre ans au total : environ douze mois de correctifs fonctionnels et de bogues, puis le régime étendu, puis les seuls correctifs de vulnérabilité. Un lecteur pressé retiendra surtout que l’ISC qualifie elle-même cette grille de repère approximatif, et non de garantie.

Les dates citées par le même document situent le contexte : BIND 9.18 est sorti en janvier 2022, a été déclaré ESV en janvier 2023 et devait atteindre sa fin de vie en juin 2026 ; BIND 9.20 est sorti en juillet 2024 ; BIND 9.16 avait été déclaré en fin de vie en mars 2024, avec une dernière version en avril 2024. La branche stable suivante, BIND 9.22, a été reportée au moins au quatrième trimestre 2026 dans ce document, et au moins à la fin de l’année 2026 dans un billet de l’ISC du 12 mai 2026, qui attribue le report à l’effet de l’analyse de code assistée par grands modèles de langage ayant mis au jour un nombre historiquement élevé de vulnérabilités potentielles.

Ce qui déclenche un avis, et ce qui ne le déclenche pas

La politique relative aux défauts logiciels et à la divulgation des vulnérabilités lie l’existence d’un avis public à une mesure de gravité. À partir d’un score CVSS de 7, classé élevé ou critique, l’ISC déclenche une divulgation de vulnérabilité de sécurité, de type I lorsque la faille n’est pas exploitée dans la nature, de type II lorsqu’elle l’est ou provoque des problèmes connus. En type I, les clients sous contrat de support et les fabricants reçoivent un préavis et du code préliminaire trois à cinq jours ouvrés avant la publication, avec notification des opérateurs de serveurs racine si le service faisant autorité est concerné ; les responsables de paquets des systèmes d’exploitation disposent de vingt-quatre heures au plus, via l’adresse de diffusion ouverte des distributions ; la publication publique intervient ensuite, avec des versions corrigées de tout le code affecté encore pris en charge. En type II, l’objectif affiché est de livrer le code de résolution dans les vingt-quatre heures suivant la notification, et la prévenance envers les responsables de paquets ne précède pas toujours l’annonce publique.

Deux exclusions comptent davantage que le calendrier. La politique ne s’applique qu’aux produits pris en charge et recommandés en production, et seulement à la version mensuelle la plus récente de chaque branche de maintenance stable ; elle ne couvre ni les versions en fin de vie ou hors maintenance, ni les branches de développement, ni les dépendances tierces embarquées dans les paquets préconstruits de l’ISC.

La règle de la dernière version mensuelle

Le billet du 12 mai 2026 déplace le rythme de publication : pour l’avenir prévisible, les utilisateurs doivent s’attendre à des correctifs de sécurité dans chaque version mensuelle de maintenance de BIND, au lieu de la pratique informelle d’environ une livraison de sécurité par trimestre. Le même texte prévient que l’ISC n’investira pas d’effort supplémentaire pour déterminer exactement quelle version mineure a introduit un problème, et que les utilisateurs doivent mettre à jour vers la dernière version de maintenance de leur branche. Il ajoute que l’ISC pourrait attribuer des identifiants CVE à davantage de problèmes de gravité moyenne, dans la plage CVSS 5 à 7, sans toujours rétroporter les correctifs correspondants, le seuil de l’avis précoce de vulnérabilité restant fixé à 7.

Ces deux phrases, prises ensemble, déplacent une part de la responsabilité vers l’aval : la maintenance devient un flux continu plutôt qu’un événement identifiable, et l’opérateur qui choisit de rester sur une version antérieure de sa propre branche se trouve hors du périmètre de correction, sans que cela constitue une faute de la part de l’ISC.

La fin de vie devient un état documenté, avec trois dates différentes

Le billet du 10 juin 2026 annonce la fin de la maintenance de BIND 9.18 avec la version de juin, prévue le 17 juin 2026, après environ quatre ans et demi, et recommande la migration vers 9.20, décrite comme de qualité ESV, donc moins exposée aux changements inattendus qu’une branche non maintenue. Le texte détaille la réorientation des dépôts de paquets vers 9.20, avec des jalons datés jusqu’en juillet 2026. La matrice des vulnérabilités de BIND 9 indique de son côté que 9.18 est en fin de vie, que 9.18.50 en est la dernière version, et marque le 1er juillet 2026 comme fin de branche, en précisant que les versions en fin de vie doivent être présumées vulnérables aux nouvelles CVE. Un relevé communautaire indépendant, endoflife.date, situe cette fin au 30 juin 2026. Ces trois formulations ne sont pas contradictoires au point d’interdire l’action, mais elles ne désignent pas la même date : une organisation qui doit prouver la fin de sa fenêtre de correction ne peut pas s’appuyer sur une seule d’entre elles.

La matrice mérite d’être lue pour ce qu’elle est : un document vivant qui ne montre que les branches stables encore prises en charge. Dans l’extrait consulté, la seule colonne de branche non en fin de vie est 9.20, avec 9.20.29 comme dernière version corrective datée du 16 septembre 2026. Les branches plus anciennes ne reçoivent généralement aucun correctif et ne sont parfois même pas évaluées.

Ce que des relevés indépendants montrent

Les enregistrements tenus par Debian, qui ne dépendent pas de l’ISC, permettent de mesurer deux choses que la documentation amont ne dit pas.

La première est la prolongation de la réparation au-delà de la frontière amont. Le suivi des bogues de sécurité de Debian montre bind9 en 1:9.20.26-1deb13u1 dans trixie et 1:9.20.29-1deb13u1 dans trixie-security, mais aussi 1:9.18.49-1deb12u1 dans bookworm et 1:9.18.49-1deb12u2 dans bookworm-security, avec forky et sid en 1:9.20.29-1, ainsi qu’une rubrique de problèmes ouverts. Autrement dit, une branche que l’amont a déclarée hors périmètre continue de recevoir des correctifs dans une distribution. Le suivi des paquets de Debian recense même quinze problèmes de sécurité ouverts dans bookworm et enregistre l’acceptation de 1:9.20.29-1deb13u1 dans stable-security le 17 septembre 2026, puis sa migration vers testing le 19 septembre 2026. L’avis de sécurité Debian DSA-6395-1, publié par Salvatore Bonaccorso le 22 juillet 2026, traite neuf CVE de bind9 et décrit des effets incluant le contournement de la validation DNSSEC, le contournement de politique RPZ, l’empoisonnement de cache et le déni de service, avec une distribution stable corrigée en 1:9.20.26-1deb13u1.

La seconde est le décalage. Une même distribution peut afficher 9.20.26 pour ses utilisateurs ordinaires et 9.20.29 pour ceux qui activent le dépôt de sécurité ; la matrice amont datait 9.20.29 du 16 septembre 2026 et le paquet correspondant était accepté le 17 septembre 2026. Ce délai court est une bonne nouvelle pour qui suit le dépôt de sécurité, et un rappel que le mot « corrigé » n’a pas le même contenu selon le canal que l’opérateur interroge. Les notes de version de BIND 9.20.26 montrent d’ailleurs à quoi ressemble une livraison mensuelle ordinaire : plusieurs correctifs de sécurité accompagnés d’identifiants CVE, dont CVE-2026-10723 sur la vérification du nom du signataire NSEC3 et CVE-2026-10822 sur une assertion liée à une DNSKEY malformée.

Le canal payant, et ce qu’il change

Le service d’avis précoce de vulnérabilité de l’ISC est fondé sur un abonnement, inclus dans les contrats de support logiciel et vendu séparément. Il autorise jusqu’à quatre personnes nommées par abonné, exige la signature d’un accord de confidentialité et prévient les abonnés jusqu’à cinq jours et au moins trois jours ouvrés avant l’annonce publique. La même page précise que la plupart des vulnérabilités BIND 9 découvertes par l’ISC sont des moyens de déclencher des échecs de type INSIST ou ASSERT qui font quitter le processus, ce qui peut constituer une attaque par déni de service efficace, et que, dans certains cas, la vulnérabilité est divulguée publiquement par celui qui l’a signalée, hors du contrôle de l’ISC.

Rien dans les documents consultés ne permet de dire si ce canal avancé modifie le moment de la correction publique : l’avis précoce porte sur l’information et sur une version corrigée en avance, non sur un correctif réservé. Ce qui est établi, c’est que l’information sur une faille critique est distribuée selon une gradation commerciale avant de l’être à tous.

Ce que personne ne mesure

Aucune mesure publique du taux d’adoption des versions corrigées n’a été trouvée. Les relevés de Debian décrivent ce qui est publié dans un dépôt, pas ce qui est exécuté sur des serveurs. Une affirmation du type « la majorité des serveurs sont à jour » ne peut donc pas être soutenue par ces sources, et cet article ne la formule pas.

Restent deux questions ouvertes, posées par les documents eux-mêmes : combien de vulnérabilités notées sous le seuil de 7 ne sont jamais rétroportées, et quel effet opérationnel elles produisent ; et pendant combien de temps une distribution portera des correctifs pour une branche que l’amont a déjà déclarée morte.

Portée de la preuve

Toute la documentation de l’ISC citée ici est le compte rendu que le mainteneur donne de ses propres engagements ; elle n’est pas une vérification indépendante de leur respect. Les relevés Debian sont indépendants de l’ISC pour l’empaquetage et le traitement des CVE, mais reprennent les données de vulnérabilité d’origine amont, et endoflife.date est une référence communautaire de cycle de vie. Aucune page n’a été ouverte directement : les éléments proviennent d’extraits rapportés par l’outil de recherche, certaines dates sont déduites d’identifiants d’URL, et les deux suivis Debian sont des pages vivantes qui changent.