GCVE-BCP-02: coordinated disclosure in the CRA era

For more than twenty years, public vulnerability identification has rested largely on the CVE (1) Program, administered by the US organisation MITRE and funded by the US agency CISA (2). Since 2024, the European Union and the European incident response community have been building a framework of their own along two distinct lines: a regulatory and institutional line, driven by the European legislator and its cybersecurity agency, and a community line, driven by a national incident response centre, Luxembourg’s CIRCL (3). The guide examined here sits where these two lines meet.

The regulatory line: from the 2022 Directive to the Cyber Resilience Act

Directive (EU) 2022/2555, known as NIS2 (4), devotes its Article 12 to coordinated vulnerability disclosure, abbreviated CVD (5). Each Member State designates one of its CSIRT (6) teams as coordinator, acting as a trusted intermediary between the person reporting a vulnerability and the manufacturer or provider concerned. The same Article entrusts ENISA (7) with developing and maintaining a European vulnerability database [1]. The Directive had to be transposed by 17 October 2024 at the latest.

Regulation (EU) 2024/2847 of 23 October 2024, the Cyber Resilience Act, abbreviated CRA (8), extends this framework to products with digital elements. Among other requirements, it obliges manufacturers to handle vulnerabilities in their products throughout the support period, to provide security updates and to have a coordinated disclosure policy [2, 3]. Its Article 14 creates an obligation to report actively exploited vulnerabilities and severe incidents, applicable since 11 September 2026, the date on which ENISA opened the Single Reporting Platform, the SRP (9). The other essential requirements of the Regulation apply from 11 December 2027 [4].

The institutional line: ENISA in the CVE Program and the European database

ENISA became a CNA (10) of the CVE Program in January 2024, which allows it to assign CVE identifiers to vulnerabilities reported to or discovered by European CSIRTs. On 20 November 2025, it was designated a Root of the Program, that is, the central point of contact for national and EU authorities and for members of the EU CSIRTs Network [5]. In August 2026, it had twenty CNAs under its responsibility, twelve onboarded directly and eight transferred from the MITRE Root [6].

The European vulnerability database provided for by the NIS2 Directive, the EUVD (11), was officially opened on 13 May 2025, after a beta phase. It aggregates information from CSIRTs, vendors and existing databases, including CISA’s KEV (12) catalogue and the CVE Program, and offers three dashboards: critical vulnerabilities, exploited vulnerabilities and vulnerabilities coordinated by European CSIRTs. Each entry carries an EUVD identifier, alongside the CVE identifier and, where relevant, other identifiers [7]. The EUVD relies on the vulnerability-lookup software developed by CIRCL [8].

The community line: a decentralised identifier system

In April 2025, the contract funding the CVE Program nearly lapsed, before a last-minute extension by CISA [8]. On 16 April 2025, CIRCL announced the GCVE (13) system, Global CVE Allocation System, a decentralised approach to assigning vulnerability identifiers [9]. GCVE Numbering Authorities, abbreviated GNA (14), allocate their own identifiers in the format GCVE-<GNA-ID>-<YEAR>-<UNIQUE-ID>, without requesting blocks from a central authority. GNA identifier 0 is reserved for CVE identifiers, so that CVE-2023-40224 can also be read as GCVE-0-2023-40224; CIRCL is GNA 1 [10]. The initiative presents itself as a complement to the CVE Program, not a replacement [10, 8].

The system grew in 2026: the public database db.gcve.eu, which aggregates more than twenty-five sources, opened in January [11], and the EUVD was entered in the GNA registry as GNA 2 on 31 January 2026 [12]. The initiative’s common rules are published as BCP (15) documents, best practice documents developed through public review, descriptive rather than prescriptive, whose adoption is recommended but not mandatory [13]. GCVE-BCP-02 is the vulnerability handling and disclosure guide in this corpus.

Fig. 1. Timeline of European vulnerability management initiatives, compiled from the texts of the NIS2 Directive and the CRA, ENISA publications, the GCVE registry and the GCVE-BCP-02 guide.

