GCVE

Un nouveau système global et décentralisé d’identifiants de vulnérabilités

Les CVE (Common Vulnerabilities and Exposures) constituent depuis des années la référence mondiale pour identifier de manière unique les failles de sécurité. Ce système centralisé, coordonné par le MITRE sous contrat gouvernemental américain, a permis d’harmoniser le suivi des vulnérabilités à l’échelle internationale.

Cependant, des limites apparaissent face à l’explosion du nombre de vulnérabilités et à la dépendance envers une seule entité de coordination. Récemment, des inquiétudes quant au financement et à la capacité du programme CVE ont stimulé l’émergence d’initiatives alternatives.

C’est dans ce contexte qu’est né GCVE.EU , le Global CVE Allocation System, un programme porté par le CIRCL (Computer Incident Response Center Luxembourg) – l’équipe CERT luxembourgeoise dirigée par Alexandre Dulaunoy – et soutenu par la communauté européenne de la cybersécurité.

Je vais vous présenter en détail ce qu’est GCVE, son origine et ses objectifs, expliquer son fonctionnement (notamment la logique des GCVE Numbering Authorities ou GNA), puis comparer ce système au CVE classique.

J’évoquerai également les acteurs impliqués et les bénéfices potentiels pour les équipes CSIRT/SOC/CERT, avant de conclure sur les perspectives d’adoption et les défis à venir.

Qu’est-ce que GCVE.eu, et pourquoi a-t-il été lancé ?

Le GCVE (Global CVE Allocation System) est un nouveau système décentralisé d’identification et de numérotation des vulnérabilités.

Lancé en 2025 par le CIRCL au Luxembourg, il vise à accroître la flexibilité, l’évolutivité et l’autonomie des organisations impliquées dans la gestion des vulnérabilités.

Autrement dit, GCVE introduit un modèle où plusieurs entités peuvent délivrer des identifiants de failles de manière indépendante, tout en restant compatibles avec le système CVE existant.

L’initiative est née à la fois d’un constat et d’une opportunité :

le constat que le système CVE actuel présente des goulets d’étranglement et des défis de coordination à grande échelle, et l’opportunité d’améliorer la résilience de l’écosystème suite aux incertitudes planant sur le programme CVE en 2024-2025.

Selon le CIRCL, de nombreux problèmes avaient été identifiés dans la corrélation des identifiants de vulnérabilités lors de l’exploitation de bases de données existantes. Pour remédier à ces lacunes, CIRCL a créé GCVE.eu comme un système d’allocation d’identifiants plus robuste, conçu pour garantir l’autonomie vis-à-vis des sources de vulnérabilités et améliorer la stabilité de la corrélation des identifiants.

L’objectif originel est donc de compléter le système CVE, en offrant un filet de sécurité et une alternative décentralisée au modèle centralisé actuel. GCVE.eu a vu le jour en parallèle d’autres efforts européens, notamment la base de données des vulnérabilités de l’ENISA (EUVD) développée dans le cadre de la directive NIS2.

Contrairement à l’EUVD qui se positionne comme une base de référence, GCVE propose un schéma d’identifiants mondial alternatif.

Le programme est opéré par le CIRCL et bénéficie de l’appui d’acteurs européens, avec une forte implication d’Alexandre Dulaunoy (responsable R&D au CIRCL) et une collaboration avec des organismes comme l’ENISA.

En résumé, GCVE.eu se veut une extension globale et communautaire du système CVE, capable d’allouer des identifiants de failles de manière distribuée.

Ses principes fondateurs sont la décentralisation (plusieurs autorités d’enregistrement plutôt qu’un seul centre), la compatibilité ascendante avec les CVE existants, et une gouvernance ouverte s’appuyant sur la communauté des CERT, CSIRT, chercheurs et industriels volontaires.

Fonctionnement du programme GCVE : GNAs, format d’identifiant et gouvernance

Le fonctionnement de GCVE repose sur la notion de GCVE Numbering Authorities (GNA), analogues aux CVE Numbering Authorities (CNA) du programme CVE, mais avec un rôle étendu et plus d’autonomie.

