Gestion des vulnérabilités Référentiels CVE · CVSS · EPSS · KEV Mis à jour · Avril 2026

CVE, CVSS, EPSS

Signification : Common Vulnerabilities and Exposures · Common Vulnerability Scoring System · Exploit Prediction Scoring System
Réponse rapide

Trois référentiels complémentaires pour gérer les vulnérabilités : CVE identifie la vulnérabilité avec un code unique, CVSS note sa gravité technique sur 10, EPSS estime la probabilité qu’elle soit exploitée dans les 30 jours à venir.

En une phrase — CVE identifie chaque vulnérabilité par un code unique, CVSS note sa gravité technique sur 10, EPSS estime la probabilité qu'elle soit exploitée dans les 30 prochains jours. Trois référentiels complémentaires pour prioriser les correctifs.
CVE
Identifiant unique — géré par MITRE depuis 1999
CVSS
Score de gravité 0-10 — maintenu par FIRST, v4.0 depuis 2023
EPSS
Probabilité d'exploitation 0-1 — FIRST, depuis 2019
KEV
Catalogue des CVE exploitées — CISA, depuis 2021
Volume 2024
~29 000 nouvelles CVE — plus de 200 000 au total

01 — Vue d'ensembleTrois référentiels complémentaires

Ces trois acronymes dominent le vocabulaire de la gestion des vulnérabilités et sont souvent confondus, alors qu'ils répondent à trois questions distinctes :

  • CVE : quelle est cette vulnérabilité ? Identifiant universel unique, comme un numéro de plaque d'immatriculation.
  • CVSS : quelle est sa gravité technique ? Score de 0 à 10 évaluant l'impact potentiel si exploitée.
  • EPSS : va-t-elle être exploitée ? Probabilité statistique d'exploitation dans les 30 prochains jours.

Ajoutons une ressource critique et complémentaire :

  • KEV : est-elle déjà exploitée ? Catalogue CISA des vulnérabilités confirmées exploitées dans la nature.

Exemple de Log4Shell (décembre 2021) :

  • CVE-2021-44228 : l'identifiant.
  • CVSS 10.0 : gravité maximale (critique).
  • EPSS ≈ 0.97 : 97% de probabilité d'exploitation.
  • Présente au KEV : oui, dès décembre 2021.

Les quatre signaux étaient concordants — remédiation immédiate obligatoire. Mais pour 95% des CVE, ces signaux divergent, et c'est précisément leur croisement qui permet une priorisation intelligente.

29 000 CVE publiées en 2024. Personne ne peut tout patcher immédiatement. L'art de la priorisation consiste à trouver les 2 à 5% qui représentent 95% du risque réel. CVSS seul ne le permet pas — il faut CVE + CVSS + EPSS + KEV + contexte métier.

02 — CVEL'identifiant universel des vulnérabilités

Principe

CVE (Common Vulnerabilities and Exposures) est le système d'identification universel des vulnérabilités logicielles depuis 1999. Chaque CVE reçoit un identifiant unique sous la forme CVE-AAAA-NNNNN : année de publication puis numéro séquentiel.

Exemples historiques marquants

  • CVE-2014-0160 — Heartbleed (OpenSSL).
  • CVE-2017-0144 — EternalBlue (SMB Windows, utilisée par WannaCry).
  • CVE-2017-5638 — Apache Struts (utilisée dans la brèche Equifax).
  • CVE-2019-19781 — Citrix ADC/Gateway.
  • CVE-2020-0601 — CurveBall (Windows CryptoAPI).
  • CVE-2021-44228 — Log4Shell (Log4j).
  • CVE-2022-30190 — Follina (Microsoft Support Diagnostic Tool).
  • CVE-2023-34362 — MOVEit Transfer (campagne ransomware Cl0p).
  • CVE-2024-3400 — Palo Alto Networks PAN-OS GlobalProtect.
  • CVE-2024-24919 — Check Point Security Gateways.

Gouvernance

Le programme CVE est coordonné par MITRE Corporation (organisation américaine à but non lucratif), financé par CISA. La gouvernance s'est étendue avec un réseau de CNA (CVE Numbering Authorities) — éditeurs, chercheurs et plateformes habilités à attribuer eux-mêmes des identifiants CVE. En 2026, plus de 400 CNA sont actifs dans le monde, dont :

  • Grands éditeurs : Microsoft, Apple, Google, Oracle, Adobe, Red Hat, IBM, Cisco.
  • Plateformes de bug bounty : HackerOne, Bugcrowd.
  • Chercheurs indépendants : Project Zero (Google), Trend Micro Zero Day Initiative.
  • Autorités nationales : CERT-EU, JPCERT, plusieurs CERT nationaux.