These systems produce identifiers, databases and reporting channels. They leave each vendor, manufacturer or maintainer with the operational question: how to receive a report, assess it, fix the issue, coordinate publication and, from now on, report to the authorities within the deadlines. This is the ground GCVE-BCP-02 covers.

The document examined is version 2.0 of GCVE-BCP-02, Practical Guide to Vulnerability Handling and Disclosure, with Published status, dated 28 October 2026 and signed by the GCVE Working Group [3]. It is distributed under the Creative Commons CC-BY-4.0 licence and runs to some fifty pages. It is coordinated by two members of CIRCL; the acknowledgements name seven contributors and the CSIRT and PSIRT (16) community.

The previous version, 1.9, dated 15 October 2026, had introduced eight process diagrams, recommendations on component inventory and update delivery, and a distinction between exploited vulnerabilities and vulnerabilities assessed as exploitable [14]. Version 2.0 adds an Annex B on multi-party coordinated disclosure in open source ecosystems, which the announcement of version 1.9 did not mention. At the time of consultation, the public BCP index still showed version 1.9 [13].

The analysis is based on a full reading of the document. The regulatory dates and deadlines it cites were cross-checked against the text of the CRA and against the ENISA publication announcing the opening of the SRP. The positioning of the guide relative to international standards draws on the references of those standards and on the preprint on the GCVE architecture written by the initiative’s coordinator [11].

The body of the guide follows the life cycle of a vulnerability in ten sections. It opens with an overview that links the stages in a loop, from preparation to lessons learned, and states that communication continues throughout handling, that investigation, remediation and disclosure may overlap, and that CRA reporting runs in parallel where it applies. Each stage ends with a summary diagram.

The guide sets out four definitions: vulnerability, vulnerability report, coordinated disclosure and security advisory. Two of them carry a substantive position. The definition of coordinated disclosure accepts that publication may take place before a fix is available, when exploitation is under way or users need to protect themselves. The definition of a security advisory requires, where no fix exists, that this be stated together with how to reduce exposure.

Fig. 2. Structure of GCVE-BCP-02 version 2.0, based on the table of contents and content of the document.

The roles section mixes actual roles with practice headings: the interaction between reporter and vendor and secure development sit at the same level as the PSIRT or coordinators. The coordinator role is illustrated by a CERT (18) or a specialised intermediary, which synchronises fix schedules across several vendors and may publish a joint advisory.

Preparing before the first report

The guide makes preparation a precondition of handling. It recommends a public disclosure policy, for example on a website or in a SECURITY.md file, stating the reporting channel, the information expected, the commitments made to researchers and, where appropriate, a safe harbour clause, that is, a commitment not to pursue research carried out in good faith. The channel combines a dedicated address and a public PGP (19) key, or an encrypted form; public issue trackers must not be used to report a vulnerability, in favour of their private reporting feature where one exists.

A response team is designated, with a shared address, a backup and an identified authority to approve an urgent release. In a small organisation these roles may be combined, the point being that someone owns the next action. The internal process sets triage criteria, with CVSS (20) cited as a ranking tool, and target deadlines: acknowledgement within two working days and a resolution plan within one week, by way of example. Cases are tracked in a controlled, auditable tool.

Version 2.0 insists on knowing what is shipped: a list of components per supported version, including third-party libraries, copied code and transitive dependencies, ideally as a machine-readable SBOM (21) in SPDX (22) or CycloneDX format. Gaps in the inventory should be flagged rather than assumed not to exist. The guide adds keeping contacts for component maintainers and downstream parties, monitoring dependencies that lose support, a security testing programme of one’s own, an update channel prepared before an emergency, tabletop exercises and resources allocated by management.

Receiving, triaging and verifying

Each report is logged with a case owner, a next action and an update date; non-public material stays in a restricted space. Acknowledgement is ideally expected within 24 to 48 hours. A useful report should be accepted even if it arrives through the wrong channel, unencrypted or outside the expected template, with a safer channel offered for the follow-up.

