GCVE BCP-02 v1.9: Making Coordinated Vulnerability Disclosure Open, Accessible, and Practical for Everyone

The GCVE initiative has published version 1.9 of GCVE BCP-02 — Practical Guide to Vulnerability Handling and Disclosure, introducing significant improvements to help software vendors, manufacturers, open-source maintainers, and security researchers establish effective Coordinated Vulnerability Disclosure (CVD) processes.

Coordinated Vulnerability Disclosure should not be a privilege reserved for large organizations with dedicated security teams, expensive compliance frameworks, or specialized legal departments. Every software developer and manufacturer, regardless of size or resources, should be able to receive, assess, remediate, and disclose security vulnerabilities responsibly. This is one of the fundamental principles behind GCVE BCP-02.

The updated document is freely available, openly developed, and distributed under the Creative Commons Attribution 4.0 (CC BY 4.0) license. Organizations can reuse, adapt, and integrate its recommendations into their own vulnerability-handling processes.

What’s New in BCP-02 v1.9?

The latest revision, published on 15 October 2026, significantly expands the operational guidance provided by BCP-02. The objective is to move beyond general principles and provide concrete recommendations that organizations can implement in their daily security operations.

The main improvements include:

• Graphical overviews of all processes: Eight Mermaid diagrams now illustrate the complete vulnerability-handling lifecycle, preparation, report intake and verification, investigation and update delivery, communication with reporters and users, coordinated disclosure, advisory publication and follow-up, and parallel CRA reporting. The flowcharts and communication sequence diagram make decision points, responsibilities, and feedback loops easier to follow. Explore the process overviews in BCP-02.

• Better preparation and internal coordination: Clearer responsibilities for vulnerability handling, including shared security contacts, backup personnel, incident ownership, and the authority to approve emergency security releases.

• Improved software supply-chain visibility: Recommendations for maintaining component inventories, tracking software dependencies, using machine-readable Software Bills of Materials (SBOMs), and identifying affected hardware and firmware versions. These practices are particularly relevant for manufacturers integrating third-party components into their products.

• More accessible vulnerability reporting: Organizations are encouraged to accept useful vulnerability reports even when they arrive through unexpected channels, without encryption, or outside a preferred reporting template. Reporting mechanisms should remain understandable, accessible, and usable by everyone.

• Risk-based vulnerability assessment: Additional guidance distinguishes technical severity from actual deployment risk, including exposure, exploitability, mitigation effectiveness, and evidence of active exploitation. The document also emphasizes the importance of distinguishing a product that is genuinely unaffected from one where a vulnerability has simply not yet been reproduced.

• Stronger responsibility for third-party vulnerabilities: Vendors and manufacturers remain responsible for assessing vulnerabilities in the components they integrate and distribute. Forwarding a report to an upstream supplier does not eliminate the responsibility to assess affected products, deliver mitigations or fixes, and inform users.

• Practical security update delivery: New recommendations cover trusted update channels, integrity verification, installation procedures, regression testing, and recovery mechanisms. Importantly, the guide recommends providing security updates without additional charges or forcing users to purchase unrelated upgrades.

• More realistic disclosure coordination: The guidance explicitly acknowledges that disclosure may sometimes be necessary before a fix is available, particularly when exploitation is occurring or users need information to protect themselves. Coordination should improve security rather than become a mechanism for indefinitely postponing disclosure.

• Continuous monitoring and improvement: The updated BCP encourages organizations to monitor vulnerability sources, track remediation effectiveness, verify update delivery, and maintain accurate advisories. It also clarifies the distinction between vulnerabilities known to be exploited and those merely assessed as exploitable, aligning with GCVE BCP-07.

These changes reinforce an important principle: vulnerability handling is not just about publishing an advisory. It is an operational process that starts before a vulnerability is discovered and continues after a security update has been released.

The initial v1.9 changes are available in the BCP-02 v1.9 GitHub commit.

Why Accessibility and Openness Matter

One of the challenges in vulnerability disclosure is the significant difference in resources and expertise between organizations.

A large software vendor might have a dedicated Product Security Incident Response Team (PSIRT), while a small manufacturer may rely on a handful of engineers. An open-source project might have only one or two maintainers, sometimes working voluntarily.

