CVE (Common Vulnerabilities and Exposures)
Une CVE est l'identifiant public unique d'une vulnérabilité logicielle connue, par exemple CVE-2021-44228 pour Log4Shell. Le référentiel est piloté par le MITRE.
Le programme Common Vulnerabilities and Exposures, piloté par le MITRE, attribue un identifiant unique à chaque vulnérabilité logicielle rendue publique. Le format est stable depuis des années : CVE, l'année de publication, puis un numéro de séquence, comme CVE-2021-44228 pour Log4Shell. Cet identifiant sert de langue commune à tout l'écosystème : éditeurs, scanners, bulletins d'alerte et pentesters parlent de la même faille sans ambiguïté.
La fiche CVE elle-même reste succincte ; ce sont les bases comme la NVD américaine qui l'enrichissent d'un score CVSS, de la liste des versions affectées et des références aux correctifs. Le volume, lui, ne cesse de croître : plus de 40 000 CVE ont été publiées sur la seule année 2024. Autant dire que "tout patcher" n'est pas un plan, et c'est pourquoi des signaux de priorisation comme l'EPSS et le catalogue KEV sont devenus indispensables.
Encore faut-il savoir quels actifs exposés portent ces CVE. C'est le travail de la surveillance continue de la surface d'attaque : rapprocher chaque service exposé des vulnérabilités qui le concernent, sans attendre le prochain audit.
Qui attribue les identifiants, et ce que ça change
Le MITRE ne remplit pas seul le référentiel. Il délègue l'attribution à un réseau de CNA, les CVE Numbering Authorities : éditeurs comme Microsoft, Red Hat ou Oracle, coordinateurs nationaux, plateformes de bug bounty. Concrètement, c'est souvent l'éditeur du logiciel concerné qui rédige la fiche et fixe le périmètre des versions affectées. Deux conséquences pratiques. Une même faille reçoit des descriptions très inégales selon la CNA qui la traite, ce qui complique les rapprochements automatiques. Et un identifiant peut exister à l'état réservé, sans qu'aucun détail ne soit public, pendant toute la durée d'une divulgation coordonnée.
L'erreur classique : compter les CVE d'un produit
Le nombre de CVE ne mesure pas la qualité d'un logiciel. Un produit très audité et transparent en publie beaucoup ; un produit propriétaire que personne ne regarde en publie peu, ce qui ne dit rien de son état réel. Comparer deux solutions au décompte de CVE revient donc à récompenser l'opacité. Les signaux utiles sont ailleurs : le délai entre signalement et correctif, l'existence d'une politique de divulgation, la présence au catalogue KEV, et surtout la part de vos propres actifs concernés. Notre guide de la gestion des vulnérabilités pose la chaîne de priorisation complète.
Questions fréquentes
Qui peut demander une CVE ?
N'importe quel chercheur, via la CNA compétente pour le produit concerné ou, à défaut, via le programme du MITRE. L'attribution ne dépend pas de l'accord de l'éditeur, ce qui protège les divulgations coordonnées quand celui-ci ne répond pas.
Toutes les vulnérabilités ont-elles une CVE ?
Non, loin de là. Les failles propres à une application interne, celles corrigées silencieusement dans une mise à jour, ou celles jugées hors périmètre par l'éditeur n'en reçoivent pas. Un pentest remonte surtout des vulnérabilités sans identifiant public.
Que signifie une CVE au statut réservé ?
Que l'identifiant a été attribué pour une faille en cours de traitement, mais que les détails ne sont pas encore publiés. C'est le cas normal pendant la divulgation coordonnée, entre le signalement au fournisseur et la sortie du correctif.