Qu'est-ce qu'une CVE ?

Deux images pour fixer l'idée

Une CVE est d'abord une plaque d'immatriculation. Elle désigne un véhicule précis et un seul. Elle ne dit ni à quelle vitesse il roule, ni s'il est en train de rouler, ni s'il vous a déjà croisé. Deux témoins qui citent la même plaque parlent forcément du même véhicule : c'est tout ce qu'elle garantit, et c'est déjà énorme.

Une CVE est ensuite un numéro de dossier aux urgences. On vous l'attribue à l'entrée, avant tout diagnostic : le numéro existe alors que le dossier est encore vide. C'est exactement l'état « réservée » d'une CVE, et c'est pourquoi une CVE peut apparaître dans un outil avec presque aucune information — puis se remplir les jours suivants.

Retenez la question à laquelle une CVE répond : « de quelle faille parle-t-on ? » — pas « est-elle grave ? », pas « suis-je attaqué ? ».

Anatomie d'un identifiant : CVE-AAAA-NNNN

Un identifiant CVE suit toujours la même structure :

Deux subtilités que presque tout le monde rate :

• L'année est celle de la réservation de l'identifiant, pas de la publication. Une CVE réservée en décembre 2025 et divulguée en mars 2026 garde son millésime 2025. Trier un flux par millésime n'a donc aucun rapport avec trier par fraîcheur.
• Le numéro séquentiel compte au moins quatre chiffres et peut s'allonger. On est passé de CVE-2014-0160 à des identifiants à six chiffres pour absorber le volume : un tri alphabétique casse là où un tri numérique tient.

Qui attribue les CVE : le rôle des CNA

Aucune autorité centrale n'attribue les identifiants. Ce sont des organisations habilitées, les CNA (CVE Numbering Authorities, littéralement « autorités de numérotation CVE »), qui les réservent et les publient pour leur périmètre. Le programme en compte plus de 400 dans le monde ; la liste officielle, seule à jour, est publiée par cve.org.

• Les éditeurs (Microsoft, Apple, Google, Red Hat, Cisco…) sont leur propre CNA et publient les CVE de leurs produits.
• Des coordinateurs — CERT/CC, CERT nationaux — couvrent les logiciels sans éditeur-CNA, en particulier l'open source.
• Le MITRE est CNA racine et secrétariat du programme ; la CISA, agence américaine de cybersécurité, le finance.

Ce modèle décentralisé donne de la couverture et de la vitesse : celui qui connaît le mieux la faille la documente. Il a un coût, et c'est le sujet du paragraphe suivant.

Ce que contient une fiche CVE, et ce qui manque souvent

Une CVE publiée fournit au minimum :

• une description de la vulnérabilité ;
• les produits et versions affectés, idéalement sous forme d'identifiant normalisé CPE (Common Platform Enumeration, la nomenclature qui décrit un logiciel de façon lisible par une machine) ;
• la faiblesse sous-jacente, classée selon le référentiel CWE ;
• un score de gravité CVSS, pas toujours présent à la publication ;
• des références : avis de sécurité, correctifs, preuves de concept.

La complétude de ces champs dépend entièrement de la CNA qui publie. Depuis février 2024, l'enrichissement assuré par le NVD (scores et CPE ajoutés après coup) a fortement ralenti, laissant un grand nombre de fiches sans version affectée exploitable. Une CVE sans CPE ni plage de versions ne peut être rapprochée d'aucun inventaire, par aucun outil : elle est invisible pour la corrélation automatique. C'est la raison pratique pour laquelle recouper plusieurs sources de données est devenu indispensable, et pourquoi la qualité d'une CNA se mesure.

Le cycle de vie d'une CVE

Une CVE n'est pas figée. Son état change, et ces changements sont souvent plus importants que sa publication initiale.

À ces états s'ajoutent deux transitions qui changent tout pour la priorisation : l'inscription au catalogue CISA KEV, qui signifie que l'exploitation est observée, et l'apparition d'une preuve de concept (PoC, proof of concept : du code publié qui démontre l'attaque), qui met l'exploitation à la portée de n'importe qui. Une veille qui ne surveille que les publications rate les deux.

