Qu'est-ce qu'un CVE ?

Une Common Vulnerability and Exposure (CVE) est une faille de sécurité connue et cataloguée. Lorsqu'une vulnérabilité reçoit une 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 cve.org avec la notation et le contexte ajoutés par la National Vulnerability Database (NVD) du NIST) afin que chacun puisse la consulter et agir en conséquence. Le suivi des CVE offre au monde de la sécurité un point de référence commun, permettant aux équipes de prioriser et de réagir aux failles connues avant que les attaquants ne les exploitent. Simple en théorie, n'est-ce pas ?

Voici le problème : Plus de 48 000 CVE ont été publiées rien qu'en 2025. Soit 131 nouvelles vulnérabilités chaque jour. Les modèles d'IA et les capacités de scan rendent la découverte de vulnérabilités plus rapide et plus accessible que jamais, mais la validation des résultats à grande échelle est plus difficile car le volume des soumissions dépasse l'infrastructure conçue pour les gérer. La NVD cède 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, comment elles sont notées, où le système montre ses limites, et ce que les équipes font pour anticiper ces problèmes.

Que contient un enregistrement CVE ?

Un ID CVE est comme un numéro de série, formaté comme suit : 'CVE-YYYY-#####'.

Chaque enregistrement contient :

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

Les anciens enregistrements CVE peuvent également inclure 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 ?

La réponse courte est : aucune organisation unique ne le fait. Et c'est de plus en plus le problème.

La corporation MITRE supervise le programme CVE lui-même, attribuant les ID et maintenant la liste officielle, et tous les enregistrements CVE sont libres de consultation et d'utilisation. Historiquement, la NVD était l'endroit où ces entrées CVE brutes étaient enrichies avec les scores CVSS, les détails des correctifs et le contexte technique. C'est aussi là que la plupart des outils de sécurité extraient leurs données. La Cybersecurity and Infrastructure Security Agency (CISA) fournit un soutien financier. D'autres bases de données, comme la CERT/CC Vulnerability Notes Database 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 « basée sur les risques » qui priorise les CVE pour les logiciels du gouvernement américain et celles figurant dans le catalogue des Known Exploited Vulnerabilities (KEV), laissant le reste non enrichi, le retard croissant étant effectivement déplacé vers « non planifié ». Le programme CVE de MITRE a été confronté à des problèmes de financement. L'UE a lancé sa propre alternative, la European Vulnerability Database (EUVD), mais elle en est à ses débuts et dépend encore fortement de la synchronisation avec la NVD. Il n'y a plus de source unique de vérité, et dépendre d'une seule base de données signifie que vous avez moins de couverture et de visibilité que vous ne l'espérez. C'est exactement le problème qu'Aikido Intel visait à résoudre : surveiller des millions de packages open source pour des correctifs de sécurité qui n'apparaissent jamais dans aucune base de données officielle, et alimenter directement la plateforme Aikido afin que les utilisateurs soient alertés automatiquement.

Comment les CVE sont-elles découvertes et attribuées ?

N'importe qui peut signaler une vulnérabilité : entreprises de sécurité, chercheurs indépendants, développeurs individuels, et même des utilisateurs curieux. De nombreuses organisations gèrent des programmes de bug bounty qui rémunèrent les chercheurs pour les découvertes valides, et les projets open source s'appuient généralement sur la divulgation communautaire.

Une fois qu'une vulnérabilité est signalée, une CVE Numbering Authority (CNA) la valide, lui attribue un ID CVE, rédige une courte description et ajoute des références avant de la publier sur la liste officielle des CVE. Les CNA sont des organisations autorisées par MITRE à attribuer des CVE dans un périmètre défini, y compris les principaux fournisseurs comme Microsoft, Google et RedHat, les fondations open source comme Python Software Foundation, les entreprises de recherche en sécurité, ainsi que des plateformes comme Django et GitLab.  Généralement, un ID 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. Ceci est connu sous le nom de divulgation coordonnée, la norme largement recommandée pour le signalement responsable des vulnérabilités, soutenue par CISA, ENISA et FIRST. 