Une GNA est une entité approuvée qui reçoit le droit d’allouer elle-même des identifiants GCVE.

Concrètement, chaque GNA se voit attribuer un code numérique unique – appelé GNA ID – qui fera partie de chaque identifiant de vulnérabilité qu’elle émettra. À l’inverse du système CVE classique où les numéros sont délivrés de manière centralisée ou via des blocs préattribués, une GNA peut générer des identifiants sans demander de plage au centre et selon ses propres besoins et procédures.

Cette autonomie permet à chaque GNA de gérer son rythme d’allocation (par exemple un éditeur pourra numéroter immédiatement les failles qu’il découvre dans ses produits, un CERT national pourra attribuer des identifiants lors de la coordination de divulgations, etc.) en suivant ses propres politiques internes de divulgation ou de classification.

Format des identifiants GCVE

Les identifiants du GCVE adoptent un format standardisé à quatre segments :

GCVE-<GNA ID>-<ANNÉE>-<NUMÉRO UNIQUE>

GCVE est le préfixe explicitant qu’il s’agit d’un identifiant du Global CVE.

<GNA ID> est le numéro d’autorité qui indique quelle entité a émis l’identifiant.

<ANNÉE> correspond à l’année de divulgation ou d’enregistrement de la vulnérabilité.

<NUMÉRO UNIQUE> est la référence numérique propre à la vulnérabilité, choisie par la GNA, unique au sein de cette GNA pour l’année donnée.

Par exemple, un identifiant GCVE-1-2025-00001 désignera la vulnérabilité numéro 00001 enregistrée en 2025 par la GNA n°1 (qui est le CIRCL). De même, GCVE-5-2024-12345 correspondrait à la vulnérabilité n°12345 de l’année 2024, attribuée par l’entité portant l’ID 5.

Ce format garantit l’unicité globale tout en permettant à chaque autorité de gérer un espace de numérotation indépendant. Notons que le choix d’un identifiant numérique laisse une grande capacité (par exemple, 00001 pourrait être sur 5 digits ou plus), évitant les collisions entre GNAs puisque chacune opère sur sa plage.

Compatibilité avec les CVE existants

Un principe clé de GCVE est la compatibilité avec le système CVE classique. Plutôt que de créer un espace d’identifiants complètement disjoint, GCVE englobe les CVE déjà en circulation. Pour ce faire, l’ID GNA 0 est réservé aux identifiants CVE émis par le système traditionnel.

Autrement dit, toute faille disposant déjà d’un CVE peut être représentée en GCVE en ajoutant l’indicateur de GNA 0. Par exemple, la vulnérabilité CVE-2023-40224 se représente sous GCVE comme GCVE-0-2023-40224.

Ainsi, les outils ou bases de données compatibles GCVE peuvent accepter indifféremment un ID CVE classique ou son équivalent GCVE, ce qui facilite une adoption progressive sans rupture.

Cette correspondance ne fonctionne qu’en sens unique (de CVE vers GCVE) – un identifiant natif GCVE émis par une GNA autre que 0 n’a pas nécessairement de CVE équivalent si la vulnérabilité n’a pas été enregistrée dans la base MITRE.

Gouvernance et processus d’enregistrement

Si GCVE se veut décentralisé dans l’allocation des identifiants, il conserve une gouvernance communautaire minimale pour encadrer le réseau des GNAs. Le site GCVE.eu maintient un registre public listant l’ensemble des GNAs approuvées ainsi que leur identifiant numérique.

Chaque nouvelle GNA doit être validée pour éviter les abus et garantir que seules des organisations légitimes participent.

Les critères d’éligibilité incluent notamment le fait d’être déjà CNA du programme CVE, ou d’être un CERT/CSIRT reconnu (par FIRST, le réseau CSIRTs EU, TF-CSIRT), ou un fournisseur ayant un historique de divulgation de failles et un policy public en la matière.