CVE, CVSS, EPSS, KEV : ne pas confondre

C'est la confusion la plus fréquente, et elle coûte cher en temps. Une CVE identifie ; les trois autres qualifient la même faille sous des angles différents.

Une même faille vue par les quatre référentiels

Prenons Log4Shell et suivons-la d'un référentiel à l'autre. C'est l'exercice qui fait comprendre la différence mieux que n'importe quelle définition.

Lisez la dernière ligne : entre la publication et la confirmation d'exploitation, il s'est écoulé quelques heures. Sur une faille de ce profil, la fenêtre entre « on apprend » et « on est attaqué » ne se compte pas en semaines. C'est ce que le score CVSS, à lui seul, ne vous aurait jamais dit.

Trois CVE qui ont marqué l'histoire

Heartbleed — CVE-2014-0160 (avril 2014)

Une faille d'OpenSSL qui laissait lire la mémoire d'un serveur : clés privées, mots de passe, contenus de session. Détail instructif : son score CVSS 3.1 est de 7.5, « élevé », pas « critique » — parce qu'elle ne permet que de lire, sans modifier ni interrompre. Elle a pourtant provoqué le renouvellement d'une part massive des certificats du web. La démonstration que le score ne mesure pas la portée.

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

Une exécution de code à distance dans Log4j, la bibliothèque de journalisation présente dans une immense partie du logiciel Java d'entreprise. Notée 10 sur 10, exploitée en masse dans les heures suivant la divulgation. Sa leçon durable : la plupart des organisations touchées ne savaient pas qu'elles utilisaient Log4j, parce qu'il arrivait comme dépendance d'une dépendance.

Porte dérobée XZ Utils — CVE-2024-3094 (mars 2024)

Une porte dérobée introduite volontairement dans un outil de compression Linux, au terme de deux ans de patience d'un contributeur devenu mainteneur. Repérée par hasard par un développeur qui trouvait une connexion SSH anormalement lente, quelques semaines avant l'arrivée du paquet dans les distributions stables. Notée 10 sur 10. Elle a déplacé la question de « mon code est-il sûr ? » à « à qui fait confiance mon code ? ».

Pourquoi le volume de CVE explose

Les chiffres, sur les dernières années pleines : plus de 40 000 CVE publiées en 2024, environ 28 800 en 2023, 25 000 en 2022. La courbe n'a pas fléchi une seule année depuis 2016. Plus de logiciels, plus de chercheurs, plus de CNA habilitées : les trois facteurs poussent dans le même sens.

Traduisons en temps de travail. Quarante mille CVE réparties sur environ 250 jours ouvrés, cela fait 160 fiches par jour. À quarante-cinq secondes pour lire une fiche et décider si elle vous concerne, il faut deux heures par jour ouvré — pour un taux de pertinence qui, sur un parc de PME, tombe largement sous le pour cent. Aucune équipe ne tient ce rythme, et aucune ne le devrait.

Le compteur officiel du programme, mis à jour en continu, est publié sur cve.org/about/Metrics. Nous préférons vous y renvoyer plutôt que de figer ici un chiffre qui aura vieilli dans six mois.

Et concrètement, pour vous

Voici ce que fait, lundi matin, une équipe qui a arrêté de subir le flux.

1. Écrire l'inventaire. Éditeur, produit, version majeure, pour tout ce qui est exposé ou porte des données. Vingt à quarante lignes suffisent dans une PME. Sans cette liste, aucun filtrage n'est possible : c'est le seul travail réellement incompressible.
2. Filtrer sur cette liste. Tout ce qui ne touche aucune ligne de l'inventaire sort du champ. C'est là que 99 % du bruit disparaît.
3. Trier ce qui reste, dans cet ordre. Présent au KEV → traitement sous 48 heures. Sinon EPSS supérieur à 0,1 → cette semaine. Sinon le CVSS départage, et seulement là.
4. Surveiller les transitions. Une CVE classée « basse » le mardi peut entrer au KEV le jeudi. Ce qui doit déclencher une alerte, ce n'est pas seulement la publication, c'est le changement d'état.

Questions fréquentes