Qu'est-ce qu'une CVE ? Définition, format des identifiants et bons réflexes

Une CVE (Common Vulnerabilities and Exposures) est un identifiant public et unique attribué à une faille de sécurité précise dans un logiciel ou un matériel donné. Une faille, un identifiant, reconnu par tous les éditeurs, scanners et équipes sécurité du monde. Quand quelqu’un dit « corrigez CVE-2021-44228 », tout le monde comprend la faille Log4Shell d’Apache Log4j, et pas un autre bug de journalisation.

Ce nom partagé est tout l’intérêt du système. Avant le lancement du programme CVE en 1999, chaque éditeur de sécurité décrivait la même faille à sa façon, et relier l’alerte de votre scanner au bulletin de votre fournisseur relevait de la devinette. La liste CVE a transformé ce désordre en langage commun.

Ce guide explique ce que l’identifiant vous apprend réellement, qui les attribue et, puisque plus de 40 000 nouvelles CVE arrivent désormais chaque année, comment une petite équipe décide lesquelles méritent son attention cette semaine.

Que signifie CVE ?

CVE signifie Common Vulnerabilities and Exposures (vulnérabilités et expositions communes). Le programme est géré par MITRE Corporation, financé par le département américain de la Sécurité intérieure via la CISA. Malgré ce financement américain, il fonctionne comme le standard mondial : des éditeurs de toutes les régions demandent et attribuent des identifiants CVE.

Deux termes de l’acronyme méritent d’être distingués :

• Une vulnérabilité est une faille de code ou de conception qu’un attaquant peut exploiter pour casser une propriété de sécurité : exécuter son propre code, lire des données interdites, élever ses privilèges.
• Une exposition est une condition plus faible : quelque chose qui donne un point d’appui ou des informations à un attaquant sans constituer une faille à proprement parler.

En pratique, presque tout ce qui figure sur la liste aujourd’hui est une vulnérabilité, et « une CVE » désigne couramment « une vulnérabilité cataloguée publiquement ».

Comment lire un identifiant CVE

Chaque identifiant suit le même schéma :

CVE-2021-44228
 |     |     |
 |     |     +-- numéro de séquence (4 chiffres ou plus)
 |     +-------- année d'attribution ou de réservation
 +-------------- préfixe littéral « CVE »

Deux détails piègent souvent :

• L’année correspond à l’attribution ou la réservation de l’identifiant, pas forcément à la découverte ni à la divulgation de la faille. Un bug découvert en décembre peut porter le millésime suivant, et une recherche publiée des années plus tard peut porter un millésime ancien.
• Le numéro de séquence ne dit rien de la gravité. CVE-2024-3400 n’est pas plus bénigne que CVE-2024-21887 parce que son numéro est plus petit. La gravité vit dans des systèmes de notation séparés, principalement CVSS.

Qui attribue les identifiants CVE ?

Pas un comité central. Le programme délègue l’attribution aux CNA (CVE Numbering Authorities) : éditeurs de logiciels, sociétés de sécurité, organismes de recherche et CERT nationaux autorisés à émettre des identifiants dans leur périmètre. Microsoft attribue les identifiants des bugs Windows, Red Hat ceux de ses distributions, et ainsi de suite. Il existe aujourd’hui plusieurs centaines de CNA répartis dans des dizaines de pays, MITRE jouant le rôle d’autorité racine et d’attributeur en dernier recours.

Conséquence pratique : n’importe qui peut signaler une vulnérabilité, mais l’identifiant vient généralement de l’éditeur du produit concerné. Si vous trouvez une faille dans un produit dont l’éditeur est un CNA, vous la lui signalez ; sinon, vous pouvez demander un identifiant directement à MITRE.

La vie d’une fiche CVE

Une CVE traverse un petit nombre d’états, et les connaître éclaire des situations déroutantes :

1. Réservée. L’identifiant existe mais les détails sont retenus, le plus souvent le temps que l’éditeur prépare un correctif en divulgation coordonnée. Tomber sur une fiche vide en cherchant une CVE réservée est normal, pas suspect.
2. Publiée. La description, les produits affectés et les références deviennent publics. À partir de ce moment, scanners et équipes sécurité peuvent agir.
3. Rejetée ou contestée. Certaines entrées s’avèrent être des doublons, des non-failles, ou sont contestées par l’éditeur. La fiche reste, marquée comme telle, et l’identifiant n’est jamais réutilisé.

