GCVE-BCP-02 : la divulgation coordonnée à l’heure du CRA

Pendant plus de vingt ans, l’identification publique des vulnérabilités a reposé pour l’essentiel sur le programme CVE (1), administré par l’organisation américaine MITRE et financé par l’agence américaine CISA (2). Depuis 2024, l’Union européenne et la communauté européenne de la réponse aux incidents construisent un cadre propre, selon deux axes distincts : un axe réglementaire et institutionnel, porté par le législateur européen et par son agence de cybersécurité, et un axe communautaire, porté par un centre de réponse aux incidents national, le CIRCL (3) luxembourgeois. Le guide étudié ici se situe à la jonction de ces deux axes.

L’axe réglementaire : de la directive de 2022 au règlement sur la cyberrésilience

La directive (UE) 2022/2555, dite NIS2 (4), consacre son article 12 à la divulgation coordonnée des vulnérabilités, abrégée CVD (5). Chaque État membre y désigne l’un de ses CSIRT (6) comme coordinateur, chargé de servir d’intermédiaire de confiance entre la personne qui signale une vulnérabilité et le fabricant ou le fournisseur concerné. Le même article confie à l’ENISA (7) le développement et la maintenance d’une base européenne des vulnérabilités [1]. La directive devait être transposée au plus tard le 17 octobre 2024.

Le règlement (UE) 2024/2847 sur la cyberrésilience, abrégé CRA (8), du 23 octobre 2024, prolonge ce cadre du côté des produits comportant des éléments numériques. Il impose aux fabricants, entre autres exigences, de traiter les vulnérabilités de leurs produits pendant la période de support, de fournir des mises à jour de sécurité et de disposer d’une politique de divulgation coordonnée [2, 3]. Son article 14 crée une obligation de notification des vulnérabilités activement exploitées et des incidents graves, applicable depuis le 11 septembre 2026, date d’ouverture par l’ENISA de la plateforme unique de notification, la SRP (9). Les autres exigences essentielles du règlement s’appliquent à compter du 11 décembre 2027 [4].

L’axe institutionnel : l’ENISA dans le programme CVE et la base européenne

L’ENISA est devenue CNA (10) du programme CVE en janvier 2024, ce qui lui permet d’attribuer des CVE aux vulnérabilités signalées aux CSIRT européens ou découvertes par eux. Le 20 novembre 2025, elle a été désignée Root du programme, c’est à dire point de contact central pour les autorités nationales et européennes et pour les membres du réseau des CSIRT de l’Union [5]. En août 2026, elle comptait vingt CNA sous sa responsabilité, dont douze recrutées directement et huit transférées depuis la Root de MITRE [6].

La base européenne des vulnérabilités prévue par la directive NIS2, l’EUVD (11), a été ouverte officiellement le 13 mai 2025, après une phase bêta. Elle agrège des informations issues des CSIRT, des éditeurs et de bases existantes, dont le catalogue KEV (12) de la CISA et le programme CVE, et présente trois tableaux de bord : vulnérabilités critiques, vulnérabilités exploitées et vulnérabilités coordonnées par les CSIRT européens. Chaque entrée porte un identifiant EUVD, accompagné de la CVE et, le cas échéant, d’autres identifiants [7]. L’EUVD s’appuie sur le logiciel vulnerability-lookup, développé par le CIRCL [8].

L’axe communautaire : un système d’identifiants décentralisé

En avril 2025, le contrat qui finance le programme CVE a failli ne pas être reconduit, avant une prolongation de dernière minute par la CISA [8]. Le 16 avril 2025, le CIRCL a annoncé le système GCVE (13), Global CVE Allocation System, une approche décentralisée de l’attribution des identifiants de vulnérabilités [9]. Des autorités de numérotation, les GNA (14), attribuent elles-mêmes leurs identifiants selon le format GCVE-<GNA-ID>-<ANNÉE>-<ID-UNIQUE>, sans demander de blocs à une autorité centrale. L’identifiant de GNA 0 est réservé aux CVE, si bien que la CVE-2023-40224 se lit aussi GCVE-0-2023-40224 ; le CIRCL est la GNA 1 [10]. L’initiative se présente comme un complément au programme CVE et non comme son remplaçant [10, 8].

Le dispositif s’est étoffé en 2026 : ouverture en janvier de la base publique db.gcve.eu, qui agrège plus de vingt-cinq sources [11], et inscription de l’EUVD au registre des GNA sous l’identifiant GNA 2, le 31 janvier 2026 [12]. Les règles communes de l’initiative sont publiées sous forme de BCP (15), documents de bonnes pratiques développés en revue publique, descriptifs plutôt que prescriptifs, dont l’adoption est recommandée sans être obligatoire [13]. GCVE-BCP-02 est le guide de traitement et de divulgation des vulnérabilités de ce corpus.