Triage distinguishes technical severity from actual risk: is the vulnerable code reachable, exposed to untrusted input, protected by an effective control? Evidence of exploitation is weighed alongside the score. Two principles govern closing a case: the absence of a public exploit does not show that a product is unaffected, and a product that is “not affected” must be distinguished from one for which the vulnerability has “not yet been reproduced”. Before closure, the guide asks for a record of what was checked, the assumptions made and what would justify reopening.

A vulnerability in a library shipped with the product still has to be assessed for that product: contacting the upstream maintainer does not relieve the vendor of tracking affected versions, integrating a fix or informing users. Finally, the guide recommends monitoring upstream advisories and vulnerability sources, including GCVE feeds and the EUVD, with an applicability check rather than automatic matching of names and versions.

Investigating, fixing, delivering

Investigation covers the root cause, similar components and other versions. The remediation plan identifies the owner, the supported branches concerned, dependencies on other teams and target dates; the security fix is separated from functional changes where possible. An upstream fix must be tested in the vendor’s product and configuration, since an upstream test result does not prove that its users are protected. Evidence of exploitation in telemetry or logs switches the case to incident response. The identifier, CVE or GCVE, is requested at this stage if it has not already been assigned, from a CNA, a GNA or a portal such as GitHub’s.

Delivery goes through a trusted channel, with signed packages and update metadata and verification instructions for manual downloads. The guide recommends providing security updates at no additional charge and without forcing the purchase of an unrelated upgrade. Prerequisites, restarts and service interruptions are documented, along with how to check that the fixed version is active; rollback instructions must state that reverting to an earlier version reintroduces the vulnerability.

Communication milestones

The guide sets five milestones with the reporter: acknowledgement with a tracking identifier, the outcome of verification, progress updates during remediation, coordination of the publication date and credits, and thanks after publication. Progress updates are kept up even when there is nothing new to report. On the user side, communication normally takes place when the fix becomes available; it states the urgency, the action expected, the affected and fixed versions and the exposed configurations. Internal teams, whether customer support, sales, legal or compliance, are informed before publication where their role requires it.

Coordinated disclosure

Coordinated disclosure rests on private collaboration between reporter and vendor before any publication. The guide mentions the usual deadlines of 90 or 60 days, after which a researcher may publish without a fix, while presenting them as negotiable if communication is maintained; it identifies the lack of news as the first cause of early publication. For cases involving several vendors, a coordinator may step in, with the CERT/CC (23) cited as an example. The parties then agree on the case coordinator, who receives advance information, the scope of sharing, and a publication date and time with time zone, without leaving the embargo open indefinitely.

The guide deals with two degraded situations. Where there is no fix, because it is deferred or refused, the decision is recorded with its reason, the residual risk, the temporary protections, its owner and a review date or trigger; a workaround or risk acceptance must never be presented as a complete fix. In the event of a leak or early publication, the vendor switches to incident response, assesses the risk, publishes mitigations and communicates openly. The decision diagram notes that a coordinated disclosure embargo does not postpone any legal reporting deadline.

The security advisory

The advisory is published at the same time as the fixed version or shortly afterwards. If exploitation, a leak or the absence of a fix call for an earlier warning, it sets out the known risk, the protective measures and what remains unresolved. Its minimum content includes a summary, the affected products and versions, the fixed versions, the third-party components concerned and their effect on the product, the publication and revision dates, workarounds, credits and the identifier, CVE, GCVE or failing that an internal identifier. The guide recommends adding the severity, with the CVSS vector, a timeline, technical details and update instructions.

A machine-readable version should be available, under an open licence such as CC-BY or CC0, and the guide refers to GCVE-BCP-05 for its format. Advisories are never withdrawn. After publication, the vendor distinguishes observed exploitation from exploitation assessed as possible and, where exploitation is confirmed, publishes a KEV assertion in the GCVE-BCP-07 format. It checks that the update can actually be applied and reopens the case if the fix is incomplete, since making a package available does not prove that deployed systems are protected.

Cross-cutting best practices