Tous les problèmes signalés ne sont pas éligibles. Trois critères doivent être remplis :

1. Correction indépendante : La faille peut être corrigée seule, indépendamment d'autres bugs.
2. Reconnu par le fournisseur : Le fournisseur confirme que le problème présente un risque de sécurité, ou un rapport tiers démontre son impact.
3. Affecte une seule base de code : Si une vulnérabilité affecte plusieurs produits, chacun reçoit sa propre CVE. Les enregistrements sont maintenus aussi isolés que possible.

Comment puis-je trouver des enregistrements CVE ?

Les informations CVE sont gratuites et accessibles au public. Pour un flux en direct des nouvelles entrées, suivez @CVEnew sur X. Au rythme actuel de plus de 130 nouvelles CVE par jour, cela évolue rapidement. Pour un accès en masse aux enregistrements historiques remontant à 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 offre 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é, il est essentiel de faire correspondre le nom du package et le numéro de version pour s'assurer que vous examinez la bonne CVE pour votre dépendance spécifique. Des outils comme Aikido gèrent cela automatiquement en faisant correspondre les noms et versions des packages avec les bases de données de vulnérabilités, vous évitant ainsi de le faire manuellement.

Qu'est-ce que la notation CVSS ?

Le CVSS (Common Vulnerability Scoring System) est la norme utilisée pour évaluer la gravité d'une vulnérabilité sur une échelle de 0,0 à 10,0. La plupart des entrées CVE comportent un score CVSS, offrant aux équipes de sécurité une évaluation rapide de 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 désaccord, les deux peuvent être répertoriés.

Comment un score CVSS est-il calculé ?

CVSS v4.0 est composé de quatre groupes de métriques :

• Base : capture les caractéristiques intrinsèques d'une vulnérabilité qui sont constantes dans le temps. 
• Menace : reflète comment ces caractéristiques évoluent en fonction de l'activité d'exploitation réelle. 
• Environnemental : prend en compte les facteurs spécifiques à la configuration de votre organisation.
• Supplémentaire : ajoute un contexte supplémentaire sans affecter le score final.
  

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

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

• Critique (9.0–10.0)
• Élevée (7.0–8.9)
• Moyenne (4.0–6.9)
• Faible (0.1–3.9)
• Aucune (0.0)

‍

Pour contextualiser cette échelle, voici quelques exemples concrets :

• Critique : CVE-2021-44228 (Log4Shell). Score CVSS v3.1 : 10.0. Une exécution de code à distance dans Apache Log4j. Un attaquant pouvait exécuter du code arbitraire sur un serveur en envoyant un message de journal spécialement conçu. L'une des vulnérabilités les plus graves jamais révélées.
• Élevée : CVE-2017-0144 (EternalBlue). Score CVSS v3.1 : 8.8. Une faille dans Windows SMB (Server Message Block). Initialement développé comme un exploit par la NSA, il a été divulgué en 2017 et presque immédiatement utilisé dans les attaques de ransomware WannaCry et NotPetya, qui ont causé des milliards de dollars de dommages dans le monde entier.
  

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

• Moyenne : Comprend généralement des failles qui nécessitent des conditions spécifiques pour être exploitées, par exemple, une vulnérabilité de cross-site scripting nécessitant une interaction utilisateur, ou une mauvaise configuration exposant des données non critiques.
• Faible : Failles qui nécessitent un accès local ou des conditions inhabituelles, par exemple, un fichier de configuration avec des identifiants par défaut qui ne peut être accédé que localement.
• Aucune : Un problème signalé sans impact de sécurité confirmé.

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 sont affichés directement sur la page d'enregistrement de chaque CVE dans le NVD, avec la prise en charge des scores v3.x et v4.0 lorsqu'ils sont disponibles. Gardez à l'esprit qu'à mesure que la couverture d'enrichissement du NVD se réduit, les scores peuvent être manquants ou basés uniquement sur l'évaluation du soumissionnaire plutôt que sur une analyse indépendante. La base de données de vulnérabilités d'Aikido est une référence croisée utile, s'appuyant sur plusieurs sources plutôt que sur le seul NVD.