Fig. 1. Chronologie des initiatives européennes de gestion des vulnérabilités, établie à partir des textes de la directive NIS2 et du règlement CRA, des publications de l’ENISA, du registre GCVE et du guide GCVE-BCP-02.

Ces dispositifs produisent des identifiants, des bases de données et des canaux de notification. Ils laissent à chaque éditeur, fabricant ou mainteneur la question opérationnelle : comment recevoir un signalement, l’évaluer, corriger, coordonner la publication et, désormais, notifier les autorités dans les délais. C’est le terrain sur lequel se place GCVE-BCP-02.

Le document étudié est la version 2.0 de GCVE-BCP-02, Practical Guide to Vulnerability Handling and Disclosure, au statut publié, datée du 28 octobre 2026 et signée par le groupe de travail GCVE [3]. Il est distribué sous licence Creative Commons CC-BY-4.0 et compte une cinquantaine de pages. Sa coordination est assurée par deux membres du CIRCL ; les remerciements citent sept contributeurs nommés et la communauté des CSIRT et des PSIRT (16).

La version précédente, 1.9, datée du 15 octobre 2026, avait introduit huit diagrammes de processus, des recommandations sur l’inventaire des composants et la livraison des mises à jour, ainsi qu’une distinction entre vulnérabilités exploitées et vulnérabilités jugées exploitables [14]. La version 2.0 ajoute une annexe B consacrée à la divulgation coordonnée multipartite dans les écosystèmes open source, que ne mentionnait pas l’annonce de la version 1.9. À la date de consultation, l’index public des BCP affichait encore la version 1.9 [13].

L’analyse repose sur une lecture intégrale du document. Les dates et délais réglementaires qu’il cite ont été recoupés avec le texte du règlement CRA et avec la publication de l’ENISA annonçant l’ouverture de la SRP. Le positionnement du guide par rapport aux normes internationales s’appuie sur les références de ces normes et sur la prépublication consacrée à l’architecture de GCVE par le coordinateur de l’initiative [11].

Le corps du guide suit le cycle de vie d’une vulnérabilité en dix sections. Il s’ouvre sur une vue d’ensemble qui relie les étapes en boucle, de la préparation au retour d’expérience, et précise que la communication se poursuit pendant tout le traitement, que l’investigation, la remédiation et la divulgation peuvent se chevaucher, et que la notification au titre du CRA se déroule en parallèle lorsqu’elle s’applique. Chaque étape se termine par un diagramme de synthèse.

Le guide pose quatre définitions : la vulnérabilité, le rapport de vulnérabilité, la divulgation coordonnée et l’avis de sécurité. Deux d’entre elles portent une position de fond. La définition de la divulgation coordonnée admet qu’une publication intervienne avant la disponibilité d’un correctif, lorsque l’exploitation est en cours ou que les utilisateurs doivent se protéger. Celle de l’avis de sécurité exige, en l’absence de correctif, de le dire et d’indiquer comment réduire l’exposition.

Fig. 2. Structure de GCVE-BCP-02 version 2.0, d’après la table des matières et le contenu du document.

La section des rôles mêle des rôles à proprement parler et des rubriques de pratique : l’interaction entre rapporteur et éditeur et le développement sécurisé y figurent au même niveau que le PSIRT ou les coordinateurs. Le rôle de coordinateur est illustré par un CERT (18) ou un intermédiaire spécialisé, qui synchronise les calendriers de correction entre plusieurs éditeurs et peut publier un avis conjoint.

Préparer avant le premier rapport

Le guide fait de la préparation une condition du traitement. Il recommande une politique de divulgation publique, par exemple sur un site web ou dans un fichier SECURITY.md, indiquant le canal de signalement, les informations attendues, les engagements envers les chercheurs et, le cas échéant, une clause de safe harbour, c’est à dire l’engagement de ne pas poursuivre les recherches menées de bonne foi. Le canal combine une adresse dédiée et une clé publique PGP (19), ou un formulaire chiffré ; les plateformes de suivi publiques ne doivent pas servir à signaler une vulnérabilité, au profit de leur fonction de signalement privé lorsqu’elle existe.

Une équipe de réponse est désignée, avec une adresse partagée, un suppléant et une autorité identifiée pour approuver une publication urgente. Pour une petite structure, ces rôles peuvent être cumulés, l’essentiel étant que quelqu’un porte l’action suivante. Le processus interne fixe des critères de tri, le CVSS (20) étant cité comme outil de classement, et des délais cibles : accusé de réception sous deux jours ouvrés et plan de résolution sous une semaine, à titre d’exemple. Les cas sont suivis dans un outil contrôlé et auditable.