Une organisation souhaitant devenir GNA soumet une demande (par e-mail) en fournissant des informations sur son identité (nom court, nom complet, éventuellement son identifiant CPE si éditeur logiciel) et les ressources associées (URL du site de divulgation, éventuelle API ou dumps de vulnérabilités publiés, etc.).

Une fois approuvée, l’organisation reçoit son GNA ID unique, qui sera utilisé dans tous les identifiants qu’elle attribue.

Le CIRCL (Luxembourg) a été la première entité à endosser le rôle de GNA, se voyant attribuer l’ID 1 (l’ID 0 étant réservé au programme CVE lui-même).

Depuis, plusieurs acteurs ont rejoint le programme en tant que GNAs. On compte par exemple l’ENISA pour la base EUVD (GNA ID 2), la plateforme commerciale VulDB (GNA ID 100), le groupe industriel Ericsson AB (ID 101), la société de conseil EACG (ID 102), la société de cybersécurité allemande SCHUTZWERK GmbH (ID 103) ou encore le DFN-CERT Services GmbH en Allemagne (ID 680), entre autres, d’après le registre officiel.

Cette diversité d’acteurs – autorités publiques, entreprises privées, CERT nationaux, projets communautaires – illustre la gouvernance distribuée de GCVE. Chaque GNA reste maître de sa politique (par exemple, un éditeur pourra n’assigner des GCVE qu’aux vulnérabilités qui ne seraient pas couvertes par le CVE, ou un CERT pourra réserver des GCVE pour des vulnérabilités locales ou en attente d’un CVE).

Néanmoins, toutes s’alignent sur le format commun et partagent leurs données de façon ouverte, ce qui assure une interopérabilité au niveau global.

GCVE vs CVE : comparaison des modèles centralisé et décentralisé

Le déploiement de GCVE.eu amène naturellement à le comparer au système CVE classique. Bien que les deux visent le même objectif – fournir des identifiants uniques de vulnérabilités – leurs modèles d’organisation diffèrent sensiblement.

Allocation des identifiants : centralisée vs. distribuée

Dans le système CVE traditionnel, l’attribution d’un identifiant passe par un réseau de CNA coordonné de manière centralisée. Les CNA (éditeurs, CERT, projets open source, etc. autorisés par le CVE Program) reçoivent des blocs de numéros ou sollicitent le MITRE pour chaque nouvelle vulnérabilité à numéroter.

Le schéma CVE est uniforme : CVE-année-numéro (ex : CVE-2025-12345), avec un compteur séquentiel global pour chaque année.

Cela implique qu’aucune entité ne peut assigner un CVE de son propre chef sans passer par le cadre du programme officiel.

Ce modèle a l’avantage d’une forte cohérence – un seul ensemble de règles, un seul dépositaire de la liste – mais aussi des inconvénients de taille : dépendance à une autorité unique, procédures parfois lentes, et impossibilité pour des acteurs non membres du programme d’obtenir rapidement un identifiant officiel.

En outre, en cas de saturation du système (afflux massif de demandes) ou de problème institutionnel (ex. réduction de budget), le flux d’émission peut être perturbé, comme cela a failli se produire début 2025 lorsque le financement du CVE Program a été menacé.

À l’opposé, le modèle GCVE est décentralisé. Chaque GNA peut émettre des identifiants de manière autonome, sans nécessité de synchronisation globale ou de demande préalable de numéro.

Techniquement, l’ajout du champ GNA ID dans l’identifiant permet à différentes autorités de travailler en parallèle sans collision : deux vulnérabilités pourraient avoir le même numéro de séquence, mais attribués par des GNA différentes, elles auront des GCVE distincts grâce au préfixe d’autorité.

Par exemple, GCVE-1-2025-0001 et GCVE-5-2025-0001 seraient deux failles différentes gérées respectivement par la GNA 1 et la GNA 5. Aucun arbitrage central n’est requis pour éviter le doublonnage, ce qui donne au système une grande scalabilité – de nouvelles autorités peuvent rejoindre et délivrer potentiellement des milliers d’identifiants sans solliciter un coordinateur central.