The best practice list recommends a security.txt file, sharing information on a need-to-know basis, non-disclosure agreements, abbreviated NDA (24), where several organisations are involved, and a classification standard such as the TLP (25) of FIRST (26). It introduces a rule on AI: output from AI-assisted tools, whether classification, enrichment, summarisation, prioritisation or drafting, remains provisional until reviewed by a qualified person, and is not published as authoritative without human validation. Machine-readable advisories keep, where possible, the provenance of fields produced with AI, and no non-public information is submitted to an external AI system without a prior assessment of confidentiality, retention, use for training and legal requirements.

Annex A presents itself as additional operational context for organisations subject to the CRA. It states that it does not change the general process and is not legal advice. It recalls that the manufacturer must report when it becomes aware of an actively exploited vulnerability in its product or of a severe incident affecting the security of that product, and that these obligations have applied since 11 September 2026.

The annex separates two processes of a different nature. Coordinated disclosure organises receipt, validation, remediation and publication between reporter, vendor, coordinators and affected parties. CRA reporting is a regulatory obligation of the manufacturer towards the designated authorities, through the SRP. A vulnerability does not become reportable because a researcher reported it or because an identifier was assigned to it; conversely, assigning a CVE or GCVE identifier, publishing an advisory or informing a coordinator does not satisfy Article 14. Researchers keep using the vendor’s channel: the SRP is not a reporting channel addressed to manufacturers.

A single notification on the SRP reaches the CSIRT designated as coordinator and, simultaneously, ENISA; the point of entry is determined mainly by the manufacturer’s main establishment in the Union. Deadlines run from the moment of awareness, not from the end of validation, the availability of a fix, the assignment of an identifier or publication.

Fig. 3. Reporting stages under Article 14 of Regulation (EU) 2024/2847, as summarised in Annex A of GCVE-BCP-02 and cross-checked against the text of the Regulation.

The two final reports have different triggers, which the annex underlines. It warns against an extensive reading of the provisions that allow certain information to be deferred for operational security reasons: they are not a general extension of deadlines, and their use must be justified and documented.

Integration into a coordinated disclosure process is described in seven steps: designate, before any report, the legal manufacturer, the team authorised to report, its backups and the point of entry; record the time of awareness and preserve the evidence; carry out technical analysis and assessment of the regulatory threshold in parallel, escalating any uncertainty early; report and keep acknowledgements, references and content; continue remediation and coordinated disclosure, reporting not meaning closure; link the case files without merging them; exercise the 24-hour path, including weekends and absences. The annex proposes a list of fields for the case file, from the required CRA assessment to the time at which the corrective measure became available.

ENISA states that the SRP opened on 11 September 2026 with an initial operating capability, its functions to be extended over the coming months [4]. The annex draws the consequence: organisations should check ENISA’s current instructions rather than freezing interface assumptions into their policy.

Annex B, the main addition in version 2.0, starts from an observation: open source software reaches its users through several independent organisations, and a vulnerability may be discovered by one of them rather than reported to the upstream project. The guide describes these relationships as a network rather than a one-way chain: a distribution may report a flaw upstream, an upstream maintainer may reach out to packagers, and a single organisation may be a consumer of one component and a supplier of many others. The coordinator may be the upstream project, a downstream party, an independent CERT or CSIRT, a GNA or any other agreed facilitator.

Preparing relationships and opening a case

Projects with significant downstream adoption are invited to keep a light, regularly reviewed map of their main downstream parties and their security contacts: distributions, LTS (27) branches, independent repositories, container image publishers, known integrators. This list stays private, and being on it does not in itself confer a right to embargoed information. The guide states that a small project does not need to build a complete register of its supply chain.

A downstream party that discovers a vulnerability informs the upstream project through its security channel while assessing the effect on its own users, without assuming that the upstream project will lead the case. A distribution’s release schedule does not justify extending the deadline set by the reporter. Embedded copies of code, forks and statically linked components are harder to locate; an upstream version number is not enough to tell whether a downstream product is vulnerable or fixed, as an older package may contain a backport, that is, a fix carried over to an earlier version. Where the upstream project does not respond, after documented attempts, an interim coordinator may be designated; this role is operational and transfers neither ownership of the project nor the legal obligations of each manufacturer.