La version 2.0 insiste sur la connaissance de ce qui est livré : une liste des composants par version supportée, y compris les bibliothèques tierces, le code copié et les dépendances transitives, idéalement sous forme de SBOM (21) lisible par machine, aux formats SPDX (22) ou CycloneDX. Les lacunes de l’inventaire doivent être signalées plutôt que tenues pour inexistantes. Le guide y ajoute la tenue des contacts des mainteneurs de composants et des acteurs aval, la surveillance des dépendances qui perdent leur support, un programme de vérifications de sécurité propre, un canal de mise à jour préparé avant l’urgence, des exercices sur table et des moyens alloués par la direction.

Recevoir, trier et vérifier

Chaque rapport est journalisé avec un propriétaire de cas, une prochaine action et une date de mise à jour ; les éléments non publics restent dans un espace restreint. L’accusé de réception est attendu idéalement sous 24 à 48 heures. Un rapport utile doit être accepté même s’il arrive par le mauvais canal, sans chiffrement ou hors du modèle prévu, un canal plus sûr étant proposé pour la suite.

Le tri distingue la gravité technique du risque réel : le code vulnérable est-il atteignable, exposé à des entrées non fiables, protégé par une mesure efficace ? La preuve d’exploitation est prise en compte avec le score. Deux principes encadrent la clôture d’un cas : l’absence d’exploit public ne démontre pas qu’un produit n’est pas affecté, et un produit « non affecté » doit être distingué d’un produit pour lequel la vulnérabilité n’a « pas encore été reproduite ». Avant clôture, le guide demande de consigner ce qui a été vérifié, les hypothèses retenues et ce qui justifierait une réouverture.

Une vulnérabilité dans une bibliothèque livrée avec le produit reste à évaluer pour ce produit : contacter le mainteneur amont ne dispense ni du suivi des versions affectées, ni de l’intégration d’un correctif, ni de l’information des utilisateurs. Le guide recommande enfin une veille sur les avis amont et sur les sources de vulnérabilités, dont les flux GCVE et l’EUVD, avec une vérification d’applicabilité plutôt qu’une correspondance automatique de noms et de versions.

Investiguer, corriger, livrer

L’investigation porte sur la cause racine, les composants similaires et les autres versions. Le plan de correction identifie le porteur, les branches supportées concernées, les dépendances envers d’autres équipes et les dates cibles ; le correctif de sécurité est séparé des évolutions fonctionnelles lorsque c’est possible. Un correctif amont doit être testé dans le produit et la configuration de l’éditeur, le résultat de test amont ne prouvant pas que ses utilisateurs sont protégés. Une preuve d’exploitation dans la télémétrie ou les journaux fait basculer le cas en réponse à incident. L’identifiant, CVE ou GCVE, est demandé à ce stade s’il n’a pas déjà été attribué, auprès d’une CNA, d’une GNA ou d’un portail comme celui de GitHub.

La livraison passe par un canal de confiance, avec signature des paquets et des métadonnées de mise à jour et des instructions de vérification pour les téléchargements manuels. Le guide recommande de fournir les mises à jour de sécurité sans frais supplémentaires et sans imposer l’achat d’une montée de version sans rapport. Les prérequis, redémarrages et interruptions de service sont documentés, ainsi que la manière de vérifier que la version corrigée est active ; les instructions de retour arrière doivent préciser qu’un retour à une version antérieure rétablit la vulnérabilité.

Les jalons de communication

Le guide fixe cinq jalons avec le rapporteur : accusé de réception avec identifiant de suivi, résultat de la vérification, points d’avancement pendant la remédiation, coordination de la date de publication et des crédits, remerciement après publication. Les points d’avancement sont maintenus même sans résultat nouveau. Côté utilisateurs, la communication intervient en principe au moment où le correctif est disponible ; elle indique l’urgence, l’action attendue, les versions affectées et corrigées et les configurations exposées. Les équipes internes, support client, commerciales, juridiques ou de conformité, sont informées avant la publication lorsque leur rôle l’exige.

La divulgation coordonnée

La divulgation coordonnée repose sur une collaboration privée entre rapporteur et éditeur avant toute publication. Le guide mentionne les délais usuels de 90 ou 60 jours, au-delà desquels un chercheur peut publier sans correctif, tout en les présentant comme négociables si la communication est maintenue ; il identifie l’absence de nouvelles comme première cause de publication anticipée. Pour les cas impliquant plusieurs éditeurs, un coordinateur peut intervenir, le CERT/CC (23) étant cité en exemple. Les parties s’accordent alors sur le coordinateur du cas, les destinataires d’une information préalable, le périmètre de partage et une date et heure de publication avec fuseau horaire, sans laisser l’embargo ouvert indéfiniment.