Comme le résume l’équipe CIRCL, GCVE ajoute à l’approche CVE classique une extension permettant à des autorités indépendantes de délivrer des identifiants uniques sans devoir se coordonner entre elles, ce qui n’était pas possible avec l’allocation séquentielle rigide du système CVE original. Cette souplesse est conçue pour améliorer la flexibilité du suivi des vulnérabilités et éviter les goulots d’étranglement liés à la centralisation.

Gouvernance et communauté

Le programme CVE est géré par un comité international (CVE Board) mais reste historiquement sous l’égide d’une entité américaine (MITRE, financé par l’agence CISA). Des efforts sont en cours pour le rendre plus indépendant (création d’une fondation CVE) et impliquer davantage d’acteurs internationaux, mais la structure reste hiérarchique : un ensemble de règles uniformes, un organe de gouvernance central, et une délégation de numérotations via les CNA homologuées.

Cette homogénéité a des avantages : définition claire de ce qui constitue une vulnérabilité admissible, contrôle de la qualité des entrées, et un langage commun partagé par tous les acteurs de la défense cyber.

En effet, grâce aux CVE, tout le monde parle le même langage des vulnérabilités. De son côté, GCVE propose une gouvernance plus communautaire et fédérée. Il n’y a pas de « siège » unique qui décide si une vulnérabilité mérite un ID : chaque GNA applique ses propres critères et politiques.

Par exemple, un CERT national pourrait numéroter des failles locales ou sectorielles qui n’entreraient pas dans le scope du CVE (par manque d’impact global ou de support d’un CNA) – ce qui leur offre un moyen de suivi plus formel de ces failles.

Un fournisseur pourrait aussi décider d’assigner un GCVE immédiatement à une vulnérabilité en attendant qu’un CVE officiel soit éventuellement accordé. La contrepartie de cette liberté est le risque de disparité dans l’application des critères : ce qui est considéré comme une vulnérabilité par l’une ou l’autre GNA pourrait différer, et les informations fournies pourraient être inégales.

En somme, l’uniformité cède la place à la diversité des pratiques. Certains experts avertissent que permettre à chaque entité d’avoir ses propres règles de publication pourrait engendrer de la confusion, voire un certain chaos sémantique, si l’harmonisation n’est pas suffisante.

Par analogie, on craint une forme de « balkanisation » du suivi des failles, où l’on perdrait le référentiel commun acquis avec les CVE.

C’est un point d’attention majeur : la communauté devra veiller à conserver une interopérabilité et des standards de qualité, peut-être via des bonnes pratiques partagées ou une coordination légère entre GNAs.

Avantages comparés et limites de chaque approche

Avantages du modèle CVE classique : Il a pour lui son ancienneté et sa reconnaissance universelle. Les processus et outils de sécurité (scanners, SIEM, bases de connaissances) sont tous calibrés pour les CVE.

La base CVE/NVD comporte des descriptions normalisées, des scores CVSS, etc., qui facilitent l’évaluation du risque. La gouvernance centralisée assure une certaine cohérence et évite les problèmes de doublons ou d’identifiants inconsistants – un même bug ne devrait idéalement avoir qu’un CVE.

Le programme CVE s’appuie sur une communauté de volontaires et de spécialistes qui depuis plus de 20 ans améliorent le système.

Toutefois, cette centralisation engendre des délais (le temps qu’un CNA attribue ou qu’un CVE soit publié dans la NVD) et une dépendance : si le système flanche (p. ex. retard de traitement, gel administratif), les utilisateurs finaux n’ont que peu de recours.

De plus, le scope du CVE est parfois restreint par sa définition officielle de ce qui constitue une vulnérabilité, ce qui peut exclure certaines failles (par exemple dans des configurations spécifiques, ou des vulnérabilités moins impactantes mais néanmoins utiles à suivre localement).

Avantages du modèle GCVE

Il offre une réactivité accrue et un contrôle local. Pour une équipe SOC/CSIRT, pouvoir elle-même allouer un identifiant à une nouvelle vulnérabilité signifie ne pas attendre qu’un acteur tiers le fasse.

