La fenêtre de déploiement des correctifs est terminée. Voici comment F5 se prépare à la suite.

Kunal AnandDirecteur des produits | F5

Il existe dans FFmpeg une ligne de code que des outils automatisés de fuzzing ont testée environ cinq millions de fois. Un bug vieux de 16 ans se cachait dans cette ligne sans avoir jamais été détecté. Rien ne l’avait signalé. Puis Anthropic a lancé son nouveau modèle Claude Mythos Preview sur le code source : le modèle a lu le code, analysé ce qu’il était censé faire et découvert la faille. Il a également identifié des milliers d’autres vulnérabilités jusqu’alors inconnues dans tous les principaux systèmes d’exploitation et navigateurs. L’une d’elles était présente dans OpenBSD depuis 27 ans. OpenAI et d’autres développent des capacités équivalentes.

Ce tournant ne concerne pas un seul fournisseur.

C’est à ce moment-là que les lois de la sécurité logicielle ont changé.

Les calculs qui comptent

Le « Zero Day Clock de Sergej Epp », qui s’appuie sur 3 515 paires CVE-exploit issues de CISA KEV, VulnCheck KEV et XDB, résume la situation en quatre chiffres :

1. En 2018, le délai médian entre la divulgation d’une vulnérabilité et la première exploitation observée était de 771 jours. Les organisations disposaient de plus de deux ans pour appliquer un correctif.
2. En 2023, ce délai n’était plus que de 6 jours.
3. En 2024, ce délai n’était plus que de 4 heures.
4. En 2025, de nombreuses vulnérabilités exploitées ont été transformées en armes avant même d’être rendues publiques.

Pendant ce temps, une organisation moyenne met encore 20 jours à tester et à déployer un correctif. La plupart ne peuvent corriger qu’environ 10 % des nouvelles vulnérabilités chaque mois. Accélérer le déploiement des correctifs ne suffira pas à combler cet écart. Ni tous les trimestres. Ni tous les mois. Ni même, de manière réaliste, toutes les semaines.

Ce calcul ne tient pas la route.

Pourquoi l’IA fait pencher la balance en faveur de l’attaque

Il existe une raison plus profonde pour laquelle l’IA accélère davantage les capacités offensives que défensives, et tout responsable de la sécurité devrait la comprendre.

L’attaque dispose du mécanisme de vérification le moins coûteux en cybersécurité. L’exploitation a-t-elle réussi ? La réponse est binaire et immédiate : soit vous avez obtenu un shell, soit vous ne l’avez pas obtenu. L’apprentissage automatique tire parti de ce type de signal de manière cumulative.

La défense est confrontée au problème inverse. Cette alerte est-elle réelle ? Ce système est-il sécurisé ? Le retour d’information est ambigu, lent et coûteux. Signal bruité, boucle rompue. L’IA fonctionne mieux du côté où le mécanisme de vérification est fiable, ce qui explique pourquoi l’exploitation assistée par l’IA s’est industrialisée plus rapidement que la défense assistée par l’IA.

C’est la réalité structurelle qui sous-tend les chiffres de Mythos. Anthropic n’a pas conçu une arme. Un modèle de pointe à usage général est simplement devenu suffisamment performant dans l’analyse du code pour accentuer encore davantage l’asymétrie de vérification en faveur des attaquants.

Tous les laboratoires développant des modèles de pointe franchiront ce seuil et, au vu de l’évolution actuelle de leurs capacités, je prévois — il s’agit d’une hypothèse, mais c’est celle sur laquelle je fonde ma planification — que des modèles open source dotés de capacités de raisonnement sur le code comparables à celles de Mythos verront le jour dans les 12 prochains mois : des modèles que toute personne disposant d’un GPU pourra exécuter localement, sans supervision.

Ce qui doit changer

C’est sur ce calendrier que tous les éditeurs de logiciels et toutes les équipes chargées de la sécurité des entreprises devraient s’aligner. Alors, qu’est-ce qui doit changer ?

Notre façon de tester le code : L’analyse statique et les tests d’intrusion périodiques ont été conçus pour un monde où la découverte de vulnérabilités était lente et coûteuse. Ce monde n’existe plus. Les tests doivent devenir continus, pilotés par l’IA et fondés sur le raisonnement. Les modèles doivent suivre les chemins d’exécution, enchaîner les flux et identifier la chaîne d’exploitation, plutôt que la seule faille isolée. La reconnaissance de motifs n’est qu’un prérequis. Le raisonnement est la nouvelle référence.

Notre façon de développer du code : La sécurité ne peut plus se limiter à un contrôle en fin de chaîne. Elle doit être intégrée dès l’écriture du code, grâce à des outils assistés par l’IA qui signalent les constructions à risque avant leur validation.

Notre façon de distribuer le code : Les délais de divulgation, les rythmes de mise à jour et les pratiques de gestion des parcs informatiques ont tous été conçus pour un rythme plus lent. Chaque éditeur de logiciels doit se demander en toute honnêteté si ses processus actuels sont adaptés à un monde où l’exploitation d’une faille précède la publication de l’avis de sécurité.