Le guide traite deux situations dégradées. En l’absence de correctif, différé ou refusé, la décision est consignée avec sa raison, le risque résiduel, les protections temporaires, son porteur et une date ou un événement de réexamen ; une mesure de contournement ou une acceptation du risque ne doit jamais être présentée comme un correctif complet. En cas de fuite ou de publication anticipée, l’éditeur passe en réponse à incident, évalue le risque, publie des mesures de réduction et communique ouvertement. Le diagramme de décision rappelle qu’un embargo de divulgation coordonnée ne reporte aucun délai légal de notification.

L’avis de sécurité

L’avis est publié en même temps que la version corrigée ou peu après. Si l’exploitation, une fuite ou l’absence de correctif imposent une alerte plus précoce, il expose le risque connu, les mesures de protection et ce qui reste non résolu. Son contenu minimal comprend un résumé, les produits et versions affectés, les versions corrigées, les composants tiers concernés et leur effet sur le produit, les dates de publication et de révision, les mesures de contournement, les crédits et l’identifiant, CVE, GCVE ou à défaut un identifiant interne. Le guide recommande d’y ajouter la gravité, avec le vecteur CVSS, une chronologie, des détails techniques et des instructions de mise à jour.

Une version lisible par machine doit être disponible, sous une licence ouverte telle que CC-BY ou CC0, et le guide renvoie pour son format à GCVE-BCP-05. Les avis ne sont jamais retirés. Après publication, l’éditeur distingue l’exploitation observée de l’exploitation jugée possible et publie, en cas d’exploitation avérée, une assertion KEV au format GCVE-BCP-07. Il vérifie que la mise à jour est effectivement applicable et rouvre le cas en cas de correctif incomplet, la mise à disposition d’un paquet ne prouvant pas que les systèmes déployés sont protégés.

Les bonnes pratiques transverses

La liste de bonnes pratiques recommande un fichier security.txt, un partage de l’information selon le besoin d’en connaître, des accords de confidentialité, les NDA (24), lorsque plusieurs organisations sont impliquées, et un standard de classification comme le TLP (25) du FIRST (26). Elle introduit une règle sur l’IA : les productions d’outils assistés par l’IA, qu’il s’agisse de classement, d’enrichissement, de résumé, de priorisation ou de rédaction, restent provisoires jusqu’à leur revue par une personne qualifiée, et ne sont pas publiées comme faisant autorité sans validation humaine. Les avis lisibles par machine conservent si possible la provenance des champs produits avec l’IA, et aucune information non publique n’est soumise à un système d’IA externe sans évaluation préalable de la confidentialité, de la conservation, de l’usage pour l’entraînement et des exigences légales.

L’annexe A se présente comme un contexte opérationnel complémentaire pour les organisations soumises au CRA. Elle précise qu’elle ne modifie pas le processus général et qu’elle ne constitue pas un avis juridique. Elle rappelle que le fabricant doit notifier lorsqu’il a connaissance d’une vulnérabilité activement exploitée dans son produit ou d’un incident grave affectant la sécurité de ce produit, et que ces obligations s’appliquent depuis le 11 septembre 2026.

L’annexe sépare deux processus de nature différente. La divulgation coordonnée organise la réception, la validation, la remédiation et la publication entre rapporteur, éditeur, coordinateurs et parties affectées. La notification au titre du CRA est une obligation réglementaire du fabricant envers les autorités désignées, par la SRP. Une vulnérabilité ne devient pas notifiable parce qu’un chercheur l’a signalée ou qu’un identifiant lui a été attribué ; inversement, attribuer une CVE ou un identifiant GCVE, publier un avis ou informer un coordinateur ne satisfait pas l’article 14. Les chercheurs continuent d’utiliser le canal de l’éditeur : la SRP n’est pas un canal de signalement à destination des fabricants.

Une notification unique sur la SRP parvient au CSIRT désigné comme coordinateur et, simultanément, à l’ENISA ; le point d’entrée est déterminé principalement par l’établissement principal du fabricant dans l’Union. Les délais courent à partir de la prise de connaissance, et non de la fin de la validation, de la disponibilité du correctif, de l’attribution d’un identifiant ou de la publication.

Fig. 3. Paliers de notification de l’article 14 du règlement (UE) 2024/2847, tels que résumés par l’annexe A de GCVE-BCP-02 et recoupés avec le texte du règlement.

Les deux rapports finaux ont des déclencheurs différents, ce que l’annexe souligne. Elle met en garde contre une lecture extensive des dispositions qui permettent de différer certaines informations pour des raisons de sécurité opérationnelle : elles ne constituent pas une prolongation générale des délais et leur usage doit être justifié et documenté.

