Patch management : arbitrer, parce qu'on ne patchera jamais tout
à temps

Le 10 juin 2026, la CISA a publié la directive BOD 26-04, qui abroge la BOD 22-01 et retire purement et simplement 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. L'administration qui avait popularisé le tri par gravité vient d'acter qu'il ne tenait plus.

C'est un bon résumé de l'état du patch management en 2026. Personne n'ignore qu'il faut appliquer les correctifs ; tout le monde bute sur la même chose, décider lesquels, quand, et que faire des actifs pour lesquels la réponse "patcher" n'existe tout simplement pas. Le geste technique, lui, est réglé depuis vingt ans par les outils de déploiement. Ce qui coince tient dans un arbitrage entre deux risques qui pointent en sens inverse : se faire exploiter, et casser la production.

La fenêtre réelle entre le correctif et l'exploitation de masse

L'intuition, sur ce sujet, a une génération de retard, et les chiffres publiés le montrent sans ménagement. Google Threat Intelligence (ex-Mandiant) a publié en octobre 2024 son analyse des tendances de time-to-exploit sur les 138 vulnérabilités divulguées en 2023 et observées exploitées : le délai moyen entre divulgation et exploitation est tombé à 5 jours, contre 32 jours en 2021-2022 et 63 jours en 2018-2019. Dans le même jeu de données, 97 des 138 failles ont été exploitées en zero-day, c'est-à-dire avant qu'un correctif existe.

VulnCheck arrive au même constat par un autre chemin dans son bilan 2024 Trends in Vulnerability Exploitation : 23,6 % des failles entrées au KEV en 2024 étaient déjà exploitées le jour même de la publication de leur CVE, ou avant (27 % en 2023). Et le DBIR 2025 de Verizon mesure, pour les vulnérabilités d'équipements de bordure présentes au KEV, un délai médian entre divulgation et exploitation de masse de zéro jour, contre cinq jours toutes catégories confondues.

Face à ces chiffres, la course est perdue d'avance pour une partie du parc, et c'est ce qui rend l'arbitrage inévitable. Le DBIR 2026 donne l'autre moitié de l'équation, côté défenseur : un délai médian de 43 jours pour remédier une vulnérabilité connue comme exploitée (contre 32 l'année précédente), et seulement 26 % de ces failles totalement refermées. L'exploitation de vulnérabilités y devient le premier vecteur d'accès initial, à 31 % des compromissions.

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. Fin 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é.

Pourquoi trier par CVSS est une mauvaise politique de patch management

Le réflexe le plus répandu consiste à écrire une politique du type "critique sous 30 jours, élevé sous 60", en s'appuyant sur le score CVSS. Ça a le mérite d'être auditable. Ça a le défaut d'être arithmétiquement intenable, et le FIRST l'a chiffré en publiant EPSS v3 : une politique "CVSS supérieur ou égal à 7" impose de traiter environ 58 % des CVE publiées pour couvrir 82 % des failles réellement exploitées. Le même niveau de couverture s'obtient avec un seuil EPSS en traitant de l'ordre de 7 % du volume. Huit fois moins de travail pour la même protection.

Le CVSS répond à la question "quel dégât si cette faille est exploitée ?". Une politique de patch, elle, a besoin de savoir si et quand elle le sera. Ce sont deux questions différentes, et c'est la raison de fond du virage de la BOD 26-04. Le détail de la mécanique EPSS et KEV est traité dans notre guide de la gestion des vulnérabilités ; ce qui nous intéresse ici, c'est ce que ces signaux changent concrètement dans une politique de correctifs, et surtout ce qu'ils ne changent pas.

Ce que le KEV et l'EPSS règlent

Le catalogue KEV règle le cas facile : quand une faille y entre, le débat interne est clos. Ce n'est plus une estimation de risque, c'est un constat d'exploitation. Historiquement, la BOD 22-01 du 3 novembre 2021 en avait fait un mécanisme de délai : deux semaines pour les CVE récentes, six mois pour les plus anciennes. L'EPSS, lui, règle le cas intermédiaire, les milliers de failles qui ne sont pas au KEV et pour lesquelles il faut bien décider quelque chose : il donne une probabilité d'exploitation à 30 jours, réévaluée quotidiennement, là où le CVSS reste figé pour l'éternité.

Ce qu'ils ne règlent pas

