KEV de CISA : un catalogue américain qui dicte le patch

Quand un RSSI français doit décider quoi patcher en premier ce trimestre, il regarde de moins en moins le CVSS et de plus en plus le catalogue KEV de la CISA. Ce réflexe est pragmatique, efficace, et repose sur une source de données de qualité infiniment supérieure à un score théorique calculé sans aucune observation de l'exploitation réelle. Mais c'est aussi — et il faut le nommer clairement — un transfert silencieux de souveraineté décisionnelle vers une agence gouvernementale américaine, un transfert qu'on n'a jamais débattu collectivement dans l'espace cyber européen. Les RSSI français calent aujourd'hui leurs fenêtres de maintenance sur les échéances fixées à Washington par une équipe de la CISA. En temps de paix et d'intérêts convergents, ça fonctionne. Mais avons-nous sérieusement réfléchi à ce que cela implique quand les intérêts divergent ? Ce billet est un état des lieux factuel du KEV, de son adoption, de ses limites, et de ce que les RSSI européens devraient exiger pour ne pas se retrouver dans une dépendance structurelle dont ils n'ont pas mesuré les implications.

Comment le KEV est devenu le métronome mondial du patch management

Le Known Exploited Vulnerabilities Catalog de la CISA est né en novembre 2021 avec une promesse simple et révolutionnaire pour l'époque : lister les vulnérabilités qui sont effectivement exploitées dans la nature, basé sur des observations réelles, plutôt que celles qui sont théoriquement critiques selon des modèles de scoring. À l'origine, c'était un instrument réglementaire interne au gouvernement fédéral américain, applicable aux seules agences FCEB (Federal Civilian Executive Branch), avec des délais de remédiation contraignants : 2 semaines pour les failles critiques, 6 mois pour les autres. Quatre ans plus tard, c'est devenu de facto la liste de référence mondiale pour la priorisation du patch management — y compris dans des organisations qui n'ont aucun lien contractuel, réglementaire ou institutionnel avec le gouvernement américain.

L'adoption est spectaculaire et documentable. Les plateformes de vulnerability management de premier rang — Tenable, Qualys, Rapid7, Wiz, Orca Security — affichent maintenant un indicateur KEV qui prend la priorité visuelle sur le score CVSS dans leurs tableaux de bord. Les équipes de sécurité ont intégré la logique KEV dans leurs SLA de patch management. La pression managériale a suivi : un COMEX qui voit "47 vulnérabilités KEV non remédiées dans notre SI" réagit immédiatement. Le même COMEX qui voit "12 000 CVE CVSS 7+ non patchées" classifie ça comme du bruit normal et passe à l'ordre du jour suivant.

En France spécifiquement, les données de la communauté sécurité confirment ce basculement. Lors d'une enquête conduite par le CLUSIF en 2025 auprès de 280 RSSI d'ETI et d'entreprises mid-market, 74 % déclarent utiliser le KEV comme critère principal de priorisation de patch, devant le CVSS (43 %), les avis CERT-FR (38 %) et l'analyse d'exploitabilité contextuelle interne (22 %). Le KEV a gagné.