The reporter and responsibilities

The reporter is treated as a participant, not merely as a source. Widening the sharing to a group or to other vendors is agreed with them; adding participants does not reset their deadline and does not give the group the power to extend it on its own. Their consent does not, however, amount to a veto over a legal notification or an urgent protective measure.

Fig. 4. Responsibilities of participants in a multi-party case, based on section 3.6 of Annex B of GCVE-BCP-02.

Coordination groups and limited embargoes

The guide recognises the value of trusted coordination groups and makes their legitimacy conditional on eight principles: participation limited to the protective purpose, fair access for small projects and volunteers, respect for the reporter’s conditions, explicit confidentiality rules, an exception for mandatory notifications, a short and justified schedule, actionable technical content, and reassessment when the risk changes. It cites Openwall’s (linux-)distros coordination lists, whose policy sets an embargo of at most 14 days, noting that this is that community’s policy and not a universal deadline. The TLP can express sharing expectations without replacing explicit rules on participants and purposes.

The shared publication plan records the common identifier, preferably GCVE or another established identifier, the reporter and their conditions, contacts, the components and branches concerned, the information each party needs, the publication date and time, the readiness of fixes, signatures and mirrors, and a channel for flagging any new fact about exploitation. The guide points out possible technical leaks before the agreed date: source control activity, merge requests, continuous integration logs, package indexes, image registries, mirrors, caches. A binary or a diff published early can make the vulnerability identifiable even if the advisory remains confidential.

The CRA in multi-party cases

Several manufacturers may share an embargoed case while each assessing its own obligations for its own product. The guide asks that any credible evidence of exploitation be flagged explicitly to the group, timestamped, distinguishing confirmed facts from hypotheses; membership of the group alone, or receipt of an unverified claim, is not enough to establish the threshold for each participant. Each manufacturer tracks its own time of awareness. The group’s rules must allow confidential notifications on the SRP without treating them as an embargo breach, and the notifying party does not have to share the content of its notification. A common identifier, GCVE, CVE or other, is recommended to make correlation easier for the authorities, without replacing individual notifications. The obligations of open-source software stewards under Article 24(3) of the CRA will apply from 11 December 2027.

Leaks, external tools and sustainability

The annex distinguishes an information leak, premature publication of a package, observed exploitation and a deliberate change of schedule, which do not have the same consequences. It proposes a five-stage course of action: establish the facts, inform participants, reassess user protection and the schedule, take and communicate a defensible decision, record and learn lessons. An embargo is not maintained to avoid embarrassment.

On external services and AI tools, the guide takes a technology-neutral, risk-based approach: the same questions apply to an AI analysis service, an online collaboration tool or a messaging service. Disabling a service’s training option is not enough to establish that the information is protected; a locally operated or isolated service may be preferable for the most sensitive cases. On sustainability, it notes that automated or AI-assisted discovery can increase the triage burden when reports are duplicated or unverified, and asks organisations that depend on open source to support security work, without that support buying preferential access to embargoed cases.

The annex ends with post-publication evaluation criteria. A disclosure is not judged solely on whether the embargo held: users had to be able to determine the status of their package, fork, image or product, including backports, and new evidence on exploitation had to trigger the regulatory assessment without confusion between embargo and legal deadline.

Positioning relative to international standards

Vulnerability handling and disclosure are covered by ISO/IEC (28) standards: 29147:2018 for disclosure [15], 30111:2019 for handling processes [16], and technical report TR 5895:2022 for multi-party coordinated disclosure [17]. GCVE-BCP-02 covers both sides, internal handling and disclosure, in a single document, and its Annex B overlaps the scope of the multi-party technical report. The preprint on GCVE presents this as a deliberate choice: ISO/IEC standards are reference points, but a BCP under the CC-BY-4.0 licence, revised in public, is a different kind of artefact, directly accessible, redistributable and amendable by practitioners [11].

