Vulnérabilités et Alertes

BOD 26-04 : priorisation des correctifs par le risque

by  • 

Ce que la nouvelle directive de la CISA change pour les équipes VOC, SOC, CERT et CSIRT

Publié le 14 juin 2026. Analyse de la Binding Operational Directive 26-04 « Prioritizing Security Updates Based on Risk », émise par la CISA le 10 juin 2026.

Résumé exécutif

Le 10 juin 2026, la CISA a publié la directive opérationnelle contraignante la BOD 26-04, qui redéfinit la façon dont les agences civiles fédérales américaines doivent prioriser l’application de leurs correctifs. Le changement de philosophie est net : on cesse de traiter toutes les vulnérabilités de la même manière pour concentrer l’effort sur le risque réel, mesuré par quatre variables objectives. L’exposition de l’actif, sa présence au catalogue KEV des vulnérabilités activement exploitées, la capacité d’un attaquant à automatiser l’exploitation, et le niveau de contrôle obtenu après compromission. De ces quatre variables découle un délai de remédiation, du plus contraint (trois jours, assorti d’un triage forensique obligatoire) au plus souple (correction au prochain cycle de mise à niveau).

Pour le décideur, trois points méritent attention. D’abord, la BOD 26-04 abroge et remplace deux textes structurants, BOD 22-01 (qui avait créé le catalogue KEV en 2021) et la BOD 19-02. Elle consolide la doctrine de gestion des vulnérabilités du gouvernement fédéral en un seul cadre, fondé sur le risque. Ensuite, la directive acte explicitement que l’usage de l’IA par les attaquants raccourcit la fenêtre entre la publication d’un correctif et son exploitation possible. La priorisation par le risque est la réponse organisationnelle à cette compression du temps. Enfin, pour les vulnérabilités du plus haut tier, la correction ne suffit plus : la CISA impose en parallèle un triage forensique destiné à déterminer si l’actif a déjà été compromis. C’est un basculement implicite vers une posture de présomption de compromission sur les cibles les plus exposées.

Sur le plan de la portée, la BOD 26-04 ne contraint juridiquement que les agences du Federal Civilian Executive Branch. Elle ne s’applique ni aux systèmes de sécurité nationale, ni au Department of War, ni à la communauté du renseignement. Pour une organisation française ou européenne, la directive n’a donc aucune obligation, mais elle constitue un modèle de doctrine de priorisation immédiatement transposable, et un signal sur la direction que prennent les attentes en matière de gestion des vulnérabilités. Une équipe VOC peut en reprendre la logique de scoring dès aujourd’hui, sans attendre une obligation réglementaire locale.(Ma recommandation)

L’essentiel à retenir pour les équipes opérationnelles : la donnée de priorisation est désormais standardisée et publiée. La CISA fournit, pour chaque CVE, le statut KEV, le caractère automatisable et l’impact technique via son programme Vulnrichment. La seule variable qui reste à la charge de l’organisation est l’exposition de ses propres actifs.

Le travail de fond se déplace donc de la notation des failles vers la connaissance fine et continue de sa surface d’exposition.

01. Ce qu’est une BOD, et à qui elle s’impose

Une Binding Operational Directive est une instruction contraignante adressée aux départements et agences de la branche exécutive civile fédérale des États-Unis, aux fins de protéger les systèmes et l’information de l’État. Son fondement juridique repose sur le titre 44 du U.S. Code (sections 3552, 3553 et 3554), qui autorise le secrétaire à la Sécurité intérieure à émettre ces directives et oblige les agences à s’y conformer.

Le périmètre est précisément délimité. La directive vise les « Federal Civilian Executive Branch systems », c’est-à-dire les systèmes d’information utilisés ou opérés par une agence civile fédérale, ou par un tiers pour le compte d’une telle agence. Elle exclut en revanche les systèmes statutairement définis comme « national security systems », ainsi que certains systèmes opérés par le Department of War et par la communauté du renseignement. Pour les contractants, la directive ne s’applique pas directement, sauf si le contrat le prévoit, mais chaque agence doit passer ses contrats en revue pour identifier les modifications nécessaires.