Cela peut accélérer la communication interne et la gestion des correctifs, surtout en cas de vulnérabilités zero-day ou actives.

La décentralisation élimine le point de défaillance unique : même si une autorité est temporairement indisponible ou débordée, les autres continuent de fonctionner.

Le système est par nature scalable : chaque nouvelle GNA ajoute de la capacité de traitement sans alourdir une instance centrale

GCVE apporte aussi de la souplesse en permettant à divers types d’organisations (au-delà des seuls éditeurs et grandes institutions) de participer.

Par exemple, une petite équipe de recherche ou une entreprise non éligible comme CNA pourrait devenir GNA si elle remplit les critères, là où intégrer le programme CVE officiel est plus complexe.

Enfin, la compatibilité ascendante garantit que GCVE ne réinvente pas tout : il intègre les CVE existants (via GNA 0), ce qui permet de construire des outils capables de gérer à la fois CVE et GCVE de manière transparente.

Cela n’en fait pas nécessairement un système concurrent exclusif, mais plutôt un complément du système actuel, offrant une alternative lorsque le classique fait défaut.

Limites du modèle GCVE

Le revers de la médaille de la distribution est le risque de fragmentation. Si deux GNAs numérotent sans se coordonner des vulnérabilités qui s’avèreraient identiques (par exemple une même faille découverte indépendamment dans deux pays), on pourrait se retrouver avec deux identifiants GCVE distincts pour un seul problème de sécurité.

Certes, ce problème existe aussi (quoique rarement) dans le système CVE quand deux CNA émettent un CVE doublon par erreur, mais il est alors résolu en fusionnant sous un seul CVE et en rejetant l’autre.

Dans un monde très distribué, la résolution de doublons pourrait s’avérer plus délicate s’il n’existe pas de canal de coordination entre GNAs.

De plus, l’adoption de GCVE n’est pas encore générale : pour le moment c’est une initiative émergente, principalement soutenue en Europe. Il faudra du temps pour que les outils de sécurité, les équipes et les processus intègrent nativement la prise en charge des identifiants GCVE.

La réussite de GCVE dépendra de la capacité de ses promoteurs à convaincre de sa valeur ajoutée sans générer de confusion. Il devra prouver qu’il peut coexister harmonieusement avec le système CVE, voire combler des lacunes sans introduire de désordre. En résumé, CVE et GCVE ne s’opposent pas nécessairement, mais reflètent deux approches : l’une centralisée, éprouvée mais possiblement rigide ; l’autre décentralisée, innovante et potentiellement plus agile, mais qui doit faire ses preuves en termes de coordination globale.

Il est probable qu’à court terme les deux systèmes cohabiteront avec des usages complémentaires : GCVE servant de relais pour certaines communautés ou en cas de défaillance du flux CVE, tout en continuant de référencer les CVE officiels pour garder un langage commun.

Acteurs impliqués et gouvernance communautaire

Le programme GCVE.eu s’inscrit dans un écosystème d’acteurs variés du monde de la sécurité.

Au premier plan se trouve le CIRCL (Luxembourg), qui est à l’initiative du projet. CIRCL, en tant que CERT pour le secteur privé et les communes luxembourgeoises, s’est fait connaître par ses contributions aux outils open source de threat intelligence (MISP, etc.) et son expertise en gestion de vulnérabilités.

Alexandre Dulaunoy, responsable de la R&D au CIRCL, est l’une des figures de proue de GCVE : il a largement communiqué sur la nécessité d’un système d’identifiants plus flexible et a piloté le développement de GCVE en s’appuyant sur les travaux existants du CIRCL en matière de collecte de vulnérabilités. Dulaunoy et son équipe entretiennent également le projet vulnerability-lookup (outil open-source permettant de consulter de multiples bases de vulnérabilités) qui sert de socle technique au GCVE

En effet, GCVE s’intègre directement dans cette plateforme et d’autres outils : toute application pouvant gérer les CVE peut en principe accepter les GCVE (notamment via le préfixe GCVE-0 pour les CVE classiques)

