CISA KEV : le catalogue Known Exploited Vulnerabilities

Qu'est-ce que le catalogue CISA KEV ?

Le catalogue Known Exploited Vulnerabilities (KEV) est tenu par l'agence américaine Cybersecurity and Infrastructure Security Agency (CISA). La CISA le présente comme la source de référence des vulnérabilités exploitées en conditions réelles et encourage vivement toutes les organisations à donner la priorité à leur remédiation.

La CISA a créé le catalogue en novembre 2021, en même temps que la Binding Operational Directive 22-01. Dans la version du catalogue du 24 septembre 2026, il compte 1 723 vulnérabilités. C'est une infime part de toutes les CVE publiées, et c'est précisément ce qui fait son utilité : une entrée KEV n'est ni une prédiction ni un niveau de sévérité, c'est un constat d'exploitation.

Comment une vulnérabilité y est ajoutée

La CISA ajoute une vulnérabilité lorsqu'elle remplit trois critères :

Elle a un identifiant CVE.
Elle est activement exploitée, avec des preuves fiables qu'elle a été ou qu'elle est exploitée.
Il existe des consignes de remédiation claires, c'est-à-dire une action claire pour les organisations concernées, comme une mise à jour de l'éditeur.

Le troisième critère compte en pratique : une vulnérabilité peut être exploitée pendant un certain temps avant d'apparaître dans le KEV, faute de correctif à indiquer. N'importe qui peut proposer une vulnérabilité via un formulaire accessible depuis la page KEV de la CISA.

Ce que contient chaque entrée KEV

Champ	Ce qu'il contient
`cveID`	L'identifiant CVE
`vendorProject`, `product`	L'éditeur du logiciel concerné et le produit
`vulnerabilityName`, `shortDescription`	Un nom et une courte description
`dateAdded`, `dueDate`	La date d'ajout par la CISA et la date limite de remédiation pour les agences fédérales américaines
`requiredAction`	Ce qu'il faut faire : généralement appliquer les mises à jour ou atténuations de l'éditeur, ou cesser l'utilisation
`knownRansomwareCampaignUse`	« Known » si elle a été utilisée dans une campagne de ransomware, sinon « Unknown »
`forensicTriage`	« Yes » si la BOD 26-04 exige un tri forensique pour cette entrée
`notes`, `cwes`	Les références et les types de faiblesse

361 entrées sont actuellement marquées comme utilisées dans des campagnes de ransomware. Si vous devez établir un classement au sein du KEV, elles passent en premier.

BOD 26-04 : les délais KEV pour les agences fédérales

Pour les agences civiles de l'exécutif fédéral américain, le KEV n'est pas un conseil. La Binding Operational Directive 26-04, publiée le 10 juin 2026, fixe la vitesse à laquelle elles doivent corriger les vulnérabilités. Elle a abrogé la BOD 22-01, qui donnait deux semaines pour la plupart des entrées KEV et six mois pour les CVE attribuées avant 2021, ainsi que la BOD 19-02. Les critères d'ajout d'une vulnérabilité au KEV n'ont pas changé.

La BOD 26-04 fixe chaque délai à partir de quatre questions, inspirées du modèle de décision SSVC de la CISA :

Exposition publique : l'actif est-il accessible depuis des réseaux publics ?
Statut KEV : la vulnérabilité figure-t-elle dans le catalogue ?
Automatisation de l'exploit : un attaquant peut-il automatiser l'exploitation ?
Impact technique : l'exploitation donne-t-elle un contrôle partiel ou total ?

Les réponses donnent des délais allant de 3 jours, avec un tri forensique pour vérifier si le système a déjà été compromis, à une correction lors de la prochaine mise à niveau du système. La directive ne s'applique pas aux entreprises extérieures à l'administration fédérale, sauf disposition contractuelle. Elle reste malgré tout une référence utile pour votre propre politique.

Comment utiliser le KEV si vous développez des logiciels

La plupart des entrées KEV concernent des produits de grands éditeurs : Microsoft en totalise à lui seul 388, suivi de Cisco, Apple, Adobe et Google. L'open source y figure aussi, et le cas échéant, c'est à l'intérieur des produits d'autres éditeurs. Log4Shell (CVE-2021-44228) est l'exemple dont tout le monde se souvient.