Qu'est-ce qu'une CWE ?

La Common Weakness Enumeration (CWE) est une liste de faiblesses logicielles et matérielles courantes, développée par la communauté et maintenue par le MITRE. L'objectif principal de la CWE est d'arrêter les vulnérabilités à la source, en éliminant les erreurs les plus courantes avant la livraison des produits. Elle offre également aux développeurs un cadre commun pour discuter et traiter les menaces de sécurité, avec des correspondances directes avec les bases de données de vulnérabilités comme CVE.

La distinction clé : CWE décrit la faiblesse sous-jacente qui mène à une vulnérabilité, tandis que CVE identifie une instance spécifique d'une vulnérabilité. Considérez CWE comme la catégorie, CVE comme l'occurrence. Comme CVE, CWE possède son propre système de notation de gravité via CWSS et CWRAF.

Jetez un œil aux 25 CWE les plus dangereuses pour 2025.

Pourquoi la surveillance des CVE devient plus difficile

Le problème du volume est réel : les soumissions de CVE ont augmenté de 263 % entre 2020 et 2025, et les soumissions au cours des trois premiers mois de 2026 sont près d'un tiers plus élevées que celles 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 une raison majeure.

L'IA a considérablement abaissé la barrière à la publication de paquets open source, et les registres en ressentent les effets. Le nombre de paquets entrants signifie qu'un examen significatif est de plus en plus rare, et l'infrastructure conçue pour suivre et contextualiser les vulnérabilités est soumise à la même pression.

Le NVD a été conçu pour enrichir chaque CVE, en ajoutant des scores CVSS, des listes de produits et un contexte technique qui rendent les enregistrements CVE bruts réellement utilisables. Le NIST a enrichi près de 42 000 CVE en 2025, soit 45 % de plus que toute année précédente. Mais cette productivité accrue n'a pas suffi à suivre l'augmentation des soumissions. Comme nous l'avons mentionné ci-dessus, le NIST a maintenant dépriorisé l'enrichissement pour la majorité des CVE. Les outils sur lesquels votre équipe s'appuie pour détecter et évaluer les vulnérabilités fonctionnent, pour une part croissante de l'univers des CVE, avec 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 de l'histoire. Le problème plus profond est que les CVE ne couvrent que ce qui est divulgué, et beaucoup ne le sont pas.

En une seule semaine de surveillance par Aikido Intel, 12 des 16 vulnérabilités signalées n'avaient aucune CVE attribuée. Il ne s'agissait pas non plus de cas limites obscurs. Axios, avec 56 millions de téléchargements npm hebdomadaires, a corrigé silencieusement une vulnérabilité de pollution de prototype qui n'a toujours pas de CVE. Apache ECharts a corrigé un problème de cross-site scripting et ne l'a jamais divulgué. Parmi les vulnérabilités qui ont finalement obtenu une CVE, le délai moyen entre le correctif et la divulgation était de 27 jours, certaines prenant jusqu'à neuf mois.

Plutôt que de dépendre de bases de données centralisées, Intel utilise des LLM entraînés sur mesure pour analyser les journaux de modifications, les notes de version et les messages de commit à travers des millions de paquets open source, faisant remonter les correctifs pertinents pour la sécurité avant qu'ils n'obtiennent un ID CVE, et les recoupant avec cinq bases de données de vulnérabilités clés pour une couverture plus large. Si aucune divulgation n'existe, les ingénieurs de sécurité d'Aikido valident et publient un avis avec un Aikido Vulnerability ID. Au cours de sa première année, 67 % des vulnérabilités signalées par Intel n'avaient jamais été divulguées à aucune base de données publique. Intel s'intègre directement à la plateforme Aikido, de sorte que lorsqu'une nouvelle vulnérabilité est détectée, les utilisateurs sont automatiquement alertés, avant même qu'un CVE ne lui soit attribué.

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