Pour les environnements tiers, y compris les offres certifiées FedRAMP, l’agence reste responsable de l’inventaire de ses systèmes et du suivi de conformité. Pour les offres cloud non certifiées FedRAMP, l’agence doit travailler directement avec son fournisseur pour que l’infrastructure sous-jacente respecte les mêmes exigences, toute dérogation devant être documentée et communiquée.

Ce cadrage juridique a une conséquence pratique pour le lecteur non américain : la valeur de la BOD 26-04 hors du périmètre fédéral n’est pas réglementaire, elle est méthodologique. C’est un référentiel de priorisation que rien n’interdit d’adopter.

02. Un changement de doctrine : du traitement uniforme à la priorisation par le risque

Jusqu’ici, la doctrine fédérale reposait sur deux textes. BOD 19-02 encadrait la remédiation des systèmes accessibles depuis Internet. La BOD 22-01, en novembre 2021, avait introduit le catalogue des Known Exploited Vulnerabilities et imposé une remédiation agressive des vulnérabilités activement exploitées. La BOD 26-04 abroge et révoque ces deux directives, et consolide l’ensemble en un cadre unique.

Le motif affiché est double. D’une part, les campagnes malveillantes, dont une partie est soutenue par des États, ciblent en priorité les infrastructures critiques en exploitant des vulnérabilités non corrigées. D’autre part, la directive constate que l’usage de l’IA par les attaquants peut réduire encore le délai entre la sortie d’un correctif et son exploitation. Dans ce contexte, traiter toutes les failles et tous les systèmes à parité revient à diluer l’effort. La réponse retenue consiste à concentrer le patching là où le risque est le plus élevé, et à différer l’action sur le risque faible.

C’est une évolution importante, parce qu’elle assume officiellement le tri. Une organisation ne peut pas tout corriger en même temps. La BOD 26-04 reconnaît cette réalité et fournit une méthode pour décider quoi corriger d’abord, sur la base de critères publiés et reproductibles plutôt que du seul score CVSS.

03. Le moteur de décision : quatre variables

L’urgence de remédiation d’une vulnérabilité, sur un actif donné, se détermine à partir de quatre questions.

Exposition de l’actif. L’actif vulnérable est-il publiquement exposé ? Au sens de la directive, est publiquement exposé tout actif détenu ou géré par l’agence et accessible à des entités non authentifiées ou non fiables via des réseaux publics tels qu’Internet, quelle que soit sa localisation physique ou logique. Si une seule méthode de détection conclut à l’exposition, la valeur est positionnée à « oui ».

Statut KEV. La vulnérabilité, identifiée par sa CVE ID, figure-t-elle au catalogue des Known Exploited Vulnerabilities de la CISA ? L’inscription au KEV est le marqueur d’une exploitation observée dans la nature.

Automatisation de l’exploitation. Un adversaire peut-il automatiser l’intégralité des étapes nécessaires à l’exploitation ? Une faille pleinement automatisable se prête au scan de masse et à l’attaque opportuniste à grande échelle.

Impact technique. Après exploitation, l’attaquant obtient il un contrôle partiel ou un contrôle total de l’actif ? La directive définit ces deux notions avec précision. Le contrôle partiel correspond à un contrôle limité du comportement du logiciel, à une exposition d’information, ou à une faible probabilité stochastique d’obtenir un contrôle total ; un déni de service est une forme de contrôle limité. Le contrôle total donne à l’adversaire la maîtrise complète du comportement du logiciel, y compris lorsque l’exploitation révèle de façon fiable des identifiants de connexion.

Le point déterminant pour les équipes est la répartition de la charge de production de ces variables. La CISA publie, pour chaque CVE ID et via son programme Vulnrichment, les réponses aux trois questions du statut KEV, de l’automatisation et de l’impact technique. La quatrième variable, l’exposition de l’actif, relève de l’organisation, qui doit s’appuyer sur sa propre connaissance de surface, guidée par l’Internet Exposure Reduction Guidance de la CISA. Autrement dit, trois quarts de la donnée de priorisation sont fournis ; le quart restant dépend de la qualité de votre inventaire.