Cela s’applique au code que nous n’avons pas encore livré. La question, tout aussi difficile, est de savoir ce que nous faisons du code déjà en production. C’est là que le véritable changement s’opère. Et c’est aussi là que F5 est particulièrement bien placé pour montrer la voie.

L’environnement d’exécution est la solution

Lorsque la fenêtre d’application des correctifs se referme, le chemin du trafic reste en place. Ce n’est pas une solution de repli. Dans ce nouveau calcul, c’est le principal mécanisme de contrôle.

La protection à l’exécution inverse l’asymétrie de la vérification. Au lieu de chercher à savoir si une faille hypothétique existe quelque part dans une base de code, l’environnement d’exécution observe le comportement d’une application et intervient lorsqu’il s’écarte de celui attendu. Le signal est concret. Le retour est clair. Un attaquant peut découvrir un millier de failles zero-day dans votre code, mais si l’exploitation ne peut pas emprunter le chemin des données, la faille ne se transforme pas en compromission.

F5 est présent sur le chemin des données depuis 30 ans. F5 BIG-IP, F5 NGINX et F5 Distributed Cloud Services — la F5 Application Delivery and Security Platform — ont été conçus précisément pour cette couche. Notre choix architectural, qui consiste à protéger l’application là où circule le trafic, est celui qui compte le plus à une époque où le code ne peut pas être corrigé assez rapidement. Tout ce que nous faisons aujourd’hui en matière de gestion du trafic d’IA et de sécurité à l’exécution prolonge ce même choix pour l’appliquer aux charges de travail que les clients développent actuellement.

Ce que nous faisons avec notre propre code

Nous travaillons également sur l’autre volet de la question. Dans le cadre de nos pratiques opérationnelles, nous testons des modèles d’IA de pointe sur notre propre base de code.

Les modèles lisent directement le code source, suivent les flux à risque à travers les différents modules et langages, et analysent les détails réels de l’implémentation. Une seconde passe de vérification permet de distinguer les résultats pertinents du bruit. Les vulnérabilités détectées sont classées selon les catégories CWE, leur niveau de gravité, les fichiers et lignes concernés, ainsi que leur contexte d’exploitabilité, puis sont directement intégrées à un processus de correction priorisé.

L’objectif n’est pas de détecter des failles isolées, mais de mettre au jour des chaînes d’exploitation, de hiérarchiser les risques les plus importants et de transformer les résultats en code renforcé. Chaque cycle enrichit une base de connaissances qui rend le suivant plus rapide et plus précis. À mesure que les modèles de pointe gagnent en performance, l’usage que nous en faisons s’affine lui aussi. Notre base de code sera toujours testée à l’aide des meilleurs outils et modèles disponibles, car ce sont précisément ceux que les attaquants utiliseront.

Le coût, et qui le supporte

Je tiens à être clair sur ce que cela implique pour les clients.

La divulgation d’un plus grand nombre de vulnérabilités n’est pas le signe d’un logiciel moins fiable. Elle témoigne de processus plus robustes. Chaque faille que nous détectons et corrigeons avant qu’un attaquant ne l’exploite représente un risque de moins en production. Mais chaque correction implique également un correctif que quelqu’un doit déployer. Les équipes qui exploitent BIG-IP en production verront davantage de correctifs, et les cycles de mise à jour jusqu’ici trimestriels devront être accélérés. Nous investissons dans F5 Insight et la gestion de parc afin de raccourcir l’ensemble du cycle : nous détectons la faille, la corrigeons, validons la correction, puis vous la déployez. Et lorsque le déploiement prend du temps, le chemin du trafic continue de protéger l’application pendant que le code est mis à jour.

Cette dernière proposition résume à elle seule tout l’argumentaire :

1. Détecter les vulnérabilités plus vite que les attaquants ne peuvent les exploiter.
2. Corrigez les failles avant qu’elles ne puissent être transformées en armes.
3. Protégez l’application à l’exécution en attendant que le code soit corrigé.

Les trois disciplines ne fonctionnent qu’ensemble. Aucune d’entre elles ne fonctionne seule.

La nouvelle normalité

Désormais, c’est ainsi que fonctionne la sécurité des logiciels. Il ne s’agit ni d’une campagne ni d’une réaction à la sortie d’un modèle en particulier. La fenêtre permettant d’appliquer des correctifs s’est refermée et ne se rouvrira pas.

Certaines entreprises considéreront qu’il s’agit simplement d’un cap à passer. Seules celles qui accepteront cette situation comme la nouvelle norme et adapteront continuellement leur architecture en conséquence, tant au niveau du code que du trafic, prospéreront.

F5 se prépare à cette nouvelle normalité. Nos clients aussi. Ensemble, nous mènerons à bien ce travail essentiel.

À 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