Le support du format complet (avec attribution GNA) est déjà implémenté dans vulnerability-lookup, ce qui montre l’engagement du CIRCL à fournir un écosystème opérationnel autour de GCVE.

Au-delà du CIRCL, d’autres GNAs ont rejoint l’initiative et façonnent la gouvernance communautaire du programme.

L’ENISA, l’agence européenne chargée de la cybersécurité, exploite la base EUVD qui a obtenu l’ID GNA 2 – traduisant la synergie entre GCVE et les efforts européens pour un partage d’informations sur les vulnérabilités

Cette collaboration vise à ce que les vulnérabilités suivies par l’EUVD puissent être identifiées de façon pérenne même en dehors du système CVE, tout en restant compatibles.

Dans le secteur privé, la base de données VulDB.com (très utilisée par les chercheurs et analystes) a adhéré en tant que GNA, ce qui lui permet d’émettre des GCVE pour des vulnérabilités issues de sa plateforme.

Des entreprises comme Ericsson ou SCHUTZWERK participent également, ce qui suggère que des acteurs industriels voient un intérêt à s’impliquer tôt. Enfin, des CERT nationaux ou sectoriels (tel que DFN-CERT en Allemagne) sont de la partie, reflétant l’intérêt de la communauté défense pour ce modèle.

La gouvernance de GCVE.eu est donc à la fois centralisée sur la coordination technique (le registre, assuré par CIRCL) et décentralisée dans son animation (chaque GNA est souveraine de ses allocations).

Aucune décision unilatérale d’une entité ne peut bloquer le système dans son ensemble, ce qui renforce sa résilience. Néanmoins, on peut imaginer qu’une certaine coordination informelle s’établit entre GNAs pionnières, afin de partager les retours d’expérience et d’affiner ensemble les bonnes pratiques.

Par exemple, éviter qu’une vulnérabilité soit numérotée deux fois par inadvertance pourrait impliquer de consulter le registre (ou un service de lookup global) avant d’émettre un nouvel ID – de telles pratiques devront être encouragées au sein de la communauté GCVE.

L’implication d’organismes publics (ENISA, CERTs) aux côtés d’initiatives privées garantit a priori un équilibre dans les orientations du programme, loin de tout contrôle exclusif par un état ou une entreprise. Cette approche communautaire et multi-acteurs rappelle celle de certains standards de l’internet ou de la sécurité où la gouvernance distribuée a permis une adoption plus large en donnant à chacun une voix au chapitre.

Bénéfices potentiels pour les CSIRT, SOC et CERT

Pour les responsables de CERT, CSIRT ou centres opérationnels de sécurité (SOC), l’initiative GCVE.eu présente plusieurs avantages notables en matière de gestion des vulnérabilités et de réactivité face aux menaces :

Réactivité et autonomie locale : Un CSIRT ou CERT qui devient GNA peut attribuer immédiatement un identifiant à une vulnérabilité critique découverte au sein de son périmètre, sans dépendre d’une autorité externe.

Cela peut accélérer la communication avec les parties prenantes : disposer d’un identifiant unique facilite les échanges dans les rapports d’incident, les bulletins d’alerte ou les tickets de remédiation. En cas de crise (exploit actif, vulnérabilité « 0day »), ce gain de temps et de contrôle peut améliorer la capacité de réaction.

Même sans être GNA, un CERT/SOC peut décider d’utiliser les identifiants GCVE (notamment via GCVE-0-* pour les CVE officiels) dans ses outils internes, profitant ainsi de la compatibilité offerte pour unifier le suivi des vulnérabilités connues et en cours d’analyse.

Maîtrise du processus de divulgation : Pour un CERT, la possibilité d’assigner un GCVE permet de structurer la gestion d’une vulnérabilité dès les premières étapes, y compris si la vulnérabilité n’a pas encore de CVE officiel.

Par exemple, lors du traitement d’un rapport de vulnérabilité d’un chercheur, un CERT national peut émettre un GCVE provisoire pour tracer l’affaire, puis travailler avec l’éditeur concerné ou un CNA afin d’obtenir un CVE plus tard. Durant tout ce laps de temps, l’identifiant GCVE sert de référence stable.