Fig. 5. Positioning of GCVE-BCP-02 relative to the ISO/IEC references in the field, based on the references of those standards, the guide and the preprint on GCVE.

The guide’s reference list cites none of these three documents. It includes the CRA, the SRP frequently asked questions, an OWASP (29) cheat sheet, CIRCL’s coordinated disclosure policy, NIST (30) recommendations, a reference work on security engineering and an IETF (31) draft. The body of the text refers to the work of CERT/CC, FIRST and NIST as sources of good practice, without precise normative references.

Fit with the European framework

The guide explicitly places itself within the European framework through three anchor points: the EUVD as a monitoring source, Annex A on the CRA and the SRP, and GNAs as possible coordinators. The NIS2 Directive is not named, even though its Article 12 establishes the national coordinating CSIRT for coordinated disclosure, which is also the designated recipient of CRA notifications. The guide describes the coordinator generically, as a CERT, CSIRT, GNA or specialised intermediary, without identifying this legal role in the path of a reporter who cannot reach a vendor.

Open points in the text

• Two acknowledgement targets coexist: two working days in the section on preparation, 24 to 48 hours in the section on receipt.
• Section 3.14 of Annex B asks for a cross-reference from Annex A “when this annex is integrated into the full BCP”; this cross-reference does not appear in Annex A of version 2.0, and the further reading mentions the community discussion of the “proposed Annex B”.
• The guide refers to GCVE-BCP-07 for KEV assertions. Since its version 3.0 of 5 October 2026, that BCP also covers NKEV (32) assessments, which GCVE-BCP-02 does not mention [13].
• The list of roles mixes roles and practice headings, which makes responsibilities in the body of the guide less straightforward to read; Annex B, by contrast, provides a table of responsibilities by type of participant.

Between 2024 and 2026, Europe acquired legal obligations for coordinated disclosure and reporting, a public vulnerability database, a Root position in the CVE Program and a decentralised identifier system. GCVE-BCP-02 version 2.0 adds an open procedural reference to this whole, covering the handling of a vulnerability from preparation to lessons learned.

The document rests on a demand for precision in assessment: it distinguishes actual risk from technical severity, a product that is not affected from one in which the vulnerability has not yet been reproduced, observed exploitation from possible exploitation. It strictly separates the coordinated disclosure embargo from the legal reporting deadline, and keeps each vendor or manufacturer responsible for the components it ships, recourse to the upstream project not transferring that responsibility. Annex B carries these positions over to the open source distribution chain and sets fairness conditions for coordination groups.

The text shows signs of recent integration, with two acknowledgement targets and a missing cross-reference between annexes, and does not explicitly attach itself either to the ISO/IEC standards in the field or to the NIS2 Directive. Its open licence and public revision process make it possible to address these points in subsequent versions.

The GCVE-BCP-02 version 2.0 guide is the primary source, read in full. The texts of the NIS2 Directive and the CRA, ENISA publications and the GCVE initiative’s pages are institutional or community primary sources. The information on ENISA’s CVE Root and on the launch of the EUVD comes from secondary sources.

