Qu’est-ce qu’une CVE (Common Vulnerabilities and Exposures) ?
Une CVE, ou Common Vulnerabilities and Exposures, est un identifiant standardisé qui référence une vulnérabilité de sécurité divulguée publiquement. Son objectif premier est de garantir que tout l’écosystème de sécurité parle du même problème lorsqu’une vulnérabilité est découverte.
Avant l’existence des CVE, une même vulnérabilité pouvait être décrite différemment par les fournisseurs, les chercheurs et les outils de sécurité. La coordination en devenait difficile. On ne savait pas toujours si deux bulletins renvoyaient à la même faille ou à des failles distinctes. Les CVE ont résolu ce problème en introduisant un système de nommage unique et partagé.
Quand une vulnérabilité reçoit une CVE, cela signifie que le problème est reconnu et documenté publiquement. Cela ne dit rien de sa gravité, de son exploitabilité réelle ni de l’urgence à la corriger dans votre environnement.
Cette distinction est essentielle. Les CVE répondent à une question précise : comment identifier et suivre de façon cohérente les vulnérabilités connues à travers les produits, les fournisseurs et les outils. Elles ne répondent pas aux questions plus larges de risque, d’impact ou de priorisation.
En pratique, les CVE forment le tissu conjonctif de la vulnerability management. Les scanners de sécurité s’appuient sur les identifiants CVE pour signaler leurs résultats, et les fournisseurs les utilisent dans leurs bulletins et leurs notes de correctifs. Les équipes de réponse aux incidents s’en servent pour communiquer sur les menaces actives. Sans les CVE, cette coordination s’effondrerait.
Le programme CVE lui-même est géré par MITRE, qui supervise la façon dont les vulnérabilités sont nommées, suivies et publiées. Cette gouvernance renforce le rôle des CVE comme système de référence neutre, et non comme cadre d’évaluation du risque.
Comprendre ce qu’est une CVE, et tout aussi important ce qu’elle n’est pas, pose les bases d’une vulnerability management efficace. Les CVE vous disent ce qui existe. Tout le reste consiste à déterminer ce qui compte vraiment.
Renforcez votre sécurité cloud
Téléchargez les pratiques avancées pour réduire les risques, prioriser les actions et sécuriser vos environnements cloud à grande échelle.
Ce que représente réellement une CVE
Une CVE représente une vulnérabilité précise, divulguée publiquement, dans un produit, une version ou un composant défini. Fondamentalement, une CVE répond à une question très étroite : de quel problème parlons-nous ?
Chaque entrée CVE comprend en général une courte description de la vulnérabilité, des informations sur les logiciels concernés et des références vers des bulletins ou des correctifs. Ces informations sont volontairement limitées. Une CVE ne décrit pas comment une vulnérabilité se comporte dans votre environnement, si elle est accessible ni les dégâts qu’elle pourrait réellement causer en cas d’exploitation.
Cette limite n’est pas un défaut du système CVE. C’est un choix de conception. Les CVE existent pour assurer la cohérence et la coordination dans un écosystème de sécurité mondial qui réunit fournisseurs, chercheurs, outils et défenseurs. Pour remplir ce rôle, les CVE doivent rester indépendantes de l’environnement.
Les problèmes commencent quand les équipes traitent les CVE comme des jugements de risque plutôt que comme des identifiants. Une CVE peut sembler alarmante sur le papier tout en étant sans objet en pratique. Une autre peut paraître anodine et se trouver pourtant sur un attack path critique dans un environnement de production. La CVE elle-même ne contient pas les informations nécessaires pour distinguer ces deux cas.
Les identifiants CVE expliqués
Les identifiants CVE suivent un format simple et standardisé, comme CVE-2021-44228. L’identifiant encode l’année d’attribution de la CVE et un numéro unique, mais il ne traduit ni la criticité, ni l’exploitabilité, ni la priorité.
Une fois attribuée, une CVE suit un cycle de vie. Les détails évoluent à mesure que de nouvelles informations sont disponibles. Dans certains cas, une CVE est contestée ou retirée si le problème ne peut être confirmé ou s’il s’avère qu’il ne s’agit pas d’une vulnérabilité. Tout au long de ce processus, l’identifiant reste le point d’ancrage utilisé par les outils et les bulletins pour rester alignés.
Les scanners de vulnérabilités, les systèmes de patch management et les bulletins de sécurité s’appuient tous sur les identifiants CVE pour corréler leurs résultats. Plusieurs fournisseurs référencent une même CVE dans des contextes différents, mais l’identifiant garantit que chacun parle bien du même problème sous-jacent.
Le programme CVE est géré par MITRE, qui encadre l’attribution et la maintenance des identifiants. Cette gouvernance renforce le rôle des CVE comme références neutres, et non comme avis sur le risque ou l’urgence.
CVE et CWE
On confond souvent les CVE avec les CWE, mais elles servent des objectifs différents.
Une CVE décrit une vulnérabilité précise dans un logiciel précis. Une CWE, ou Common Weakness Enumeration, décrit la classe plus large de faiblesse à l’origine de la vulnérabilité, comme une validation d’entrée incorrecte ou une logique d’authentification non sécurisée.
Concrètement, une CVE est l’instance, tandis qu’une CWE est le modèle. De nombreuses CVE différentes renvoient à une même CWE. Comprendre les catégories CWE aide à expliquer pourquoi des vulnérabilités similaires reviennent d’un produit et d’une version à l’autre.
La CWE ne remplace pas la CVE pour autant. Les CVE restent nécessaires pour suivre les problèmes individuels, coordonner la divulgation et gérer la remédiation. La CWE éclaire les causes profondes, tandis que les CVE fournissent les références partagées dont dépendent les workflows de vulnerability management.
Reconnaître cette distinction aide à comprendre pourquoi les données de vulnérabilité seules ne suffisent pas. Les CVE et les CWE décrivent ce qui existe et pourquoi cela existe. Déterminer si cela compte exige un contexte supplémentaire.
Vulnérabilité et exposition dans les environnements cloud
Une vulnérabilité et une exposition ne sont pas la même chose, même si on les traite souvent comme interchangeables. Comprendre la différence est essentiel pour donner du sens aux CVE dans les environnements cloud modernes.
Une vulnérabilité est une faille logicielle qui pourrait être exploitée, et une CVE vous indique qu’une telle faille existe. Une exposition décrit si cette faille est réellement accessible et utilisable par un attaquant dans un environnement réel. L’exposition dépend de la façon dont le composant vulnérable est déployé, de ce à quoi il accède et de la manière dont il est relié au reste du système.
Dans les environnements on-prem traditionnels, l’écart entre vulnérabilité et exposition était souvent plus faible. Les systèmes duraient longtemps, les frontières réseau restaient relativement stables et la responsabilité était plus facile à établir. Dans les environnements cloud, cet écart se creuse fortement.
Les architectures cloud introduisent des couches d’abstraction et de dynamisme qui changent la façon dont le risque se matérialise. Les services communiquent via des API, les workloads passent automatiquement à l’échelle et les containers sont reconstruits fréquemment. Les droits d’identité et d’accès déterminent souvent l’accessibilité plus que la seule topologie réseau. Résultat : un composant vulnérable peut exister sans présenter de risque réel, tandis qu’une vulnérabilité en apparence modeste peut devenir critique dans les bonnes conditions.
Voilà pourquoi les CVE seules peinent à traduire le risque réel dans le cloud. Une CVE ne vous dit pas si un service vulnérable est exposé à Internet ou isolé. Elle ne vous dit pas si le workload s’exécute avec des permissions minimales ou de larges droits d’administration. Elle ne vous dit pas non plus si le service peut atteindre des données sensibles ou s’il se trouve sur un chemin qu’un attaquant pourrait réellement emprunter.
Le risque apparaît à l’intersection de la vulnérabilité et de l’exposition.
Pourquoi l’exposition change tout
L’exposition transforme une faiblesse théorique en menace concrète. Dans les environnements cloud, quelques facteurs de contexte pèsent bien plus lourd que le nombre brut de vulnérabilités.
Accessibilité depuis Internet. Une vulnérabilité dans une API ou un load balancer exposés au public diffère radicalement de la même faille dans un service interne sans accès externe. L’accessibilité détermine si un attaquant peut ne serait-ce que tenter l’exploitation.
Contexte d’identité et de permissions. Les workloads cloud se définissent par les permissions qu’ils portent. Une même vulnérabilité dans un workload doté de larges permissions IAM peut permettre un déplacement latéral ou une élévation de privilèges.
Accès à des données sensibles ou réglementées. L’exposition augmente fortement quand un composant vulnérable peut atteindre des données clients, des secrets ou des informations réglementées. Même des vulnérabilités qui semblent mineures ont alors de lourdes conséquences.
Attack paths et combinaisons. Dans le cloud, les incidents graves naissent souvent de combinaisons plutôt que d’une défaillance unique. Une CVE devient dangereuse quand elle s’associe à une erreur de configuration, un secret exposé ou des politiques d’identité trop permissives. Ces attack paths restent rarement visibles quand on évalue les vulnérabilités isolément.
Cette distinction explique pourquoi la vulnerability management se grippe quand les équipes s’appuient uniquement sur les listes de CVE et les scores de criticité. La plupart des environnements comptent des milliers de vulnérabilités à tout moment. Seule une petite fraction est exposée d’une façon qui crée un risque réel.
Une gestion efficace des CVE, surtout dans le cloud, suppose de passer du décompte des vulnérabilités à la compréhension de l’exposition. Dès que les équipes voient quelles CVE sont accessibles, à fort impact et reliées à des actifs critiques, la priorisation cesse d’être une devinette et devient défendable.
Les scores CVSS et leurs limites
Le Common Vulnerability Scoring System, ou CVSS, est souvent considéré comme la référence en matière de criticité des vulnérabilités. En pratique, le CVSS a été conçu pour répondre à une question bien plus étroite que ce que beaucoup d’équipes attendent de lui.
Le guide pratique des responsables sécurité
Obtenez des conseils concrets pour structurer votre stratégie CloudSec et aligner équipes, outils et priorités métier.
Le CVSS offre une façon standardisée de décrire l’impact potentiel d’une vulnérabilité prise isolément. Il évalue des facteurs comme la manière dont une vulnérabilité pourrait être exploitée et ce qui pourrait se produire en cas de succès. Cela rend le CVSS utile pour la comparaison et la coordination entre outils et fournisseurs, surtout quand peu d’informations de contexte sont disponibles.
Ce que le CVSS ne fait pas, c’est évaluer le risque dans un environnement précis. Les scores CVSS sont statiques et indépendants de l’environnement par conception. Ils ne tiennent pas compte de la façon dont un logiciel est déployé, du fait qu’un composant vulnérable soit exposé ou des données auxquelles il accède. Ces facteurs sortent du périmètre du système de scoring.
Voilà pourquoi une même CVE, avec un même score CVSS, représente des niveaux de risque très différents selon les environnements. Une vulnérabilité notée « critique » peut être inaccessible en pratique, tandis qu’un problème de criticité moyenne se trouve sur un service exposé avec accès à des données sensibles. Le CVSS traite ces scénarios comme équivalents, car il ne voit pas le contexte environnant.
Dans les environnements cloud, cette limite s’accentue. L’infrastructure est dynamique, les identités sont puissantes et les services s’interconnectent d’une façon que le CVSS n’a jamais été conçu pour modéliser. Les scores de criticité restent un signal utile, mais on ne peut pas s’en servir seuls comme mécanisme de décision.
Le CVSS est maintenu par FIRST, et son rôle de cadre commun a de la valeur. Les difficultés surgissent uniquement quand on demande au CVSS plus que ce pour quoi il a été prévu.
Pour une vulnerability management efficace, surtout dans le cloud, il faut traiter le CVSS comme un signal parmi d’autres. Il aide à mettre en avant des problèmes qui méritent attention, mais déterminer quoi corriger en premier réclame d’autres signaux, notamment ceux liés à l’exposition, à l’identité et à l’impact. Sans ce contexte, les scores de criticité seuls orientent la remédiation par le volume plutôt que par le risque.
Comment les CVE sont attribuées et publiées
Les CVE n’apparaissent pas automatiquement à la découverte d’une vulnérabilité. Chaque identifiant suit un processus défini d’attribution et de divulgation, pensé pour garantir cohérence, coordination et publication responsable dans l’écosystème de sécurité.
Quand une vulnérabilité est identifiée, elle est en général signalée par un chercheur, un fournisseur ou une équipe de sécurité. Ce signalement est examiné par une CVE Numbering Authority, ou CNA. Les CNA sont des organisations autorisées à valider les vulnérabilités et à attribuer des identifiants CVE dans un périmètre précis, comme une gamme de produits, un écosystème fournisseur ou un domaine de recherche.
Le programme CVE lui-même est supervisé par MITRE, qui fixe les règles d’attribution des CVE et assure la cohérence dans l’écosystème. Le rôle de MITRE est administratif et de coordination. Il n’évalue ni la criticité, ni l’exploitabilité, ni l’impact métier. Sa responsabilité est de maintenir un système d’identification fiable et neutre.
Une fois qu’une CNA confirme qu’un problème répond aux critères d’une CVE, un identifiant est attribué. À ce stade, la CVE peut être réservée sans être encore divulguée publiquement. Cela laisse aux fournisseurs le temps de développer des correctifs et de coordonner une divulgation responsable. Au moment de la divulgation, la CVE est publiée avec une description initiale et des références, puis devient disponible pour les bases de vulnérabilités, les scanners et les bulletins.
Les organisations de recherche en sécurité peuvent aussi agir comme CNA. Wiz est une CVE Numbering Authority, ce qui signifie que les vulnérabilités découvertes par l’équipe de recherche Wiz reçoivent directement des identifiants CVE et sont divulguées à la communauté de sécurité sans délais inutiles. Cela garantit que les vulnérabilités propres au cloud sont documentées et partagées rapidement au sein de l’écosystème CVE public.
Le calendrier d’attribution et de publication des CVE varie beaucoup. Certaines CVE sont émises et divulguées en quelques jours. D’autres prennent des semaines ou des mois, en raison de la complexité de validation, de la coordination avec les fournisseurs ou des périodes d’embargo. Pendant ce temps, les détails évoluent à mesure que les chercheurs comprennent mieux l’impact et les composants concernés.
Tout problème signalé ne devient pas une CVE valide. Certains identifiants sont retirés ou marqués comme contestés si la vulnérabilité ne peut être reproduite, s’avère être un problème de configuration plutôt qu’une faille logicielle ou ne répond pas aux critères de divulgation. Même après publication, les entrées CVE évoluent à mesure que de nouvelles informations apparaissent.
Ce processus rappelle un point important. Les CVE documentent et suivent les vulnérabilités connues de façon cohérente. Elles ne reflètent ni l’activité d’exploitation en temps réel ni l’exposition réelle d’un environnement. L’existence d’une CVE indique qu’un problème existe, mais déterminer s’il compte vraiment exige un contexte au-delà de l’attribution.
Le vrai défi de la gestion des CVE dans le cloud
À ce stade, le problème de la gestion des CVE dans les environnements cloud devrait se préciser. Les CVE sont des identifiants utiles, le CVSS fournit un signal générique de criticité et l’attribution suit un processus structuré. Pourtant, malgré toute cette structure, les équipes de sécurité peinent encore à répondre à une question simple : que faut-il corriger en premier ?
Le défi central, c’est l’échelle. Les environnements cloud modernes contiennent couramment des dizaines de milliers de CVE, souvent héritées d’images de base, de bibliothèques tierces ou de services managés. Traiter chaque CVE comme une action individuelle sature vite la capacité de remédiation, même pour des équipes bien dotées.
L’infrastructure cloud change en permanence. Les containers sont reconstruits, les fonctions serverless redéployées et les services montent ou descendent en charge automatiquement. Certaines vulnérabilités n’existent que brièvement, d’autres persistent parce qu’elles sont enfouies dans des images ou des dépendances partagées.
La responsabilité est diffuse. L’équipe qui reçoit une alerte CVE n’est pas toujours celle qui peut la corriger, car la faille provient parfois d’images de base ou de bibliothèques amont maintenues ailleurs. Sans lien clair avec les dépôts ou pipelines responsables, la remédiation se bloque.
Les CVE évaluées isolément trompent. Le risque réel émerge quand les vulnérabilités croisent l’exposition, les permissions d’identité et les erreurs de configuration. Une CVE de faible criticité devient critique sur un service exposé à Internet avec accès à des données sensibles, tandis qu’une CVE de forte criticité pose peu de risque si elle reste inaccessible.
Beaucoup d’organisations se retrouvent alors piégées dans un cycle de bruit, où les tableaux de bord se remplissent de CVE et les backlogs de correctifs gonflent sans que le risque réel diminue. L’écart tient à l’absence du contexte cloud permettant d’interpréter ces données, bien plus qu’à un manque de données brutes.
Une gestion efficace des CVE dans le cloud demande un changement d’approche. Plutôt que de compter les vulnérabilités, les équipes doivent identifier celles qui sont exposées et qui ouvrent une voie réaliste vers l’impact. Sans ce changement, les programmes CVE deviennent des exercices de conformité plutôt que de véritables moteurs de résultats de sécurité.
Comment Wiz transforme la découverte et la priorisation des CVE
Wiz aborde la gestion des CVE sous l’angle de l’Unified Vulnerability Management (UVM). Au lieu de traiter les vulnérabilités, les erreurs de configuration et les expositions comme des ensembles séparés, Wiz les évalue ensemble comme les parties d’une même surface de risque.
La vulnerability management traditionnelle traite les CVE comme l’unité de travail principale. Les résultats sont générés, scorés et mis en file de remédiation en grande partie isolément. Dans les environnements cloud, ce modèle se grippe, car les vulnérabilités existent rarement seules. Le risque réel naît de la façon dont elles croisent l’exposition, l’identité et la configuration.
Wiz commence par une découverte continue et agentless des CVE sur les workloads cloud, dont les virtual machines, les containers, les fonctions serverless et les services managés. Cela garantit une large couverture dans des environnements où les workloads sont éphémères et changent sans cesse. Mais la découverte n’est que le point d’entrée, pas le résultat.
Dans le modèle UVM, les CVE ne sont qu’un signal parmi d’autres. Wiz corrèle chaque vulnérabilité avec le contexte runtime : exposition à Internet, permissions d’identité et accès aux données sensibles. Cette vue unifiée permet de distinguer les vulnérabilités théoriquement graves de celles qui créent un risque réel en pratique.
Le Wiz Security Graph est au cœur de cette approche. Il relie les CVE aux erreurs de configuration, aux identités trop permissives et aux attack paths accessibles. Une vulnérabilité devient prioritaire non pas à cause de son seul score CVSS, mais parce qu’elle participe à un chemin menant à un accès privilégié ou à des données critiques. À l’inverse, les CVE dépourvues d’exposition ou d’impact réel peuvent être déprioritisées sans accroître le risque.
C’est là que Wiz UVM change la conversation. Au lieu de se demander quelles CVE existent, les équipes voient quelles vulnérabilités comptent vraiment dans le contexte de leur architecture cloud. Vulnérabilités, expositions et attack paths sont évalués ensemble, produisant un ensemble priorisé de risques défendables et actionnables.
L’UVM améliore aussi la vitesse de réponse. Quand une nouvelle CVE ou une vulnérabilité zero-day est divulguée, Wiz aide les équipes à déterminer vite si des workloads concernés sont présents, exposés et reliés à des actifs sensibles. En rattachant les vulnérabilités aux ressources cloud, aux identités et aux responsables, les efforts de remédiation se concentrent sur les risques qui exigent une action immédiate.
Enfin, l’UVM réduit le bruit à la source. Beaucoup de CVE proviennent d’images de base et de composants hérités partagés. Wiz offre une visibilité sur ces sources de risque et permet aux équipes de les traiter de façon systématique, au lieu de trier sans cesse les mêmes problèmes sur des workloads individuels.
Dans ce modèle, les CVE restent importantes, mais elles ne sont plus le centre de gravité. L’Unified Vulnerability Management déplace l’attention du décompte des vulnérabilités vers la réduction du risque, en évaluant comment les vulnérabilités se comportent dans des environnements cloud réels. C’est ce changement qui permet aux équipes de sécurité de passer d’un tri réactif des CVE à une gestion du risque proactive et guidée par le contexte.
Pour voir comment Wiz relie chaque CVE au contexte cloud et fait ressortir les risques réellement exploitables, Voir Wiz en action.
Voyez Wiz en action
Découvrez comment Wiz aide vos équipes à identifier les risques critiques et à sécuriser le cloud plus rapidement.
