CVSS 10 ne veut plus rien dire : plaidoyer pour une gestion

En juillet 2026, Adobe ColdFusion reçoit un correctif noté CVSS 10.0. Soixante-douze heures plus tard, un PoC public circule sur GitHub. Deux minutes après sa publication, les honeypots enregistrent les premières tentatives d'exploitation. Et pourtant, des milliers d'instances exposées restent non patchées des semaines durant. Ce n'est ni un problème de complexité technique, ni un manque de moyens : c'est une chaîne de priorisation cassée. Quand tout est critique, plus rien ne l'est vraiment. Le score CVSS, conçu pour mesurer la sévérité théorique d'une faille, a été détourné en outil de décision opérationnelle qu'il n'a jamais eu vocation à être. Repenser sa gestion des vulnérabilités CVSS KEV priorisation patch management autour de l'exploitation réelle, et non du score maximal, devient la seule approche tenable pour les équipes sécurité en 2026.

Le CVSS : un système conçu pour une autre époque

Le Common Vulnerability Scoring System a été conçu en 2005 par le NIST et le FIRST pour offrir un langage commun de mesure de la sévérité des vulnérabilités. Version 2, puis 3.0, puis 3.1, puis 4.0 sorti en 2024 — la formule a évolué, les critères de vecteur d'attaque, complexité, privilèges requis, interaction utilisateur et impact sur la confidentialité/intégrité/disponibilité ont été affinés. Le résultat est un score de 0 à 10, universel, consigné dans chaque fiche NVD du NIST.

En pratique, les incidents que nous traitons révèlent que l'écart entre politiques de sécurité documentées et application réelle est presque toujours plus grand que prévu. La vérification terrain régulière reste la seule façon de mesurer ce delta.

— Retour terrain, Ayi NEDJIMI Consultants

En théorie, un score de 10.0 devrait déclencher une réponse immédiate. En pratique, voici ce qui se passe dans la plupart des organisations de taille moyenne en 2026 : l'équipe sécurité reçoit une alerte automatique "CVSS 10 détecté". Elle ouvre un ticket. Elle le classe P1. La prochaine fenêtre de maintenance est dans 12 jours. Le patch est planifié. Les 12 jours passent. Mission accomplie.

Sauf que pendant ces 12 jours, CVE-2026-48282 (ColdFusion, CVSS 10.0) était exploitée activement depuis le jour 3. L'organisation était compromise depuis 9 jours au moment d'appliquer le patch. Et ça, le CVSS ne le dit pas.

Le problème fondamental du CVSS : il mesure la sévérité théorique d'une vulnérabilité dans les conditions les plus favorables à un attaquant, mais n'intègre pas la dimension temporelle de l'exploitation réelle. Un CVSS 10 sans exploit connu et un CVSS 10 avec des kits d'exploitation automatisés actifs depuis 48h devraient appeler des réponses radicalement différentes. Pourtant, ils produisent le même score, le même ticket P1, la même fenêtre de maintenance à J+12.

L'inflation des scores critiques : quand tout est urgent, rien ne l'est

Le Patch Tuesday de juillet 2026 de Microsoft a corrigé 622 CVE, dont une cinquantaine de critiques (CVSS 9.0+) selon les analyses de Rapid7 et Tenable. L'année précédente, on dépassait rarement 150 CVE par mois. Nous atteignons des niveaux records qui auraient été impensables en 2020.

Ce volume génère un phénomène bien documenté : la fatigue des alertes. Quand un SOC reçoit 50 alertes CVSS 9+ par mois, il s'adapte par nécessité. Les équipes développent des heuristiques informelles : "Si c'est Windows et qu'on a une MAJ mensuelle planifiée, on attend." "Si c'est un composant legacy qu'on remplace dans un an, on priorise autre chose." "Si l'éditeur dit 'pas d'exploitation connue', on peut attendre J+30."

Ces heuristiques ne sont pas irrationnelles — elles sont des mécanismes d'adaptation à un flux d'alertes qui dépasse les capacités humaines de réponse. Mais elles créent des angles morts dangereux précisément là où les attaquants opèrent : dans les 72 premières heures après publication d'un PoC, sur des composants que les équipes pensent à faible risque car "jamais vu d'exploitation dans notre secteur".

