Le 28 septembre 2026, la CISA a officiellement arrêté son bulletin hebdomadaire de vulnérabilités — une publication qui durait depuis plus de vingt ans. Beaucoup ont salué la décision. Moi, j'ai surtout pensé : il était temps. Et pas pour les raisons officielles.

Ce que représentait le bulletin CISA pour l'industrie

Pendant plus de deux décennies, le bulletin hebdomadaire de vulnérabilités de la CISA (anciennement US-CERT) a été la bible de nombreuses équipes de sécurité. Chaque lundi matin, des milliers de RSSI, d'ingénieurs système et d'administrateurs réseau à travers le monde ouvraient cet email pour décider quoi patcher en priorité cette semaine. C'était un rituel. Un repère dans le chaos permanent de la gestion des vulnérabilités.

Il faut comprendre le contexte dans lequel ce bulletin a émergé. Dans les années 2000 et 2010, la surface d'attaque des organisations était relativement contenue. Les systèmes exposés sur Internet étaient l'exception plutôt que la règle. Un RSSI pouvait raisonnablement lire la liste hebdomadaire, identifier les systèmes concernés dans son parc, et planifier des fenêtres de maintenance. Le bulletin CISA fonctionnait parce que le monde était encore gérable à cette échelle-là.

Ce monde n'existe plus. Aujourd'hui, une organisation de taille moyenne expose des centaines d'applications et de services sur Internet. Les cloud providers publient des dizaines de nouvelles vulnérabilités par semaine dans leurs propres services. Les fournisseurs SaaS patchent en continu sans bulletin coordonné. Et les attaquants, eux, n'attendent pas le lundi matin pour lire la liste CISA — ils ont leurs propres pipelines de détection des CVEs critiques, souvent plus rapides que les équipes défensives.

La CISA a officiellement justifié l'arrêt du bulletin par un « changement de paradigme vers la priorisation basée sur le risque réel » et par l'existence du catalogue KEV (Known Exploited Vulnerabilities), lancé en novembre 2021. Ces raisons sont valides. Mais elles occultent une vérité plus inconfortable que l'industrie n'aime pas admettre : le vrai problème, c'est le CVSS lui-même.

Le problème fondamental du CVSS comme indicateur d'urgence

Le Common Vulnerability Scoring System (CVSS) a été conçu pour fournir une mesure standardisée de la sévérité technique d'une vulnérabilité. C'est ce pour quoi il a été conçu. Le problème, c'est ce pour quoi on l'a utilisé : décider quoi patcher en priorité, en temps réel, dans un environnement de production.

Ces deux usages sont fondamentalement différents. La sévérité technique d'une vulnérabilité — est-ce que c'est grave dans l'absolu ? — est une propriété relativement stable qu'on peut calculer une fois et publier. La priorité de remédiation — est-ce que je dois patcher ça maintenant, ce soir, ou dans deux semaines ? — dépend d'une multitude de facteurs contextuels que le CVSS ne mesure pas : est-ce que j'ai ce système ? Est-il exposé sur Internet ? Y a-t-il une exploitation active dans la nature ? Mon WAF bloque-t-il déjà le vecteur ? Est-ce que l'actif vulnérable est en production ou en dev ?

Des études répétées ont montré l'échec du CVSS comme outil de priorisation. Une étude de Cyentia Institute publiée en 2024 a analysé plus de 200 000 CVEs historiques et conclu que seulement 5 à 7 % des vulnérabilités publiées sont jamais exploitées dans des attaques réelles. Parmi les CVEs avec un CVSS supérieur à 9, le taux d'exploitation effective était certes plus élevé — autour de 15 % — mais cela signifie que 85 % des vulnérabilités CVSS 9+ que vous vous épuisez à patcher en urgence ne seront jamais exploitées contre vous. Pendant ce temps, des vulnérabilités CVSS 6 ou 7 avec une exploitation active et ciblée font des dégâts réels chez vos concurrents.

J'ai vu ce phénomène des dizaines de fois en mission. Des équipes qui passent une semaine à patcher en urgence une CVE 9.8 sur un système en VLAN isolé sans exposition Internet, pendant que leur VPN SSL non patché depuis six mois (CVSS 7.5) sert de porte d'entrée à un acteur de menace. La dictature du score CVSS crée une fausse urgence sur les mauvaises cibles.

Le bulletin CISA hebdomadaire amplifiait ce problème en fournissant une liste non-filtrée et non-contextualisée de vulnérabilités avec leur score CVSS brut. Le message implicite : « voici ce qui est sorti cette semaine, traitez les CVSS 9+ en priorité. » C'est une approche qui semblait raisonnable mais qui en réalité guidait les équipes vers un effort considérable pour une protection marginale.

La gestion du risque réel : le tournant KEV et l'exploitation active

