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

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 CISA. C'est efficace. C'est aussi un transfert silencieux de souveraineté décisionnelle qu'on n'a pas tranché collectivement.

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

Le Known Exploited Vulnerabilities Catalog de CISA est né en novembre 2021 avec une promesse simple : lister les vulnérabilités qui sont effectivement exploitées dans la nature, plutôt que celles qui sont théoriquement critiques. À l'origine, c'était un instrument réglementaire interne au gouvernement fédéral américain, applicable aux seules agences FCEB. 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 avec le gouvernement américain.

Le constat se vérifie sur le terrain. Quand je discute avec des équipes sécurité d'ETI françaises ou de PME industrielles, la première question qu'elles se posent face à une CVE n'est plus « Quel CVSS ? » mais « Est-ce qu'elle est dans le KEV ? ». Les outils de Vulnerability Management — Tenable, Qualys, Rapid7, Wiz — affichent désormais un drapeau KEV qui passe systématiquement avant le score CVSS dans les écrans de dashboard. La pression managériale suit : un comité direction qui voit « 47 vulnérabilités KEV non patchées chez nous » réagit. La même DSI qui voit « 12 000 CVE CVSS 7+ non patchées » classe ça sous « bruit normal ».

Pourquoi ça marche — et pourquoi ça remplace le CVSS

Soyons honnêtes : le CVSS, en tant qu'outil de priorisation, ne fonctionnait pas. Sur dix ans de pratique, le score CVSS d'une CVE n'est qu'un prédicteur médiocre de la probabilité qu'elle soit effectivement exploitée. Des études comme celles de Cyentia ou Kenna Security ont montré que moins de 5 % des CVE publiées sont exploitées dans la nature, mais la distribution n'est pas du tout corrélée au CVSS. On a passé une décennie à patcher en priorité des CVSS 9 qui ne seraient jamais exploitées, en laissant ouvertes des CVSS 6 qui le seraient.

Le KEV change ça. C'est une liste basée sur l'observation, pas sur la modélisation. Quand CISA inscrit CVE-2026-32202 sur le KEV avec une échéance au 12 mai, ils disent factuellement « on a vu cette faille être exploitée, voici une preuve ». Pour un RSSI, c'est une donnée actionnable d'une qualité incomparable par rapport à un score théorique.

Couplé au framework EPSS — qui donne une probabilité d'exploitation prédictive sur les 30 prochains jours — on obtient enfin un binôme cohérent : EPSS pour anticiper, KEV pour confirmer. C'est l'outillage de priorisation qu'on aurait dû avoir depuis 2015.

Le problème : on a externalisé la priorisation chez CISA

Maintenant la partie qu'on ne dit pas assez. Le KEV n'est pas neutre. C'est un produit éditorial. Une équipe humaine de CISA, basée à Washington, décide quelle vulnérabilité entre dans le catalogue, à quel moment, avec quel délai imposé. Les critères sont publiés mais l'application reste discrétionnaire : il y a des CVE manifestement exploitées qui mettent des semaines à entrer dans le KEV, et inversement, certaines entrées sont contestées par les vendors concernés.

En pratique, quand une PME industrielle française cale sa fenêtre de maintenance sur une échéance KEV, elle s'aligne sur le calendrier opérationnel d'une agence fédérale américaine. C'est un transfert d'autorité. Pas grave en soi tant que les intérêts convergent. Plus problématique le jour où ils divergeront — sur des vulnérabilités touchant des produits stratégiques européens, ou en cas de tension géopolitique.

Le CERT-FR publie des avis et des alertes, mais sans la dimension d'obligation calendaire qui fait la force du KEV. NIS2 introduit une logique de signalement, pas de priorisation directive. Il n'existe pas, à ce jour, d'équivalent européen au KEV qui aurait la même portée prescriptive.

Ce qu'il faut faire concrètement

Le KEV est un excellent outil. Il faut continuer à l'utiliser. Mais il faut aussi arrêter de le traiter comme une source unique. Trois choses à mettre en place dans une équipe sécurité mature :

D'abord, croiser KEV avec les avis du CERT-FR et de l'ANSSI. Le CERT-FR signale parfois en avance des vulnérabilités exploitées en Europe avant qu'elles n'apparaissent dans le KEV. C'est notamment vrai sur les produits français comme Centreon ou OVH, et sur les ciblages spécifiques d'organisations européennes.

Ensuite, intégrer EPSS dans la pondération. Une CVE non encore au KEV mais avec un EPSS au-dessus de 0,5 mérite la même attention qu'une entrée KEV. Attendre que CISA confirme l'exploitation, c'est attendre d'avoir été précédé par d'autres victimes.

Enfin, garder une lecture contextuelle. Une CVE KEV sur un produit que vous n'avez pas, ou dans une configuration que vous ne déployez pas, n'est pas votre priorité même si elle est dans le catalogue. À l'inverse, une CVE non KEV mais sur un système exposé Internet sans EDR mérite d'être traitée comme prioritaire.

Conclusion

Le KEV de CISA est devenu un outil indispensable du patch management moderne. Il faut continuer à l'utiliser, le revendiquer même, et arrêter le déni qui consistait à dire qu'on priorisait sur le CVSS alors qu'on ne le faisait jamais vraiment. Mais l'utiliser intelligemment, c'est aussi le compléter — par les avis CERT-FR, par EPSS, par une lecture contextuelle de son propre périmètre — et reconnaître qu'on confie aujourd'hui une partie de notre priorisation cyber à une agence étrangère. C'est une réalité opérationnelle qu'il vaut mieux nommer pour pouvoir la gouverner.