Les pipelines de build ne sont pas épargnés. Les GitHub Actions compromises tj-actions/changed-files (CVE-2025-30066) et reviewdog/action-setup (CVE-2025-30154) figurent toutes deux au catalogue : une vulnérabilité exploitée connue peut se trouver dans le workflow qui construit votre produit, et pas seulement dans le produit.

Comparez le KEV à ce que vous livrez, et non à ce que déclarent vos dépôts. Une bibliothèque vulnérable entraînée de façon transitive, ou téléchargée par un script de build, reste dans le produit.
Traitez une correspondance comme un incident, et non comme un élément du backlog. Corrigez-la, ou atténuez-la et consignez pourquoi.
Vérifiez votre période d'exposition. Quelles releases ont livré la version vulnérable, et depuis quand ? C'est ce que demandent les clients.
Surveillez le délai de notification. Selon le Cyber Resilience Act de l'UE, une vulnérabilité activement exploitée dans un produit déclenche pour le fabricant une obligation d'alerte précoce sous 24 heures.
Classez tout le reste avec EPSS et CVSS. La priorisation des vulnérabilités détaille la méthode.

Comment obtenir les données KEV

CISA : la page du catalogue, ainsi que CSV, JSON et un schéma JSON.
GitHub : cisagov/kev-data reproduit les fichiers de données et se met à jour en même temps que le catalogue.
E-mail : la CISA propose un abonnement aux mises à jour du catalogue.
Vos outils : de nombreux scanners et plateformes de gestion des vulnérabilités signalent les entrées KEV, parmi lesquels Grype, Tenable, Qualys et Rapid7.

Comment CRACI vous aide

Le KEV vous dit quelles vulnérabilités sont exploitées. CRACI vous dit où elles se trouvent. Il exécute vos jobs GitHub Actions et enregistre les paquets que chaque job a réellement récupérés, y compris les dépendances transitives, les paquets en cache et les dépendances cachées qu'aucun lockfile ne liste, et réévalue en continu les SBOM surveillées.

Quels builds sont touchés. L'historique des builds montre quels builds passés contenaient la dépendance vulnérable, directe ou transitive : vous connaissez ainsi la période d'exposition.
Qui corrige. Les équipes de sécurité trient les résultats et envoient chacun à l'équipe chargée de la correction.
Empêcher une nouvelle livraison. Les gates de politique peuvent bloquer un build qui contient une CVE précise.
La notification. Pour les vulnérabilités activement exploitées relevant du CRA, CRACI soumet les notifications aux autorités au nom du fabricant.

CISA KEV : questions fréquentes

Qu'est-ce que CISA KEV ?

Le catalogue Known Exploited Vulnerabilities (KEV) est la liste tenue par la CISA des vulnérabilités exploitées en conditions réelles. La CISA le présente comme la source de référence des vulnérabilités exploitées et encourage toutes les organisations à donner la priorité à leur remédiation.

Combien de vulnérabilités le catalogue KEV contient-il ?

1 723 dans la version du catalogue du 24 septembre 2026, sur les centaines de milliers de CVE publiées. 361 d'entre elles sont marquées comme ayant été utilisées dans des campagnes de ransomware.

Qu'est-ce qui fait entrer une vulnérabilité dans le KEV ?

Trois critères : elle a un identifiant CVE, il existe des preuves fiables qu'elle a été ou qu'elle est exploitée, et il existe des consignes de remédiation claires, comme une mise à jour de l'éditeur.

Les entreprises privées doivent-elles respecter les dates limites du KEV ?

Non. Les dates limites s'imposent aux agences civiles de l'exécutif fédéral américain en vertu de la Binding Operational Directive 26-04. Tous les autres peuvent utiliser le catalogue comme signal de priorisation, et de nombreux clients et auditeurs l'attendent.

Qu'est-ce qui a remplacé la BOD 22-01 ?

La BOD 26-04, publiée le 10 juin 2026, a abrogé la BOD 22-01 et la BOD 19-02. Au lieu d'un délai fixe de deux semaines pour les entrées KEV, elle fixe des délais allant de 3 jours à la prochaine mise à niveau du système, selon le statut KEV, l'exposition publique, la possibilité d'automatiser l'exploitation et l'impact technique.

Quelle est la différence entre KEV et EPSS ?

KEV recense les vulnérabilités déjà exploitées. EPSS estime la probabilité qu'une CVE publiée soit exploitée dans les 30 prochains jours. Utilisez d'abord KEV, puis EPSS pour classer tout le reste.