Cette approche offre un contrôle local renforcé sur le cycle de vie de la vulnérabilité, tout en restant compatible avec une éventuelle normalisation ultérieure (grâce au mapping CVE/GNA 0).

Interopérabilité et intégration outillée : GCVE étant conçu pour être interopérable avec les CVE, les équipes SOC/CSIRT n’auront pas à refondre entièrement leurs processus.

Les plateformes SIEM, les bases de connaissances vulnérabilités ou les scanners pourront être étendus pour reconnaître le format GCVE.

En interne, un SOC peut déjà intégrer le support des GCVE via des outils existants : par exemple, l’outil vulnerability-lookup permet de consulter des failles via leur identifiant CVE ou GCVE de manière unifiée.

Pour les CERT/CSIRT européens, l’alignement de GCVE avec l’EUVD d’ENISA signifie qu’ils bénéficieront d’une meilleure coordination des informations : une vulnérabilité publiée via l’EUVD aura un identifiant (EUVD) qui correspondra à un GCVE dans le registre global, facilitant le cross référencement entre sources européennes et internationales.

In fine, cela renforce la capacité d’agrégation des renseignements sur les failles, car un identifiant GCVE pourra pointer vers des informations multiples (avis de différents CERT, analyses de différentes entreprises) là où un CVE tardif aurait pu manquer temporairement.

Réduction de la dépendance unique : En adoptant et en surveillant GCVE, les équipes de sécurité se prémunissent contre un éventuel affaiblissement du flux CVE.

Par exemple, si le programme CVE connaît des retards importants ou si certaines vulnérabilités sont volontairement non publiées (pour des raisons stratégiques, légales, etc.), il y a plus de chances que la communauté GCVE comble ce vide par un identifiant alternatif. Pour un SOC, suivre parallèlement les CVE et les GCVE assure qu’aucune faille pertinente ne passe sous le radar faute d’identifiant.

Cela peut être vu comme une forme de redondance bénéfique dans le système global de veille sur les vulnérabilités.

En somme, pour les CERT/SOC/CSIRT, GCVE offre un niveau de contrôle supplémentaire et une flexibilité qui complète le dispositif existant.

Il ne s’agit pas de remplacer immédiatement les CVE dans tous les usages, mais d’ajouter un outil à la panoplie pour améliorer la rapidité d’identification et l’exhaustivité du suivi des failles.

A mon sens et à terme, si l’initiative gagne en traction, ces équipes auront l’avantage d’être montées en compétence dessus dès le début. Suivre de près GCVE dès maintenant, c’est anticiper une possible évolution des pratiques de gestion des vulnérabilités, et potentiellement influencer son développement en y participant (par exemple en candidatant comme GNA ou en contribuant aux discussions de la communauté).

Ma conclusion sur ce programme

Le lancement de GCVE.eu marque une étape importante dans l’évolution de la gestion des vulnérabilités. Face à un modèle CVE centralisé qui a montré ses forces mais aussi ses limites, GCVE propose une vision alternative :

• décentralisée, communautaire et résiliente,
• sans rupture brutale avec l’existant grâce à la compatibilité ascendante.

Pour les professionnels de la sécurité – et en particulier les responsables de CERT, CSIRT et SOC – cette initiative ouvre de nouvelles perspectives d’organisation du suivi des failles. Dans un futur proche, il est probable que CVE et GCVE cohabitent.

Le système CVE, fort de son historique et soutenu par une fondation en projet, va continuer d’évoluer pour rester la référence principale du domaine.

Parallèlement, GCVE va chercher à faire ses preuves : son adoption restera sans doute progressive et volontaire.

On peut imaginer qu’au sein de la communauté européenne, encouragée par les instances comme l’ENISA et le réseau des CSIRTs, l’usage de GCVE se diffuse pour gagner en autonomie stratégique vis-à-vis des dépendances externes.

Les cas d’usage complémentaires vont se préciser : GCVE pourrait être privilégié pour documenter des vulnérabilités locales, sectorielles ou n’entrant pas dans le périmètre CVE, tandis que les CVE continueraient de couvrir le socle commun des failles largement reconnues. Néanmoins, des défis subsistent.