La directive s’inscrit par ailleurs en cohérence avec la circulaire OMB A-130, le FISMA de 2014, l’executive order sur l’innovation et la sécurité en matière d’IA avancée, et la stratégie cyber nationale.

04. Les délais de remédiation : la table SSVC

La directive fixe les échéances dans une Table 1 « Remediation Timelines », placée en annexe et construite à partir de la méthodologie SSVC (Stakeholder-Specific Vulnerability Categorization). SSVC croise le statut d’exploitation, l’impact sur la sûreté et la prévalence du produit affecté pour produire une décision de priorisation. L’impact technique de la table est conceptuellement proche de la sévérité au sens du score de base CVSS, la définition du périmètre d’exploitation jouant un rôle particulier dans son évaluation.

Le texte de la directive expose deux points d’ancrage de cette table de lecture.

Au sommet de la pile de risque, la mention « & forensic triage » impose que la remédiation ou la mesure d’atténuation soit conduite dans un délai de trois jours, et qu’un triage forensique de l’actif soit réalisé pour évaluer s’il est compromis. Le triage doit suivre la Forensic Triage Guidance du guide d’implémentation. C’est le tier des vulnérabilités les plus dangereuses, typiquement une faille exposée, inscrite au KEV, automatisable et menant au contrôle total. Sur ce tier, corriger ne suffit pas : il faut aussi vérifier qu’on n’a pas déjà été ouvert.

À l’opposé, la mention « fix on system upgrade » signifie que, sauf changement des conditions, la vulnérabilité sera corrigée lors de la prochaine mise à niveau majeure ou reconstruction planifiée de l’actif. C’est le tier du risque faible, où l’action immédiate n’est pas requise.

Entre ces deux bornes se déploie une grille de délais intermédiaires que la CISA matérialise dans sa figure annexe. Les valeurs exactes de chaque case dépendent de la combinaison des quatre variables et sont publiées par la CISA ; les premières inscriptions traitées sous la BOD 26-04 ont d’ailleurs porté des échéances très courtes, à l’image d’une remédiation sous trois jours pour une injection de commande non authentifiée en root sur un produit exposé.

Trois règles encadrent le déclenchement et l’évolution des délais. Le compteur démarre au premier des deux événements suivants : l’ajout de la vulnérabilité au catalogue KEV par la CISA, ou l’énumération de la vulnérabilité sur un actif par l’agence et la mise à jour du tableau de bord CDM. Les délais sont dynamiques : retirer un système d’Internet fait passer son exposition de « oui » à « non » et repousse l’échéance, tandis que l’inscription d’une CVE au KEV la raccourcit. Enfin, les délais s’expriment en jours calendaires.

05. Les obligations en trois phases, et les actions de la CISA

La directive échelonne les obligations des agences en trois phases.

Phase I, avec effet immédiat. Les agences doivent revoir et, au besoin, mettre à jour leurs politiques de gestion des vulnérabilités. Au minimum, ces politiques doivent établir un processus de remédiation continue des vulnérabilités que la CISA signale comme à risque significatif via le KEV, dans les délais fixés ; attribuer rôles et responsabilités ; définir les actions permettant une réponse rapide ; mettre en place une validation et une application internes ; et instaurer un suivi et un reporting internes. Les agences doivent surveiller les mises à jour du KEV et atténuer agressivement selon les délais, automatiser le reporting de l’état des vulnérabilités KEV via le tableau de bord CDM, ou à défaut reporter manuellement toutes les deux semaines. Elles poursuivent le Cyber Hygiene scanning, retirent les adresses IP source de ce scan de leurs listes de blocage, et attestent chaque trimestre, ou à la demande de la CISA, de leurs adresses IP et noms de domaine publiquement exposés.

Phase II, sous 60 jours. Les agences mettent à jour leurs processus et procédures de gestion des vulnérabilités pour soutenir une remédiation continue fondée sur la base CVE et le catalogue KEV, et fournissent ces documents à la CISA sur demande.

