BOD 26-04 : la CISA enterre le score CVSS comme boussole de priorisation

Bonne nouvelle pour les équipes de sécurité épuisées de courir après chaque CVE : vous pouvez (presque) souffler. Le 10 juin 2026, la Cybersecurity and Infrastructure Security Agency (CISA) a publié la BOD 26-04. Elle officialise ce que beaucoup d'équipes pensaient déjà : tout patcher n'est ni possible, ni utile.

La directive remplace une logique fondée sur la gravité théorique des CVE par une logique fondée sur le risque réel pour l'organisation. Elle enterre au passage le score CVSS comme principale boussole de priorisation.

Lecture · 7 min

À retenir

• Changement de doctrine : la BOD 26-04 (10/06/2026) remplace BOD 22-01 et BOD 19-02. Le score CVSS sort de la priorisation, place au risque réel.

• 4 variables décident du délai : exposition de l'actif, statut KEV, automatisation de l'exploit et impact technique. Du « 3 jours + analyse inforensique » au report sur la prochaine mise à jour.

• Une seule variable vous appartient : l'exposition de vos actifs. La CISA fournit les trois autres ; à vous de connaître votre surface d'attaque. C'est le cœur de l'EASM.

• Concerne aussi l'Europe : obligatoire pour les agences fédérales américaines, mais convergent avec NIS2 et DORA et appelé à devenir un standard de facto.

Pour un RSSI comme pour une équipe de gestion des vulnérabilités (vulnerability management), c'est un soulagement autant opérationnel que politique. Enfin un cadre officiel qui dit : « concentrez vos mises à jour de sécurité là où elles réduisent réellement le risque ».

Plus besoin de justifier pourquoi vous n'avez pas traité les milliers de CVE « critiques » du trimestre. L'enjeu n'est plus de vider une file d'attente. L'enjeu est de protéger les systèmes critiques et les actifs réellement exposés. Votre posture de sécurité se mesure désormais à votre capacité à prioriser, pas à votre volume de correctifs.

La Binding Operational Directive 26-04, « Prioritizing Security Updates Based on Risk » (prioriser les mises à jour de sécurité selon le risque), est une réponse pragmatique à une situation devenue intenable. Le flot de vulnérabilités s'accumule, l'IA raccourcit le délai entre la divulgation d'une faille et son exploitation, et les processus traditionnels de gestion des correctifs ne suivent plus.

La CISA arrête donc de traiter chaque CVE de la même façon. Elle concentre l'effort là où le risque est réel et assume de différer le reste.

Le rappel utile : le score CVSS d'une vulnérabilité, à lui seul, ne dit rien de votre exposition. Un « critique » sur un actif interne non automatisable n'est pas un « critique » sur un serveur exposé qu'un attaquant peut compromettre en quelques minutes. La BOD 26-04 inscrit désormais cette évidence dans la politique fédérale américaine.

La directive révoque et remplace BOD 19-02 (2019, systèmes exposés sur Internet) et BOD 22-01 (2021, le catalogue des vulnérabilités activement exploitées, Known Exploited Vulnerabilities ou KEV). Là où BOD 22-01 appliquait un délai unique à toute CVE présente dans le KEV, la BOD 26-04 introduit un modèle gradué : le statut KEV n'est plus que l'une des quatre variables qui décident de l'urgence.

Conséquence directe : le score CVSS sort du calcul de priorisation. La méthodologie s'appuie désormais sur le modèle SSVC (Stakeholder-Specific Vulnerability Categorization). Concrètement, ce modèle cherche à répondre à une question simple : cette vulnérabilité doit-elle être corrigée immédiatement ou peut-elle attendre ? L'objectif est de prioriser selon le risque réel plutôt que selon la seule gravité théorique.

Chaque vulnérabilité est évaluée sur quatre critères binaires. La CISA publie les réponses aux trois derniers critères via son programme Vulnrichment, qui enrichit les fiches CVE avec des informations supplémentaires sur le risque réel d'exploitation. Une seule variable reste à votre charge : l'exposition réelle de vos actifs.

1. Expsoition : l'actif est-il exposé ?

   Accessible depuis Internet ou une IP routable. C'est la seule variable que vous devez déterminer vous-même.

2. KEV : exploitée dans la nature ?

   La CVE figure-t-elle au catalogue KEV de la CISA ? C'est la preuve d'une exploitation réelle observée.

3. Automatisation : exploitation automatisable ?

   Un attaquant peut-il automatiser toutes les étapes de l'exploit ? Cela mesure la maturité de l'arme.