Après publication, la NVD (National Vulnerability Database), gérée par le NIST, enrichit la fiche d’un score de gravité CVSS, d’identifiants de produits affectés et de liens. C’est pourquoi la plupart des équipes consultent les CVE via la NVD ou un outil construit dessus plutôt que la liste brute : cve.org vous dit que la faille existe, la NVD vous dit sa gravité estimée et les versions exactes concernées.

Toutes les vulnérabilités n’ont pas de CVE

L’inverse de la définition compte tout autant. Une CVE catalogue les failles des logiciels publiés et partagés. Des pans entiers du risque réel n’en reçoivent jamais :

• Les vulnérabilités de votre propre code, de vos applications internes et de vos API.
• Les erreurs de configuration : le bucket de stockage lisible par tous, le panneau d’administration sans MFA, l’identifiant par défaut jamais changé.
• Les failles de logique métier propres à vos processus.

Scanner les CVE répond à la question « quelles failles connues de logiciels tiers sont présentes chez moi ? ». Cela ne dit rien des catégories ci-dessus ; on les trouve par test d’intrusion et revue de configuration. Un scan CVE vierge n’est pas un certificat de bonne santé.

Combien de CVE existe-t-il, et pourquoi ce chiffre compte

Le rythme est le vrai problème opérationnel. Le programme a dépassé les 40 000 nouvelles CVE publiées sur une seule année en 2024, un record, et le volume continue de grimper depuis ; les totaux sont publics sur la page de métriques du programme CVE. Cela représente bien plus d’une centaine de nouvelles entrées par jour, week-ends compris.

Aucune équipe ne corrige à ce rythme, et aucune n’en a besoin. Trois chiffres remettent ce flot en perspective :

• Seule une petite minorité de CVE voit un jour du code d’exploitation circuler.
• Le catalogue KEV de la CISA, la liste des exploitations confirmées sur le terrain, compte environ 1 300 entrées contre plus de 200 000 CVE cataloguées au total : bien moins de 1 %.
• EPSS, le modèle de prédiction d’exploitation de FIRST, attribue à la plupart des CVE une probabilité d’exploitation quasi nulle sur les 30 prochains jours.

À retenir : l’existence d’une CVE est un fait sur le logiciel, pas une consigne d’action. La consigne vient du croisement des CVE avec ce que vous exécutez réellement, puis du classement par preuves d’exploitation. Nous détaillons cette logique de classement, CVSS contre EPSS contre KEV, dans notre guide de priorisation.

Ce qu’une petite équipe doit concrètement faire des CVE

Un processus CVE viable pour une équipe sans fonction sécurité dédiée tient en quatre étapes :

1. Savoir ce que vous exécutez. Un inventaire des actifs et des logiciels est le prérequis de tout le reste. Une CVE dans un logiciel que vous n’utilisez pas est du bruit.
2. Croiser en continu. De nouvelles CVE tombent chaque jour ; des scans trimestriels laissent des mois d’exposition. Le croisement continu des CVE publiées avec votre inventaire transforme le flot en une courte liste pertinente.
3. Classer par preuves, pas seulement par score. Les CVE du KEV d’abord, les EPSS élevés ensuite, le CVSS brut après. Cet ordre couvre les CVE que les attaquants utilisent vraiment avant celles qui font seulement peur.
4. Fixer des délais de correction par niveau. Par exemple : failles KEV sur les systèmes exposés à Internet sous 48 heures, EPSS élevé dans le sprint, le reste au cycle mensuel. Des délais tenables valent mieux que des ambitions intenables.

Questions rapides

Toutes les CVE sont-elles dangereuses ? Non. La gravité va de négligeable à critique, et même les CVE critiques ne sont, pour la plupart, jamais exploitées. L’identifiant est un nom, pas un verdict.

Peut-on consulter une CVE gratuitement ? Oui. La fiche de référence est sur cve.org, et la NVD ajoute la notation de gravité et les versions affectées, le tout gratuitement.

Qui peut demander un identifiant CVE ? Quiconque trouve une faille éligible dans un logiciel publié. Signalez-la à l’éditeur concerné s’il est CNA, ou à MITRE sinon.

Une CVE implique-t-elle qu’un correctif existe ? Non. Des CVE sont régulièrement publiées avant la sortie d’un correctif, et certaines n’en reçoivent jamais. Les références de la fiche pointent vers le bulletin de l’éditeur quand il existe.

Quelle différence entre CVE et CVSS ? CVE est le nom de la faille ; CVSS est un score de 0 à 10 estimant sa gravité en cas d’exploitation. L’un identifie, l’autre évalue.