Qu'est-ce qu'un CVE ?

Un identifiant CVE (Common Vulnerability and Exposure) désigne une faille de sécurité connue et répertoriée. Lorsqu’une vulnérabilité se voit attribuer un identifiant CVE, cela signifie que la communauté de la sécurité l’a identifiée, nommée et ajoutée à une base de données publique (principalement et cve.org , avec une notation et un contexte fournis par la base de données nationale sur les vulnérabilités (NVD) du NIST) afin que tout le monde puisse la consulter et prendre les mesures qui s’imposent. Le suivi des CVE offre au monde de la sécurité un point de référence commun, permettant ainsi aux équipes de hiérarchiser les priorités et de réagir aux failles connues avant que les attaquants ne les exploitent. Simple en théorie, n'est-ce pas ?

Mais voici le hic : plus de 48 000 CVE ont été publiés rien qu'en 2025. Cela représente 131 nouvelles vulnérabilités chaque jour. Les modèles d'IA et les capacités d'analyse permettent de détecter les vulnérabilités plus rapidement et plus facilement que jamais, mais la validation de ces résultats à grande échelle s'avère plus difficile, car le volume considérable de signalements dépasse les capacités de l'infrastructure mise en place pour les traiter. Le NVD croule sous le volume, et un nombre croissant de vulnérabilités réelles ne sont jamais signalées. 

Ce guide explique le fonctionnement des CVE, leur système de notation, les failles du système et les mesures prises par les équipes pour garder une longueur d'avance.

Que contient un enregistrement CVE ?

Un identifiant CVE est comparable à un numéro de série, dont le format est le suivant : « CVE-AAAA-##### ».

Chaque enregistrement contient :

• Identifiant CVE
• Description
• Références
• Attribution de CNA
• Date de création de l'enregistrement

Les anciennes entrées CVE peuvent également comporter des champs hérités, tels que « phase », « votes », « commentaires » et « proposé », qui ne sont plus utilisés dans les nouvelles entrées.

Qui maintient la base de données CVE ?

En bref, la réponse est : aucune organisation ne le fait à elle seule. Et c'est là que réside de plus en plus le problème.

La société MITRE supervise le programme CVE lui-même, attribuant des identifiants et tenant à jour la liste officielle ; tous les enregistrements CVE peuvent être consultés et utilisés librement. Le NVD a toujours été l'endroit où ces entrées CVE brutes sont enrichies de scores CVSS, de détails sur les correctifs et de contexte technique. C'est également là que la plupart des outils de sécurité puisent leurs données. L'Agence pour la cybersécurité et la sécurité des infrastructures (CISA) apporte un soutien financier. D'autres bases de données, comme la base de données CERT/CC Vulnerability Notes et GitHub Advisory, comblent des lacunes supplémentaires.

Mais aucune de ces bases n'a jamais été vraiment complète, et en 2026, les lacunes sont difficiles à ignorer. Le NIST a adopté une approche « fondée sur les risques » qui donne la priorité aux CVE concernant les logiciels du gouvernement américain et à celles figurant dans le catalogue des vulnérabilités connues exploitées (KEV), laissant le reste sans enrichissement, le retard accumulé étant de fait transféré vers la catégorie « non planifié ». Le programme CVE de MITRE a été confronté à des problèmes de financement. L'UE a lancé sa propre alternative, la base de données européenne sur les vulnérabilités (EUVD), mais celle-ci en est encore à ses débuts et dépend fortement de la synchronisation avec la NVD. Il n'existe plus de source unique de vérité, et le fait de dépendre d'une seule base de données signifie que vous disposez d'une couverture et d'une visibilité moindres que ce que vous espériez. C'est exactement le problème Aikido était censé résoudre : surveiller des millions de paquets open source à la recherche de correctifs liés à la sécurité qui ne sont jamais intégrés dans aucune base de données officielle, et transmettre les résultats directement à la Aikido afin que les utilisateurs soient automatiquement alertés.

Comment les CVE sont-ils identifiés et attribués ?

Tout le monde peut signaler une faille de sécurité : les entreprises de sécurité, les chercheurs indépendants, les développeurs individuels, voire les utilisateurs simplement curieux. De nombreuses organisations mettent en place des programmes de prime aux bogues qui rémunèrent les chercheurs pour leurs découvertes valides, et les projets open source s'appuient généralement sur les signalements de la communauté.

