Notre premier cycle de publication renforcé : ce que nous avons appris et les changements que nous apportons

Kunal AnandDirecteur des produits | F5

Note de la rédaction (14 octobre 2026) : F5 désigne désormais les « versions renforcées » sous le nom de « versions critiques ». Ce changement de terminologie reflète l’importance de ces versions et la nécessité de déployer la dernière version dès que possible.

En juillet, j’ai écrit au sujet de notre passage à des versions renforcées mensuelles et à des notifications de sécurité mensuelles. J’avais alors indiqué que ce rythme était adapté à notre situation et que la même rigueur qui nous avait conduits à abandonner le rythme trimestriel nous amènerait à nouveau à évoluer lorsque le contexte l’exigerait.

Après un cycle de publication, nous avons beaucoup appris. Nous avons appris de nos clients, de nos partenaires et en observant la manière dont un rythme mensuel s’intègre aux environnements de production. Certains de ces enseignements nous amènent à revoir notre approche.

À compter de HR2, le 2 septembre, les versions renforcées seront publiées toutes les six semaines, et non plus tous les mois. Nous suspendons également les notifications de sécurité régulières que nous avions prévu de publier en parallèle.

Je tiens à expliquer comment nous en sommes arrivés là, car le raisonnement compte davantage que les dates.

Ce que nos clients nous ont dit

Nous avons lancé HR1 le 15 juillet, puis nous avons fait ce que nous avions promis : nous avons écouté.

Les retours que nous avons reçus étaient unanimes, et ils ne concernaient pas vraiment F5. Les organisations qui utilisent nos produits dans leurs environnements les plus critiques nous ont expliqué qu’un rythme mensuel ne leur laissait pas suffisamment de temps pour effectuer les tests, la préproduction et le déploiement — pas nécessairement parce que nos versions étaient difficiles à intégrer en elles-mêmes, mais parce qu’elles arrivaient en même temps que celles de tous les autres fournisseurs. Tous les fournisseurs sérieux s’adaptent à la même évolution, et la charge cumulée repose sur une seule et même équipe aux ressources limitées au sein de chaque entreprise.

Un délai de six semaines revient à reconnaître qu’un correctif que personne ne peut déployer n’en est pas vraiment un. La vitesse à laquelle les clients peuvent intégrer un changement fait désormais partie intégrante de l’équation de la sécurité, et un rythme qui dépasse leur capacité d’adaptation accroît leur exposition au lieu de la réduire.

L’autre enseignement que nous en avons tiré va dans le sens opposé. Les clients qui ont investi dans la gestion de parc et l’automatisation constatent une nette amélioration de leur rapidité de mise à jour. Un client international disposant d’un vaste parc F5 BIG-IP a réduit le délai de mise à jour, le faisant passer de plus de six mois à environ deux semaines.

Pourquoi nous suspendons les notifications de sécurité

Le deuxième changement est plus difficile, et je tiens à expliquer franchement le raisonnement qui le sous-tend.

Lorsque nous avons annoncé des notifications de sécurité mensuelles, nous pensions qu’un délai d’environ 30 jours entre la publication de la version renforcée et la divulgation des informations laisserait aux clients suffisamment de temps pour effectuer la mise à jour avant que les détails ne soient rendus publics. Cette hypothèse reflétait ce qui nous semblait être la meilleure décision à l’époque.

Ce n’est plus le cas. Les échanges que nous avons eus ces dernières semaines avec nos clients et d’autres acteurs du secteur nous ont amenés à revoir notre estimation de la quantité d’informations réellement nécessaire pour mettre au point un exploit fonctionnel. Les modèles de pointe continuent d’améliorer leur capacité à déduire, à partir d’indices limités — un diff, une description partielle, une plage de versions — une chaîne d’attaque opérationnelle. La fenêtre que nous pensions offrir aux défenseurs est, en pratique, également une fenêtre pour les attaquants, et elle se réduit.

Nous suspendons donc les notifications régulières pendant que nous réfléchissons collectivement à ce que doit être une divulgation responsable dans ce contexte. Il y aura des exceptions. Lorsqu’une vulnérabilité est activement exploitée, que nous travaillons en coordination avec des chercheurs ou des organismes gouvernementaux, ou que des obligations réglementaires ou contractuelles l’exigent, nous procéderons différemment. Il ne s’agit pas d’une position définitive en matière de transparence. Cette décision a été prise avec pour impératif de protéger les clients avant tout, et nous continuerons à la réévaluer.

Je reconnais que cette situation est inconfortable. Elle l’est aussi pour moi, en tant qu’ancien RSSI. Les normes de divulgation existent pour de bonnes raisons, et la communauté de la cybersécurité les a élaborées au fil de décennies d’expériences difficiles. Cependant, ces normes ont été conçues pour un monde où le délai entre la « publication des détails » et la « disponibilité d’un exploit » se comptait en semaines. Ce délai a disparu, et toute organisation qui publie des informations sur les vulnérabilités va devoir prendre la mesure de ce que cela implique.

La question la plus délicate : le triage sans niveau de gravité

C’est, à mon avis, l’aspect auquel le secteur ne s’est pas encore pleinement confronté.

La plupart des programmes de gestion des vulnérabilités reposent sur leur niveau de gravité. Les vulnérabilités critiques sont corrigées sous 24 heures, celles de gravité élevée sous trois jours, celles de gravité moyenne au cours d’un sprint, et celles de faible gravité lorsque le temps le permet. Ce modèle repose sur deux hypothèses : que les niveaux de gravité permettent de prédire les risques de manière pertinente et que vous disposez de tels niveaux pour travailler.