En 2026, l'inflation des CVE critiques a conditionné les équipes à traiter le CVSS 10 comme un P1 ordinaire plutôt qu'une urgence absolue. Et les attaquants misent précisément sur ce décalage entre la note et la réaction.

La révolution silencieuse : le catalogue KEV de la CISA

En novembre 2021, la CISA américaine a lancé son catalogue KEV — Known Exploited Vulnerabilities. Le principe : lister les CVE pour lesquelles une exploitation active dans la nature a été confirmée. Pas de score, pas d'algorithme. Un critère binaire : est-ce qu'on a vu cette faille utilisée par de vrais attaquants dans de vraies attaques ?

En juillet 2026, le catalogue KEV contient plus de 1 200 entrées — beaucoup moins que les dizaines de milliers de CVE publiées chaque année dans le NVD. Et c'est précisément là que réside sa valeur : le KEV représente les vulnérabilités qui comptent vraiment d'un point de vue opérationnel défensif.

Des études de Tenable et Rapid7 en 2025 ont montré que la corrélation entre CVSS élevé et exploitation active est bien plus faible qu'on ne le suppose : sur les CVE CVSS 9+ publiées entre 2022 et 2024, moins de 8% ont fait l'objet d'une exploitation documentée. À l'inverse, certaines CVE avec des scores modérés (6.0-7.5) ont été massivement exploitées parce qu'elles ciblaient des composants répandus et simples à exploiter — mais le score n'avait pas déclenché d'alerte P1.

La règle que j'applique et recommande : le catalogue KEV prime sur le CVSS pour la priorisation opérationnelle. CVE dans le KEV = urgence absolue, SLA 24-48h maximum. CVE CVSS 10 sans KEV = cycle accéléré J+7. Ce n'est pas une règle parfaite, mais elle est bien plus proche de la réalité des attaquants que la note théorique.

La fenêtre d'exploitation : un problème de temps, pas de score

L'autre dimension que le CVSS ignore : la vitesse du cycle d'exploitation. En 2020-2021, le délai moyen entre publication d'une CVE critique et première exploitation réelle était de 15 à 30 jours (données Mandiant). En 2024-2025, il est tombé à 5-7 jours. En 2026, pour les vulnérabilités avec PoC public, nous parlons d'heures.

CVE-2026-48282 (ColdFusion) : PoC publié le 2 juillet, premières attaques quelques minutes plus tard. CVE-2026-39808 (FortiSandbox) : exploitation active sous 48h. CVE-2026-15409/15410 (SonicWall) : zero-days exploités avant même la publication du patch.

Cette accélération résulte de plusieurs facteurs convergents :

• L'outillage d'exploitation industrialisé : des frameworks comme Metasploit ou Nuclei permettent d'intégrer un nouveau PoC en quelques heures et de le déployer à l'échelle internet automatiquement.
• Le scanning Internet continu : Shodan, Censys et leurs équivalents offensifs permettent d'identifier en quelques minutes toutes les instances exposées d'un produit vulnérable dans le monde entier.
• L'IA accélère le développement d'exploits : des études académiques de 2025 ont démontré que des LLM spécialisés peuvent générer des exploits fonctionnels dans des délais divisés par 3 à 5 par rapport au développement humain classique.
• Les marchés de vulnérabilités : des acteurs revendent des zero-days avant que les éditeurs ne soient informés, comprimant encore la fenêtre de réaction défensive.

Dans ce contexte, une politique de patch management sur cycles mensuels est structurellement inadaptée pour les CVE avec PoC public. Le délai médian entre disponibilité d'un exploit et premier compromis réussi observé dans des incidents réels traités ces deux dernières années est inférieur à 96 heures. Un cycle mensuel = exposition garantie de 3 à 28 jours selon la date de publication. Inacceptable pour une CVE dans le KEV.

Ce que les organisations font mal concrètement

Après plusieurs années d'audits et de réponse à incident, j'observe les mêmes cinq dysfonctionnements récurrents.

1. L'inventaire des actifs est incomplet. On ne peut pas patcher ce qu'on ne sait pas qu'on possède. CVE-2026-48282 en est l'exemple parfait : des milliers d'instances ColdFusion tournent dans des environnements oubliés — portails de test jamais supprimés, applications héritées de rachats, intranets maintenus par des équipes parties. Ces instances ne figurent pas dans le CMDB, ne reçoivent pas les alertes, et sont souvent celles que trouvent en premier les scans offensifs automatisés.

