Patch management : ce que 1 447 failles du catalogue KEV disent de vos délais
de correctif

Le 10 juin 2026, la CISA a publié la directive BOD 26-04, qui abroge les BOD 19-02 et 22-01 et retire le score CVSS des critères de délai imposés aux agences fédérales américaines. À la place, quatre variables : l'actif est-il joignable depuis un réseau public, la faille figure-t-elle au catalogue KEV, l'exploitation est-elle automatisable de bout en bout, et donne-t-elle un contrôle partiel ou total ? Selon les combinaisons : 3 jours, 14 jours, 60 jours, ou simple correction à la prochaine mise à niveau. Le catalogue KEV devient le pivot de la politique de patch management.

Encore faut-il savoir ce que vaut ce signal dans le temps. Quand une faille entre au KEV, depuis combien de temps est-elle publique ? Et le CERT-FR, la source que lit un RSSI français, l'avait-il signalée avant ? J'ai mesuré les deux sur les données ouvertes. Les réponses changent la façon de construire un cycle de correctifs, et c'est l'objet de la suite : l'étude d'abord, puis ce qu'elle implique pour les arbitrages qui font le vrai travail, actifs non patchables, correctifs qui cassent la production, mesure de l'exposition et exigences de NIS2.

La méthode, en court

Le catalogue Known Exploited Vulnerabilities de la CISA a été téléchargé le 6 octobre 2026 (version 2026.10.04, 1 734 entrées). Pour chaque faille, j'ai calculé l'écart entre sa date de publication dans la NVD (instantané du 3 octobre) et sa date d'inscription au catalogue, le champ dateAdded. J'écarte le lot initial du 3 novembre 2021, un stock de failles anciennes versé d'un coup à l'ouverture du catalogue, ce qui laisse 1 447 failles.

Pour le CERT-FR, j'ai pris un sous-ensemble plus récent : les 317 failles ajoutées au KEV en 2024 et 2025 et publiées depuis le 1^er janvier 2024. Je les ai cherchées par leur identifiant CVE dans trois canaux : les avis et les alertes (versions JSON, 4 342 avis et 84 alertes citant au moins une CVE) et les bulletins d'actualité hebdomadaires, qui n'existent qu'en HTML et ont été archivés tels quels (210 bulletins de 2023 à 2026). Une faille évoquée sans son identifiant n'est pas comptée.

Scripts, fichiers bruts et empreintes SHA-256 sont conservés. Une contre-expertise indépendante a ensuite recalculé l'étude et relevé trois défauts dans sa première version, corrigés ici. Les bulletins d'actualité n'étaient pas moissonnés, ce qui faisait passer pour "jamais citées" des failles qui l'étaient. Et le délai médian était calculé sur les seules failles récentes déjà inscrites, ce qui écarte par construction les longs délais encore à venir et raccourcit artificiellement la médiane. Le calcul porte désormais sur toutes les inscriptions postérieures au lot initial. Enfin, 114 failles présentées comme "citées avant la CISA" étaient en majorité de simples relais de correctif.

Combien de temps avant l'entrée au catalogue KEV

La moitié des 1 447 failles sont entrées au catalogue plus de 164 jours après leur publication. Le graphique ci-dessous montre pourquoi une médiane seule ne suffit pas : les inscriptions se concentrent aux deux extrémités, 29,4 % dans la semaine, 42,8 % après plus d'un an.

Deux populations se superposent. 592 failles avaient été publiées avant la création du catalogue : la CISA rattrape un stock, avec un délai médian de 4,9 ans. Les 855 autres, publiées depuis novembre 2021, sont inscrites bien plus vite, en 8 jours en médiane, un chiffre qui remontera à mesure que des failles de 2024 ou 2025 entreront au catalogue avec retard. Au total, seules 426 failles (29,4 %) sont entrées dans la semaine qui a suivi leur publication, ou avant, et 620 (42,8 %) plus d'un an après.