L’intégration dans un processus de divulgation coordonnée est décrite en sept étapes : désigner avant tout rapport le fabricant légal, l’équipe habilitée à notifier, ses suppléants et le point d’entrée ; enregistrer l’heure de prise de connaissance et conserver les preuves ; mener en parallèle l’analyse technique et l’évaluation du seuil réglementaire, en remontant tôt toute incertitude ; notifier et conserver accusés, références et contenus ; poursuivre remédiation et divulgation coordonnée, la notification ne valant pas clôture ; relier les dossiers sans les confondre ; exercer le circuit de 24 heures, y compris les week-ends et les absences. L’annexe propose une liste de champs pour le dossier de cas, de l’évaluation CRA requise jusqu’à l’heure de disponibilité de la mesure corrective.

L’ENISA indique que la SRP a été ouverte le 11 septembre 2026 dans une capacité opérationnelle initiale, ses fonctions devant être étendues au fil des mois [4]. L’annexe en tire la conséquence : les organisations doivent vérifier les instructions en vigueur de l’ENISA plutôt que figer des hypothèses d’interface dans leur politique.

L’annexe B, apport principal de la version 2.0, part d’un constat : un logiciel open source atteint ses utilisateurs par plusieurs organisations indépendantes, et une vulnérabilité peut être découverte par l’une d’elles plutôt que signalée au projet amont. Le guide décrit ces relations comme un réseau et non comme une chaîne à sens unique : une distribution peut signaler un défaut au projet amont, un mainteneur amont peut solliciter les empaqueteurs, une même organisation peut être consommatrice d’un composant et fournisseur de beaucoup d’autres. Le coordinateur peut être le projet amont, un acteur aval, un CERT ou CSIRT indépendant, une GNA ou tout autre facilitateur convenu.

Préparer les relations et ouvrir un cas

Les projets à forte adoption aval sont invités à tenir une carte légère et régulièrement revue de leurs principaux acteurs aval et de leurs contacts de sécurité : distributions, branches LTS (27), dépôts indépendants, publieurs d’images de conteneurs, intégrateurs connus. Cette liste reste privée et la présence d’un contact n’ouvre pas, à elle seule, un droit à l’information sous embargo. Le guide précise qu’un petit projet n’a pas à constituer un registre complet de sa chaîne d’approvisionnement.

Un acteur aval qui découvre une vulnérabilité informe le projet amont par son canal de sécurité tout en évaluant l’effet sur ses propres utilisateurs, sans présumer que le projet amont prendra la direction du cas. Le calendrier de publication d’une distribution n’autorise pas à prolonger le délai fixé par le rapporteur. Les copies embarquées de code, les forks et les composants liés statiquement sont plus difficiles à localiser ; un numéro de version amont ne suffit pas à dire si un produit aval est vulnérable ou corrigé, un paquet ancien pouvant contenir un backport, c’est à dire un correctif reporté sur une version antérieure. Lorsque le projet amont ne répond pas, après des tentatives documentées, un coordinateur par intérim peut être désigné ; ce rôle est opérationnel et ne transfère ni la propriété du projet ni les obligations légales de chaque fabricant.

Le rapporteur et les responsabilités

Le rapporteur est traité comme un participant et non comme une simple source. L’élargissement du partage à un groupe ou à d’autres éditeurs est convenu avec lui ; l’ajout de participants ne remet pas son délai à zéro et ne donne pas au groupe le pouvoir de le prolonger seul. Son consentement ne vaut pas pour autant droit de veto sur une notification légale ou une mesure de protection urgente.

Fig. 4. Responsabilités des participants à un cas multipartite, d’après la section 3.6 de l’annexe B de GCVE-BCP-02.

Groupes de coordination et embargos limités

Le guide reconnaît la valeur des groupes de coordination de confiance et en conditionne la légitimité à huit principes : participation limitée à la finalité de protection, accès équitable pour les petits projets et les bénévoles, respect des conditions du rapporteur, règles de confidentialité explicites, exception pour les notifications obligatoires, calendrier court et justifié, contenu technique exploitable, réévaluation lorsque le risque change. Il cite les listes de coordination (linux-)distros d’Openwall, dont la politique fixe un embargo de 14 jours au plus, en précisant qu’il s’agit de la politique de cette communauté et non d’un délai universel. Le TLP peut exprimer les attentes de partage sans remplacer des règles explicites sur les participants et les finalités.

Le plan de publication partagé recense l’identifiant commun, de préférence GCVE ou un autre identifiant établi, le rapporteur et ses conditions, les contacts, les composants et branches concernés, l’information nécessaire à chaque partie, la date et l’heure de publication, l’état de préparation des correctifs, des signatures et des miroirs, et un canal pour signaler tout fait nouveau sur l’exploitation. Le guide signale les fuites techniques possibles avant la date convenue : activité du gestionnaire de sources, demandes de fusion, journaux d’intégration continue, index de paquets, registres d’images, miroirs, caches. Un binaire ou un diff publiés en avance peuvent rendre la vulnérabilité identifiable même si l’avis reste confidentiel.