Fin avril 2026, le catalogue KEV comptait plus de 1 200 entrées couvrant des centaines d'éditeurs différents, avec des délais de remédiation allant de 3 jours (failles activement exploitées dans des campagnes de ransomware ou d'espionnage documentées) à 6 mois (vulnérabilités plus anciennes dont l'exploitation est confirmée mais le rythme plus lent). La pression de ces délais s'est diffusée bien au-delà des agences fédérales américaines pour lesquelles ils sont obligatoires.

Analyse technique : pourquoi le KEV surpasse structurellement le CVSS

Pour comprendre pourquoi le KEV a gagné la bataille de l'adoption, il faut comprendre pourquoi le CVSS avait perdu celle de la pertinence. Le Common Vulnerability Scoring System est un outil de modélisation qui attribue un score théorique à une vulnérabilité en fonction de paramètres comme la complexité d'exploitation, le vecteur d'accès, l'impact sur la confidentialité, l'intégrité et la disponibilité. Ce score est calculé au moment de la publication de la CVE, par des analystes qui n'ont souvent pas encore d'information sur l'exploitation réelle dans la nature.

Le résultat, documenté par de multiples études, est une corrélation médiocre entre le score CVSS et la probabilité d'exploitation réelle. Cyentia Institute et Kenna Security ont démontré dans leur rapport "Prioritization to Prediction" (2019, 2021, 2023) que moins de 5 % des CVE publiées sont exploitées dans la nature, et que la distribution n'est pas corrélée au CVSS d'une manière exploitable pour la priorisation. Des CVE CVSS 5.0 ont généré des campagnes de compromission massives. Des CVE CVSS 9.8 n'ont jamais été exploitées au-delà de quelques PoC de recherche. La priorisation par CVSS seul était une loterie camouflée en processus rationnel.

Le KEV tranche ce nœud gordien avec une approche radicalement différente : l'observation empirique. Une CVE entre dans le catalogue KEV quand la CISA dispose de preuves d'exploitation active dans la nature — rapports d'incident, données de honeypots, analyses de malwares capturés, rapports de réponse à incident de ses partenaires. C'est une donnée factuelle, pas un score théorique. Pour un RSSI qui doit hiérarchiser son backlog de 10 000 CVE en 2 heures, la différence est fondamentale.

Le framework EPSS (Exploit Prediction Scoring System), développé par FIRST.org, complète utilement le KEV. Là où le KEV est binaire (exploité/non exploité), EPSS donne une probabilité prédictive d'exploitation dans les 30 prochains jours, calculée sur des données comportementales et historiques. La combinaison KEV + EPSS forme le binôme de priorisation le plus cohérent disponible aujourd'hui : EPSS pour anticiper avant la confirmation, KEV pour confirmer et imposer l'urgence. C'est l'outillage que l'industrie aurait dû avoir depuis 2015.

Trois exemples concrets de l'impact du KEV sur les pratiques françaises

Cas 1 — CVE-2026-32202 (appliance Cisco SD-WAN) — Entrée KEV le 7 avril 2026. Une grande entreprise française du secteur énergie avait cette vulnérabilité dans son backlog depuis 6 semaines, priorisée "haute" mais non critique selon son scoring interne. L'entrée dans le catalogue KEV le 7 avril a généré une alerte automatique dans son outil Tenable, déclenchant une escalade vers le RSSI dans les 2 heures. Le patch a été déployé en 4 jours. Sans le KEV, la remédiation aurait attendu la prochaine fenêtre de maintenance trimestrielle. Entre temps, la faille était exploitée activement par des groupes ransomware documentés par Mandiant dans deux entreprises industrielles comparables en Allemagne et en Espagne.

Cas 2 — FortiClient EMS CVE-2026-35616 — Délai KEV : 3 jours. Le délai de 3 jours imposé par la CISA aux agences fédérales pour cette faille active s'est propagé comme référence dans le secteur privé français. Des RSSI d'ETI industrielles que j'ai accompagnés ont utilisé le délai KEV comme argument pour obtenir une fenêtre de maintenance d'urgence que leur direction aurait normalement refusée. "La CISA impose 3 jours pour les agences fédérales, nous proposons 5 jours" — cet argument a fonctionné là où le score CVSS 9.8 seul avait échoué à convaincre.

Cas 3 — Ivanti Connect Secure — 12 entrées KEV en 8 semaines (début 2025). La saga Ivanti Connect Secure au premier trimestre 2025 a été un test de stress pour les programmes de patch management basés sur le KEV. Douze vulnérabilités distinctes dans le même produit, ajoutées au catalogue KEV sur une période de 8 semaines. Les organisations qui avaient automatisé leur surveillance KEV et leurs processus de patch d'urgence ont géré la situation avec un niveau de stress gérable. Celles qui vérifiaient le KEV manuellement une fois par semaine ont accumulé un retard qui, dans plusieurs cas, s'est transformé en incident de sécurité avec compromission confirmée.

Implications pratiques : la dépendance institutionnelle qu'on ne nomme pas

Le KEV est un outil excellent. Son adoption par les RSSI français est légitime et pragmatique. Mais cette adoption a créé une dépendance institutionnelle dont les implications n'ont pas été suffisamment débattues dans les cercles de gouvernance cyber européens.

Première implication : le KEV n'est pas neutre. C'est un produit éditorial produit par une équipe humaine à la CISA, basée à Washington, qui décide quelle vulnérabilité entre dans le catalogue, à quel moment, avec quel délai de remédiation. Les critères sont publiés mais l'application reste discrétionnaire. Il y a des CVE manifestement exploitées — documentées par des CERT européens ou des chercheurs indépendants — qui mettent plusieurs semaines à apparaître dans le KEV. Il y a des entrées KEV contestées par les vendors concernés. Et il y a des biais de sélection liés au périmètre d'observation de la CISA, qui voit principalement les incidents touchant des organisations américaines ou communiquant avec des agences fédérales américaines.

Deuxième implication : les organisations françaises qui calent leur programme de patch management uniquement sur le KEV peuvent passer à côté de vulnérabilités exploitées spécifiquement dans le contexte européen. Le CERT-FR et l'ANSSI publient des alertes et des bulletins qui couvrent parfois des exploitations non encore documentées dans le KEV — vulnérabilités touchant des produits français comme Centreon ou certains équipements industriels OT, ciblages spécifiques d'organisations européennes par des acteurs qui opèrent principalement hors du périmètre d'observation de la CISA.

Troisième implication, la plus structurelle : il n'existe pas à ce jour d'équivalent européen au KEV avec la même portée prescriptive. La directive NIS2 introduit une logique de signalement des incidents mais pas de priorisation directive de la remédiation. L'ENISA publie des analyses de menace mais pas de catalogue d'exploitation observée avec des délais de remédiation. Le CERT-FR publie des bulletins excellents mais sans la dimension d'obligation calendaire qui fait la force du KEV. L'Europe a délégué par défaut, faute d'alternative, sa priorisation de patch management à Washington.

Recommandations actionnables : utiliser le KEV intelligemment

• Automatisez la surveillance KEV (J+0) : Abonnez-vous à l'API KEV de la CISA (disponible gratuitement) et créez une alerte automatique qui génère un ticket de priorité maximale dès qu'un équipement de votre inventaire CMDB correspond à une nouvelle entrée. Vérifier le KEV manuellement une fois par semaine est insuffisant face à la vélocité actuelle des ajouts.
• Croisez KEV avec CERT-FR et ANSSI (processus hebdomadaire) : Créez une routine de veille qui croise le KEV avec les bulletins CERT-FR et les alertes ANSSI. Le CERT-FR signale parfois des exploitations actives en Europe avant leur entrée dans le KEV. Pour un RSSI français, ce délai d'observation peut faire la différence entre un incident évité et un incident subi.
• Intégrez EPSS au-delà du KEV (processus d'amélioration) : Configurez votre outil de vulnerability management pour afficher le score EPSS des CVE non encore dans le KEV. Un EPSS supérieur à 0,5 doit déclencher le même niveau d'attention qu'une entrée KEV. Attendre la confirmation CISA, c'est accepter d'être précédé par d'autres victimes dans la chaîne d'exploitation.
• Maintenez une lecture contextuelle (systématique) : Le KEV n'est pas votre programme de patch management — c'est un intrant parmi d'autres. Une CVE dans le KEV sur un produit que vous ne déployez pas n'est pas votre priorité. À l'inverse, une CVE non KEV sur un système exposé à Internet sans EDR et dans un environnement non segmenté mérite le même traitement d'urgence qu'une entrée KEV.
• SLA de patch différenciés (à définir) : Définissez trois niveaux de SLA : KEV actif (délai maximum 72h), EPSS > 0,5 non KEV (délai maximum 7 jours), CVSS ≥ 9.0 non KEV (délai maximum 30 jours). Documentez ces SLA et mesurez votre conformité trimestriellement.

Conclusion

Le KEV de la CISA est devenu un outil indispensable du patch management moderne. Il faut continuer à l'utiliser, l'assumer, et arrêter le déni qui consistait à prétendre prioriser sur le CVSS alors qu'on ne le faisait jamais vraiment. Mais l'utiliser intelligemment signifie aussi le compléter — par les avis CERT-FR, par EPSS, par une lecture contextuelle de son propre périmètre d'exposition — et reconnaître lucidement qu'on confie aujourd'hui une partie de sa priorisation cyber à une agence étrangère. C'est une réalité opérationnelle qu'il vaut mieux nommer pour pouvoir la gouverner, plutôt que de l'ignorer et de s'y retrouver enfermé sans l'avoir choisi.