TL; DR
La sécurité CVE consiste à suivre, prioriser et corriger les vulnérabilités à l'aide des identifiants CVE. standardIdentifiants attribués aux failles logicielles connues du public. La couche de dénomination fonctionne. La couche d'analyse sous-jacente ne suit plus le rythme, et une part croissante des menaces réelles n'intègre jamais le système.
- Le volume de données a dépassé les capacités d'analyse. 48 185 CVE ont été publiés en 2025, soit environ 131 par jour, et le nombre de soumissions a augmenté de 263 % entre 2020 et 2025. Le nombre d’identifiants a augmenté, mais pas leur enrichissement.
- NVD a cessé d'enrichir tout. Depuis avril 2026, le NIST n'enrichit que les CVE répondant à des critères définis. Environ 29 000 enregistrements en attente ont été reclassés comme non planifiés. Si votre priorisation dépend d'un score CVSS du NVD, une part croissante des CVE n'en obtiendra jamais.
- La peur du financement s'est dissipée, mais la dépendance, elle, est restée. CISLe programme a été relancé après avoir failli être abandonné en avril 2025, mais la structure à sponsor unique qui a provoqué la panique est restée inchangée, et c'est grâce à elle que la Fondation CVE existe.
- Toutes les menaces ne font pas l'objet d'un CVE. Un paquet malveillant est un élément publié dans le but de nuire, et non une faille dans un code légitime. Il ne génère aucun avertissement, aucun score, et généralement aucun identifiant. Un programme conçu pour détecter les vulnérabilités CVE est, par définition, aveugle à ce type de vulnérabilité.
- Privilégiez le contexte, et non l'identifiant. L'accessibilité, la disponibilité de l'exploit, l'EPSS et l'impact commercial classent une découverte, que le dossier CVE soit complet ou non.
La sécurité CVE consiste à suivre, prioriser et corriger les vulnérabilités à l'aide des identifiants CVE. standardIdentifiants attribués aux failles logicielles connues du public. Cela fonctionne car tout le monde utilise les mêmes noms. Le système est mis à rude épreuve car le volume a dépassé les capacités de l'infrastructure : 48 185 CVE ont été publiées en 2025, et depuis avril 2026, la base de données nationale sur les vulnérabilités ne les enrichit plus toutes.
Cet article explique ce que la sécurité CVE fait bien, où elle échoue actuellement, et sur quoi il faut se concentrer lorsqu'un identifiant CVE ou un score CVSS est tardif, manquant ou absent intentionnellement.
Premièrement : qu’est-ce que le CVE en cybersécurité ?
C'est une question clé : qu'est-ce que le CVE en cybersécurité ?
CVE signifie Common Vulnerabilities and Exposures (vulnérabilités et expositions courantes). Il s'agit d'une standardIdentifiant personnalisé attribué aux vulnérabilités logicielles connues. Plutôt qu'une base de données ou un score de risque en soi, un CVE attribue simplement à chaque vulnérabilité publique un identifiant unique, comme CVE-2025-XXXX. Cela permet un suivi cohérent entre les outils, les avis et les processus de correction.
Alors, qu'est-ce que la CVE en cybersécurité ? Il s'agit essentiellement d'une convention de nommage qui garantit que chaque équipe parle du même problème et utilise le même langage. C'est crucial pour coordonner les réponses entre la sécurité, le développement et les opérations. Pour en savoir plus, visitez notre glossaire.
Le rôle de la sécurité CVE dans DevSecOps
Dans DevSecOps, pipelineLes outils et les systèmes doivent collaborer pour identifier et corriger les vulnérabilités à mesure que le code passe du développement à la production. Quel est le ciment de cet écosystème ? Sécurité CVE :
- Scanners de vulnérabilité : détectent les failles et les associent aux identifiants CVE
- Systèmes de gestion des correctifs : ils utilisent les identifiants CVE pour automatiser la correction
- Plateformes de renseignement sur les menaces : celles-ci enrichissent les CVE avec des données d'exploitabilité, de gravité et d'activité
- Rapports de conformité : ils s'appuient sur le suivi de l'exposition à des CVE spécifiques
Sans identifiant partagé, ces outils ne pourraient pas communiquer efficacement. La sécurité CVE est donc non seulement utile, mais essentielle à l'intégration et à la livraison continues.
Une crise de gestion des vulnérabilités : les enjeux de la CVE
Le concept de CVE en cybersécurité est solide, mais sa mise en œuvre est de plus en plus fragile. La CSA l'a récemment souligné dans un article de blog intitulé A Crise de gestion des vulnérabilités : les enjeux de la CVE. Cette analyse révèle trois problèmes critiques :
- Retards et incohérences : Le programme CVE a du mal à attribuer rapidement des identifiants, en particulier pour vulnérabilités open source. Par conséquent, les équipes manquent souvent d’identifiants opportuns, ce qui ralentit le triage et l’application des correctifs.
- Couverture incomplète : De nombreuses vulnérabilités ne sont pas répertoriées dans la base de données CVE. Cela crée des failles de détection et expose les organisations à des risques non surveillés.
- Dépendance Fragilité : L'écosystème est devenu trop dépendant d'une seule source de vérité. Lorsque les missions CVE sont retardées ou indisponibles, l'ensemble de la gestion des vulnérabilités est impacté. pipeline est perturbé
Ces problèmes systémiques liés à la sécurité CVE mettent en lumière un point important : le besoin urgent de modernisation et d'approches alternatives. Comprendre ces limites permet aux équipes de sécurité d'éviter les angles morts et de développer des pratiques plus robustes. Regardez notre conférence sur YouTube !
Les défis de la CVE en cybersécurité
La complexité croissante du développement logiciel a dépassé les capacités du système CVE traditionnel. Plusieurs défis définissent désormais le paysage CVE en cybersécurité :
- Volume: Le programme CVE a été conçu pour un écosystème plus restreint. Il a publié 48 185 nouvelles vulnérabilités en 2025, soit une augmentation de 20.6 % par rapport aux 40 009 de 2024, et le nombre d'autorités de numérotation CVE a atteint 484 en janvier 2026. Cela représente environ 131 divulgations par jour. La couche de nommage a évolué, contrairement à la couche d'analyse.
- Lacunes contextuelles : De nombreux CVE manquent de données d'exploitabilité ou de configurations affectées, ce qui rend difficile la priorisation.
- Systèmes de notation obsolètes : Le CVSS, le cadre de notation lié à de nombreux CVE, ne reflète souvent pas le risque réel.
- Financement et gouvernance : En avril 2025, CISA a exécuté une option de contrat la nuit précédente MITRE L'accord a expiré après que MITRE a informé le conseil d'administration du CVE que le gouvernement n'avait pas l'intention de le renouveler. Le financement a depuis été renouvelé, et CISA décrit désormais le programme comme étant entièrement financé et en voie de modernisation. Les questions de gouvernance restent cependant en suspens : le conseil d’administration du CVE joue principalement un rôle consultatif, tandis que MITRE conserve le pouvoir de décision final.cisautorité décisionnelle et demandes d'accès au MITRE-CISUn contrat, ainsi qu'une demande d'accès à l'information, sont restés sans réponse. Cet épisode a également donné naissance à la CVE Foundation, une organisation à but non lucratif créée par des membres du conseil d'administration afin de s'affranchir de tout parrainage gouvernemental unique.
- L'enrichissement n'est plus universel. Le 15 avril 2026, le NIST a modifié le fonctionnement du NVD. Désormais, seuls les CVE répondant à des critères définis sont enrichis ; les autres sont listés mais classés comme prioritaires et ne sont pas enrichis immédiatement. Tous les enregistrements en attente dont la date de publication NVD était antérieure au 1er mars 2026 ont été déplacés vers la catégorie « Non planifié ». Cela a permis de reclasser environ 29 000 CVE. L’explication du NIST repose davantage sur des calculs que sur une politique : près de 42 000 CVE ont été enrichis en 2025, soit 45 % de plus que les années précédentes, et le nombre de soumissions est resté supérieur. Si votre priorisation pipeline Vous attendez un score NVD CVSS ; une part croissante des nouvelles CVE ne vous en attribuera jamais.
Tout cela nous envoie un message clair : la sécurité CVE seule ne suffit plus.
Toutes les menaces ne font pas l'objet d'un CVE.
La discussion autour des CVE part du principe que l'élément suivi est une faille dans un code écrit de bonne foi. Un paquet malveillant est différent. C'est un artefact conçu et publié pour nuire, et personne ne publie d'avis de sécurité à son sujet : il n'y a ni CVE, ni score CVSS, et généralement aucun identifiant. Il est actif pendant quelques minutes à quelques heures, puis supprimé.
La conséquence est préoccupante. La question « Ce logiciel possède-t-il une CVE ? » renvoie la même réponse, qu'il s'agisse d'un logiciel sûr ou d'un voleur d'identifiants publié il y a une heure. Un programme entièrement basé sur l'intégration des CVE, l'évaluation de leur gravité et les fenêtres de correctifs est structurellement aveugle à toute une catégorie d'attaques, qui est pourtant celle qui connaît la croissance la plus rapide.
La détection doit intervenir dès la publication et non lors de la divulgation. La solution d'alerte précoce aux logiciels malveillants de Xygeni analyse les nouveaux paquets publiés sur npm, PyPI, Maven et autres registres dès leur apparition, en utilisant l'analyse comportementale et la détection d'anomalies plutôt que d'attendre une signature.
Comment les équipes DevSecOps peuvent-elles renforcer les pratiques de sécurité CVE ?
Même avec ses limites, la CVE en cybersécurité reste la standardMais les équipes DevSecOps doivent aller plus loin. Voici cinq stratégies pour améliorer votre résilience :
- Diversifiez vos sources : Ne construisez pas de pipeline avec un point de défaillance unique. Outre NVD et MITRE, utilisez la base de données de conseils GitHub, OSV, la base de données de vulnérabilités de l'UE gérée par ENISA, et CISCatalogue KEV de A. Pour les organisations européennes soumises aux obligations de déclaration NIS2, DORA ou CRA, le recours à une source primaire non américaine relève de plus en plus d'une question de gouvernance plutôt que d'une préférence.
- Utiliser la notation contextuelle : Enrichissez les données CVE avec KEV (vulnérabilités connues exploitées) et EPSS (Système de notation de prédiction d'exploitation) pour mieux comprendre le risque
- Automatisez avec Precision: Créez une automatisation qui ne se contente pas d'ingérer les CVE, mais applique une logique basée sur l'utilisation, l'exposition et la criticité
- Former les équipes de développement : Les développeurs doivent savoir non seulement ce qu'est le CVE en matière de cybersécurité, mais également comment interpréter et agir sur les données CVE dans leurs flux de travail.
- Contribuer à l'ouverture Standards: Les organisations peuvent contribuer à améliorer la sécurité CVE en devenant des autorités de numérotation CVE (CNA) ou en contribuant à des bases de données ouvertes.
Lorem ipsum dolor sit amet, consectetur elip adipiscing elit. Ut elit tellus, luctus nca ullamcorper mattis, pulvinar dapibus leo.
L'avenir de CVE dans un monde DevSecOps
Les défis posés par la CVE en cybersécurité ne signifient pas que le système est obsolète. Ils signalent plutôt un besoin d'évolution. Les responsables de la sécurité et les praticiens DevSecOps doivent comprendre à la fois la puissance et les pièges de la sécurité CVE afin d'élaborer une stratégie à toute épreuve et pérenne.
Que ce soit par une automatisation plus intelligente, un contexte de menace plus riche ou la participation aux efforts communautaires, la voie à suivre repose sur la reconnaissance du fait que la CVE en cybersécurité n'est qu'un début. L'objectif réel est de construire des systèmes qui dépassent l'identification pour offrir une défense contextualisée en temps réel.
Comment Xygeni renforce la sécurité CVE
Xygéni ne présume pas que l'enregistrement CVE arrivera complet ou à temps.
- Priorisation qui ne dépend pas de l'enrichissement NVD. L'analyse d'accessibilité au niveau fonctionnel détermine si l'exécution dans votre application peut effectivement atteindre le code vulnérable, réduisant ainsi les faux positifs jusqu'à 70 %. La disponibilité de l'exploit, l'EPSS et le contexte métier sont également pris en compte en tant qu'étapes configurables dans un processus de priorisation pouvant comporter jusqu'à huit niveaux. Une vulnérabilité sans score CVSS NVD est tout de même classée.
- Couverture pour ce qui n'a pas de CVE. Le système d'alerte précoce aux logiciels malveillants détecte les paquets malveillants dès leur publication, avant même l'existence d'une signature ou d'un avertissement.
- Une seule file d'attente, incluant les outils que vous utilisez déjà. ASPM Ce système intègre les résultats des scanners tiers et leur applique le même tri, les mêmes explications et les mêmes mesures correctives qu'aux résultats natifs. Il ne s'agit pas de remplacer une pile logicielle pour obtenir une meilleure priorisation.
- Remédiation avec des conséquences visibles. Pour chaque dépendance vulnérable, Xygeni indique les vulnérabilités que la mise à jour corrige, celles qu'elle introduit et si le changement de version rend votre code incompatible, puis ouvre le pull request.
- Preuves justifiant la réglementation. SBOM et la sortie VDR dans SPDX et CycloneDX, les artefacts demandés par CRA, NIS2 et DORA.
Conclusion : pérennisez votre stratégie de vulnérabilité grâce à une protection CVE plus intelligente
La sécurité CVE restera au cœur du suivi des vulnérabilités et de la coordination entre les équipes, fournisseurs et outils de gestion des vulnérabilités. Cela ne fait aucun doute. Mais le système actuel est fragile, sujet aux déficits de financement, aux retards d'affectation et à un contexte incomplet. Reconnaître les limites de la CVE en cybersécurité est la première étape vers une gestion plus résiliente et plus intelligente des vulnérabilités.
En tant qu'expert en sécurité, vous devez aller au-delà de la simple définition de la CVE en cybersécurité. Vous devez évaluer la dépendance des outils, des processus et des personnes à cette approche, et comment faire évoluer ces systèmes. En diversifiant les sources de données, en enrichissant le contexte des vulnérabilités et en développant une automatisation qui tient compte des nuances, les équipes DevSecOps peuvent renforcer leur posture et mieux protéger ce qui, comme nous l'avons déjà dit, compte vraiment.
Qu'est-ce que la sécurité CVE ?
La sécurité CVE consiste à suivre, prioriser et corriger les vulnérabilités à l'aide des identifiants CVE. standardLes CVE (Current Vedars) sont des identifiants standardisés attribués aux failles logicielles connues du public. Un CVE n'est ni une base de données ni un score de risque. Il s'agit d'un nom commun permettant aux outils d'analyse, de gestion des correctifs, de veille sur les menaces et de reporting de conformité de faire référence à un même problème.
Pourquoi certaines CVE n'ont-elles pas de score CVSS ?
La base de données nationale sur les vulnérabilités (NVDB) n'enrichit plus systématiquement tous les enregistrements. Depuis avril 2026, le NIST n'ajoute de score de gravité et de détails sur le produit qu'aux CVE répondant à des critères définis ; les autres sont publiées, mais classées comme étant de priorité minimale. Environ 29 000 enregistrements en attente ont été reclassés comme non planifiés. L'absence de score signifie que l'enregistrement n'a pas été analysé, et non qu'il présente un faible risque.
Toutes les vulnérabilités reçoivent-elles un CVE ?
Non. De nombreuses failles open source ne sont jamais répertoriées, et une catégorie entière de menaces reste, de par sa conception, en dehors du système. Les paquets malveillants sont des éléments publiés dans le but de nuire, et non des erreurs dans du code légitime ; par conséquent, aucun avis de sécurité n'est publié à leur sujet. Ils ne possèdent généralement ni CVE, ni score, ni identifiant.