Le CRA dans les cas multipartites

Plusieurs fabricants peuvent partager un cas sous embargo tout en évaluant chacun leurs obligations pour leur propre produit. Le guide demande de signaler explicitement au groupe toute preuve crédible d’exploitation, horodatée, en distinguant faits confirmés et hypothèses ; la seule appartenance au groupe ou la réception d’une allégation non vérifiée ne suffit pas à établir le seuil pour chaque participant. Chaque fabricant suit sa propre heure de prise de connaissance. Les règles du groupe doivent autoriser les notifications confidentielles sur la SRP sans les traiter comme une rupture d’embargo, le notifiant n’ayant pas à communiquer le contenu de sa notification. Un identifiant commun, GCVE, CVE ou autre, est recommandé pour faciliter le rapprochement par les autorités, sans remplacer les notifications individuelles. Les obligations des gestionnaires de logiciels open source au titre de l’article 24, paragraphe 3, du CRA s’appliqueront à compter du 11 décembre 2027.

Fuites, outils externes et soutenabilité

L’annexe distingue la fuite d’information, la publication prématurée d’un paquet, l’exploitation observée et le changement délibéré de calendrier, qui n’ont pas les mêmes conséquences. Elle propose une conduite en cinq temps : établir les faits, informer les participants, réévaluer la protection des utilisateurs et le calendrier, prendre et communiquer une décision défendable, consigner et tirer les enseignements. Un embargo n’est pas maintenu pour éviter l’embarras.

Sur les services externes et les outils d’IA, le guide adopte une approche neutre vis-à-vis de la technologie et fondée sur le risque : les mêmes questions s’appliquent à un service d’analyse par IA, à un outil collaboratif en ligne ou à une messagerie. Désactiver l’option d’entraînement d’un service ne suffit pas à établir que l’information est protégée ; un service opéré localement ou isolé peut être préférable pour les cas les plus sensibles. Sur la soutenabilité, il relève que la découverte automatisée ou assistée par l’IA peut accroître la charge de tri lorsque les rapports sont dupliqués ou invérifiés, et demande aux organisations qui dépendent de l’open source de soutenir le travail de sécurité, sans que ce soutien achète un accès préférentiel aux cas sous embargo.

L’annexe se termine par des critères d’évaluation après publication. Une divulgation n’y est pas jugée au seul fait que l’embargo a tenu : les utilisateurs devaient pouvoir déterminer l’état de leur paquet, fork, image ou produit, y compris les backports, et les éléments nouveaux sur l’exploitation devaient déclencher l’évaluation réglementaire sans confusion entre embargo et délai légal.

Positionnement par rapport aux normes internationales

Le traitement et la divulgation des vulnérabilités font l’objet de normes ISO/IEC (28) : la norme 29147:2018 pour la divulgation [15], la norme 30111:2019 pour les processus de traitement [16], et le rapport technique TR 5895:2022 pour la divulgation coordonnée multipartite [17]. GCVE-BCP-02 couvre les deux faces, traitement interne et divulgation, dans un seul document, et son annexe B recouvre le champ du rapport technique multipartite. La prépublication consacrée à GCVE présente ce choix comme délibéré : les normes ISO/IEC sont des points de référence, mais un BCP sous licence CC-BY-4.0, révisé en public, est un objet différent, directement accessible, redistribuable et amendable par les praticiens [11].

Fig. 5. Positionnement de GCVE-BCP-02 par rapport aux référentiels ISO/IEC du domaine, d’après les références de ces normes, le guide et la prépublication consacrée à GCVE.

La liste de références du guide ne cite aucun de ces trois référentiels. Elle comprend le règlement CRA, la foire aux questions de la SRP, une fiche de l’OWASP (29), la politique de divulgation coordonnée du CIRCL, des recommandations du NIST (30), un ouvrage de référence en ingénierie de la sécurité et un projet de l’IETF (31). Le corps du texte renvoie aux travaux du CERT/CC, du FIRST et du NIST comme sources de bonnes pratiques, sans renvoi normatif précis.

Articulation avec le cadre européen

Le guide s’inscrit explicitement dans le cadre européen par trois points d’appui : l’EUVD comme source de veille, l’annexe A sur le CRA et la SRP, et les GNA comme coordinateurs possibles. La directive NIS2 n’y est pas nommée, alors que son article 12 institue le CSIRT coordinateur national de la divulgation coordonnée, qui est aussi le destinataire désigné des notifications CRA. Le guide décrit le coordinateur de manière générique, CERT, CSIRT, GNA ou intermédiaire spécialisé, sans désigner ce rôle légal dans le parcours d’un rapporteur qui ne parvient pas à joindre un éditeur.