2. Le "pas d'exploitation connue" justifie des délais dangereux. "Il n'y a pas encore d'exploitation, on peut attendre la prochaine fenêtre." Ce raisonnement était valable en 2015. En 2026, pour une CVE avec PoC sur un composant exposé internet, l'exploitation active se compte en heures. La décision de reporter doit intégrer cette réalité.

3. La gestion des exceptions est opaque et non revisitée. Quand un patch ne peut pas être appliqué immédiatement, une exception est documentée avec date d'expiration et contrôles compensatoires. En pratique : les exceptions s'accumulent, les dates passent sans revue, les contrôles ne sont jamais vérifiés. Résultat : un parc avec des vulnérabilités critiques non patchées depuis des mois, couvertes par une justification administrative qui masque le risque réel.

4. L'exposition internet n'est pas différenciée. Une instance vulnérable exposée sur internet et la même instance sur un réseau interne isolé ne posent pas le même risque. La priorité de patch doit être modulée en fonction de l'exposition réseau réelle : 24h pour ce qui est exposé internet, 7 jours pour ce qui est interne avec accès indirect, cycle normal pour ce qui est réellement isolé.

5. Les tests de régression bloquent les patches d'urgence. Pour les composants critiques, appliquer un patch peut casser une fonctionnalité. Les équipes infrastructure refusent légitimement de patcher sans tests. Mais les cycles de tests sont calés sur des fenêtres de maintenance, pas sur des délais de sécurité. La solution : des environnements de préproduction bien entretenus, des tests automatisés, et une pré-qualification des patches critiques dès leur publication.

Construire une priorisation adaptée à 2026

Voici le framework que j'applique, volontairement simple pour être opérationnel dans une organisation sans équipe dédiée de 20 personnes.

Tier 1 — Urgence absolue (SLA : 24h) : Toute CVE dans le catalogue KEV de la CISA ciblant un composant exposé internet. Ces cas ne passent pas par le change management ordinaire. Ils déclenchent un processus d'urgence avec approbation accélérée. Si le patch n'est pas disponible sous 24h : coupure réseau, désactivation du service, ou mise derrière WAF avec règle temporaire.

Tier 2 — Priorité haute (SLA : 7 jours) : CVE CVSS 9.0+ avec PoC public mais pas encore dans le KEV, OU dans le KEV sur des actifs internes non exposés internet. Cycle accéléré avec fenêtre dédiée dans la semaine.

Tier 3 — Priorité normale (SLA : 30 jours) : CVE CVSS 7.0-8.9, sans PoC public, hors KEV. Intégration dans le cycle mensuel standard.

Tier 4 — Backlog (SLA : 90 jours) : CVE sous 7.0, internes uniquement, conditions d'exploitation complexes.

Ce framework découple la priorité du score CVSS brut pour la connecter à l'exploitation réelle et à l'exposition réseau. Il réduit drastiquement le nombre de cas traités en urgence absolue — dans la pratique, les CVE simultanément dans le KEV ET ciblant des actifs exposés internet dans votre parc sont bien moins nombreuses que les CVE CVSS 9+ hebdomadaires.

Il est complété par trois processus non négociables :

• Un inventaire des actifs exposés internet tenu en temps réel, couplé à un outil de scan continu capable de corréler les nouvelles CVE avec l'inventaire en quelques minutes.
• Une veille KEV quotidienne : s'abonner au flux RSS du catalogue CISA KEV et configurer une alerte automatique croisant chaque nouvelle entrée avec l'inventaire des logiciels du parc.
• Un processus d'urgence cybersécurité documenté et testé, avec contacts d'astreinte identifiés, chaîne d'approbation raccourcie, et communications préparées pour les parties prenantes métier.

Le cas particulier des technologies legacy

ColdFusion nous rappelle que des milliers de systèmes critiques fonctionnent en 2026 sur des technologies dont la base d'utilisateurs a considérablement rétréci, dont les équipes de développement sont parties, et dont la mise à jour est perçue comme trop risquée ou trop coûteuse.

Ces systèmes legacy concentrent des vulnérabilités historiques et récentes sur des composants peu surveillés. Et ils sont souvent en accès internet direct parce qu'ils hébergent des portails publics jamais migrés. La combinaison la plus dangereuse qui soit.