Base de données associée — NVD

Le NVD (National Vulnerability Database) du NIST américain est la base de référence qui enrichit les CVE avec : description détaillée, références bibliographiques, produits affectés (via CPE), score CVSS, CWE (classification de type de faille). Important : le NVD a connu des difficultés sérieuses de traitement en 2024 avec un retard significatif d'enrichissement. La communauté a accéléré le développement d'alternatives : OSV (Google Open Source Vulnerabilities), GitHub Advisory Database, OSS Index (Sonatype). CVE.org a lancé son propre enrichissement.

Volume

  • 2018 : ~16 500 CVE.
  • 2021 : ~20 000 CVE.
  • 2023 : ~28 900 CVE.
  • 2024 : ~29 000+ CVE (rythme record).
  • Total historique 2026 : plus de 240 000 CVE enregistrées.

Cette inflation reflète : plus d'acteurs impliqués dans la recherche, plus de logiciels à auditer, des outils de détection automatisée plus efficaces, l'explosion de l'open source.

03 — CVSSLa gravité technique sur 10

Principe

CVSS (Common Vulnerability Scoring System) est un système de notation de la gravité d'une vulnérabilité, de 0 à 10. Maintenu par le FIRST (Forum of Incident Response and Security Teams), il est la référence de notation depuis 2005. Version actuelle : CVSS 4.0 publiée en 2023, adoption progressive en 2024-2026 en parallèle de CVSS 3.1 encore largement utilisé.

Échelle qualitative

  • 0.0 : None.
  • 0.1 – 3.9 : Low (faible).
  • 4.0 – 6.9 : Medium (moyenne).
  • 7.0 – 8.9 : High (élevée).
  • 9.0 – 10.0 : Critical (critique).

Composition du score

CVSS combine plusieurs métriques organisées en groupes :

Base Metrics (score de base — obligatoire)

  • Attack Vector : réseau, adjacent, local, physique.
  • Attack Complexity : faible ou élevée.
  • Privileges Required : aucun, faible, élevé.
  • User Interaction : requise ou non.
  • Scope : inchangé ou modifié.
  • Confidentiality Impact : aucun, faible, élevé.
  • Integrity Impact : aucun, faible, élevé.
  • Availability Impact : aucun, faible, élevé.

Threat Metrics (ex-Temporal)

  • Exploit Code Maturity : non prouvé, PoC, fonctionnel, actif.
  • Évolue dans le temps selon l'apparition d'exploits publics.

Environmental Metrics (contexte)

Permettent d'ajuster selon votre environnement — criticité des données, contrôles de sécurité en place, configuration spécifique. Rarement utilisés en pratique car demande d'effort de paramétrage.

Supplemental Metrics (nouveautés CVSS 4.0)

CVSS 4.0 introduit des métriques supplémentaires : Safety, Automatable, Recovery, Value Density, Vulnerability Response Effort, Provider Urgency. Elles apportent du contexte sans modifier le score principal.

Exemples concrets

  • Log4Shell (CVE-2021-44228) : CVSS 10.0 — réseau, complexité faible, pas d'auth, pas d'interaction, scope modifié, impact total C/I/A.
  • Heartbleed (CVE-2014-0160) : CVSS 7.5 — impact limité à la confidentialité (lecture mémoire).
  • EternalBlue (CVE-2017-0144) : CVSS 8.1.
  • MOVEit (CVE-2023-34362) : CVSS 9.8.
  • Meltdown (CVE-2017-5754) : CVSS 5.6 — local nécessaire, impact confidentialité.

Limites de CVSS

  • Théorique : mesure la gravité potentielle, pas la probabilité réelle d'exploitation.
  • Scoring subjectif : différents analystes peuvent attribuer des scores différents sur la même CVE.
  • Inflation des scores : depuis CVSS 3.0, une large proportion des vulnérabilités est scorée ≥ 7.
  • Pas d'indication temporelle : la maturité d'exploitation (Threat Metrics) est rarement mise à jour.
  • Résultat : CVSS seul sature et ne permet plus de prioriser efficacement — d'où l'émergence d'EPSS.

04 — EPSSLa probabilité d'exploitation

Principe