Ces deux hypothèses sont de moins en moins valables.

La première s’érode parce que les attaquants qui utilisent des modèles de pointe n’ont pas besoin d’une vulnérabilité critique. Ils enchaînent les failles. Trois problèmes de faible gravité qui, pris individuellement, pourraient se retrouver tout en bas d’une file de triage peuvent constituer une voie d’attaque exploitable lorsqu’un modèle est capable de raisonner simultanément sur les trois. Lorsque nous analysons notre propre code, nous trouvons ce type de problèmes : des failles de moindre gravité susceptibles d’être enchaînées. Les éliminer systématiquement permet de renforcer les logiciels. Les trier individuellement selon leur gravité conduit à les laisser en place.

La deuxième hypothèse est en train de perdre de sa validité, car les fournisseurs — nous y compris — vont publier moins de détails, et plus tardivement. Les équipes de sécurité auront le sentiment de perdre le contrôle, et je comprends pourquoi.

Alors, que faire à la place ?

Priorisez en fonction de l’exposition, et non de la note. L’accessibilité, l’exposition à Internet, l’étendue des dommages potentiels et la criticité pour l’activité sont des critères plus pérennes qu’un score CVSS que vous ne recevrez peut-être pas. Un actif exposé et non corrigé présente un risque, indépendamment de ce qu’indique l’avis de sécurité.

Faire de la mise à jour permanente une discipline. Les organisations qui réussiront dans cet environnement seront celles qui considéreront le fait d’« utiliser la dernière version renforcée » comme un engagement opérationnel permanent, plutôt que comme une action ponctuelle déclenchée par un niveau de gravité. Il s’agit d’un changement culturel autant que technique, qui nécessite un soutien durable de la direction.

Investissez dès maintenant dans votre capacité d’absorption. L’automatisation, la visibilité sur le parc, des fenêtres de maintenance régulières et reproductibles, ainsi que des procédures de retour arrière éprouvées sont indispensables pour soutenir un rythme plus soutenu. Ces investissements peuvent sembler facultatifs aujourd’hui. Dans un an, ce ne sera plus le cas.

Partez du principe que ce délai existera et protégez-vous en conséquence. Aucune organisation n’applique les correctifs instantanément. La protection à l’exécution — détection comportementale, correctifs virtuels et contrôles ne nécessitant pas de connaître la vulnérabilité précise — peut contribuer à couvrir la période entre la disponibilité d’un correctif et son déploiement. Cette période ne disparaîtra pas. Anticipez-la au lieu de chercher à la contourner.

Sur le fait de changer d’avis

Nous avons pris une décision en juillet sur la base des meilleures informations dont nous disposions. Nous l’avons mise en œuvre, avons tiré les enseignements des retours de nos clients et partenaires, puis l’avons ajustée. L’autre option — maintenir notre position simplement parce que nous l’avions annoncée — aurait été plus préjudiciable à nos clients et partenaires.

J’ai déclaré en juillet que nous continuerions à nous adapter à mesure que le contexte et vos besoins évolueraient. Voilà ce que cela donne concrètement. À l’heure actuelle, tout fournisseur se doit d’admettre en toute honnêteté que les pratiques établies sont réévaluées en temps réel dans l’ensemble du secteur, et que quiconque prétend avoir entièrement résolu la question ne prête pas attention à ce qui se passe.

Ce qui ne change pas, c’est le niveau d’exigence que nous nous imposons. Les organisations placent F5 entre leurs utilisateurs et leurs applications, ainsi qu’entre leurs agents et leurs API. Cette position explique pourquoi nous détectons et corrigeons les problèmes aussi rapidement, pourquoi nous menons nos tests de cette manière et pourquoi nous avons pris cette décision en matière de divulgation. Merci pour vos retours, qui ont contribué à façonner cette approche. Continuez à nous en faire part et veillez à rester à jour.

À propos de l’auteur

Kunal AnandDirecteur des produits | F5

Kunal Anand dirige l’organisation produit de F5 en tant que directeur des produits. Responsable de la vision, de la stratégie et de l’exécution des produits, il veille au développement de solutions révolutionnaires qui répondent à des enjeux critiques et offrent aux clients des expériences exceptionnelles. Dans ses précédentes fonctions de directeur de la technologie et de l’IA, Kunal a défini la stratégie et la vision de l’entreprise en matière de technologie et d’intelligence artificielle. Avant de rejoindre F5, Kunal a occupé le double poste de directeur de la technologie et de directeur de la sécurité des systèmes d’information chez Imperva. Son parcours chez Imperva a débuté en 2018 avec l’acquisition de Prevoty, une start-up spécialisée dans la sécurité des applications qu’il avait cofondée en 2013. Avant de rejoindre Prevoty, il était directeur de la technologie chez BBC Worldwide. Fort d’une longue expérience en matière d’innovation et d’une solide expertise technique, Kunal a dirigé des équipes chargées de la sécurité, des données, de la technologie et de l’ingénierie chez Gravity, MySpace et au Jet Propulsion Laboratory de la NASA. Kunal possède plus de 15 ans d’expérience dans les domaines de l’IA et de l’apprentissage automatique, notamment dans l’entraînement de modèles, l’utilisation d’algorithmes fondés sur l’IA pour améliorer les produits, ainsi que la conception et la mise en œuvre d’architectures d’IA. Kunal est titulaire d’une licence en informatique du Babson College.

Autres articles de Kunal Anand