La solution n'est pas de patcher indéfiniment des technologies en fin de vie — c'est d'établir un plan de sortie documenté, priorisé et financé, et de mettre en place des contrôles compensatoires forts en attendant : isolation réseau maximale, WAF devant tout service exposé, surveillance renforcée des logs, revue de sécurité semestrielle. Un système legacy sans plan de remplacement et sans contrôles compensatoires n'est pas un risque acceptable — c'est une dette de sécurité qui finira par se régler dans les mauvaises conditions.

Sur les audits que je réalise, les composants legacy non patchés accessibles depuis internet constituent systématiquement l'un des vecteurs d'entrée les plus faciles. Pas parce que les failles sont sophistiquées, mais parce que personne ne les surveille vraiment. Un attaquant qui scanne l'internet à la recherche d'instances ColdFusion 2023 non patchées en juillet 2026 est face à des milliers de cibles. Il lui suffit d'en exploiter une.

Pourquoi les équipes de direction résistent encore

Une réalité terrain à nommer : même avec un framework clair et des outils adaptés, la gestion des vulnérabilités se heurte à des résistances organisationnelles.

Le premier obstacle est le coût perçu du patch vs le risque perçu. Un patch d'urgence peut coûter une demi-journée d'interruption de service et mobiliser 3 personnes. Un compromis que l'attaquant ne lancera peut-être jamais. Dans ce calcul, le risque est abstrait et futur ; le coût est concret et immédiat. Les organisations qui ont déjà subi un incident ransomware ont une perception très différente de ce calcul. Les autres font confiance à leur chance.

Le second obstacle est la fragmentation des responsabilités. La sécurité identifie, l'infrastructure patche, les équipes applicatives valident, le management approuve les fenêtres. Chaque maillon peut créer un délai. Et personne n'est individuellement responsable du délai global. L'accountability est diluée — c'est l'une des raisons pour lesquelles les SLA de patch sont si souvent dépassés sans conséquence interne.

La solution passe par la désignation d'un vulnerability owner par périmètre applicatif, avec un suivi des SLA et une escalade nominative en cas de dépassement. Ce n'est pas une question d'outils — c'est une question de gouvernance.

L'EPSS : combler le vide laissé par le CVSS sur la probabilité d'exploitation

Le FIRST — l'organisme qui maintient le CVSS — a lui-même reconnu la limite du système en développant l'Exploit Prediction Scoring System (EPSS). Contrairement au CVSS qui mesure une sévérité théorique figée à la publication, l'EPSS calcule chaque jour, pour chaque CVE active, une probabilité d'exploitation réelle dans les 30 jours à venir, sur une échelle de 0 à 1. Le modèle s'appuie sur un apprentissage automatique entraîné sur des données de scan actif, de trafic IDS, de mentions sur les forums d'exploitation et de code publié sur GitHub — près de 1 100 variables par CVE dans la version 4 déployée en 2025.

Les chiffres publiés par le FIRST sont éclairants : sur l'ensemble des CVE référencées, moins de 5 % sont un jour exploitées activement en conditions réelles. Pourtant, le CVSS seul pousse les équipes à traiter uniformément ces 5 % et les 95 % restants dès lors que le score dépasse 9.0. L'EPSS permet un tri radicalement différent : une étude du FIRST montre qu'en ne patchant que les CVE dont l'EPSS dépasse 0.36 — soit environ 4 % du volume total — une organisation couvre plus de 80 % des vulnérabilités réellement exploitées. C'est un changement d'échelle complet dans l'allocation des ressources de patch management.

Concrètement, pour ColdFusion (CVE-2026-48282), le CVSS affichait 10.0 dès la publication — un score statique. L'EPSS, lui, est passé de 0.04 à 0.89 en moins de 72 heures, au rythme où les premiers scans et PoC apparaissaient sur les dépôts publics. Une organisation surveillant l'EPSS en continu aurait vu ce signal grimper avant même l'apparition du CVE dans le catalogue KEV de la CISA — gagnant potentiellement 24 à 48 heures sur la fenêtre de compromission.

