La vulnérabilité au score de gravité le plus élevé n'est pas nécessairement la première qu'une organisation doit corriger. Le virage de la CISA vers le risque opérationnel, en juin 2026, place l'exposition à Internet, l'exploitation confirmée, l'automatisation des attaques et les conséquences aux côtés de la gravité technique. En parallèle, des expériences d'IA rapportées suggèrent que certains travaux de développement d'exploits peuvent désormais tenir dans les heures nécessaires aux défenseurs pour identifier les systèmes concernés.
Ces évolutions sont liées, sans prouver que toute faille peut être exploitée de façon autonome. La politique concerne les priorités fédérales de correction ; les résultats des modèles proviennent de recherches contrôlées ; un incident décrit par Google révèle une intention criminelle, mais laisse des détails techniques importants inconnus. Ensemble, ils montrent le décalage entre une recherche offensive accélérée et des files de vulnérabilités actualisées périodiquement et rapprochées manuellement.
Ce que change la directive fédérale
Le récit situe au 10 juin 2026 la publication de la Binding Operational Directive 26-04, destinée aux agences civiles fédérales. Son cadre combine exposition à Internet, inscription au catalogue Known Exploited Vulnerabilities, automatisation de l'exploitation et impact technique d'une compromission. Il ne soumet pas toutes les entreprises privées à la même directive et ne supprime ni les analyses de vulnérabilités ni le CVSS.
Chaque facteur décrit une partie différente de l'attaque. L'exposition indique si l'adversaire peut atteindre un actif. L'inscription au KEV signifie que la CISA dispose de preuves d'exploitation réelle. L'automatisation modifie la facilité de réutilisation d'une capacité offensive. Les conséquences distinguent la compromission d'un service de test isolé de l'accès à un système d'identité ou au plan de contrôle de production.
Les obligations dépassent le réordonnancement des tickets. Les agences doivent identifier et étiqueter les actifs publiquement exposés, maintenir l'accès nécessaire aux scans et attester régulièrement les adresses Internet et domaines exposés. Certains cas imposent également de rechercher une compromission antérieure au correctif. Installer ce dernier et déterminer si une intrusion a déjà eu lieu sont deux tâches distinctes.
Une CVE identifie une faille divulguée, pas l'architecture, les contrôles, les dépendances métier ou l'historique d'incidents d'une organisation. Deux sociétés peuvent livrer le même paquet vulnérable alors qu'une seule expose la fonction concernée. Dans une même entreprise, une instance de production traitant les identités clients et une image de développement inaccessible vouée à la suppression ne nécessitent pas forcément le même traitement. La décision porte donc sur la faille dans un système actif plutôt que sur une faille isolée.
Les preuves concernant l'IA ont des chiffres et des limites
La feuille de route de Google sur l'exploitation par IA, publiée en avril 2026, décrit des modèles généralistes plus capables de découvrir des vulnérabilités et d'aider à générer des exploits fonctionnels. Ils peuvent comparer une version corrigée à la précédente, repérer les modifications de sécurité et transformer un plantage en démonstration reproductible. Cela réduit le coût d'exploration des hypothèses, sans garantir de contourner les défenses modernes ou de fonctionner dans d'autres configurations.
En mai, Google a déclaré avoir perturbé un groupe criminel qui cherchait à utiliser l'IA contre une vulnérabilité jusque-là inconnue chez une autre entreprise. Le récit d'Associated Press relie capacités des modèles et intérêt adverse réel. John Hultquist, analyste en chef du renseignement sur les menaces de Google, a évoqué l'ère de l'exploitation pilotée par IA ; les informations publiques limitées n'établissent toutefois pas la part accomplie indépendamment par le modèle.
Les tests Anthropic Mythos rapportés ont étudié des vulnérabilités divulguées après la date limite de connaissances des modèles, réduisant la possibilité d'une simple restitution de code public mémorisé. Le système a produit sa première preuve de concept pour le noyau Windows en 31 minutes, puis huit exploits distincts sur 21 défauts de noyau testés. Il a aussi généré huit exploits fonctionnels d'exécution de code sur 18 correctifs de sécurité Firefox. L'exploit de noyau réussi le plus long aurait demandé environ 5,7 heures.
Ce sont des résultats de recherche contrôlée, pas un taux de réussite mesuré dans une campagne criminelle incontrôlée. Anthropic a fourni accès, expertise, infrastructure d'évaluation et cibles définies. Les opérateurs réels affrontent des environnements incomplets, de l'incertitude et des contraintes de sécurité opérationnelle ; de nombreuses tentatives échouent, plantent sans dommage ou supposent des conditions irréalistes. Inversement, les attaquants peuvent choisir des produits favorables, réutiliser des outils et acheter des accès. La conclusion défendable est une capacité accrue à examiner les divulgations avant la fin du premier triage, non une compromission autonome universelle.
L'asymétrie des obligations importe. L'attaquant n'a besoin que d'un chemin exploitable. Les défenseurs doivent découvrir les déploiements, trouver leurs responsables, évaluer les conséquences, tester les correctifs et coordonner les changements sans casser la production. Un scan hebdomadaire suivi d'exports, de dédoublonnage et d'une réunion supplémentaire laisse des délais que l'investigation assistée par IA ne partage pas nécessairement.
CVSS, EPSS et KEV répondent à des questions différentes
Le CVSS reste un langage commun utile pour la complexité d'attaque, les privilèges, l'interaction utilisateur et les effets sur confidentialité, intégrité et disponibilité. Sa gravité technique ne démontre ni qu'une organisation utilise la version concernée, ni que la fonction est accessible, ni que des criminels l'exploitent aujourd'hui. Une faille mieux notée dans une image de test inaccessible peut être moins urgente qu'une faille distante activement exploitée dans un service d'authentification public sans contrôle compensatoire efficace.
Les recommandations EPSS de FIRST apportent un autre signal. Mis à jour quotidiennement, EPSS estime la probabilité d'activité d'exploitation d'une vulnérabilité publiée sur les 30 prochains jours. Il utilise notamment code public, discussions de sécurité, caractéristiques des failles et activité observée. Il complète la gravité sans la remplacer ni prédire l'attaque d'une organisation désignée.
KEV consigne l'exploitation confirmée au lieu de la prévoir. Une confirmation récente peut peser plus qu'une prévision, mais le catalogue ne recense pas toutes les campagnes actives : collecte et validation demandent du temps, et certaines activités ciblées restent secrètes. Ni KEV ni EPSS ne prouvent déploiement local, accessibilité ou accès aux données critiques. Un faible EPSS n'est pas un certificat de sécurité, surtout parmi des milliers de constats.
FIRST déconseille également de multiplier EPSS par CVSS pour fabriquer un score de risque apparemment précis. L'un est une probabilité calibrée, l'autre une note technique ordinale ; leur produit n'a pas de sens statistique clair. Leur combinaison utile constitue des preuves pour décider, pas une opération arithmétique effaçant leurs différences.
Le contexte peut créer une fausse assurance
Un dossier défendable associe identité du composant, version déployée et responsable aux preuves adverses : KEV, exploits publics, évolution EPSS, scans et renseignements crédibles. Il doit aussi contenir contexte de déploiement et d'appel, contrôles validés, données, frontières d'identité, processus ou engagements clients menacés. Les raisons d'accélérer, différer, atténuer ou accepter doivent être conservées. Le guide connexe sur la base de connaissances d'ingénierie traite de décisions consultables auprès de la documentation technique, pas d'un substitut à la découverte des actifs.
La difficulté est que le contexte change. Déploiements déplacés, règles de pare-feu modifiées, nouveaux services publics et transferts de responsabilité se succèdent. Conteneurs éphémères, fonctions autoscalées, images de base et dépendances transitives compliquent les inventaires cloud. Une nomenclature logicielle identifie les composants sans prouver leur exécution. L'analyse statique révèle des chemins possibles ; le comportement réel dépend encore de la configuration, du trafic et de l'état de l'application.
Ne pas trouver de chemin accessible est une preuve limitée, pas une preuve d'absence. Pare-feu applicatifs, règles réseau et contrôles de terminaux peuvent réduire l'exposition, mais une mauvaise configuration, un contournement ou un changement opérationnel peut les invalider. Responsable, date de validation et conséquences d'échec valent plus que l'étiquette « protégé par pare-feu ». Un responsable absent ou un contrôle non vérifié doit attirer l'attention, non justifier silencieusement une priorité moindre.
Un argument fournisseur n'est pas une validation indépendante
Russ Andersson, PDG de RapidFort, critique le comptage des CVE dans une analyse sponsorisée. L'intérêt commercial compte : il dirige un fournisseur de sécurité de la chaîne logicielle dont la catégorie de produits correspond à l'approche proposée. Cela ne réfute pas la priorisation contextuelle, mais ni cet argument ni la politique fédérale ne prouvent la couverture complète d'une plateforme.
Le classement automatique dépend des intégrations, des capteurs et des métadonnées. L'évaluation indépendante doit examiner les reports erronés, pas seulement une file urgente réduite. Retirer 90 % des constats est une illustration d'efficacité, pas une preuve de sécurité si une faille accessible exclue permet ensuite une intrusion. Exploitation confirmée et exposition publique critique justifient un plancher de priorité élevée, avec prudence pour les actifs à fortes conséquences et escalade explicite des informations incomplètes.
L'IA défensive accélère analyse des avis, cartographie, tests et propositions de correctifs, mais peut inventer des détails ou réparer le mauvais chemin. L'automatisation collecte les preuves et crée les tickets ; les humains autorisent encore les indisponibilités et arbitrent les enjeux métier. Tests, revue de code et protections de déploiement doivent rester proportionnés à l'impact. Une défense plus rapide ne signifie pas des changements non examinés en production.
Le test est une exposition plus courte, pas un tableau plus propre
Trois sources de preuves détermineront l'efficacité. La mise en œuvre fédérale devrait montrer des procédures actualisées et des règles d'automatisation et d'impact clarifiées, surtout un confinement plus rapide des KEV exposées. Les études indépendantes doivent fournir des comparaisons reproductibles entre modèles et classes de failles, avec travail humain, calcul, échecs, outils et contraintes réalistes. Davantage d'incidents montrerait une diffusion hors recherche ; peu de signalements n'annulerait pas le risque, mais contesterait une automatisation universelle immédiate.
Dans l'entreprise, la chronologie utile va de la divulgation à la découverte, à l'attribution, à l'atténuation puis à la correction vérifiée. Les actifs Internet et les constats KEV doivent rester distincts des systèmes internes et des constats non confirmés. Une moyenne globale ou des milliers de tickets sans grande conséquence peuvent masquer un chemin critique ouvert. Les lacunes de couverture et les reports dus à un contexte erroné doivent accompagner la mesure de vitesse.
Le modèle résultant est une boucle continue entre renseignement, télémétrie de production, responsables, ingénierie et réponse aux incidents, pas une gestion entièrement autonome. Un service déployé ce matin et un pare-feu modifié ce soir peuvent invalider le tableau du mois dernier. La politique donne une direction ; preuves actuelles, responsabilités établies et travaux vérifiés déterminent si la fenêtre d'exploitation se ferme réellement.
Entrée agrégée d’origine (Google News RSS, pas la directive CISA)