Ces deux signaux sont mondiaux. Ils décrivent une faille dans l'absolu, jamais votre installation. Un KEV à 10 sur un service enfoui derrière trois couches d'authentification et un VPN peut légitimement attendre ; un EPSS moyen sur un portail exposé, non authentifié, qui porte vos données clients, ne le peut pas. La variable qui tranche est celle que personne d'extérieur ne connaît, et ce n'est pas un hasard si la BOD 26-04 la place en premier de ses quatre critères : l'exposition. C'est aussi celle que la plupart des organisations documentent le plus mal, faute d'un inventaire externe à jour.

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, ce n'est pas un risque informatique : c'est un risque de sécurité des personnes et une garantie constructeur qui saute.
• 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.
• 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 pour toujours ; 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, l'alternative n'est pas entre patcher et ne rien faire. Elle est 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. L'arbre ci-dessous est le minimum tenable : il tient dans un tableur, et chaque branche produit soit un ticket, soit une acceptation de risque datée et signée.

ACTIF VULNERABLE -> QUE FAIT-ON ?

  Un correctif existe ?
   |
   +-- NON --> fin de support / pas de mise a jour editeur
   |            -> mesures compensatoires + acceptation de risque datee
   |            -> plan de remplacement avec une date, pas "un jour"
   |
   +-- OUI --> peut-on l'appliquer dans le delai vise ?
                |
                +-- NON (fenetre de maintenance, certification,
                |        dependance figee)
                |     -> compensation temporaire + date de patch engagee
                |     -> re-arbitrage si la CVE entre au KEV
                |
                +-- OUI --> classe de risque ?
                             |
                             +-- expose + KEV   -> canari puis parc, sous 72 h
                             +-- expose         -> cycle accelere
                             +-- interne        -> cycle normal

  Regle : toute branche qui ne finit pas par un patch finit par
          une signature. Pas de troisieme sortie.

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. Ce n'est pas une crainte théorique de sysadmin réticent. 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 dont on a vu qu'elle peut être exploitée massivement en moins de cinq jours. 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.

TEMPS D'EXPOSITION EXTERNE (par actif expose)

  T0  = date de publication du correctif par l'editeur
  T1  = date a laquelle le service expose n'annonce plus la version vulnerable

  exposition = T1 - T0

  A suivre, par classe :
    - mediane et 90e percentile, pas la moyenne
      (la moyenne est ecrasee par le parc facile a patcher)
    - part des actifs exposes DECOUVERTS hors inventaire officiel
      (ceux-la ne figurent dans aucun taux de conformite)
    - actifs sans correctif possible : compte + date de fin des
      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". Une politique, une capacité, une traçabilité. Pas un délai.

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 régulateur renvoie explicitement la fixation du délai à l'entité, qui devra le justifier au regard de son exposition et de sa taille.
• Point 6.6.1 (b) : les correctifs sont testés avant application en production. Le bake n'est donc pas une tolérance, c'est 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 l'emportent sur les bénéfices 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, il vaut mieux qu'il soit tenu que qu'il soit ambitieux.

À retenir

• La fenêtre s'est refermée : 5 jours de délai moyen entre divulgation et exploitation pour les failles de 2023 (Google Threat Intelligence, octobre 2024), et zéro jour en médiane pour les équipements de bordure présents au KEV (DBIR 2025). Face à 43 jours de délai médian de remédiation (DBIR 2026), une politique uniforme perd forcément.
• Trier par CVSS coûte huit fois plus d'effort pour la même couverture qu'un seuil EPSS (chiffres FIRST, EPSS v3). La CISA elle-même a retiré le CVSS de sa doctrine de délais avec la BOD 26-04 du 10 juin 2026, au profit de l'exposition, du KEV, de l'automatisation de l'exploit et de l'impact.
• 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. Jamais par le silence.
• Le délai de bake se remplace par des anneaux de déploiement et un retour arrière réellement répété : une demi-journée de test par an, et la politique de patch rapide devient tenable.
• 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. Elle exige un inventaire externe continu, et elle démasque les correctifs installés mais jamais actifs.
• 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.

Une politique de correctifs se juge sur un seul chiffre, et il ne sort d'aucun outil de déploiement : le temps pendant lequel un service joignable depuis Internet a continué d'annoncer une version vulnérable. Le produire 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.