Points ouverts relevés dans le texte

• Deux cibles d’accusé de réception coexistent : deux jours ouvrés dans la section consacrée à la préparation, 24 à 48 heures dans celle consacrée à la réception.
• La section 3.14 de l’annexe B demande un renvoi depuis l’annexe A « lorsque cette annexe sera intégrée au BCP complet » ; ce renvoi n’apparaît pas dans l’annexe A de la version 2.0, et les lectures complémentaires mentionnent la discussion communautaire de « l’annexe B proposée ».
• Le guide renvoie à GCVE-BCP-07 pour les assertions KEV. Depuis sa version 3.0 du 5 octobre 2026, ce BCP couvre aussi les évaluations NKEV (32), que GCVE-BCP-02 ne mentionne pas [13].
• La liste des rôles mêle rôles et rubriques de pratique, ce qui rend moins directe la lecture des responsabilités dans le corps du guide ; l’annexe B présente au contraire un tableau de responsabilités par type de participant.

Entre 2024 et 2026, l’Europe s’est dotée d’obligations légales en matière de divulgation coordonnée et de notification, d’une base publique des vulnérabilités, d’une position de Root dans le programme CVE et d’un système d’identifiants décentralisé. GCVE-BCP-02 version 2.0 apporte à cet ensemble un référentiel procédural ouvert, qui couvre le traitement d’une vulnérabilité de la préparation au retour d’expérience.

Le document repose sur une exigence de précision dans l’évaluation : il distingue le risque réel de la gravité technique, le produit non affecté du produit où la vulnérabilité n’a pas encore été reproduite, l’exploitation observée de l’exploitation possible. Il sépare strictement l’embargo de divulgation coordonnée du délai légal de notification, et maintient la responsabilité de chaque éditeur ou fabricant pour les composants qu’il livre, le recours au projet amont ne la transférant pas. L’annexe B transpose ces positions à la chaîne de distribution open source et pose des conditions d’équité pour les groupes de coordination.

Le texte présente des marques d’intégration récente, avec deux cibles d’accusé de réception et un renvoi entre annexes encore absent, et ne se rattache explicitement ni aux normes ISO/IEC du domaine ni à la directive NIS2. Sa licence ouverte et son processus de révision publique permettent de traiter ces points dans les versions suivantes.

Le guide GCVE-BCP-02 version 2.0 est la source primaire, lue en intégralité. Les textes de la directive NIS2 et du règlement CRA, les publications de l’ENISA et les pages de l’initiative GCVE sont des sources primaires institutionnelles ou communautaires. Les éléments sur la Root CVE de l’ENISA et sur le lancement de l’EUVD proviennent de sources secondaires.