4. Impact technique : contrôle total ou partiel ?

   L'exploitation donne-t-elle un contrôle total du système (jusqu'aux identifiants) ou seulement limité ?

Posez l'hypothèse haute sur les trois derniers critères. Avec un modèle public, un bon pentesteur écrit un script d'exploitation en quelques minutes, et l'intégration dans une chaîne d'attaque complète (élévation de privilèges, RCE, persistance, mouvement latéral, exfiltration) n'est pas beaucoup plus complexe. Dans les faits, « exploitable » et « automatisable » sont souvent à considérer comme vrais par défaut. La variable qui fait réellement la différence reste la première : votre exposition.

La matrice : 5 paliers, du « 3 jours » au « prochain upgrade »

Point clé : les délais sont dynamiques. Sortez un système d'Internet et son échéance s'allonge ; la CISA ajoute la CVE au KEV et l'échéance se raccourcit immédiatement. La priorisation n'est pas un instantané, c'est un suivi continu.

Le « moins, mais mieux » en chiffres : sur une grande agence fédérale analysée par la CISA, seulement 1 % des instances de vulnérabilités tombent dans la catégorie « 3 jours ». À l'inverse, plus de 60 % sont reportées au prochain upgrade. Le modèle est conçu pour concentrer les ressources, pas pour les noyer.

Deux facteurs convergent. D'abord, l'efficacité du patching traditionnel se dégrade. Selon le Verizon DBIR 2026 cité par la CISA :

• 26 % des CVE du KEV ont été pleinement remédiées en 2025, contre 38 % l'année précédente ;

• 43 jours est le délai médian nécessaire pour résoudre complètement une vulnérabilité ;

• 31 % des compromissions utilisent l'exploitation de vulnérabilités comme vecteur d'accès initial.

Ensuite, l'IA. La CISA reconnaît explicitement qu'elle accélère à la fois la découverte et l'armement des vulnérabilités, tout en comprimant le délai entre divulgation et exploitation. La directive s'engage d'ailleurs à réévaluer ses délais chaque année et à les resserrer si les capacités offensives progressent. Le « 3 jours » n'est probablement qu'une première étape. La CISA indique déjà qu'elle pourrait raccourcir ces délais si les capacités offensives continuent de progresser.

La BOD 26-04 constitue probablement l'évolution la plus pragmatique du vulnerability management depuis plusieurs années. Pour autant, elle ne doit pas être interprétée comme une solution parfaite. Plusieurs limites méritent d'être gardées à l'esprit.

• Le catalogue KEV reste réactif. Une vulnérabilité peut être exploitée dans la nature plusieurs jours avant son ajout officiel au catalogue de la CISA. Le KEV est un excellent signal de priorisation, mais il ne constitue pas un système d'alerte précoce.

• Le KEV reflète principalement les priorités des agences fédérales américaines. Certaines technologies métier, applications sectorielles ou expositions spécifiques à d'autres environnements peuvent ne jamais apparaître dans le catalogue, même si elles présentent un risque important pour votre organisation.

• Trois jours restent parfois trop longs. Pour certaines vulnérabilités exposées sur Internet, les premières tentatives d'exploitation apparaissent quelques heures après la publication d'une CVE. Dans ces cas-là, même le délai le plus agressif prévu par la directive peut sembler généreux au regard du rythme réel des attaques.

Ces limites ne remettent pas en cause la pertinence de la BOD 26-04. Elles rappellent simplement qu'aucun modèle de priorisation externe ne remplacera une connaissance précise de votre surface d'attaque et de votre exposition réelle.

La BOD 26-04 n'est obligatoire que pour les agences fédérales civiles américaines (Federal Civilian Executive Branch). Mais le catalogue KEV de la BOD 22-01 est devenu, en quelques années, le signal de priorisation le plus largement adopté au monde, bien au-delà du gouvernement américain.

Ce modèle de gestion des vulnérabilités basée sur le risque suivra probablement la même trajectoire. La priorisation fondée sur le risque réel deviendra progressivement une attente du marché.

Surtout, sa logique converge avec ce que NIS2 et DORA exigent déjà côté européen : une gestion des vulnérabilités fondée sur le risque, une surveillance continue et une capacité à démontrer que l'on traite en priorité ce qui est réellement exposé et exploité. S'aligner sur ce cadre dès maintenant constitue davantage un avantage qu'une contrainte.