Une fois qu'une vulnérabilité est signalée, une autorité de numérotation CVE (CNA) la valide, lui attribue un identifiant CVE, rédige une brève description et ajoute des références avant de la publier dans la liste officielle CVE. Les CNA sont des organisations autorisées par MITRE à attribuer des identifiants CVE dans un champ d'application défini ; il s'agit notamment de grands fournisseurs tels que Microsoft, Google et RedHat, de fondations open source comme la Python Software Foundation, de cabinets de recherche en sécurité, ainsi que de plateformes telles que Django et GitLab.  En général, un identifiant CVE est attribué avant que la vulnérabilité ne soit rendue publique. Les fournisseurs gardent les détails secrets pendant qu'ils développent et testent un correctif, puis divulguent tout en une seule fois. C'est ce qu'on appelle la divulgation coordonnée, la norme largement recommandée pour le signalement responsable des vulnérabilités, soutenue par la CISA, l'ENISA et FIRST. 

Toutes les difficultés signalées ne sont pas prises en compte. Trois critères doivent être remplis :

1. Corrigible indépendamment : cette faille peut être corrigée de manière autonome, sans dépendre d'autres bogues.
2. Reconnu par le fournisseur : le fournisseur confirme que le problème présente un risque pour la sécurité, ou un rapport émanant d'un tiers démontre son impact.
3. Concerne une seule base de code : si une vulnérabilité touche plusieurs produits, chacun se voit attribuer son propre identifiant CVE. Les enregistrements sont conservés de manière aussi isolée que possible.

Comment puis-je trouver des enregistrements CVE ?

Les informations CVE sont gratuites et accessibles au public. Pour suivre en temps réel les nouvelles entrées, suivez @CVEnew sur X. Avec un rythme actuel de plus de 130 nouveaux CVE par jour, les mises à jour sont fréquentes. Pour accéder en masse aux archives remontant jusqu'à 1999, CVE.org/Downloads propose la base de données complète via un dépôt GitHub au format JSON 5.0/5.1, mise à jour toutes les sept minutes environ. CVEdetails.com propose une interface plus accessible et consultable, avec des mises à jour quotidiennes.

Comment faire correspondre vos bibliothèques au bon CVE ?

Lors de l'analyse d'une vulnérabilité, l'essentiel est de faire correspondre le nom du paquet et le numéro de version afin de s'assurer que vous examinez bien le CVE correspondant à votre dépendance spécifique. Des outils tels Aikido s'en chargent automatiquement en comparant les noms et les versions des paquets avec les bases de données de vulnérabilités, ce qui vous évite d'avoir à le faire manuellement.

Qu'est-ce que le système de notation CVSS ?

Le CVSS (Common Vulnerability Scoring System) est la norme utilisée pour évaluer la gravité d'une vulnérabilité sur une échelle allant de 0,0 à 10,0. La plupart des entrées CVE sont accompagnées d'un score CVSS, ce qui permet aux équipes de sécurité d'évaluer rapidement la gravité d'une faille. Les scores CVSS sont généralement attribués par le NVD dans le cadre de son processus d'enrichissement, bien que les CNA puissent également fournir des scores. En cas de divergence, les deux scores peuvent être indiqués.

Comment un score CVSS est-il calculé ?

Le CVSS v4.0 se compose de quatre groupes de paramètres :

• Base : rend compte des caractéristiques intrinsèques d'une vulnérabilité qui restent constantes dans le temps 
• Menace : rend compte de la manière dont ces caractéristiques évoluent en fonction des activités d'exploitation observées dans la réalité 
• Environnement : prend en compte les facteurs propres à la configuration de votre organisation
• Complémentaire : apporte des précisions supplémentaires sans influencer la note finale 
  

Qu'est-ce que l'échelle de notation CVSS ?

L'échelle de notation CVSS actuelle (v4.0) comprend cinq catégories :

• Excellent (9,0–10,0)
• Élevé (7,0–8,9)
• Moyen (4,0–6,9)
• Faible (0,1–3,9)
• Aucun (0,0)

‍

Pour vous donner une idée de l'ampleur du phénomène, voici quelques exemples concrets :

• Critique : CVE-2021-44228 (Log4Shell). Score CVSS v3.1 : 10,0. Une faille permettant l'exécution de code à distance dans Apache Log4j. Un attaquant pourrait exécuter du code arbitraire sur un serveur en envoyant un message de journal spécialement conçu. Il s'agit de l'une des vulnérabilités les plus graves jamais révélées.
• Risque élevé : CVE-2017-0144 (EternalBlue). Score CVSS v3.1 : 8,8. Une faille dans le protocole SMB (Server Message Block) de Windows. Développée à l'origine comme un exploit par la NSA, elle a fait l'objet d'une fuite en 2017 et a été presque immédiatement exploitée dans le cadre des attaques par ransomware WannaCry et NotPetya, qui ont causé des milliards de dollars de dommages à l'échelle mondiale. 
  

Pour les niveaux inférieurs, les exemples concrets bien connus sont plus rares, car les vulnérabilités de faible gravité font rarement la une des journaux. En pratique :