• Consultation de l'EPSS : API publique gratuite sur api.first.org/data/v1/epss, interrogeable par CVE ou en flux quotidien complet (CSV, ~250 000 entrées).
• Seuil opérationnel recommandé : combiner EPSS > 0.36 OU présence au catalogue KEV comme déclencheur automatique de patch sous 72h, indépendamment du score CVSS brut.
• Fréquence de mise à jour : quotidienne — contrairement au CVSS qui reste figé une fois publié, l'EPSS doit être réévalué en continu dans le pipeline de vulnerability management.

SSVC et l'outillage : automatiser la décision plutôt que le score

Le CERT/CC et la CISA ont développé une alternative structurellement différente du scoring : le Stakeholder-Specific Vulnerability Categorization (SSVC). Plutôt que de produire un nombre unique, SSVC est un arbre de décision qui croise l'état d'exploitation (aucune, PoC, active), l'automatisabilité de l'attaque, l'impact technique et les missions critiques exposées, pour aboutir à l'un de quatre verdicts opérationnels : Track, Track*, Attend ou Act. Un CVE classé "Act" déclenche une remédiation immédiate, hors cycle de maintenance — exactement le mécanisme qui aurait dû s'enclencher pour ColdFusion.

Cette logique se retrouve désormais nativement dans l'outillage commercial de vulnerability management. Qualys VMDR calcule un TruRisk Score qui pondère CVSS, EPSS, présence au KEV, exposition réseau (interne/externe) et criticité métier de l'actif. Tenable propose le Vulnerability Priority Rating (VPR), recalculé quotidiennement selon les mêmes principes. Rapid7 InsightVM utilise un Real Risk Score sur 1000 points intégrant la maturité des exploits disponibles sur Metasploit et ExploitDB. Dans les trois cas, le score CVSS brut devient une variable parmi cinq ou six, plus jamais le seul critère de décision.

L'automatisation ne s'arrête pas au scoring : les organisations les plus matures branchent ces plateformes à leur SOAR pour déclencher des playbooks sans intervention humaine. Exemple type observé chez plusieurs grands comptes en 2026 : un actif taggé "internet-facing" et "critique", touché par un CVE présent au KEV depuis moins de 24h avec un EPSS supérieur à 0.5, déclenche automatiquement l'isolation réseau temporaire du service concerné en attendant le patch — plutôt que l'ouverture d'un simple ticket P1 dans la file d'attente habituelle. C'est ce delta entre détection automatisée et décision automatisée qui sépare aujourd'hui les organisations compromises en 72 heures de celles qui absorbent l'incident avant qu'il ne devienne une brèche.

Questions fréquentes

Qu'est-ce que gestion des vulnérabilités CVSS KEV priorisation patch management et pourquoi est-ce important ?

La réponse dépend du contexte organisationnel, mais les principes fondamentaux restent constants : évaluation du périmètre, identification des actifs critiques et priorisation par risque réel plutôt que par vulnérabilité isolée.

Comment mettre en oeuvre les bonnes pratiques liées à gestion des vulnérabilités CVSS KEV priorisation patch management ?

Une approche structurée et documentée est clé. Les outils et méthodologies évoluent rapidement — rester informé des ressources ANSSI, NIST et MITRE ATT&CK est indispensable pour adapter les recommandations génériques à chaque contexte.

Quelles ressources pour approfondir gestion des vulnérabilités CVSS KEV priorisation patch management ?

Les ressources officielles (ANSSI, CISA, CERT-FR) constituent le point de départ. Complétées par des retours d'expérience terrain, elles permettent d'adapter les recommandations aux réalités opérationnelles de chaque organisation.

Conclusion

Le CVSS continuera d'exister parce qu'il remplit une fonction utile de communication. Mais en 2026, s'appuyer uniquement sur lui pour prioriser les actions de sécurité, c'est naviguer dans une tempête avec une carte météo vieille d'une semaine. L'exploitation des vulnérabilités se mesure maintenant en heures. Le catalogue KEV de la CISA, l'exposition réseau et la disponibilité d'un PoC sont les trois variables qui doivent piloter vos SLA de patch management.

ColdFusion CVSS 10 exploité en 2 minutes. Fairlife infiltré 6 semaines. Conduent compromis 84 jours. Les incidents de juillet 2026 partagent un dénominateur commun : une réponse trop lente face à des attaquants qui opèrent en temps réel. Les outils et les méthodes pour répondre à cette vitesse existent. Ce qui manque dans la plupart des organisations, c'est la décision d'en faire une priorité — avant que l'incident suivant ne l'impose.