Le vrai signal d'un changement de paradigme est venu en novembre 2021 avec le lancement du catalogue KEV par la CISA. L'idée est simple et puissante : au lieu de lister toutes les CVEs avec leur score théorique, lister uniquement les vulnérabilités pour lesquelles des preuves d'exploitation réelle dans la nature ont été identifiées.

Le résultat est frappant. Là où le NVD publie entre 25 000 et 30 000 nouvelles CVEs par an, le catalogue KEV en compte environ 1 200 au total depuis sa création en 2021 — soit une infime fraction des vulnérabilités théoriquement sévères. Si vous patchés systématiquement et rapidement les CVEs dans le catalogue KEV, vous couvrez l'immense majorité des vecteurs d'attaque réellement utilisés par les acteurs de menace. C'est le principe de Pareto appliqué à la gestion des vulnérabilités : 20 % de l'effort de priorisation pour 80 % de la réduction du risque réel.

La Binding Operational Directive 26-04 émise par la CISA en 2026 pousse cette logique encore plus loin en imposant aux agences fédérales américaines de prioriser les remédiations selon une combinaison de critères : exploitation active confirmée (KEV), exposition sur Internet de l'actif vulnérable, présence dans des systèmes critiques. C'est une approche que les équipes de sécurité les plus matures appliquaient déjà intuitivement. Elle devient maintenant normative pour les entités fédérales américaines, et il y a fort à parier que les référentiels européens (NIS2, RGS) suivront dans les prochaines années.

En France, l'ANSSI adopte depuis plusieurs années une approche similaire dans ses bulletins de sécurité, en distinguant entre les avis de sécurité (informationnel) et les alertes (exploitation active, action urgente requise). La fin du bulletin CISA devrait inciter les équipes de sécurité françaises à se concentrer encore davantage sur les alertes ANSSI et les publications CERT-FR plutôt que sur les listes brutes de CVEs.

Ce que ça change concrètement pour les équipes françaises

La question que me posent souvent les RSSI en mission : « Si je ne suis plus le bulletin CISA, qu'est-ce que je suis ? » Ma réponse est claire : vous devriez suivre trois sources en priorité, et trois seulement pour la veille quotidienne.

Première source : le catalogue KEV de la CISA, mis à jour en temps réel dès qu'une exploitation active est confirmée. Abonnez-vous aux notifications par email ou RSS directement sur le site de la CISA. Une vulnérabilité qui entre dans le KEV mérite une attention immédiate, indépendamment de son score CVSS. Deuxième source : les alertes du CERT-FR et de l'ANSSI, qui couvrent spécifiquement le contexte européen et français. Pour les entreprises françaises, ces sources sont souvent plus pertinentes car elles tiennent compte des produits les plus déployés dans les organisations françaises et des acteurs de menace actifs en France. Troisième source : les bulletins de vos fournisseurs critiques. Microsoft Patch Tuesday, les advisories Cisco, Fortinet, VMware et les autres éditeurs présents dans votre SI. Ces bulletins sont beaucoup plus actionables que les listes génériques parce qu'ils concernent précisément votre stack technologique.

Au-delà des sources, la vraie question est celle du processus. La fin du bulletin CISA est une opportunité pour les équipes de sécurité de revoir leur cycle de gestion des vulnérabilités. Si votre processus de priorisation consiste encore à trier une liste CVSS décroissante et à patcher les CVSS 9+ en premier, il est temps de le refondre. Un processus mature de gestion des vulnérabilités doit intégrer quatre dimensions : la sévérité technique (CVSS), l'exploitation active (KEV, EPSS), l'exposition concrète de l'actif dans votre SI, et la criticité métier de l'actif concerné.

La bonne nouvelle, c'est que des outils open source permettent désormais d'automatiser une partie de ce travail. L'EPSS (Exploit Prediction Scoring System) du FIRST calcule pour chaque CVE une probabilité d'exploitation dans les 30 prochains jours basée sur des signaux comportementaux. Un CVE avec un EPSS élevé mais un CVSS modéré mérite souvent plus d'attention qu'un CVSS 9.8 avec un EPSS bas. L'intégration de l'EPSS dans vos scanners de vulnérabilités (Tenable, Qualys, Wiz) est désormais possible sur la plupart des plateformes.

Le vrai défi : passer du score à la surface d'attaque réelle

La fin du bulletin CISA n'est pas seulement un changement de source d'information. C'est le symptôme d'une transformation plus profonde que les équipes de sécurité matures ont déjà amorcée et que les autres vont devoir rattraper : passer de la gestion des vulnérabilités théoriques à la gestion de la surface d'attaque réelle.