Ce second chiffre est celui qui devrait inquiéter un responsable de correctifs. Une faille inscrite au KEV trois ans après sa publication n'est pas une faille neuve : c'est une ligne qui dort dans votre arriéré, notée "moyenne" ou "élevée", et que personne n'a rouverte depuis. Le jour de son inscription, elle passe de la file lente à l'urgence, sans qu'aucun nouveau correctif ne soit publié.

Les failles récentes : une sur deux dans la semaine

Pour isoler la vitesse sur les failles neuves, j'ai suivi deux années de publication complètes. Sur les 160 failles publiées en 2024 et inscrites depuis au KEV, 78 (48,8 %) l'ont été dans les sept jours suivant leur publication, ou avant ; pour 2023, 87 sur 165 (52,7 %). Rapporté à toutes les CVE publiées, c'est rare : 19,5 pour 10 000 en 2024, 30,2 pour 10 000 en 2023.

Les deux années n'ont pas le même recul, il faut donc les comparer sur une fenêtre commune. Sur les failles inscrites dans l'année suivant leur publication, la part entrée en sept jours ou moins vaut 60,0 % pour 2023 (87 sur 145) et 52,3 % pour 2024 (78 sur 149). Une faille récente qui finit au catalogue y entre donc le plus souvent très vite, et plus vite encore s'il s'agit d'une faille zero-day sur un VPN ou un pare-feu, ce qui rejoint ce que décrivent les études de délai d'exploitation : Mandiant (Google Cloud) mesurait en octobre 2024 5 jours en moyenne entre divulgation et exploitation pour les failles de 2023, contre 32 jours en 2021-2022, zero-days compris, qui font 70 % de son échantillon. Côté défenseur, le DBIR 2026 de Verizon mesure 43 jours de délai médian de remédiation complète pour les failles du catalogue KEV (32 l'année précédente).

Un cas réel rend cette fenêtre palpable. Citrix publie le correctif de CVE-2023-4966, dite "Citrix Bleed", le 10 octobre 2023. La CISA l'ajoute au KEV le 18 octobre, huit jours plus tard. Le 25 octobre, un exploit public circule. Le 21 novembre 2023, la CISA et le FBI publient un avis conjoint sur les affiliés de LockBit 3.0 qui s'en servent pour chiffrer des organisations entières. Entre le correctif et le rançongiciel : six semaines, sur un équipement dont la fonction même est d'être exposé.

Le CERT-FR les avait-il vues ?

Un RSSI français ne lit pas d'abord la CISA, il lit le CERT-FR. Sur les 317 failles inscrites au KEV en 2024 et 2025, le CERT-FR en a cité 289, soit 91,2 %, dans un avis, une alerte ou un bulletin d'actualité. La couverture dépend beaucoup du canal.

Les bulletins d'actualité hebdomadaires font l'essentiel du travail : 83 failles n'apparaissent que là, dans le tableau des vulnérabilités significatives. S'abonner aux seuls avis, c'est passer à côté de 83 failles de ce sous-ensemble (26 %) que le CERT-FR a pourtant relayées ailleurs. Les alertes, elles, sont réservées aux cas graves et n'en couvrent qu'une sur dix.

Restent 28 failles citées dans aucun des trois canaux, vérifiées une à une. On y trouve des produits de niche ou peu déployés en France (caméras PTZOptics, Edimax et GeoVision, Advantive VeraCore, Trimble Cityworks, CyberPanel, Rejetto HFS), mais aussi des produits courants en entreprise : ServiceNow, Commvault Command Center, SimpleHelp, Progress WhatsUp Gold, Apache OFBiz, GeoServer, Oracle Agile PLM. Le CERT-FR n'a pas vocation à tout relayer, mais votre veille, elle, doit couvrir votre parc.

Avant ou après la CISA ?

La comparaison des dates bute sur une difficulté : le CERT-FR ne publie que la dernière version d'un avis ou d'une alerte. Quand une CVE, ou la mention de son exploitation, a été ajoutée par une révision que la description ne date pas, on sait seulement qu'elle se situe entre la version initiale et la dernière. J'ai donc retenu la date la plus tardive compatible, celle qui est la plus défavorable au CERT-FR : c'est la seule qui permette d'affirmer une antériorité. Les bulletins d'actualité, eux, ne sont presque jamais révisés.

Avec cette règle, pour 129 des 317 failles (40,7 %), un document du CERT-FR citait déjà la faille avant son entrée au KEV. Mais le plus souvent pour relayer le correctif de l'éditeur, sans parler d'exploitation : c'est le cas de 71 d'entre elles. Le CERT-FR signalait déjà une exploitation avant la CISA pour 58 failles (18,3 %), via un avis dans 31 cas et un bulletin d'actualité dans 27. Les avis reprennent le plus souvent l'annonce de l'éditeur, du type "l'éditeur indique que la vulnérabilité est activement exploitée". En retenant à l'inverse la date de la version initiale, hypothèse la plus favorable, on monte à 136 failles citées avant, dont 59 avec mention d'exploitation : l'incertitude des révisions ne change pas l'ordre de grandeur.

Deux précautions de lecture. La comparaison se fait au jour calendaire, alors que la CISA date en heure américaine et le CERT-FR en heure de Paris : les citations du même jour sont comptées à part, ni avant ni après. Et le classement entre "relais de correctif" et "mention d'exploitation" a été fait par expressions régulières, puis relu à la main pour toutes les failles signalées avant le KEV.

Ce que ça change pour votre cycle de patch

Trois conséquences pratiques.

Le KEV doit être rejoué contre l'arriéré, pas seulement contre le flux. 42,8 % des inscriptions concernent des failles publiées depuis plus d'un an. Croiser chaque mise à jour du catalogue avec l'inventaire des correctifs non appliqués, tous âges confondus, est le seul moyen de voir une vieille ligne "moyenne" devenir une urgence. Et un tri par gravité ne suffit pas à les repérer : sur les failles du catalogue publiées depuis 2016, 62,4 % notent sous 9.0 en CVSS, comme le détaille l'étude sur le score CVSS face au catalogue KEV.

Sur une faille neuve, n'attendez pas le KEV. Pour les cohortes 2023 et 2024, environ une faille inscrite sur deux l'a été dans la semaine suivant sa publication, ou avant. Si votre voie rapide se déclenche à l'inscription au catalogue, elle part déjà en retard, puisque l'inscription constate une exploitation déjà en cours. Elle doit s'ouvrir sur vos propres signaux : un équipement exposé concerné, une annonce d'exploitation de l'éditeur, un bulletin du CERT-FR.

Lisez les bulletins d'actualité du CERT-FR. Ils couvrent 88,6 % des failles de l'échantillon, et 83 n'y apparaissent que là. Dans 27 cas, c'est un bulletin d'actualité qui signalait l'exploitation avant l'inscription au KEV (58 tous canaux confondus). C'est gratuit, en français, et ça arrive une fois par semaine.

Ces signaux ont une limite commune : ils décrivent une faille dans l'absolu, jamais votre installation. Une faille inscrite au KEV sur un service enfoui derrière trois couches d'authentification peut attendre ; une faille moyenne sur un portail exposé qui porte vos données clients ne le peut pas. La variable qui tranche est l'exposition, que la BOD 26-04 place en tête de ses critères, et c'est elle qu'une gestion des vulnérabilités bien menée croise avec le KEV et l'EPSS avant de produire une échéance. Côté rançongiciels, les familles de produits les plus souvent visées, VPN, pare-feu et messagerie notamment, sont détaillées dans l'étude sur les failles qu'exploitent les ransomwares.

Les actifs qu'on ne peut pas patcher

Toute politique de correctifs finit par heurter le même mur : une partie du parc ne se patche pas, et pas par négligence. Quatre familles reviennent en permanence, avec des raisons parfaitement défendables.

• Les systèmes industriels. Un automate qui pilote une ligne de production ne redémarre pas parce qu'un correctif est sorti. La fenêtre de maintenance est trimestrielle, parfois annuelle, et le firmware est validé avec la machine. Un patch hors validation dépasse le risque informatique : il met en jeu la sécurité des personnes et fait sauter la garantie constructeur.
• Le biomédical. Un scanner ou une pompe à perfusion est un dispositif médical certifié. Modifier son logiciel peut invalider la certification, et la mise à jour n'arrive que quand le fabricant a fait revalider l'ensemble. L'hôpital subit le calendrier de l'éditeur, il ne le fixe pas. C'est une des raisons qui expliquent pourquoi les établissements de santé restent une cible facile.
• Les appliances en fin de support. Là, il n'y a plus de correctif du tout. Windows Server 2012 R2 est sorti du support étendu le 10 octobre 2023, Windows 10 le 14 octobre 2025. Une CVE publiée après cette date reste ouverte, sauf souscription aux mises à jour de sécurité étendues payantes de Microsoft, elles-mêmes limitées dans le temps ; la seule remédiation possible est le remplacement, qui est un projet, pas un ticket.
• La dépendance applicative figée. Un ERP qui certifie sa compatibilité avec une seule version de base de données ou de runtime, un composant maison dont l'auteur est parti, une bibliothèque abandonnée en amont. Monter la version casse l'application ; ne pas la monter laisse la CVE ouverte. Ce cas se traite en partie très en amont, en sachant ce qu'on embarque : c'est tout l'intérêt d'un SBOM tenu à jour, et la raison pour laquelle une attaque sur la chaîne d'approvisionnement se propage si loin.

Pour ces actifs, le choix se fait entre réduire l'exposition et l'accepter en connaissance de cause. Les mesures compensatoires ne sont pas équivalentes entre elles, et leur ordre compte : la première supprime réellement le risque d'exploitation à distance, la dernière se contente de vous prévenir qu'elle a eu lieu.

Reste à écrire la décision. Un actif non patchable sans trace écrite devient, six mois plus tard, un actif que personne ne sait expliquer devant un auditeur ou après un incident. Le tableau ci-dessous est le minimum tenable : il tient dans un tableur, et chaque ligne produit soit un ticket, soit une acceptation de risque datée et signée.

Toute branche de cette table qui ne finit pas par un patch finit par une signature.

Le correctif qui casse la production, et le délai de bake

L'autre moitié de l'arbitrage est rarement dite à voix haute par les équipes sécurité, alors qu'elle décide de tout côté production : un correctif peut faire plus de dégâts que la faille qu'il referme. Le Patch Tuesday du 11 janvier 2022 a livré les mises à jour KB5009624, KB5009557 et KB5009555 ; sur Windows Server, elles ont provoqué des boucles de redémarrage sur les contrôleurs de domaine, empêché Hyper-V de démarrer et rendu des volumes ReFS inaccessibles. Microsoft a publié des correctifs hors bande une semaine plus tard. Entre-temps, la seule remédiation disponible était de désinstaller la mise à jour de sécurité.

L'archétype de la casse par déploiement global reste la mise à jour de contenu CrowdStrike Falcon du 19 juillet 2024, qui a mis hors service environ 8,5 millions de machines Windows d'après l'estimation publiée par Microsoft. Ce n'était pas un correctif de vulnérabilité, mais le mécanisme en cause est celui du patch management, trait pour trait : une diffusion simultanée à tout le parc, sans anneau de déploiement progressif, sur un composant qui s'exécute au cœur du système.

D'où la question du délai de bake, ce temps d'observation entre la disponibilité d'un correctif et son déploiement généralisé. Il se présente souvent comme une bonne pratique, quand il s'agit d'un pari chiffrable. Chaque jour de bake est un jour d'exposition supplémentaire à une faille alors que le délai moyen entre divulgation et exploitation est tombé à 5 jours en 2023. Chaque jour économisé est un jour de test en moins. Une durée unique pour tout le parc est donc forcément fausse quelque part : soit trop lente sur ce qui brûle, soit trop rapide sur ce qui est fragile.

Ce qui rend un déploiement rapide acceptable, ce n'est pas la confiance dans la qualité du correctif, c'est la capacité démontrée à revenir en arrière. Un retour arrière qu'on n'a jamais répété n'existe pas : le jour où il faut désinstaller une mise à jour sur quarante serveurs à trois heures du matin, on découvre qu'il manque la clé de chiffrement du disque, que la sauvegarde de configuration date de l'an dernier, ou que le rollback impose un redémarrage qu'on voulait justement éviter. Tester le retour arrière coûte une demi-journée par an et débloque toute la politique de patch rapide.

La mesure qui compte : le temps d'exposition externe

La plupart des tableaux de bord de patch management mesurent un taux de conformité : le pourcentage de machines à jour dans l'outil de déploiement. C'est une métrique de processus, utile en interne, et elle ne dit rien du risque réel. La question qu'un attaquant se pose est beaucoup plus étroite : combien de temps un service joignable depuis Internet a-t-il continué d'annoncer une version vulnérable après la publication du correctif ? C'est cette durée qu'il faut suivre, parce que c'est la seule qu'il exploite.

Cette durée se définit avec deux dates. T0 est la date de publication du correctif par l'éditeur ; T1, la date à laquelle le service exposé cesse d'annoncer la version vulnérable. Le temps d'exposition externe d'un actif est l'écart entre les deux. Par classe d'actifs, le tableau de bord affiche alors :

• La médiane et le 90e percentile, jamais la moyenne : celle-ci est écrasée par le parc facile à patcher.
• La part des actifs exposés découverts hors de l'inventaire officiel, puisque ceux-là ne figurent dans aucun taux de conformité.
• Le nombre d'actifs sans correctif possible, avec la date de fin de leurs mesures compensatoires.

Trois pièges rendent cette mesure fausse quand on la construit naïvement. Le premier est le plus banal : on ne mesure que ce qu'on connaît. Un taux de conformité à 98 % calculé sur un inventaire qui ignore un sous-domaine de préproduction, une instance montée par un prestataire ou un actif hérité d'une acquisition décrit un parc qui n'existe pas. Changer de scanner de vulnérabilité n'y fera rien, puisque ces outils qualifient les cibles qu'on leur fournit et ne vont pas en chercher d'autres. Il faut une découverte d'actifs en continu, et c'est la raison d'être de l'EASM : adopter le point de vue de l'attaquant sur votre périmètre plutôt que celui de votre CMDB.

Le deuxième est technique et coûte cher : le paquet mis à jour ne suffit pas. Corriger une bibliothèque système ne protège pas les processus déjà lancés, qui continuent d'exécuter en mémoire l'ancienne version tant qu'ils n'ont pas redémarré. C'est le grand classique d'OpenSSL et de la glibc : needrestart ou lsof | grep DEL vous diront qui tourne encore sur du code supprimé. Même logique côté conteneurs : mettre à jour l'image de base ne change rien tant que l'image n'est pas reconstruite et redéployée. Un correctif installé mais pas actif se voit de l'extérieur, et il est compté "à jour" dans tous les tableaux de bord internes.

Le troisième est organisationnel : sans propriétaire d'actif, la mesure produit un chiffre que personne n'a le mandat de faire baisser. C'est le même problème que celui d'un rapport d'audit sans suite, et il se traite de la même façon, en transformant la liste en file de travail assignée : notre article sur le plan de remédiation détaille ce passage du constat à la correction tracée.

Ce que NIS2 exige, et ce qu'elle n'exige pas

Il circule beaucoup d'approximations sur les délais de patch imposés par la réglementation européenne. Le texte est pourtant clair, et il ne contient aucun chiffre. La directive NIS2 (directive (UE) 2022/2555) demande à son article 21.2, point e, des mesures couvrant "la sécurité de l'acquisition, du développement et de la maintenance des réseaux et des systèmes d'information, y compris le traitement et la divulgation des vulnérabilités".

Le niveau de détail le plus élevé disponible aujourd'hui se trouve dans le règlement d'exécution (UE) 2024/2690 du 17 octobre 2024, qui précise ces exigences pour une liste limitée d'entités : fournisseurs de services DNS, registres de noms de domaine, fournisseurs d'informatique en nuage, de centres de données, de réseaux de diffusion de contenu, prestataires de services gérés et de sécurité gérés, places de marché, moteurs de recherche, plateformes de réseaux sociaux et prestataires de services de confiance. Son annexe consacre le point 6.6 à la gestion des correctifs de sécurité, et quiconque écrit une politique de correctifs a intérêt à le lire de près.

• Point 6.6.1 (a) : les correctifs sont appliqués "dans un délai raisonnable après leur mise à disposition". Le texte laisse à l'entité le soin de fixer ce délai, dans le cadre de la proportionnalité de l'article 21.1 de NIS2 (exposition aux risques, taille, probabilité et gravité des incidents).
• Point 6.6.1 (b) : les correctifs sont testés avant application en production. Le bake est donc une exigence écrite. Encore faut-il qu'il soit proportionné, ce qui nous ramène aux anneaux de déploiement.
• Point 6.6.1 (c) : les correctifs proviennent de sources de confiance et leur intégrité est vérifiée. Un canal de mise à jour est un canal d'exécution de code privilégié, donc une cible de choix.
• Point 6.6.1 (d) et point 6.6.2 : des mesures additionnelles sont mises en œuvre et les risques résiduels acceptés lorsqu'un correctif n'est pas disponible ou pas appliqué. Le texte autorise même explicitement à ne pas appliquer un correctif lorsque "les inconvénients de leur application l'emportent sur les avantages en matière de cybersécurité", à charge de documenter et motiver la décision.

Autrement dit, la réglementation européenne valide la posture décrite plus haut : on peut ne pas patcher, à condition de l'avoir décidé, écrit et compensé. À l'inverse, certains référentiels sectoriels, eux, chiffrent : PCI DSS 4.0.1 exige à son exigence 6.3.3 l'installation des correctifs critiques dans le mois qui suit leur publication. Selon les contraintes qui pèsent sur vous, le délai est donc soit imposé, soit à écrire et à défendre. Dans les deux cas, mieux vaut un délai tenu qu'un délai ambitieux.

À retenir

• 164 jours de délai médian entre la publication d'une faille et son inscription au KEV, sur 1 447 failles ajoutées depuis fin 2021 : 29,4 % en sept jours ou moins, 42,8 % après plus d'un an. La date d'inscription est une borne haute, pas la date d'exploitation.
• Les failles récentes vont vite : 52,7 % des failles de 2023 et 48,8 % de celles de 2024 qui ont fini au catalogue y sont entrées dans la semaine, ou avant. Une voie rapide déclenchée par le KEV part en retard.
• Le CERT-FR couvre 91,2 % des 317 failles inscrites au KEV en 2024-2025, surtout grâce à ses bulletins d'actualité. Il citait la faille avant son inscription au KEV dans 129 cas, le plus souvent pour relayer le correctif, et signalait déjà l'exploitation dans 58.
• Les actifs non patchables (industriel, biomédical, fin de support, dépendance figée) se traitent par mesures compensatoires ordonnées, la plus efficace étant de retirer l'actif d'Internet, et par une acceptation de risque datée et signée.
• La métrique qui compte n'est pas le taux de conformité de l'outil de déploiement, mais le temps pendant lequel un service exposé continue d'annoncer une version vulnérable, mesuré avec des anneaux de déploiement et un retour arrière réellement répété.
• NIS2 impose une politique de gestion des correctifs, pas un délai chiffré universel : le règlement d'exécution (UE) 2024/2690 parle de "délai raisonnable" et autorise à ne pas patcher, à condition de documenter et de compenser.

Mesurer le temps d'exposition externe suppose de savoir ce qui est joignable, ce que notre plateforme EASM établit en cartographiant le périmètre externe en continu et en datant chaque actif. Pour les failles qui survivent au correctif, un pentest web blackbox tranche l'exploitabilité réelle, et la page contact reste le chemin le plus court pour en parler avant d'outiller quoi que ce soit.

Questions fréquentes sur le patch management