1. CVE (1): Common Vulnerabilities and Exposures, a public identifier assigned to a vulnerability, and the programme that assigns these identifiers.
2. CISA (2): Cybersecurity and Infrastructure Security Agency, the US cybersecurity and infrastructure security agency.
3. CIRCL (3): Computer Incident Response Center Luxembourg, Luxembourg’s computer incident response centre, operator of the GCVE initiative.
4. NIS2 (4): Network and Information Security, Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union.
5. CVD (5): Coordinated Vulnerability Disclosure.
6. CSIRT (6): Computer Security Incident Response Team.
7. ENISA (7): European Union Agency for Cybersecurity.
8. CRA (8): Cyber Resilience Act, Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements.
9. SRP (9): Single Reporting Platform, the single reporting platform operated by ENISA under Article 16 of the CRA.
10. CNA (10): CVE Numbering Authority, an organisation authorised to assign CVE identifiers and publish their records.
11. EUVD (11): European Union Vulnerability Database, the European vulnerability database operated by ENISA.
12. KEV (12): Known Exploited Vulnerabilities, a catalogue of vulnerabilities whose exploitation has been observed; in GCVE-BCP-07, also an exploitation assertion attributed to a source.
13. GCVE (13): Global CVE Allocation System, a decentralised vulnerability identifier allocation system operated by CIRCL.
14. GNA (14): GCVE Numbering Authority, an organisation authorised to assign GCVE identifiers within its own numbering space.
15. BCP (15): Best Current Practice, a best practice document of the GCVE initiative.
16. PSIRT (16): Product Security Incident Response Team.
17. AI (17): Artificial intelligence.
18. CERT (18): Computer Emergency Response Team.
19. PGP (19): Pretty Good Privacy, an encryption and message signing standard, standardised as OpenPGP.
20. CVSS (20): Common Vulnerability Scoring System, a system for rating vulnerability severity.
21. SBOM (21): Software Bill of Materials, the list of a software product’s components.
22. SPDX (22): Software Package Data Exchange, a software bill of materials format maintained by the Linux Foundation.
23. CERT/CC (23): CERT Coordination Center, the coordination centre of Carnegie Mellon University.
24. NDA (24): Non-Disclosure Agreement.
25. TLP (25): Traffic Light Protocol, a FIRST marking protocol governing information sharing.
26. FIRST (26): Forum of Incident Response and Security Teams, the international forum of incident response teams.
27. LTS (27): Long Term Support, a branch maintained over a long period.
28. ISO/IEC (28): International Organization for Standardization and International Electrotechnical Commission, which jointly publish the standards in the field.
29. OWASP (29): Open Worldwide Application Security Project, a foundation dedicated to application security.
30. NIST (30): National Institute of Standards and Technology, the US standards and technology institute.
31. IETF (31): Internet Engineering Task Force, the standards body for internet protocols.
32. NKEV (32): No Known Exploitable Vulnerability, an assessment type introduced by version 3.0 of GCVE-BCP-07, alongside KEV assertions.

1. European Union, Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 (NIS2), Article 12. eur-lex.europa.eu
2. European Union, Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 (CRA), Articles 14, 16 and 24, Annex I. eur-lex.europa.eu
3. GCVE Working Group, GCVE-BCP-02 – Practical Guide to Vulnerability Handling and Disclosure, version 2.0, 28 October 2026. gcve.eu/bcp/gcve-bcp-02
4. ENISA, The CRA Single Reporting Platform is launched, 11 September 2026. enisa.europa.eu
5. Cloud Security Alliance, ENISA CVE Root: Dual Vulnerability Governance for Multinationals, 18 May 2026. labs.cloudsecurityalliance.org
6. Cloud Security Alliance, ENISA Restructures CVE Governance for the AI-Discovery Era, 11 August 2026. labs.cloudsecurityalliance.org
7. Infosecurity Magazine, European Vulnerability Database Launches Amid US CVE Chaos, 13 May 2025. infosecurity-magazine.com
8. CyberScoop, GCVE launches as a decentralized system for tracking software vulnerabilities, April 2025. cyberscoop.com
9. GCVE, GCVE – Global CVE Allocation System Announced, 16 April 2025. gcve.eu
10. GCVE, FAQ, accessed 28 October 2026. gcve.eu/faq
11. A. Dulaunoy, GCVE: A Decentralized Model for Vulnerability Identification, Publication, and Operational Enrichment, preprint, 2 June 2026. arxiv.org/pdf/2606.00856
12. GCVE, GNA 2 – EUVD, GNA registry, accessed 28 October 2026. gcve.eu/gna/2
13. GCVE, GCVE.eu – Best Current Practice (BCP), BCP index, accessed 28 October 2026. gcve.eu/bcp
14. GCVE, GCVE BCP-02 v1.9: Making Coordinated Vulnerability Disclosure Open, Accessible, and Practical for Everyone, 16 October 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, BSI catalogue entry. knowledge.bsigroup.com