However, the security vulnerabilities affecting their products can have equally significant consequences for users.

We strongly believe that good vulnerability-handling practices should not depend on an organization’s financial resources or its ability to purchase specialized services.

A practical CVD process can begin with relatively simple measures: a public security contact, a documented reporting policy, a means of tracking vulnerabilities, a defined response workflow, and a commitment to communicating with researchers and users.

Not every organization needs an elaborate vulnerability-management platform. What matters is having a functioning and accountable process that can evolve as the organization develops its capabilities.

Openness is equally important. By publishing BCP-02 under an open license, the GCVE initiative encourages organizations to reuse and adapt the guidance rather than reinventing processes independently or depending on proprietary frameworks.

The goal is not to create yet another certification scheme or impose unnecessary administrative burdens. The goal is to make good security practices easier to understand, adopt, share, and improve.

Supporting Vendors and Manufacturers

For vendors and manufacturers, vulnerability handling is increasingly becoming an essential part of the product lifecycle.

Modern products often combine proprietary software, open-source libraries, embedded components, firmware, and external dependencies. A vulnerability discovered in one component can potentially affect many products and manufacturers.

A working CVD process must therefore extend beyond simply receiving reports.

Manufacturers need to understand what they ship, identify potentially affected products, coordinate with upstream suppliers, prepare and distribute security updates, and communicate clearly with their customers.

These requirements are particularly important in the context of the European Cyber Resilience Act (CRA), which introduces cybersecurity obligations for manufacturers of products with digital elements.

BCP-02 provides practical guidance that can help organizations develop and improve these operational capabilities. While the BCP does not replace regulatory obligations or guarantee compliance, it offers a reusable foundation for establishing a vulnerability-handling process.

Security should be built into the product lifecycle, not added as an administrative exercise when a vulnerability is reported or a regulatory deadline approaches.

CVD Is About Collaboration, Not Control

Coordinated Vulnerability Disclosure works when researchers, vendors, manufacturers, coordinators, and users can cooperate effectively.

Unfortunately, vulnerability disclosure is still sometimes perceived as an adversarial process. Reports may be ignored, rejected because they do not follow a specific format, or delayed indefinitely while affected users remain unaware of potential risks.

We believe this approach is counterproductive.

A security researcher who reports a vulnerability is providing valuable information that can help improve a product. Vendors should make this process as accessible as possible, acknowledge reports, communicate openly, and provide realistic expectations.

Similarly, disclosure coordination should not be confused with permanent confidentiality. There are circumstances in which warning users about a vulnerability, even without an available fix, is necessary to reduce the potential harm.

The updated BCP-02 explicitly recognizes these realities and encourages a pragmatic, risk-based approach.

The ultimate objective of CVD is not to protect a vendor’s reputation or control the publication of vulnerability information. It is to reduce risks and protect users.

An Open Best Current Practice That Can Evolve

GCVE Best Current Practices are community-driven documents designed to capture practical experience and encourage interoperability.

They are recommendations rather than mandatory requirements, and they evolve as operational practices improve.

This approach is especially important for vulnerability disclosure, where operational realities vary significantly between organizations, products, and communities.

BCP-02 is intended to remain a living document. Feedback from researchers, software developers, manufacturers, CSIRTs, and other stakeholders is essential to improving its usefulness.

The document is openly available, and we encourage organizations to use it as a starting point for their own policies, adapt it to their operational needs, and contribute improvements based on practical experience.

Good vulnerability disclosure practices should be public knowledge, not an exclusive capability or a competitive advantage.

By keeping these practices open, accessible, and reusable, we can help more vendors and manufacturers improve their security processes, reduce unnecessary barriers for researchers, and ultimately provide better protection for everyone.

Read, Reuse, and Contribute

The updated GCVE BCP-02 v1.9 is available through the following resources:

• BCP-02: Practical Guide to Vulnerability Handling and Disclosure
• Source and changes: GitHub — BCP-02 v1.9 update
• Community discussion: GCVE BCP-02 Public Review
• Other GCVE Best Current Practices: GCVE BCP Directory

We welcome contributions, comments, and practical feedback from the community.

Vulnerability disclosure should be accessible to everyone. The processes and knowledge needed to protect users should remain open, transparent, and freely reusable. This is what GCVE BCP-02 aims to support.