Le principal sera d’éviter une fragmentation nuisible : il faudra assurer une coordination suffisante entre les différents systèmes d’identification (CVE, GCVE, éventuellement d’autres comme l’EUVD ou des bases nationales) pour que la communauté de défense ne se perde pas dans de multiples référentiels concurrents.

La réussite de GCVE dépendra de sa capacité à fédérer une masse critique d’acteurs sans heurter l’écosystème existant. Un équilibre délicat est à trouver entre indépendance et harmonisation. Par ailleurs, la charge reposera sur chaque GNA de fournir des informations de qualité sur les vulnérabilités qu’elle numérote, faute de quoi un identifiant nu sans données exploitables n’apportera pas grand-chose.

L’initiative devra également gagner la confiance au-delà de l’Europe : idéalement, voir des acteurs d’autres régions rejoindre GCVE permettrait de réellement concrétiser le “Global” CVE et d’éviter une dichotomie EU/USA.

et pour finir, GCVE.eu constitue une réponse innovante et pragmatique aux enjeux contemporains de la gestion des vulnérabilités. Sans prétendre remplacer du jour au lendemain le système en place, il offre une voie alternative qui renforce la robustesse globale du cyber-éco-système en multipliant les sources d’identifiants tout en gardant une cohérence d’ensemble.

Je recommande fortement à tous les responsables CERT, SOC et CSIRT à suivre avec intérêt de près cette initiative : elle pourrait influencer les pratiques de suivi des failles dans les années à venir, et présenter des opportunités pour gagner en rapidité et en souveraineté dans le traitement des vulnérabilités.

Une adoption nuancée, progressive et éclairée de GCVE – en complément des CVE – pourra offrir le meilleur des deux mondes : la fiabilité d’un standard éprouvé et la souplesse d’une innovation communautaire.

En restant informées et impliquées, les équipes de défense pourront tirer parti des avantages de GCVE tout en contribuant à orienter positivement son développement au service de la sécurité de tous.

« Je tiens à remercier le CIRCL pour cette initiative essentielle. Je m’engage à la soutenir activement. »

J’espère que cet article vous aura donné envie de suivre de près cette initiative innovante autour de la gestion décentralisée des vulnérabilités, et de réfléchir à son potentiel pour renforcer nos pratiques en matière de cybersécurité sans dépendre d’un système centralisé.

Sources utilisées pour cet article :

1. GCVE – Global CVE Allocation System – Site Officiel 🔗 https://gcve.eu/about/ 🔗 https://gcve.eu/faq/ 🔗 https://gcve.eu/register/
2. CIRCL – Computer Incident Response Center Luxembourg 🔗 https://www.circl.lu/services/gcve/
3. Statement from Matt Hartman on the CVE Program – CISA 🔗 https://www.cisa.gov/news-events/news/statement-matt-hartman-cve-program
4. CVE Foundation – News & Mission Statement 🔗 https://www.thecvefoundation.org/news
5. ReversingLabs Blog – Changes to CVE program are a call to action on your AppSec strategy 🔗 https://www.securityweek.com/changes-to-cve-program-are-a-call-to-action-on-your-appsec-strategy/
6. Heise Online – After the impending CVE blackout: EU vulnerability database goes live 🔗 https://www.heise.de/news/After-the-impending-CVE-blackout-EU-vulnerability-database-goes-live-9624027.html
7. The Register – The splintering of a standard bug tracking system has begun 🔗 https://www.theregister.com/2025/04/18/cve_program_changes_analysis/
8. Sophos News – Moving CVEs past one-nation control 🔗 https://news.sophos.com/en-us/2025/04/17/moving-cves-past-one-nation-control/
9. GCVE Register of GNAs – Liste des GCVE Numbering Authorities 🔗 https://gcve.eu/register/
10. vulnerability-lookup – outil open-source de lookup vulnérabilités (CIRCL) 🔗 https://github.com/circl/vulnerability-lookup