Mettre en œuvre ce modèle suppose de répondre à quatre questions, pour chaque vulnérabilité, sur chaque actif, en continu. Trois réponses viennent du renseignement sur la menace :

• KEV ;

• automatisation de l'exploit ;

• impact technique.

La quatrième, l'exposition, n'appartient qu'à vous. Et c'est précisément là que la plupart des programmes de gestion des vulnérabilités rencontrent leurs limites :

• Inventaire et cartographie : connaissez-vous réellement vos actifs exposés — serveurs, applications, API, services cloud, agents IA ou shadow IT ?

• Surface d'attaque externe : savez-vous, à un instant donné, ce qui est accessible depuis Internet, y compris ce que vous avez oublié avoir déployé ?

• Contrôle continu : disposez-vous d'un mécanisme capable de détecter qu'un actif vient de passer d'« interne » à « exposé » et de faire évoluer instantanément son niveau de priorité ?

C'est la conviction que nous portons depuis le début chez Patrowl et que nous appliquons quotidiennement. L'External Attack Surface Management (EASM) cartographie et surveille en continu votre exposition réelle, la seule variable que votre organisation doit déterminer elle-même. Le Continuous Threat Exposure Management (CTEM) corrèle ensuite cette exposition aux signaux d'exploitabilité et de criticité afin de ne faire remonter que l'essentiel.

Évaluer cette variable manuellement, sur des milliers d'actifs et en continu, ne passe pas à l'échelle avec des analystes seuls.

Restons lucides sur ce que cela change, et sur ce que cela ne change pas. Prioriser par le risque ne corrige rien à votre place et ne corrige pas tout. Cela vous indique où regarder en premier et avec quel niveau d'urgence. Le rôle d'une couche de vérification active est de produire la donnée d'exposition fiable et continue dont dépend tout le modèle de la BOD 26-04, pas de prétendre vider la file d'attente.

Une vulnérabilité qualifiée en critique sur un actif supervisé, qui illustre bien la logique de la directive :

Fortinet SSL-VPN — RCE pré-authentification (CVE-2023-27997)

Asset : passerelle VPN exposée sur Internet

✓Exposé — portail SSL-VPN, exposé par nature

✓Exploité — RCE pré-auth confirmée dans la nature, contourne le MFA

✓Automatisable — scan de masse des interfaces exposées, exploitation reproductible

✓Impact total — RCE pré-auth, CVSS 9.1 (qualifié par Patrowl)

Sur la matrice BOD 26-04 : patch sous 3 jours + triage forensique. Le palier maximal.

Le détail qui compte : cette CVE date de 2023. Ce n'est même pas une vulnérabilité zero-day, mais une faille connue de longue date, exposée et activement exploitée. Voilà le cœur du changement de doctrine. Un actif ancien, exposé et exploité passe avant des dizaines de « critiques » aux scores CVSS élevés qui, sans exposition réelle, ne mettent rien en danger. Patrowl l'a remontée et qualifiée parce qu'elle relève de la seule variable qui vous incombe, l'exposition. Et l'a fait passer en tête de file.

Sans cartographie continue de la surface d'attaque, cet actif serait resté un angle mort. Impossible de tenir un délai de 3 jours sur une passerelle qu'on ignorait exposée. C'est ce que ferme l'EASM de Patrowl. Une fois l'actif qualifié, son suivi contre un SLA applique concrètement la logique de délais gradués de la BOD 26-04.

Ce modèle ne vaut que par la qualité de la donnée qui l'alimente. Le programme Vulnrichment de la CISA ne couvre aujourd'hui qu'une fraction des CVE en SSVC, autour de la moitié selon les sources tierces.

Pour le reste, l'automatisation et l'impact technique restent à évaluer par vous-même ou via un fournisseur.

Mal alimentée, une priorisation par le risque donne surtout un faux sentiment de maîtrise. Le cadre est solide, mais il n'exonère pas d'une donnée d'exposition fiable et continue.

Nos procédures actuelles ne suivent plus la cadence, et tout corriger n'est plus une option. La BOD 26-04 acte un changement de doctrine : corriger moins, mais mieux. En priorité ce qui est exposé, exploité et critique pour vos activités. La priorisation par le risque n'est plus une option de confort. C'est une condition de résilience.

Source : CISA, BOD 26-04 : Prioritizing Security Updates Based on Risk (10/06/2026).
Données de remédiation : Verizon 2026 DBIR.
Données terrain : analyse CISA d'une agence fédérale.