Phase III, sous 180 jours. Les agences remédient chaque vulnérabilité aussi vite que possible, et au plus tard dans les délais de la Table 1. Elles identifient et étiquettent en continu tous les actifs joignables depuis l’extérieur du réseau via une adresse IP routable. Celles qui n’ont pas pleinement automatisé leur reporting via le programme CDM transmettent l’information à la CISA tous les sept jours, dans un format lisible par machine. L’étiquetage doit préciser l’organisation et la sous-organisation, l’environnement (production ou développement), l’exposition (publique ou interne) et le type d’actif (serveur, application ou équipement réseau). Tous les actifs remontés dans le tableau de bord fédéral CDM, postes de travail, serveurs, mobiles, actifs cloud, imprimantes et autres équipements en réseau, doivent inclure l’ensemble de leurs adresses IP, y compris les adresses privées RFC 1918 et RFC 4193.

Du côté de la CISA, les engagements sont symétriques. Maintenir le catalogue KEV et alerter les agences à chaque mise à jour, à un rythme aligné sur celui auquel de nouvelles vulnérabilités exploitées sont identifiées. Fournir les métadonnées de vulnérabilité à la base CVE via le mécanisme Authorized Data Publisher, comme le fait le programme Vulnrichment. Maintenir la doctrine de triage forensique. Publier sous 60 jours les exigences de données pour l’étiquetage des actifs selon un schéma standardisé. Réévaluer formellement les délais de la Table 1 une fois par exercice fiscal, et produire un rapport d’état annuel au secrétaire à la Sécurité intérieure, au directeur de l’OMB et au National Cyber Director.

06. Traduction opérationnelle pour le VOC

Pour une cellule de gestion des vulnérabilités, la BOD 26-04 fournit un modèle de scoring prêt à l’emploi. La logique se reprend directement.

La première action consiste à intégrer la donnée Vulnrichment dans le pipeline de priorisation. Le statut KEV, le caractère automatisable et l’impact technique deviennent des attributs de chaque CVE, au même titre que le CVSS, mais avec une valeur opérationnelle supérieure parce qu’ils intègrent l’exploitation réelle et l’automatisation. Le CVSS seul ne dit pas si une faille est activement exploitée ni si elle se prête au scan de masse ; SSVC le dit.

La deuxième action porte sur l’exposition, qui reste la variable à produire en interne. La qualité de la priorisation est plafonnée par la qualité de l’inventaire. Un VOC qui ne sait pas, en continu, quels actifs sont joignables depuis Internet ne peut pas appliquer correctement le modèle. L’enjeu se déplace donc vers la cartographie de surface et son rafraîchissement, idéalement automatisé, avec un étiquetage cohérent de l’exposition.

La troisième action consiste à matérialiser les tiers de délai dans l’outillage. Une vulnérabilité exposée, au KEV, automatisable et menant au contrôle total appelle une réaction en trois jours ; une vulnérabilité interne, hors KEV, non automatisable et à impact partiel peut attendre le prochain cycle de mise à niveau. Entre les deux, des paliers intermédiaires. Traduire ces paliers en SLA internes et en automatisation de tickets transforme la directive en routine de production.

07. Traduction opérationnelle pour le SOC et le CERT/CSIRT

Pour le SOC, la BOD 26-04 confirme que le catalogue KEV est une source de priorisation de la détection, et non seulement du patching. Chaque ajout au KEV doit déclencher une vérification de la couverture de détection sur les CVE concernées, une recherche de signes d’exploitation, et une attention particulière aux actifs exposés correspondants. Le rythme de mise à jour du KEV, que la CISA s’engage à accélérer, impose un mécanisme de veille automatisé plutôt qu’une consultation manuelle.

Pour le CERT et le CSIRT, l’apport le plus structurant est l’exigence de triage forensique sur le tier le plus à risque. La directive acte que, pour ces vulnérabilités, la remédiation seule ne clôt pas l’incident potentiel : il faut, dans le même délai de trois jours, évaluer si l’actif a déjà été compromis. Cela suppose une capacité de triage prête à l’emploi, des playbooks de réponse adaptés, et une collecte de preuves alignée sur les guides applicables. En pratique, cela revient à adopter une posture de présomption de compromission sur les actifs exposés touchés par une faille exploitée et automatisable. Patcher sans vérifier devient insuffisant.