• Niveau moyen: comprend généralement des failles dont l'exploitation nécessite des conditions spécifiques, par exemple une vulnérabilité de type « cross-site scripting » qui requiert une interaction de l'utilisateur, ou une erreur de configuration exposant des données non critiques.
• Faible: failles nécessitant un accès local ou des conditions inhabituelles, par exemple un fichier de configuration contenant des identifiants par défaut accessible uniquement en local.
• Aucun : Problème signalé sans impact confirmé sur la sécurité

Téléchargez une copie complète du guide de l'utilisateur du système de notation CVSS.

Comment puis-je trouver un score CVSS pour un enregistrement CVE ?

Les scores CVSS s'affichent directement sur la page de fiche de chaque CVE dans le NVD, avec prise en charge des scores v3.x et v4.0 lorsqu'ils sont disponibles. Gardez à l'esprit que, à mesure que la couverture des données du NVD se réduit, certains scores peuvent manquer ou reposer uniquement sur l'évaluation de l'auteur de la soumission plutôt que sur une analyse indépendante. La base de données de vulnérabilités Aikido constitue une référence croisée utile, car elle s'appuie sur plusieurs sources et non uniquement sur le NVD.

Qu'est-ce qu'une CWE ?

Le Common Weakness Enumeration (CWE) est une liste, élaborée par la communauté, des failles courantes en matière de logiciels et de matériel, gérée par MITRE. L'objectif principal du CWE est de prévenir les vulnérabilités à la source, en éliminant les erreurs les plus courantes avant la mise sur le marché des produits. Il offre également aux développeurs un cadre commun pour discuter des menaces de sécurité et y remédier, avec des correspondances directes vers des bases de données de vulnérabilités telles que le CVE.

La principale différence : le CWE décrit la faille sous-jacente à l'origine d'une vulnérabilité, tandis que le CVE identifie un cas précis de vulnérabilité. On peut considérer le CWE comme la catégorie et le CVE comme l'occurrence. À l'instar du CVE, le CWE dispose de son propre système de notation de gravité via le CWSS et le CWRAF.

Découvrez le classement des 25 CWE les plus dangereux pour 2025.

Pourquoi la surveillance des vulnérabilités CVE devient de plus en plus difficile

Le problème lié au volume est bien réel : les signalements de vulnérabilités (CVE) ont augmenté de 263 % entre 2020 et 2025, et ceux enregistrés au cours des trois premiers mois de 2026 sont supérieurs de près d'un tiers à ceux de la même période l'année dernière. Cette croissance ne fait que s'accélérer, et les registres open source en sont l'une des principales causes.

L'IA a considérablement abaissé les obstacles à la publication de paquets open source, et les registres en ressentent les effets. L'afflux de paquets rend les examens approfondis de plus en plus rares, et l'infrastructure mise en place pour suivre et contextualiser les vulnérabilités subit la même pression.

Le NVD a été conçu pour enrichir chaque CVE en y ajoutant des scores CVSS, des listes de produits et un contexte technique qui rendent les enregistrements CVE bruts réellement exploitables. Le NIST a enrichi près de 42 000 CVE en 2025, soit 45 % de plus que lors de toute année précédente. Mais cette augmentation de la productivité n'a pas suffi à suivre le rythme des soumissions croissantes. Comme nous l'avons mentionné plus haut, le NIST a désormais dépriorisé l'enrichissement pour la majorité des CVE. Les outils sur lesquels votre équipe s'appuie pour détecter et noter les vulnérabilités fonctionnent, pour une part croissante de l'univers des CVE, sur des données incomplètes sans vous en informer.

Les limites des CVE : ce qui n'est pas signalé

Le problème du NVD n'est qu'une partie du problème. Le véritable enjeu réside dans le fait que les CVE ne couvrent que ce qui est rendu public, alors que beaucoup de choses ne le sont pas.

Au cours d'une seule semaine de surveillance Aikido , 12 des 16 vulnérabilités signalées n'avaient reçu aucun identifiant CVE. Il ne s'agissait pas non plus de cas marginaux obscurs. Axios, avec 56 millions de téléchargements npm hebdomadaires, a corrigé en silence une vulnérabilité de type « pollution » dans son prototype qui n'a toujours pas de CVE. Apache ECharts a corrigé un problème de cross-site scripting sans jamais le divulguer. Parmi les vulnérabilités qui ont finalement obtenu un CVE, le délai moyen entre la correction et la divulgation était de 27 jours, certaines ayant même pris jusqu'à neuf mois.

