CISA KEV et GCVE : pourquoi l’exploitation confirmée doit changer vos SLA CVE

Toutes les CVE ne méritent pas le même traitement. Certaines décrivent une faiblesse théorique ou difficilement exploitable dans votre contexte. D’autres sont déjà utilisées par des attaquants. Les sources d’exploitation confirmée, comme CISA KEV et GCVE, servent précisément à séparer ces deux catégories.

Dans un backlog de vulnérabilités, une CVE exploitée activement ne doit pas rester au même niveau qu’une CVE non observée. Elle modifie le langage : on ne parle plus seulement de remédiation planifiée, mais de réduction d’exposition, de chasse, de communication et parfois d’incident response.

KEV : un signal court, fort et actionnable

Le catalogue Known Exploited Vulnerabilities de CISA est précieux parce qu’il tranche une question souvent débattue : “est-ce exploité dans le monde réel ?” Lorsqu’une CVE est dans KEV, le débat sur la simple gravité CVSS devient secondaire. Les attaquants ont prouvé qu’ils savent l’utiliser.

Dans isMalicious, ce signal alimente les compteurs KEV, les bannières d’urgence et les filtres de CVE Watch. Il est aussi utile pour les équipes qui explorent manuellement une vulnérabilité via CVE Search.

GCVE : enrichir l’évidence d’exploitation

GCVE ajoute une couche de métadonnées sur l’exploitation et les sources d’évidence. Selon les cas, il peut aider à documenter la source primaire, la confiance, les dates de première et dernière observation, ou des attributs comme l’exécution de code à distance et l’authentification requise.

La nuance est importante : CISA KEV garde une signification institutionnelle forte ; GCVE peut élargir le contexte d’exploitation. Ensemble, ils aident à classer les CVE selon la maturité de l’attaque.

Pourquoi cela change les SLA

Un SLA basé uniquement sur CVSS mélange trop de situations. Une politique plus réaliste peut définir :

• P0 : KEV ou exploitation confirmée sur actif exposé ;
• P1 : EPSS élevé et PoC public sur technologie utilisée ;
• P2 : high/critical sans exploitation connue, corrigible en fenêtre standard ;
• P3 : faible probabilité, non exposé, compensating controls solides.

Ce modèle évite deux erreurs : tout traiter comme urgent, ou ignorer une CVE exploitée parce qu’elle n’a pas le score maximal.

Ce que le SOC doit faire avec KEV

Lorsqu’une CVE KEV touche un actif, le SOC doit ouvrir un cycle de surveillance :

1. identifier les assets et produits concernés ;
2. confirmer l’exposition réseau ;
3. rechercher des indicateurs d’exploitation ;
4. corréler avec IP/domain reputation via Threat Intel IP et Domain Intelligence ;
5. suivre le patch ou la mitigation ;
6. documenter la fermeture.

Cette approche complète les guides d’incident response et de threat hunting.

KEV ne remplace pas EPSS, CERT-FR ou MSRC

KEV répond à une question : exploitation confirmée. Il ne remplace pas EPSS, qui estime une probabilité, ni CERT-FR, MSRC, GHSA ou advisories fournisseurs, qui donnent le contexte de correction. Il ne remplace pas non plus les preuves PoC d’Exploit-DB ou Nuclei.

Un bon système CVE combine donc :

• KEV/GCVE pour l’exploitation ;
• EPSS pour la probabilité ;
• NVD/OpenCVE pour la base et le mapping produit ;
• advisories pour la remédiation ;
• CPE/périmètres pour l’impact réel.

Communication interne

Le mot “exploité” est compréhensible par les dirigeants. Il aide à justifier une fenêtre de changement, un redémarrage, un blocage temporaire ou une exception réseau. Mais il faut éviter l’alarmisme : l’exploitation confirmée dans le monde ne signifie pas automatiquement compromission chez vous. Elle signifie que la preuve externe justifie une vérification accélérée.

Construire une politique KEV concrète

Une politique KEV efficace doit être écrite avant la crise. Elle peut définir une fenêtre de triage courte, par exemple quelques heures pour vérifier l’exposition, puis une fenêtre de remédiation dépendant de la criticité. Les actifs internet-facing, systèmes d’identité, appliances d’accès distant, serveurs de messagerie et services d’administration doivent être traités plus vite que les systèmes isolés.

La politique doit aussi prévoir le cas où le patch n’est pas immédiatement possible. Dans ce scénario, l’équipe documente les contrôles compensatoires : filtrage réseau, restriction d’accès, règle WAF, désactivation de fonctionnalité, surveillance renforcée, sauvegarde, plan de rollback. Un risque accepté sans mitigation explicite n’est pas une décision de sécurité ; c’est une dette invisible.

Relier KEV aux preuves internes

Une CVE KEV doit déclencher une recherche d’indices internes. Les logs web, VPN, EDR, proxy, DNS, authentification et egress peuvent révéler des tentatives ou des compromissions. L’équipe doit aussi vérifier les dates : si l’exploitation publique précède le patch interne, une fenêtre de risque existe et mérite une investigation.

Les signaux d’infrastructure enrichissent cette analyse. Une tentative provenant d’une IP déjà suspecte, un domaine fraîchement créé ou une connexion sortante vers une infrastructure de commande et contrôle rend le dossier plus sérieux. Les pages IP Threat Intelligence et Domain Intelligence complètent donc naturellement la vue KEV.

Reporting et audit

Les vulnérabilités KEV sont faciles à expliquer aux auditeurs : elles sont connues, exploitées et documentées. Un reporting utile doit montrer le nombre de KEV ouvertes, le délai moyen de remédiation, les exceptions, les propriétaires et les contrôles temporaires. Cette visibilité protège l’organisation contre deux risques : l’oubli opérationnel et la communication imprécise.

Conclusion

CISA KEV et GCVE sont des accélérateurs de décision. Ils ne doivent pas être enterrés dans un champ secondaire. Ils doivent modifier les SLA, déclencher des contrôles compensatoires, orienter le SOC et rendre la communication plus claire. Dans une plateforme CVE complète, l’exploitation confirmée est le signal qui transforme une vulnérabilité connue en priorité opérationnelle.