Appendix B: Multi-Party Coordinated Vulnerability Disclosure in Open-Source Ecosystems
Purpose and scope
The vulnerability handling process described in GCVE BCP-02 does not always involve only a reporter, an upstream developer, and an end user. Open-source software often reaches users through several independent organisations and maintainers, each responsible for packaging, integrating, distributing, deploying, or supporting the same component. A vulnerability may also be discovered by one of these downstream participants, rather than by a researcher contacting the upstream project directly.
This appendix provides additional guidance for multi-party coordinated vulnerability disclosure (CVD) across upstream projects, distributions, third-party repositories, forks, integrators, manufacturers, operators, reporters, and coordinators. It addresses preparation, case ownership, trusted groups and embargoes, cross-project releases, confidentiality, regulatory reporting, and the long-term sustainability of open-source security work.
The objective is not to make CVD more restrictive or bureaucratic. It is to help all parties who can protect users obtain timely, actionable information without unnecessarily exposing sensitive technical details. The guidance is proportionate to the risk, project size, available resources, and participants’ actual ability to act. It complements the main BCP-02 process and the EU Cyber Resilience Act (CRA) guidance in Appendix A; it does not replace either.
Preparing downstream relationships before a vulnerability is reported
Multi-party coordination works best when contact discovery does not begin during an urgent security incident. Projects with significant downstream adoption should maintain a lightweight, regularly reviewed map of their important downstream relationships and security contacts before a vulnerability arises, while recognising that no list can be exhaustive.
Preparation can include:
- Identifying major operating-system distributions, long-term support branches, independent repositories, package ecosystems, container-image publishers, and known product integrators that distribute or embed the software.
- Maintaining a private, access-controlled contact list of security contacts, backup contacts, communication preferences, and relevant supported branches. This list should not itself disclose confidential vulnerability cases.
- Publishing a discoverable upstream security contact, such as a
SECURITY.md file or a suitable security.txt endpoint, together with a clear reporting and coordination policy.
- Identifying existing trusted coordination groups and criteria for contacting additional downstream participants, including smaller volunteer-maintained repositories.
- Agreeing internally who can open a multi-party case, authorise information sharing, approve a release schedule, act if the regular maintainer is absent, and arrange regulatory escalation when applicable.
- Establishing a method to identify vendored dependencies, bundled source copies, forks, and products that reuse a component without receiving upstream updates automatically. Dependency inventories, package metadata, software bills of materials (SBOMs), and other provenance information can help, but may be incomplete.
- Periodically testing the contacts and procedures, removing obsolete entries, and updating known release channels and points of contact.
A downstream maintainer should likewise know how to contact upstream securely and where to seek coordination assistance if the upstream project is unresponsive. Small projects are not expected to construct a complete supply-chain registry; a maintained set of key contacts and a documented fallback path are already valuable.
Practical recommendation: Prepare the relationships before a case whenever feasible, then validate and expand the participant list as soon as a specific vulnerability is identified. Neither the existence of a contact list nor the absence of an entry automatically entitles an organisation to embargoed information.
Recognising the full software distribution chain
An upstream project may publish source code and fixes, but users often obtain software through intermediate channels, including:
- Operating-system distributions and vendors, including organisations maintaining long-term support branches and backported security fixes.
- Independent repositories (such as RPM or DEB) as well as language-specific and scientific packaging ecosystems such as conda-forge.
- Container-image publishers, cloud platforms, managed service providers, hosting companies, and appliance manufacturers.
- Forks, downstream patch sets, bundled or vendored source copies, statically linked components, and commercial products or services embedding open-source components.
- Internal enterprise repositories, system integrators, deployment operators, and organisations delivering updates to end users.
The relationships form a network, not a single one-way chain. A distribution may discover a defect and report it upstream; an upstream maintainer may request help from downstream packagers; a customer may report a problem in a bundled copy before the original project is aware of it. The same organisation may be a downstream consumer of one component and an upstream supplier to many others.
flowchart TD
R["Reporter or researcher"] <--> C["Case owner or CVD coordinator"]
U["Upstream project or security team"] <--> C
D["Distributions and LTS maintainers"] <--> C
P["Independent repositories and forks"] <--> C
I["Integrators, image publishers and manufacturers"] <--> C
D <--> U
P <--> U
I <--> U
D --> X["Operators and users"]
P --> X
I --> X
X -. "Findings and deployment feedback" .-> D
X -. "Findings and deployment feedback" .-> P
X -. "Findings and deployment feedback" .-> I
The diagram shows possible bidirectional information flows, not mandatory group membership or a fixed hierarchy. The coordinator may be the upstream project, a downstream participant, an independent CERT/CSIRT, a GCVE Numbering Authority (GNA), or another agreed facilitator. Not every case needs a separate coordinator.
A vulnerability in a shared component can affect multiple products and package versions differently. In particular, a fork or vendored copy may have diverged substantially, and an old-looking distribution package may already contain a security backport. Coordinators should not assume that upstream version numbers alone determine whether a downstream product is vulnerable or fixed.
Starting a case from upstream or downstream
When a downstream participant discovers the vulnerability
A distributor, repository maintainer, integrator, or operator who finds a vulnerability should seek to notify the relevant upstream project through its security channel, where feasible and appropriate, while beginning to assess the impact on its own users. The initial report should include the evidence needed to reproduce or investigate the issue, the affected component and versions, any known exploitation evidence, and the reporter’s intended disclosure deadline where applicable.
The downstream participant should not assume that upstream will automatically lead the case. Participants should promptly establish who owns technical remediation, who coordinates the disclosure, and who publishes package- or product-specific advisories. If an upstream fix is appropriate, participants should cooperate on a reusable correction; downstream-specific mitigations or urgent protective actions may still be necessary.
Where a downstream participant is also the original reporter, the parties should explicitly agree how the report may be redistributed and which dates govern public disclosure. A distribution’s own release calendar is not, by itself, permission to extend the reporter’s deadline.
Vendored components, forks, and difficult-to-identify consumers
Bundled source copies, forks, and vendored dependencies can be harder to locate than packages distributed through an established repository. A fix in the original project may not reach products that have copied, frozen, modified, or statically linked the vulnerable code.
The case owner should use available dependency information, advisories, package identifiers, SBOMs, known forks, and community contacts to identify materially affected consumers. When a shared component has broad or uncertain reach, the advisory should explicitly warn that downstream copies may require separate assessment and fixes. Do not claim that all consumers have been reached, or postpone user protection indefinitely while attempting to identify them.
When upstream is unresponsive, discontinued, or abandoned
A missing upstream response does not mean that no one can coordinate a vulnerability or protect users. After reasonable, documented contact attempts, the reporter or affected downstream parties may request assistance from an independent coordinator, a relevant CERT/CSIRT, a GNA, or another trusted community group.
The participants should designate an acting case coordinator with a clear contact point, disclosure timetable, escalation process, and record of affected downstream products. This role is operational: it does not imply ownership of an abandoned project, authority to bind all downstream vendors, or transfer of each manufacturer’s legal obligations. Individual downstream maintainers remain responsible for their own packages and protective communications.
Depending on the risk and technical feasibility, parties may prepare independent patches or backports, temporary mitigations, notices of unsupported software, or migration advice. Attempts to reach upstream should continue where useful, but an unresponsive project should not create an indefinite embargo or prevent necessary warnings to users.
Respecting the original reporter and the disclosure timeline
The reporter is a participant in the coordination process, not merely a source of technical data. Before extending a report to a trusted group or additional vendors, the receiving organisation should discuss and agree the scope of sharing with the reporter, unless that scope is already established by the applicable reporting policy or another valid agreement. Record any restrictions on technical details, identity, attribution, and contact information. Minimise sharing of personal information that other participants do not need.
The case owner should record the reporter’s original planned disclosure date, the agreed publication date and time (including time zone), and any subsequent changes. Adding downstream participants must not silently reset the reporter’s clock or give a coordination group unilateral authority to extend it. If further time is needed, explain the dependency and seek a new agreement with the reporter as early as possible. An inability to agree should be escalated and documented rather than concealed.
Reporter consent to voluntary sharing and confidentiality commitments must also be distinguished from mandatory regulatory reporting or urgent measures needed to protect users. Organisations should assess any lawful obligation to disclose relevant information, share no more than necessary, and inform the reporter when appropriate and possible. Consent requirements must not be presented as a veto over statutory reporting duties or over independent reports made in good faith.
Responsibilities of participating organisations
Upstream maintainers should validate technical impact, identify affected supported branches, prepare a fix or mitigation where feasible, provide a security contact, communicate with the reporter, and help downstream consumers assess whether the same issue affects their packaging or modified code. They should not promise that every downstream product is fixed by the release of an upstream patch.
Downstream maintainers and redistributors should assess their actual shipped code, prepare and test patches or backports, protect information received in confidence, report blockers promptly, and publish product-specific fixed-package versions or mitigations. They should also contribute upstream fixes and findings where possible, not simply consume embargoed information.
Case owners, coordinators, and trusted groups should maintain an actionable participant list, define the confidentiality boundary, record key dates and decisions, track the reporter’s preferences and deadline, communicate changes in exploitation evidence, and support an orderly transition to public advisories. Coordinators should make a reasonable effort to include relevant independent and volunteer-maintained channels, not just major vendors.
Commercial manufacturers, integrators, cloud providers, and operators should track affected embedded components, support their own customers, prepare fixes and mitigations, contribute technical findings and testing resources, and evaluate regulatory duties attached to their role. They should not shift the entire maintenance and coordination burden to unpaid upstream volunteers.
When one organisation fills several roles, those responsibilities should be explicitly assigned. A shared CVD case does not substitute for each participant’s product-security decisions, communication duties, or applicable legal obligations.
Trusted coordination groups and limited embargoes
Trusted coordination groups can be valuable, and sometimes necessary, when multiple downstream teams need private technical information to prepare compatible security updates. Their existence is not, by itself, a failure of openness. Their legitimacy depends on whether they improve user protection rather than create privileged access for a selected group of vendors.
A coordination group should apply the following principles:
- Purpose-limited participation. Share non-public information with parties who have a credible reason and the ability to prepare a protective action. Participation should not depend solely on company size, payment, or market position.
- Fair and workable access. Use documented criteria and workable channels for smaller projects, independent repositories, volunteer maintainers, and downstream integrators. Where full membership is impractical, use targeted disclosure to parties that need to act.
- Reporter-aware sharing. Respect agreed restrictions on redistribution, attribution, and timing. Ask before broadening the audience when the original policy or consent does not cover it.
- Explicit confidentiality boundaries. Define who may receive technical information, onward-sharing rules, secure-channel expectations, suspected-leak reporting, and permitted uses. FIRST’s Traffic Light Protocol (TLP) can express sharing expectations, but it does not replace explicit rules about the participants and purposes of a particular case.
- Mandatory-notification exception. State clearly that confidential notifications required by applicable law or regulation, including relevant CRA submissions through the Single Reporting Platform, are not breaches of a CVD embargo. Such notifications are distinct from public advisories. Parties should protect the submitted information and need not distribute the content of regulatory reports to the group.
- Short, justified schedules. Specify a release date and time with a time zone, decision owner, and a documented reason for the coordination period. Avoid indefinite embargoes while waiting for a single participant.
- Actionable technical content. Share sufficient information for recipients to identify affected code, build and test fixes, prepare mitigations, and communicate accurately. Early access without an actionable purpose has limited value.
- Reassessment when risk changes. Evidence of exploitation, a meaningful leak, an early artifact release, or a serious remediation delay should trigger a review of the disclosure plan. Private agreement cannot override applicable legal deadlines or the need for urgent protective advice.
The Openwall (linux-)distros coordination lists provide one established model: their policy sets a maximum embargo period of 14 days and favours shorter periods. This is that community’s policy, not a universal CVD deadline. Complex remediation may begin earlier, with a shorter final downstream coordination window, and some vulnerabilities require immediate public guidance.
Preparing and delivering a coordinated multi-party release
The case owner or coordinator should maintain a concise, access-controlled shared release plan that records:
- A common vulnerability or case identifier, preferably a GCVE or other established identifier where appropriate, together with aliases and the identifier-allocation contact (see GCVE BCP-04).
- The original reporter, any agreed anonymity or attribution requirements, the reporter’s disclosure deadline, and the permitted scope of information sharing.
- The case coordinator and backups, upstream security contact, participating downstream contacts, and any known missing or unresponsive parties.
- Affected and potentially affected components, forks, vendored copies, products, branches, package releases, and known differences caused by backports.
- Information each party needs to act, its sharing restrictions, and any relevant technical or regulatory escalation contacts.
- The agreed public release date and time, dependencies, decision owner, criteria for changing the schedule, and escalation path when participants disagree.
- Patch, backport, build, test, package-signing, publication, mirror, and user-advisory readiness; available mitigations; and parties unlikely to meet the schedule.
- An explicit channel and format for communicating evidence of exploitation, changes in impact, and other time-critical facts that may affect participants’ regulatory duties.
The coordinator should consider whether confidential technical information could become public through source-control activity, pull requests, CI logs, public build systems, package indexes, image registries, mirrors, release metadata, caches, or accessible release artifacts. Publishing a patched binary or diff before the agreed date can make the vulnerability discoverable even if the advisory remains private.
At public disclosure, upstream and downstream parties should publish or link to actionable information for their own users. In particular, downstream advisories should name the actual fixed package release, backport status, supported branches, mitigation, and verification method where possible. A common vulnerability identifier improves correlation, but does not replace precise product- and package-specific information. If a product’s status remains unknown, say so explicitly rather than treating it as unaffected.
CRA considerations in multi-party cases
This subsection supplements Appendix A. It is operational guidance, not legal advice. Article 14 CRA reporting obligations have applied to manufacturers since 11 September 2026. The corresponding duties for open-source software stewards under Article 24(3) are scheduled to apply from 11 December 2027. Organisations must determine their own legal status and obligations under the applicable rules; participation in a trusted group does not automatically make every participant a manufacturer or create an Article 14 reporting duty.
Several manufacturers may share an embargoed case involving the same underlying vulnerability while each independently evaluates its obligations for its own affected product with digital elements. The key coordination practices are:
- Flag potentially reportable evidence explicitly. When credible evidence of active exploitation or a severe product-security incident is shared in the group, mark the message clearly, provide the evidence and observation or receipt timestamp, distinguish confirmed facts from hypotheses, and alert participants that may be subject to Article 14 to assess their obligations immediately. The group should not bury this change in routine patch discussion. Sharing the evidence may be the first point at which a manufacturer becomes aware of a reportable event, but mere membership or receipt of an unverified allegation does not automatically establish that the statutory threshold is met for every participant.
- Track awareness and deadlines independently. Every potentially affected manufacturer should record when it became aware of facts relevant to an actively exploited vulnerability in its product or a qualifying severe incident, assess applicability promptly, and retain its own decision and rationale. Where Article 14 is triggered, an early warning is required without undue delay and in any event within 24 hours of awareness, with a notification within 72 hours of awareness, and the applicable final-report deadline thereafter. These deadlines do not wait for upstream confirmation, identifier assignment, embargo expiry, or the coordinator’s release decision.
- Permit confidential regulatory notification. The group’s rules should explicitly allow mandatory notifications via the CRA Single Reporting Platform (SRP) and other applicable legal channels without treating the act of notifying as an embargo violation. A notifying participant should inform the case coordinator that a notification was made when legally permissible and operationally useful, but need not provide its submission text, regulatory case number, or other protected details to the group. The coordinator should not assume that an SRP notification is a public disclosure.
- Use a common vulnerability identifier where feasible. Agree on a stable GCVE ID, CVE ID, or other appropriate identifier, preserve known aliases, and recommend that participants reference it in their applicable SRP submissions and public advisories. This helps authorities and CSIRTs correlate reports about the same underlying weakness without conflating distinct affected products or separate legal notifications. The coordinator may record the preferred identifier in the release plan and follow the identifier-allocation guidance in BCP-04. A shared identifier does not replace individual reporting or guarantee automatic linking by the SRP.
- Keep the two tracks separate. CVD coordinates investigation, remediation, downstream notification, and public disclosure. CRA reporting is a separate confidential statutory process performed by the party responsible under the regulation. A group coordinator should not assume it can report on behalf of another manufacturer without the necessary authority, and receipt or completion of an SRP submission does not mean the vulnerability has been remediated or publicly disclosed.
Participants should refer to Appendix A of BCP-02, the CRA Regulation (EU) 2024/2847, and ENISA’s SRP guidance and FAQ for the applicable definitions, staged reporting duties, and current operational instructions.
Handling a leak, an early release, or a disagreement
Information leakage, premature package publication, observed exploitation, and a deliberate change in disclosure timing are related risks but not equivalent events. A rumour does not necessarily establish that exploitable information became public; a leak does not by itself prove malicious exploitation; and an early vendor release may have consequences that differ from those of a technical leak.
When a significant coordination problem arises, the case owner should:
- Establish the facts. Record what became accessible, when, how credible the evidence is, whether details are practically exploitable, and whether users are exposed. Preserve relevant records without amplifying sensitive information.
- Notify the necessary participants. Inform the reporter, upstream contacts, downstream maintainers, and relevant coordinators securely. Distinguish what is confirmed public from what remains confidential, and flag any evidence that may affect regulatory reporting.
- Reassess user protection and the clock. Revisit available fixes, real-world exploitation, defensive mitigations, disclosure commitments, reporter deadlines, and the likely consequences of preserving or ending the embargo. Do not keep an embargo merely to avoid embarrassment.
- Make and communicate a defensible decision. Continue coordination only if confidentiality still protects users. Otherwise shorten or end the embargo, release fixes or mitigations where available, and issue accurate protective advice that explains remaining uncertainties.
- Record decisions and learn. Document the timeline, communication failures, operational causes, remedial steps, and lessons. Do not infer deliberate wrongdoing without evidence or use one problematic release to conclude that all CVD processes fail.
Disagreements between a reporter, an upstream project, and downstream participants should be escalated to the identified coordinator or another neutral party where appropriate. An error by one member does not automatically justify another member’s unilateral embargo break, but neither does the group have authority to suppress urgent warnings or legal notifications. The aim is a proportionate, documented decision based on the actual risk to users.
Confidentiality when using external services and AI-assisted tools
Confidential handling should be technology-neutral and risk-based. The relevant questions concern the sensitivity of the data, the parties authorised to receive it, the controls used by the service, and the possibility of unintentional disclosure. These questions apply to an AI-assisted analysis service as well as to cloud collaboration, hosted issue trackers, messaging platforms, and other third-party tools.
Before transmitting embargoed reports, proof-of-concept material, patches, or personal data to any external service, participants should consider:
- Whether the service is approved for the case’s confidentiality classification and permitted recipients, and whether the reporter’s sharing conditions cover the disclosure.
- Contractual guarantees and technical settings for retention, use for model training or service improvement, access by provider staff, subprocessors, logging, and incident notification.
- The ability to restrict access, minimise or redact submitted data, delete or expire it appropriately, and verify the controls that matter for the particular service.
- The possibility of accidental disclosure through prompts, generated outputs, shared workspaces, telemetry, integrations, retrieval systems, or insecure links.
- Applicable legal, data-protection, and cross-border transfer requirements, as well as the organisation’s own information-handling policy.
Disabling a service’s model-training or improvement option may reduce one risk but does not, by itself, establish that confidential information is adequately protected. Equally, use of an AI service does not automatically make it less suitable than another external service with comparable controls. A locally operated or otherwise appropriately isolated service may be preferable for particularly sensitive cases. The decision should be based on the actual service design, enforceable terms, controls, and threat model rather than on broad assumptions about a technology category.
Where AI-assisted tools are used to analyse vulnerability data or draft advisories, their technical conclusions and generated text should be validated by a qualified human, consistently with the main BCP-02 guidance. A tool’s output should not be treated as independent evidence of exploitation or as a substitute for product-specific testing.
Open-source sustainability and emerging reporting workloads
Multi-party CVD relies on people who reproduce vulnerabilities, review patches, manage secure releases, maintain packaging branches, prepare advisories, and support affected users. Many open-source projects carry out this work with limited resources even when their software is embedded in products operated by much larger organisations.
Automated and AI-assisted vulnerability discovery may improve coverage, but can also impose substantial triage costs when reports are duplicated, speculative, unverified, or submitted at scale. Reports should be assessed on technical merit rather than solely on whether AI was involved. Reporters and operators of automated reporting systems should validate claims as far as practicable, provide reproducible evidence, avoid unnecessary duplicates, and remain available for clarification.
Organisations that substantially depend on open-source components, particularly commercial platforms and large software consumers, should help sustain the security work on which they rely. Support may take the form of funding maintainer time, contributing engineering or security staff, maintaining backports, providing build and test infrastructure, assisting incident response, or supporting independent coordination services. Such contributions should not purchase preferential access to embargoed cases, exclusive fixes, or control of disclosure decisions.
Upstream maintainers, packagers, manufacturers, security communities, CERTs/CSIRTs, and major software consumers should maintain practical forums for identifying coordination bottlenecks and agreeing concrete improvements. The distribution of responsibility should be revisited regularly; sustainable CVD cannot rest indefinitely on the goodwill of a small number of maintainers.
Evaluating whether coordination worked
A coordinated disclosure should not be assessed only by whether an embargo remained secret. A generally effective process may still encounter a leak or a late package; conversely, a quiet disclosure is not necessarily successful if users could not obtain suitable protection.
A post-disclosure review should consider whether:
- Important upstream and downstream participants were identifiable and reachable, ideally through contacts established before the case.
- The original reporter was kept informed, and permissions, attribution, and any disclosure deadline were respected or explicitly renegotiated.
- A downstream-origin report or an unresponsive upstream project had a clear coordination path and accountable acting coordinator.
- Forks, vendored copies, and bundled components were considered, with residual uncertainty communicated honestly.
- Participants had actionable information, reasonable confidentiality rules, and tested fixes or mitigations.
- Users could determine the status of their installed package, fork, image, or product, including downstream backports.
- New exploitation evidence triggered timely technical and, where relevant, regulatory assessment without confusing an embargo with statutory reporting deadlines.
- External services were used in a manner consistent with confidentiality obligations and the actual risks of the tools involved.
- Coordination and reporting workloads were sustainable and avoidable delays or information exposure led to improvements.
The aim is continuous improvement of CVD as a cooperative security process. Trust is earned through equitable participation, proportionate sharing, transparent decisions, credible release commitments, and responsible follow-up.
Relationship to BCP-02 and other guidance
This appendix supplements the sections Roles and Responsibilities, Preparing for Vulnerability Handling, Communicating with Submitters and Users, Coordinated Vulnerability Disclosure, Publishing Advisories, and Best Practices of BCP-02. In particular, the subsection CRA considerations in multi-party cases expands on Appendix A: EU Cyber Resilience Act Reporting, and should be cross-referenced from Appendix A when this annex is incorporated into the full BCP.
A confidential coordination agreement must not be interpreted as permission to delay a legally required notification, override the reporter’s agreed rights, or withhold urgent and necessary protection advice. This appendix provides recommended practices and does not create new legal duties or transfer existing duties between organisations.
Further reading
