5 min

Pourquoi le CVSS score n'est plus un outil de priorisation des vulnérabilités ?

Publié en
30.06.2026
Pourquoi le CVSS score n'est plus un outil de priorisation des vulnérabilités ?
S'inscrire à la newsletter

Votre scanner de vulnérabilités vient de remonter 847 alertes. 312 sont estampillées "Critique" ou "Élevé". Votre équipe a la capacité d'en traiter 20 cette semaine. Par où commencer ?

Si votre réponse est "par celles avec le score CVSS le plus élevé", vous confondez priorisation et classification. Du moins, c'est ce que nous fait comprendre la CISA.

Le 10 juin 2026, la CISA (Cybersecurity and Infrastructure Security Agency, l'agence fédérale américaine de cybersécurité) a publié la Binding Operational Directive 26-04 : une directive contraignante qui s'impose à l'ensemble des agences civiles fédérales américaines. Pour la première fois, un gouvernement retire le score CVSS comme base de décision pour prioriser les vulnérabilités à corriger. Ce n'est pas un détail technique, c'est un signal pour l'ensemble du secteur.

‍

Pourquoi le CVSS ne suffit plus ?

Le CVSS (Common Vulnerability Scoring System) attribue à chaque vulnérabilité un score de 0 à 10. Simple, universel, et adopté partout. Pendant des années, c'était suffisant.

Le problème fondamental est là : les scores CVSS ne reflètent pas l'exploitabilité réelle ni l'impact spécifique sur votre environnement. Une vulnérabilité notée Critique peut présenter un risque minimal si le composant concerné fonctionne dans un segment réseau isolé. À l'inverse, une vulnérabilité de gravité moyenne dans une application exposée à internet peut représenter votre risque le plus urgent.

Un exemple réel illustre parfaitement ce décalage. La CVE-2025-13956 est une faille d'autorisation manquante dans LearnPress, un plugin WordPress. Score CVSS : 5.3, classée "Moyenne". Avec une logique CVSS pure, elle reste indéfiniment dans le backlog derrière des dizaines de vulnérabilités théoriquement plus graves. Pourtant, publiée en mars 2025, elle est restée silencieuse plus d'un an avant qu'une exploitation active soit détectée en avril 2026, avec 168 IP attaquantes identifiées et un ciblage orienté prise de contrôle totale. Un score CVSS de 5.3, mais un risque réel de niveau critique pour toute organisation exposée.

Un CVSS 9.8 sur un produit de niche sans outillage attaquant disponible est potentiellement moins urgent qu'un CVSS 7.5 sur un appareil de périmètre largement déployé et déjà massivement exploité.

Ce décalage était tolérable tant que les volumes restaient gérables. Mais ce n'est plus le cas. Plus de la moitié des CVE publiées affichent un score qualifié d'Élevé ou Critique. Si tout est critique, rien ne l'est. Et pendant ce temps, seulement 26 % des vulnérabilités du catalogue KEV ont été entièrement remédiées en 2025, contre 38 % l'année précédente.

Les équipes s'épuisent à courir après des scores élevés pendant que les vraies menaces avancent.

‍

Ce que dit exactement la BOD 26-04

La BOD 26-04 remplace et révoque deux directives précédentes : la BOD 19-02 sur la remédiation des systèmes accessibles depuis internet, et la BOD 22-01 sur les vulnérabilités connues et exploitées. Les agences fédérales n'ont désormais plus l'obligation d'utiliser le CVSS pour prioriser leurs vulnérabilités.

Contenu de l’article
BOD 26-04 - CISA

‍

À la place, quatre variables déterminent l'urgence de remédiation :

  1. Exposition de l'actif. L'actif vulnérable est-il accessible depuis internet ? C'est la seule variable que vous devez évaluer vous-même. La CISA fournit les réponses aux trois autres variables via son programme Vulnrichment pour chaque CVE identifiée. Si vous ne savez pas précisément ce que vous exposez, vous ne pouvez pas appliquer ce modèle.
  2. Statut KEV. La vulnérabilité figure-t-elle dans le catalogue Known Exploited Vulnerabilities ? Si oui, des attaquants réels l'exploitent déjà sur de vraies cibles. C'est la donnée la plus actionnable disponible, publique et gratuite.
  3. Automatisation de l'exploit. Un adversaire peut-il automatiser l'ensemble des étapes d'exploitation ? Une attaque automatisable est scalable : elle peut être lancée en masse sans effort humain supplémentaire. La CVE-2025-13956 citée plus haut en est un exemple, une fois le pattern d'attaque établi, l'exploitation devient industrialisable en quelques heures.
  4. Impact technique. L'exploitation donne-t-elle à l'attaquant un contrôle total ou partiel du système ? La prise de contrôle complète n'a pas le même impact qu'un accès limité.

‍

Les délais de remédiation qui en découlent

La combinaison de ces quatre variables détermine le délai obligatoire pour corriger la vulnérabilité :

  • Exposition oui, KEV oui, automatisable oui, impact total → 3 jours + triage forensique
  • Exposition oui, KEV oui, automatisable oui, impact partiel → 3 jours
  • Exposition oui, KEV oui, automatisable non, impact total → 3 jours
  • Exposition oui, KEV non, automatisable oui, impact total → 14 jours
  • Exposition oui, KEV non, impact partiel → 60 jours
  • Exposition non → report au prochain cycle de mise à jour

Le dernier palier est aussi important que le premier : une vulnérabilité sans exposition, sans exploitation confirmée et sans impact total peut légitimement attendre le prochain cycle de mise à jour. Patcher moins, mais mieux, c'est désormais une doctrine officielle.

‍

Pourquoi ça concerne les organisations françaises ?

La BOD 26-04 est formellement contraignante pour les seules agences fédérales civiles américaines. Mais son impact dépasse largement ce périmètre.

La précédente directive majeure de la CISA, la BOD 22-01, avait créé le catalogue KEV et était devenue un standard de facto dans le secteur privé mondial, adopté par des équipes de sécurité, des auditeurs. La BOD 26-04 est son successeur direct.

Pour une organisation française, trois implications concrètes :

  • NIS2 et DORA exigent une gestion des risques cyber documentée et proportionnée. Le modèle à quatre variables de la BOD 26-04 correspond exactement au type de priorisation contextuelle que ces réglementations valorisent, bien plus qu'une liste triée par score CVSS.
  • Les auditeurs et assureurs vont probablement aligner progressivement leurs critères sur ce modèle, comme ils l'ont fait avec le KEV après la BOD 22-01.
  • La logique est universelle. La directive répond à un contexte dans lequel les outils d'IA peuvent aider les attaquants à identifier et exploiter les vulnérabilités plus rapidement. Ce risque ne s'arrête pas aux frontières américaines.

‍

Ce que ça implique concrètement pour vos équipes

Trois changements de posture s'imposent, indépendamment de votre réglementation applicable.

  1. Savoir ce que vous exposez n'est plus optionnel. La première variable du modèle est la seule que vous devez évaluer vous-même. Sans cartographie continue de vos actifs accessibles depuis internet, sous-domaines, services, API, ports ouverts, vous ne pouvez pas appliquer ce modèle.
  2. Le KEV devient votre premier filtre. Avant tout autre critère, demandez-vous si la vulnérabilité est dans le catalogue KEV. C'est la donnée la plus actionnable disponible, mise à jour en permanence par la CISA.
  3. Votre backlog peut être rationalisé. Les organisations qui s'appuient encore sur des scans périodiques et une priorisation basée sur le CVSS font face à un écart significatif entre leurs capacités actuelles et ce que le nouveau modèle exige. C'est aussi une opportunité : réduire le bruit, concentrer les efforts, et démontrer une priorisation défendable à vos auditeurs.

‍

Comment Activ Security répond à ce cadre ?

Savez-vous exactement quels actifs vous exposez en ce moment ? C'est la question que la BOD 26-04 vous pose en premier, et la plus difficile pour la majorité des organisations.

Notre module EASM cartographie en continu l'ensemble de vos services exposés sur internet. Chaque sous-domaine, port et technologie est détecté automatiquement, actualisé en temps réel. Quand un actif passe de l'interne à l'exposé, vous le savez immédiatement, la réponse à la première variable du modèle BOD 26-04.

Sur la priorisation, Activ Security croise chaque vulnérabilité avec les trois signaux que la directive formalise : CVSS pour la sévérité de base, EPSS pour la probabilité d'exploitation dans les 30 prochains jours, et KEV pour l'exploitation active confirmée. Ce croisement produit une liste d'actions priorisées selon le risque réel.

‍

Et pendant que vos équipes traitent ces priorités, notre WAF protège vos applications en temps réel, sans attendre le prochain patch 🛡️

Découvrir >