EPSS (Exploit Prediction Scoring System) est un système développé par le FIRST depuis 2019 qui estime la probabilité qu'une CVE donnée soit exploitée dans la nature dans les 30 prochains jours. Le score est un nombre entre 0 et 1 (ou exprimé en pourcentage). Exemples :

  • EPSS 0.02 → 2% de probabilité d'exploitation dans les 30 jours.
  • EPSS 0.95 → 95% de probabilité d'exploitation (quasi-certitude).

Méthodologie

EPSS utilise un modèle d'apprentissage automatique entraîné sur des données réelles d'exploitation observées dans de multiples sources :

  • Télémétrie d'intrusion de partenaires (Shadowserver, Greynoise, Fortinet, AlienVault, Cisco Talos).
  • Détections d'IDS/IPS déployés mondialement.
  • Catalogues d'exploits publics (Exploit-DB, Metasploit, GitHub).
  • KEV Catalog de CISA.
  • Rapports de threat intelligence.

Pour chaque CVE, le modèle analyse des centaines de caractéristiques (score CVSS, type de CWE, produits affectés, disponibilité publique d'exploit, mentions sur des forums underground, discussions Twitter/X, etc.) et produit une probabilité. Le score est recalculé quotidiennement pour toutes les CVE connues.

Distribution typique

Statistiques observées :

  • ~95% des CVE ont un EPSS < 0.05 (5%).
  • ~3% ont un EPSS entre 0.05 et 0.5.
  • ~2% ont un EPSS > 0.5.
  • <1% ont un EPSS > 0.9.

Cette distribution reflète une réalité opérationnelle : la grande majorité des CVE ne sont jamais réellement exploitées. Selon les études Cyentia, environ 5% des CVE sont exploitées dans la nature — EPSS quantifie et priorise ces 5%.

Performance du modèle

EPSS est évalué régulièrement par le FIRST. Exemple de performance (v3, 2023) : pour prédire les CVE qui seront exploitées, EPSS permet de détecter ~75% des exploitations en examinant seulement les 5% des CVE avec les scores EPSS les plus élevés. Un gain massif d'efficacité par rapport à CVSS seul (CVSS ≥ 7 couvre la majorité des CVE mais ne priorise pas dans cette masse).

Accès aux données EPSS

Les données EPSS sont publiques et gratuites :

  • Site officiel : first.org/epss.
  • API REST publique pour requêter les scores.
  • Fichier CSV quotidien téléchargeable.
  • Intégration dans la plupart des outils modernes de gestion de vulnérabilités.

Limitations d'EPSS

  • Fenêtre de prédiction limitée à 30 jours — certaines CVE dormantes peuvent être exploitées plus tard.
  • Probabilité globale, pas spécifique à un contexte organisationnel.
  • Biais possibles dans les données d'entraînement (plus de visibilité sur les exploitations massives que ciblées).
  • Ne capture pas le risque d'exploitation par APT sophistiqués qui opèrent sans laisser de traces publiques.

EPSS ne remplace pas CVSS — il le complète. CVSS dit « c'est grave si exploité », EPSS dit « c'est probable que ce soit exploité ». Les deux ensemble permettent d'aller au-delà de la matrice basique.

05 — KEVLe catalogue des vulnérabilités exploitées

Principe

Le KEV Catalog (Known Exploited Vulnerabilities Catalog) est maintenu par la CISA (Cybersecurity and Infrastructure Security Agency, USA) depuis novembre 2021. Il liste les CVE confirmées comme exploitées dans la nature. Mise à jour quotidienne.

Critères d'inclusion

Pour qu'une CVE entre au KEV, elle doit satisfaire trois critères :

  1. Identifiant CVE attribué.
  2. Preuve d'exploitation dans la nature (rapports incident, analyses forensic, signalements).
  3. Action de remédiation claire (patch, workaround, mitigation documentée).

Volume

En 2026, le KEV contient environ 1 200 CVE — soit moins de 0,5% des CVE totales. Cette sélectivité en fait un outil de priorisation très efficace : si une CVE est au KEV, elle est exploitée quelque part dans le monde.

BOD 22-01

Aux USA, la directive opérationnelle contraignante BOD 22-01 oblige les agences fédérales civiles à remédier les CVE du KEV dans des délais stricts (souvent 14 jours après ajout au catalogue). Cette exigence accélère considérablement le cycle de remédiation dans le secteur public américain.

Usage mondial

Même hors USA, le KEV est devenu une référence mondiale de priorisation :

  • Intégré dans la plupart des scanners de vulnérabilités commerciaux (Tenable, Qualys, Rapid7).
  • Cité dans les recommandations CERT-FR et ANSSI.
  • Utilisé comme SLA dans les contrats des MSSP.
  • Base de référence pour les programmes de bug bounty.

Limites du KEV

  • Centré sur les exploitations visibles — les campagnes APT discrètes peuvent ne pas y figurer.
  • Biais géographique : priorise les CVE observées dans le périmètre américain.
  • Réactif, pas prédictif : une CVE n'y entre qu'après exploitation confirmée, ce qui peut être tardif.
  • Complémentaire d'EPSS qui, lui, est prédictif.

06 — PrioriserUtiliser ces référentiels en production

Matrice de priorisation simplifiée
  • Priorité P0 — urgence (patch < 24-48h) : CVE au KEV, CVSS ≥ 9, sur système exposé et critique.
  • Priorité P1 — rapide (< 7 jours) : CVSS ≥ 7 ET (EPSS ≥ 0.5 OU au KEV).
  • Priorité P2 — cycle normal (< 30 jours) : CVSS ≥ 7 sans signal de criticité immédiate.
  • Priorité P3 — planifié (< 90 jours) : CVSS 4-7 sur systèmes internes non exposés.
  • Priorité P4 — accepté ou reporté : CVSS < 4, composant non utilisé, mitigation en place.
Au-delà du score — les facteurs contextuels
  • Exposition du système : Internet-facing ? VPN ? DMZ ? Réseau interne isolé ?
  • Criticité métier : données sensibles, processus critique, fonction régulée.
  • Authentification requise : vulnérabilité pre-auth ou post-auth ?
  • Mitigations en place : WAF, EDR, segmentation qui réduisent l'exploitabilité réelle.
  • Disponibilité du patch : existe-t-il ? Impact sur la production ?
  • Complexité opérationnelle : fenêtre de maintenance, dépendances applicatives.
Outils qui intègrent ces référentiels
  • Scanners de vulnérabilités : Tenable Nessus/Security Center, Qualys VMDR, Rapid7 InsightVM, Microsoft Defender Vulnerability Management.
  • DevSecOps : Snyk, Sonatype, Mend, Checkmarx, GitHub Advanced Security.
  • Plateformes VM modernes : Vulcan Cyber, Kenna (Cisco), Brinqa. Intègrent nativement EPSS + KEV + contexte.
  • Open source : Dependency-Track, Trivy, OpenVAS, Vuls.
  • Services français : Vade, Stormshield, YesWeHack, BZHunt pour bug bounty, Sekoia.io pour CTI.
Intégration avec SBOM
  • SBOM fournit la liste des composants utilisés.
  • Croisement avec les bases CVE → vulnérabilités théoriques.
  • Enrichissement EPSS + KEV → vulnérabilités prioritaires.
  • VEX (émis par l'éditeur) → déclaration d'exploitabilité réelle.
  • Workflow complet : SBOM + CVE + CVSS + EPSS + KEV + VEX = priorisation intelligente.
Processus recommandé
  • Détection automatique : scans quotidiens ou continus.
  • Enrichissement automatique : EPSS + KEV + contexte métier.
  • Priorisation : tri selon matrice P0-P4.
  • SLA documentés : délais de remédiation par priorité.
  • Reporting : dashboard sécurité avec tendances, âge des CVE ouvertes, taux de remédiation.
  • Gouvernance : comité de gestion des vulnérabilités mensuel, arbitrage des acceptations de risque.
  • Alertes critiques : procédure d'urgence pour les CVE ajoutées au KEV pendant la nuit.

07 — CasApplication sur des cas emblématiques

Log4Shell (CVE-2021-44228) — décembre 2021

Exécution de code à distance non authentifiée dans Log4j, bibliothèque Java utilisée partout.

  • CVSS 10.0 — critique.
  • EPSS 0.97+ — exploitation quasi certaine.
  • Ajoutée au KEV le jour même de sa divulgation.
  • Exploitation massive à l'échelle mondiale en quelques heures.
  • Remédiation : patch Log4j 2.17.0+, mise à jour urgente imposée par tous les grands éditeurs.

MOVEit Transfer (CVE-2023-34362) — juin 2023

Injection SQL dans la solution MOVEit Transfer (Progress Software), exploitée massivement par Cl0p ransomware.

  • CVSS 9.8 — critique.
  • EPSS monté à 0.94 dans les jours suivants.
  • Ajoutée au KEV très rapidement.
  • Plus de 2 700 organisations touchées, ~90 millions de personnes impactées.
  • Victimes notables : British Airways, BBC, Shell, TJX, universités.

Follina (CVE-2022-30190) — mai 2022

Exécution de code via Microsoft Support Diagnostic Tool déclenchée par un document Office malveillant.

  • CVSS 7.8 — élevée.
  • EPSS 0.94 rapidement.
  • Ajoutée au KEV.
  • Exploitée en masse, patch initial difficile (contournement temporaire par Registry).
  • Cas où CVSS 7.8 ne reflète pas l'urgence réelle — EPSS et KEV l'ont capturée immédiatement.

Ivanti Connect Secure (CVE-2023-46805, CVE-2024-21887) — janvier 2024

Chaîne d'exploit sur les VPN Ivanti Connect Secure (ex-Pulse Secure), exploitée par des acteurs APT chinois dès décembre 2023.

  • CVSS 8.2 et 9.1.
  • EPSS montée rapidement à 0.95+.
  • Entrée au KEV rapide.
  • Exploitation ciblée et massive, compromission de centaines d'organisations.
  • Patch initial incomplet, bypass découvert en quelques jours.

XZ Utils backdoor (CVE-2024-3094) — mars 2024

Backdoor sophistiqué injecté dans la bibliothèque XZ par un contributeur patient sur 2 ans.

  • CVSS 10.0.
  • EPSS initialement bas car pas d'exploitation observée en masse (détecté à temps).
  • Au KEV par précaution.
  • Cas remarquable : détection in extremis avant déploiement en production — Debian/Fedora/Ubuntu stable non affectés.
  • Souligne la fragilité de l'open source maintenu par peu de personnes.

CVE avec CVSS élevé mais rarement exploitées

De nombreuses CVE ont un CVSS ≥ 8 mais un EPSS très bas (< 0.01) — signifiant qu'aucune exploitation réelle n'est observée. Exemples fréquents : vulnérabilités dans des produits de niche, nécessitant des conditions très spécifiques, ou pour lesquelles aucun exploit public n'existe. Les organisations matures accordent la priorité selon EPSS plutôt que CVSS seul pour ces cas.

08 — FAQQuestions fréquentes

Que faire si le NVD est en retard d'enrichissement ?

Situation réelle en 2024-2025 avec le retard du NVD. Alternatives recommandées : OSV (Google, gratuit, couvre largement l'open source), GitHub Advisory Database, OSS Index (Sonatype), bases spécialisées (VulnDB, DeepSurface). Beaucoup de scanners commerciaux ont développé leurs propres bases enrichies. Croiser plusieurs sources est devenu la norme. CVE.org lance son propre enrichissement en alternative.

EPSS remplace-t-il CVSS ?

Non, ils sont complémentaires. CVSS mesure la gravité technique si exploitée (nécessaire pour évaluer l'impact). EPSS mesure la probabilité d'exploitation (nécessaire pour prioriser). Utiliser l'un sans l'autre donne une vision incomplète. La pratique moderne : matrice combinant les deux, enrichie par KEV et contexte métier.

Une CVE sans patch disponible, que faire ?

Plusieurs stratégies selon la criticité : mitigations temporaires (WAF, règles firewall, désactivation de la fonctionnalité vulnérable), supervision renforcée (détection EDR, règles SIEM dédiées), isolation du système affecté, acceptation temporaire du risque avec documentation formelle. Pour les CVE critiques sans patch, certains éditeurs fournissent des outils de détection (Microsoft Defender signatures spécifiques, CISA notifications). Ne jamais laisser un système exposé avec une CVE au KEV sans contre-mesure.

Comment gérer les fausses alertes de scanners ?

Les scanners produisent fréquemment des faux positifs — détection d'un composant qui n'est pas réellement utilisé, ou version incorrecte. Bonnes pratiques : activer les vérifications authentifiées (agent ou credentials), utiliser VEX pour documenter les faux positifs systématiques, croiser avec SBOM précis, ajuster les règles du scanner. Certains outils modernes (Snyk, Dependency-Track) intègrent le VEX nativement pour supprimer les alertes non pertinentes.

Faut-il s'abonner à un flux de threat intelligence pour les CVE ?

Pour les grandes organisations et les secteurs régulés : oui, plusieurs sources. Pour les PME : les sources gratuites suffisent généralement. Gratuites : CERT-FR (bulletins d'alerte), CISA KEV, NVD, GitHub Advisory Database. Commerciales : Recorded Future, Mandiant Intelligence, CrowdStrike Intelligence, Sekoia.io, Flashpoint. Le niveau d'investissement doit être proportionné à la surface d'attaque et à la criticité métier.