1. CVE (1) : Common Vulnerabilities and Exposures, identifiant public attribué à une vulnérabilité, et programme qui attribue ces identifiants.
2. CISA (2) : Cybersecurity and Infrastructure Security Agency, agence américaine de cybersécurité et de sécurité des infrastructures.
3. CIRCL (3) : Computer Incident Response Center Luxembourg, centre de réponse aux incidents informatiques du Luxembourg, opérateur de l’initiative GCVE.
4. NIS2 (4) : Network and Information Security, directive (UE) 2022/2555 concernant des mesures destinées à assurer un niveau élevé commun de cybersécurité dans l’Union.
5. CVD (5) : Coordinated Vulnerability Disclosure, divulgation coordonnée des vulnérabilités.
6. CSIRT (6) : Computer Security Incident Response Team, équipe de réponse aux incidents de sécurité informatique.
7. ENISA (7) : European Union Agency for Cybersecurity, Agence de l’Union européenne pour la cybersécurité.
8. CRA (8) : Cyber Resilience Act, règlement (UE) 2024/2847 relatif à des exigences horizontales en matière de cybersécurité pour les produits comportant des éléments numériques.
9. SRP (9) : Single Reporting Platform, plateforme unique de notification opérée par l’ENISA au titre de l’article 16 du CRA.
10. CNA (10) : CVE Numbering Authority, organisme habilité à attribuer des CVE et à publier leur fiche.
11. EUVD (11) : European Union Vulnerability Database, base européenne des vulnérabilités opérée par l’ENISA.
12. KEV (12) : Known Exploited Vulnerabilities, catalogue de vulnérabilités dont l’exploitation est constatée ; désigne aussi, dans GCVE-BCP-07, une assertion d’exploitation attribuée à une source.
13. GCVE (13) : Global CVE Allocation System, système décentralisé d’attribution d’identifiants de vulnérabilités opéré par le CIRCL.
14. GNA (14) : GCVE Numbering Authority, organisme habilité à attribuer des identifiants GCVE dans son propre espace de numérotation.
15. BCP (15) : Best Current Practice, document de bonnes pratiques de l’initiative GCVE.
16. PSIRT (16) : Product Security Incident Response Team, équipe de réponse aux incidents de sécurité des produits.
17. IA (17) : Intelligence artificielle.
18. CERT (18) : Computer Emergency Response Team, équipe de réponse aux urgences informatiques.
19. PGP (19) : Pretty Good Privacy, standard de chiffrement et de signature des messages, normalisé sous le nom OpenPGP.
20. CVSS (20) : Common Vulnerability Scoring System, système de notation de la gravité des vulnérabilités.
21. SBOM (21) : Software Bill of Materials, nomenclature des composants d’un logiciel.
22. SPDX (22) : Software Package Data Exchange, format de nomenclature logicielle maintenu par la Linux Foundation.
23. CERT/CC (23) : CERT Coordination Center, centre de coordination de l’université Carnegie Mellon.
24. NDA (24) : Non-Disclosure Agreement, accord de confidentialité.
25. TLP (25) : Traffic Light Protocol, protocole de marquage du FIRST encadrant le partage de l’information.
26. FIRST (26) : Forum of Incident Response and Security Teams, forum international des équipes de réponse aux incidents.
27. LTS (27) : Long Term Support, branche maintenue sur une longue durée.
28. ISO/IEC (28) : International Organization for Standardization et International Electrotechnical Commission, qui publient conjointement les normes du domaine.
29. OWASP (29) : Open Worldwide Application Security Project, fondation consacrée à la sécurité des applications.
30. NIST (30) : National Institute of Standards and Technology, institut américain de normalisation et de technologie.
31. IETF (31) : Internet Engineering Task Force, organisme de normalisation des protocoles de l’internet.
32. NKEV (32) : No Known Exploitable Vulnerability, type d’évaluation introduit par la version 3.0 de GCVE-BCP-07, à côté des assertions KEV.

1. Union européenne, Directive (UE) 2022/2555 du Parlement européen et du Conseil du 14 décembre 2022 (NIS2), article 12. eur-lex.europa.eu
2. Union européenne, Règlement (UE) 2024/2847 du Parlement européen et du Conseil du 23 octobre 2024 (CRA), articles 14, 16 et 24, annexe I. eur-lex.europa.eu
3. GCVE Working Group, GCVE-BCP-02 – Practical Guide to Vulnerability Handling and Disclosure, version 2.0, 28 octobre 2026. gcve.eu/bcp/gcve-bcp-02
4. ENISA, The CRA Single Reporting Platform is launched, 11 septembre 2026. enisa.europa.eu
5. Cloud Security Alliance, ENISA CVE Root: Dual Vulnerability Governance for Multinationals, 18 mai 2026. labs.cloudsecurityalliance.org
6. Cloud Security Alliance, ENISA Restructures CVE Governance for the AI-Discovery Era, 11 août 2026. labs.cloudsecurityalliance.org
7. Infosecurity Magazine, European Vulnerability Database Launches Amid US CVE Chaos, 13 mai 2025. infosecurity-magazine.com
8. CyberScoop, GCVE launches as a decentralized system for tracking software vulnerabilities, avril 2025. cyberscoop.com
9. GCVE, GCVE – Global CVE Allocation System Announced, 16 avril 2025. gcve.eu
10. GCVE, FAQ, consultée le 28 octobre 2026. gcve.eu/faq
11. A. Dulaunoy, GCVE: A Decentralized Model for Vulnerability Identification, Publication, and Operational Enrichment, prépublication, 2 juin 2026. arxiv.org/pdf/2606.00856
12. GCVE, GNA 2 – EUVD, registre des GNA, consulté le 28 octobre 2026. gcve.eu/gna/2
13. GCVE, GCVE.eu – Best Current Practice (BCP), index des BCP, consulté le 28 octobre 2026. gcve.eu/bcp
14. GCVE, GCVE BCP-02 v1.9: Making Coordinated Vulnerability Disclosure Open, Accessible, and Practical for Everyone, 16 octobre 2026. gcve.eu
15. ISO, ISO/IEC 29147:2018, Information technology, Security techniques, Vulnerability disclosure, 2018. iso.org
16. ISO, ISO/IEC 30111:2019, Information technology, Security techniques, Vulnerability handling processes, 2019. iso.org
17. ISO, ISO/IEC TR 5895:2022, Cybersecurity, Multi-party coordinated vulnerability disclosure and handling, 2022, notice BSI. knowledge.bsigroup.com