Plutôt que de s'appuyer sur des bases de données centralisées, Intel utilise des modèles de langage de grande échelle (LLM) spécialement entraînés pour analyser les journaux de modifications, les notes de mise à jour et les messages de commit de millions de paquets open source, identifiant ainsi les correctifs liés à la sécurité avant même qu'ils ne se voient attribuer un identifiant CVE, et effectuant des recoupements avec cinq bases de données de vulnérabilités clés pour une couverture plus étendue. Si aucune information n'est disponible, les ingénieurs Aikido valident et publient un avis accompagné d'un identifiant Aikido . Au cours de sa première année, 67 % des vulnérabilités signalées par Intel n'avaient jamais été divulguées dans aucune base de données publique. Intel alimente directement la Aikido ; ainsi, lorsqu'une nouvelle vulnérabilité est détectée, les utilisateurs sont automatiquement alertés, avant même qu'un identifiant CVE ne lui soit attribué.

Que puis-je faire pour maintenir une posture de sécurité robuste ?

Toutes les vulnérabilités CVE ne vous concernent pas forcément. Il vous faut adopter une approche à plusieurs niveaux. Les scores CVSS constituent un bon point de départ, mais ils ne tiennent pas compte de votre contexte spécifique. Le catalogue KEV de la CISA offre un indicateur plus concret : si une vulnérabilité CVE y figure, cela signifie qu’elle fait l’objet d’une exploitation active dans la nature. Cependant, le catalogue KEV ne couvre que moins de 1 % de l’ensemble des vulnérabilités CVE et se concentre principalement sur les failles au niveau du périmètre réseau ; il est donc loin d’être exhaustif. 

Le système de notation de prédiction d'exploitation (EPSS) constitue un autre outil utile. Il prédit la probabilité qu'une vulnérabilité soit exploitée au cours des 30 prochains jours en s'appuyant sur renseignement sur les menaces concrets renseignement sur les menaces, ce qui vous aide à déprioriser la longue liste des CVE qui ont peu de chances d'être un jour utilisées à des fins malveillantes. Aikido nativement la hiérarchisation basée sur l'EPSS, en déclassant automatiquement les problèmes à faible risque afin que votre équipe puisse se concentrer sur l'essentiel.

Avant de signaler une vulnérabilité, réfléchissez aux points suivants :

• Accessibilité : il se peut que la fonction vulnérable ne soit pas accessible dans votre application, ce qui constitue l’une des principales raisons pour lesquelles analyse d’accessibilité, et non les scores CVSS bruts, qui devrait guider votre hiérarchisation.
• Impact sur l'activité : le composant concerné n'affecte pas les systèmes critiques, les données clients ni les opérations essentielles.
• Contexte particulier : les systèmes personnalisés ou hérités peuvent présenter des profils de risque différents de ceux supposés dans la description standard du CVE.
• Mesures de contrôle existantes : vous disposez peut-être déjà de mesures de protection qui neutralisent ce risque.
• Limites en matière de ressources : il n'est pas réaliste de tout régler. Il faut donner la priorité à ce qui est réellement exploitable et qui a un impact.

Obtenez un scanner de vulnérabilités

Le meilleur point de départ est Aikido , une plateforme spécialement conçue pour faire le tri parmi le flot d'informations qui rend l'utilisation de la plupart des scanners CVE fastidieuse. Les scanners traditionnels génèrent des centaines d’alertes brutes, sans tenir compte du fait qu’une vulnérabilité soit réellement exploitable dans votre environnement. analyse d’accessibilité Aikido analyse d’accessibilité les chemins d’exécution à travers votre code pour déterminer quelles vulnérabilités peuvent réellement être atteintes et déclenchées, en filtrant les problèmes inaccessibles, les faux positifs et les résultats non pertinents, ce qui permet souvent d’atteindre jusqu’à 95 % réduction du bruit. 

‍

Prenez une longueur d'avance

Les CVE répertorient les vulnérabilités qui ont déjà été identifiées et cataloguées. Au moment où un CVE est publié, les pirates ont parfois déjà eu plusieurs jours, voire plusieurs semaines, pour en tirer parti. Et comme nous l'avons vu plus haut, de nombreuses vulnérabilités ne se voient jamais attribuer de CVE.

Garder une longueur d'avance ne se résume pas à appliquer des correctifs de manière réactive. Maintenez vos dépendances à jour et vérifiez la conformité de votre code par rapport aux benchmarks Top 10 OWASP et CIS, les outils standard permettant d'identifier les faiblesses les plus courantes et les erreurs de configuration de sécurité de base. Vous pouvez consulter vos scores OWASP et CIS directement dans Aikido. Pour les menaces qui n'ont pas encore été répertoriées, Aikido surveille plus de 4,3 millions de paquets open source afin de détecter les vulnérabilités avant même qu'elles ne disposent d'un identifiant CVE. 

Découvrez quelles vulnérabilités CVE affectent réellement votre base de code.

‍

{{cta}}

‍