La gestion des vulnérabilités traditionnelle repose sur un modèle linéaire : scanner les systèmes, obtenir une liste de CVEs, prioriser par score, patcher. Ce modèle a trois défauts majeurs dans le contexte de 2026. Premier défaut : il ne prend pas en compte l'exposition réelle. Une vulnérabilité sur un serveur en DMZ avec accès Internet direct n'a pas la même priorité qu'une vulnérabilité identique sur un système en réseau interne sans aucune exposition. Le score CVSS est le même dans les deux cas ; le risque réel est radicalement différent.

Deuxième défaut : il ne prend pas en compte les chemins d'attaque. Dans une infrastructure moderne, un attaquant ne compromet pas directement le système le plus critique — il entre par un système périphérique moins bien protégé et se déplace latéralement. Identifier les chemins d'attaque possibles depuis l'extérieur vers les actifs critiques est une approche beaucoup plus pertinente que de patcher tous les CVSS 8+ de manière uniforme. Les outils de gestion de la surface d'attaque externe (ASM — Attack Surface Management) comme Censys, Shodan ou Tenable.asm permettent de cartographier ces chemins.

Troisième défaut : il ne prend pas en compte la vitesse d'exploitation. Le délai entre la publication d'une CVE et les premières tentatives d'exploitation s'est considérablement réduit depuis 2020. En 2021, selon Google Project Zero, la médiane était de 12 jours. En 2024, elle était descendue sous les 5 jours pour les CVEs avec PoC public. En 2026, certaines vulnérabilités (comme CVE-2026-87902 sur WordPress, exploitée dans les heures suivant la publication du patch) atteignent une exploitation quasi-immédiate. Dans ce contexte, un cycle de patch mensuel ou même hebdomadaire est insuffisant pour les actifs critiques exposés sur Internet. Les actifs de la « couture » — pare-feux, VPN, load balancers, serveurs web en DMZ — doivent être patchés dans les 24 à 48 heures suivant la publication d'une CVE critique les concernant.

Ce n'est pas réaliste pour toutes les organisations, me répondra-t-on. C'est vrai. Mais c'est précisément pourquoi la priorisation basée sur le risque réel est indispensable : vous ne pouvez pas tout patcher vite, donc vous devez savoir avec précision où concentrer votre effort. Et le bulletin CISA hebdomadaire, avec sa liste non-filtrée de centaines de CVEs, était exactement l'outil inverse de ce dont vous avez besoin.

Le calendrier qui vient et ce que j'anticipe

La disparition du bulletin CISA va probablement accélérer plusieurs tendances déjà en cours. Premièrement, l'adoption de plateformes intégrées de gestion des vulnérabilités et de la surface d'attaque : les outils qui combinent scan, priorisation contextuelle (EPSS + KEV + exposition), et suivi de remédiation vont gagner du terrain face aux simples scanners CVSS. Deuxièmement, le rôle des MSSPs (Managed Security Service Providers) va se renforcer pour les organisations sans équipe de sécurité dédiée — la veille sur les sources pertinentes et la priorisation contextualisée sont exactement les services de valeur que les MSSPs peuvent apporter.

En France spécifiquement, je pense que NIS2 va jouer un rôle accélérateur. Les organisations couvertes par NIS2 — qui vient d'entrer en phase d'application effective en France en 2026 — ont des obligations renforcées de gestion des vulnérabilités. Ces obligations vont forcer des processus plus structurés et moins dépendants des raccourcis CVSS. C'est une bonne nouvelle pour la posture de sécurité globale, même si la transition sera douloureuse pour beaucoup d'équipes habituées aux anciens réflexes.

Mon avis d'expert

La fin du bulletin CISA est la bonne décision, prise avec cinq ans de retard. Le vrai scandale n'est pas que la CISA ait arrêté son bulletin — c'est que tant d'organisations aient continué à l'utiliser comme outil de priorisation alors que des alternatives clairement supérieures (KEV, EPSS) existaient depuis des années. En 2026, prioriser vos patchs sur la base du CVSS seul, c'est comme naviguer avec une carte de 2005 dans une ville qui a entièrement reconstruit son réseau routier. Le score vous dit que quelque chose est potentiellement dangereux. Il ne vous dit pas si c'est dangereux pour vous, maintenant, avec votre infrastructure. C'est cette question que vous devez apprendre à répondre seuls — ou avec les bons partenaires.

Conclusion

La mort du bulletin CISA est un signal de marché. Elle dit aux équipes de sécurité que le monde a changé et que les outils et réflexes des années 2000 ne sont plus adaptés. La gestion des vulnérabilités en 2026 ne peut plus être une liste à cocher triée par score décroissant. Elle doit être une discipline contextualisée, dynamique et connectée aux signaux d'exploitation réelle. Si vous n'avez pas encore intégré le catalogue KEV et l'EPSS dans votre processus de priorisation, c'est le premier chantier à adresser. Pas la semaine prochaine.

Besoin d'un regard expert sur votre sécurité ?

Discutons de votre contexte spécifique et de votre processus de gestion des vulnérabilités.

Prendre contact