Toutes les CVE ne sont pas votre problème. Vous avez besoin d'une approche multicouche. Les scores CVSS sont un bon point de départ, mais ils ne tiennent pas compte de votre contexte spécifique. Un signal plus exploitable est le catalogue KEV de la CISA : si une CVE y est répertoriée, elle est activement exploitée dans la nature. Mais KEV couvre moins de 1 % de toutes les CVE et tend vers les vulnérabilités du périmètre réseau, il est donc loin d'être exhaustif.

L'Exploit Prediction Scoring System (EPSS) est une autre couche utile. Il prédit la probabilité qu'une vulnérabilité soit exploitée dans les 30 prochains jours en se basant sur le renseignement sur les menaces du monde réel, vous aidant à déprioriser la longue traîne des CVE qui sont peu susceptibles d'être exploitées. Aikido prend en charge nativement la priorisation basée sur l'EPSS, rétrogradant automatiquement les problèmes à faible risque afin que votre équipe puisse se concentrer sur ce qui compte.

Avant d'escalader toute vulnérabilité, considérez :

• Accessibilité : La fonction vulnérable peut ne pas être accessible dans votre application, une raison clé pour laquelle l'analyse d’accessibilité, et non les scores CVSS bruts, devrait guider votre priorisation.
• Impact commercial : Le composant affecté peut ne pas toucher les systèmes critiques, les données clients ou les opérations principales.
• Environnement unique : Les systèmes personnalisés ou hérités peuvent présenter des profils de risque différents de ceux supposés par la description CVE standard.
• Contrôles existants : Vous pourriez déjà avoir des défenses en place qui neutralisent le risque.
• Contraintes de ressources : Tout corriger n'est pas réaliste. Priorisez ce qui est réellement exploitable et impactant.

Obtenez un scanner de vulnérabilités

Le meilleur point de départ est Aikido Security, une plateforme conçue spécifiquement pour réduire le bruit qui rend la plupart des scanners CVE épuisants à utiliser. Les scanners traditionnels font remonter des centaines d'alertes brutes, que la vulnérabilité soit réellement exploitable dans votre environnement ou non. L'analyse d’accessibilité d'Aikido trace les chemins d'exécution à travers votre code pour déterminer quelles vulnérabilités peuvent réellement être atteintes et déclenchées, filtrant les problèmes non accessibles, les faux positifs et les résultats non pertinents, atteignant souvent jusqu'à 95 % de réduction du bruit.

‍

Prenez de l'avance sur la CurVE

Les CVE décrivent des vulnérabilités qui ont déjà été identifiées et cataloguées. Au moment où une CVE est publiée, les attaquants peuvent avoir eu des jours ou des semaines pour agir. Et comme nous l'avons vu plus haut, de nombreuses vulnérabilités n'obtiennent jamais de CVE.

Garder une longueur d'avance signifie plus que des correctifs réactifs. Maintenez vos dépendances à jour et vérifiez votre code par rapport au Top 10 OWASP 2025 et aux benchmarks de conformité CIS, les outils standards pour identifier les faiblesses les plus courantes et les configurations de sécurité inadéquates de base. Vous pouvez vérifier vos scores OWASP et CIS directement dans Aikido. Pour les menaces qui n'ont pas encore été cataloguées, Aikido Intel surveille plus de 4,3 millions de paquets open source pour détecter les vulnérabilités avant qu'elles n'aient un ID CVE. 

Voyez quelles CVE affectent réellement votre base de code.

‍

{{cta}}

‍