L’articulation entre les trois fonctions devient alors lisible. Le VOC priorise et déclenche la remédiation, le SOC surveille l’exploitation et alimente la détection, le CERT et le CSIRT conduisent le triage forensique sur le haut du spectre. La donnée commune qui les relie est le couple inventaire d’exposition et flux Vulnrichment.

08. Portée hors du périmètre fédéral américain

La BOD 26-04 n’oblige aucune organisation française ou européenne. Sa valeur, vue d’ici, est celle d’un référentiel. Le modèle de priorisation par le risque, fondé sur l’exposition, le statut d’exploitation, l’automatisation et l’impact technique, est directement transposable à toute démarche de gestion des vulnérabilités, indépendamment du contexte réglementaire. Il offre un langage commun et une grille de décision que beaucoup d’équipes construisent aujourd’hui de façon empirique.

Deux signaux méritent d’être notés au-delà du dispositif lui-même. Le premier est la reconnaissance officielle, dans un texte contraignant, de l’effet de l’IA offensive sur la fenêtre de remédiation. Le second est l’inflexion vers la présomption de compromission sur les cibles les plus exposées, matérialisée par le triage forensique obligatoire. Ces deux éléments dépassent la seule sphère fédérale américaine et alimentent la réflexion doctrinale de toute structure de défense.

Pour une équipe DFIR qui souhaite s’en inspirer sans attendre, le chemin le plus rentable est clair : se procurer la donnée SSVC publiée, fiabiliser la connaissance de sa surface d’exposition, et traduire les tiers de délai en SLA internes assortis, pour le haut du spectre, d’un réflexe de triage.

La directive ne fait pas la moitié du job à votre place, l’inventaire, mais elle fournit gratuitement la moitié la plus difficile, la notation du risque réel.

Enjoy !

Sources

Source primaire et textes cités dans la directive. Seules figurent les URL explicitement référencées par la CISA dans BOD 26-04 et ses notes de bas de page.

  1. BOD 26-04 — Prioritizing Security Updates Based on Risk — CISA : https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk
  2. BOD 26-04 — Implementation Guidance for Prioritizing Security Updates Based on Risk — CISA (directive associée, 10 juin 2026) : https://www.cisa.gov/news-events/directives
  3. Known Exploited Vulnerabilities Catalog (catalogue KEV) — CISA : https://www.cisa.gov/known-exploited-vulnerabilities-catalog
  4. Criteria for Known Exploited Vulnerabilities (conditions d’inscription au KEV) — CISA : https://www.cisa.gov/known-exploited-vulnerabilities
  5. Cybersecurity Directives (page de référence des directives) — CISA : https://www.cisa.gov/news-events/directives
  6. SSVC Guide (Stakeholder-Specific Vulnerability Categorization) — CISA : https://www.cisa.gov/sites/default/files/publications/cisa-ssvc-guide%20508c.pdf
  7. SSVC — méthodologie et définitions (Automatable, Technical Impact) — GitHub CERTCC/SSVC : https://github.com/CERTCC/SSVC
  8. CVE Authorized Data Publishers (mécanisme ADP, programme Vulnrichment) — CVE.org : https://www.cve.org/ProgramOrganization/ADPs
  9. OMB Circular A-130 — Managing Information as a Strategic Resource — Federal Register : https://www.federalregister.gov/documents/2016/07/28/2016-17872/revision-of-omb-circular-no-a-130-managing-information-as-a-strategic-resource
  10. Federal Information Security Modernization Act of 2014 (S.2521) — Congress.gov : https://www.congress.gov/bill/113th-congress/senate-bill/2521/all-info
  11. Executive Orders (EO Promoting Advanced Artificial Intelligence Innovation and Security) — The White House : https://www.whitehouse.gov/presidential-actions/executive-orders/