Appendix B: Multi-Party Coordinated Vulnerability Disclosure in Open-Source Ecosystems

Purpose and scope

The vulnerability handling process described in 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. This appendix extends the guidance on coordinated vulnerability disclosure (CVD) to those downstream participants, with particular attention to trust groups, embargoes, operational failures, and shared responsibility for the security of open-source ecosystems.

The objective is not to make CVD more restrictive. It is to ensure that the people who can protect users have timely, actionable information, while preventing unnecessary disclosure of exploitable details. The recommendations are adaptable to the severity of the vulnerability, the maturity of the project, and the resources of the participants. They complement, rather than replace, the main BCP-02 process and the regulatory obligations described in Appendix A.

Recognising the full software distribution chain

An upstream project may publish source code and fixes, but users frequently install software through other channels, including:

• Operating-system distributions and vendors, including organisations maintaining long-term support branches and backported fixes.
• Third-party or community repositories, such as independent RPM repositories, including Remi, and language or scientific package ecosystems, such as conda-forge.
• Container-image publishers, cloud platforms, managed service providers, hosting companies, and appliance manufacturers.
• Commercial products and services that embed, modify, or redistribute an affected open-source component.
• Internal enterprise repositories, integrators, and organisations responsible for deploying updates to end users.

These relationships form a network, not necessarily a single linear chain. A package maintainer may simultaneously be downstream of a library, upstream of a container-image producer, and the direct supplier to another vendor. Each actor may have different release cycles, supported versions, update mechanisms, and technical constraints.

flowchart TD
    R[Reporter or researcher] --> U[Upstream project security team]
    U <--> C[CVD coordinator or trusted coordination group]
    C <--> D[Operating-system distributions and LTS vendors]
    C <--> P[Independent repositories and package ecosystems]
    C <--> I[Product integrators, container images and cloud providers]
    D --> X[Operators and users]
    P --> X
    I --> X

This diagram represents coordination and delivery relationships, not mandatory membership or a single required disclosure channel. Depending on the case, upstream maintainers may coordinate directly with downstream participants, or a trusted third party may facilitate that process.

Practical recommendation: As early as possible, identify the materially affected distribution and integration channels. Do not assume that fixing upstream source code means that users can immediately obtain a tested, deployable security update. Conversely, do not delay public guidance indefinitely while attempting to enumerate every downstream product.

Responsibilities of upstream and downstream participants

Upstream maintainers should provide a validated impact assessment, affected branches, a fix or suitable mitigation when available, a provisional disclosure schedule, and a point of contact. They should identify known downstream consumers where practical and avoid assuming that every downstream package can use the same version number or patch.

Downstream maintainers and redistributors should assess their own packages and supported branches, prepare and test backports where necessary, protect information shared in confidence, and communicate clearly with their users. They should report blockers or inability to meet the planned release time promptly. A downstream participant must not describe its product as fixed merely because an upstream fix exists.

Coordinators and trusted groups should provide a defined channel for relevant participants, maintain the disclosure plan, track dependencies and readiness, establish clear sharing rules, and support a timely transition to public advisories. They should help include maintainers who are important to user protection but lack an established security team or a large corporate sponsor.

Commercial integrators, cloud providers, and operators should track the security of components they deploy or redistribute, prepare updates or exposure-reduction measures, communicate product-specific impact, and contribute relevant technical findings to upstream and the coordinating group. Commercial use of open-source software does not transfer the entire security burden to unpaid upstream volunteers.

Where one organisation performs several of these roles, it should explicitly track each responsibility rather than relying on another participant to complete it.

Trusted coordination groups and limited embargoes

Trusted coordination groups can be 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 serve user protection rather than privileged access for a selected group of vendors.

A trusted coordination process should follow these principles:

1. Purpose-limited access. Share non-public information with participants who have a credible need and the ability to take protective action before disclosure. Do not grant privileged access solely because of market position, payment, or organisational prestige.
2. Fair and usable participation. Publish contact and eligibility criteria where appropriate. Account for independent repositories, small open-source projects, and community maintainers, not only large operating-system vendors. When full participation is impractical, a coordinator can provide restricted or staged information sufficient for a specific task.
3. Explicit confidentiality rules. State who may receive information, for what purpose, whether forwarding requires approval, and how suspected leaks should be reported. Use secure channels and appropriate access controls. FIRST’s Traffic Light Protocol (TLP) can help communicate restrictions, but the agreed coordination policy must also identify any narrower sharing boundaries.
4. Short, justified timelines. Agree on a disclosure date and time, including the time zone, and keep any embargo no longer than reasonably needed to protect users. Review the date when risk or release readiness changes. Avoid an open-ended embargo simply because one participant is not ready.
5. Actionable information. Provide sufficient information for packaging, backporting, testing, or mitigation. Recipients who cannot act on an embargoed notification do not necessarily benefit from detailed early access.
6. No exclusivity over public safety. If evidence of exploitation, a meaningful leak, or a dangerous delay changes the risk, reassess whether earlier public warning or release is preferable. Agreement within a private group cannot override applicable statutory reporting duties.

Existing practices offer useful precedents. The Openwall (linux-)distros coordination lists limit their embargo period to 14 days, favour shorter periods, and require an actionable reason for advance notification. This is an example of one community’s operating policy, not a universal deadline for all CVD cases. Some cases require immediate public guidance, while complex upstream remediation may begin well before a short downstream coordination window.

Preparing a coordinated multi-party release

The case owner or coordinator should maintain a minimal shared release plan recording:

• The unique vulnerability or case identifier, coordinator, upstream security contact, and relevant downstream contacts.
• Confirmed and potentially affected components, branches, package names, and product versions, including differences caused by backported fixes.
• The information required by each participant and the agreed confidentiality and redistribution rules.
• The planned disclosure date and time, release dependencies, decision owner, and escalation path.
• The status of patches, build and installation tests, release artifacts, update channels, and user-facing advisories.
• Known blockers, participants unable to deliver on time, available mitigations, and the criteria for changing the schedule.

Participants should consider whether private work could inadvertently become public through source-control activity, continuous integration logs, public package indexes, image registries, mirrors, build caches, release metadata, or publicly accessible artifacts. An unpublished advisory does not guarantee that an already accessible patched binary or source diff remains confidential. Publication of patched artifacts ahead of the agreed date should be coordinated and treated as a potential disclosure event if it reveals the vulnerability.

At public disclosure, upstream and downstream organisations should publish or link to actionable information for their own users. In particular, an upstream version number does not establish whether a distribution’s older-version package includes a security backport. Downstream advisories should identify their actual fixed package release, mitigation, and verification method, with references to the common vulnerability identifier where possible. An unknown package status should be stated as unknown, not silently treated as unaffected.

Handling a leak, an early release, or a disagreement

Information leakage, premature package publication, and observed exploitation are related risks but not equivalent events. A CVD group should not assume that a rumour proves a technical leak, that a leak establishes malicious exploitation, or that every early release has the same consequences.

When a significant coordination problem is reported, the case owner should:

1. Establish the facts. Determine what became accessible, when it happened, how reliable the evidence is, and whether the exposed information materially increases exploitation risk. Preserve relevant records without amplifying sensitive details.
2. Inform affected participants. Notify the upstream project, reporter, coordinator, and necessary downstream contacts through existing secure channels. Clarify what remains confidential and what is already public.
3. Reassess user risk and timing. Consider evidence of active exploitation, public reproducibility, available mitigations, patch readiness, and the remaining value of confidentiality. Do not preserve an embargo merely to avoid reputational embarrassment.
4. Choose a defensible response. Continue coordination if confidentiality and user protection still justify it; otherwise shorten or lift the embargo and publish accurate protective guidance, available fixes, and unresolved limitations.
5. Document and learn. Record the timeline, decisions, operational causes, communication gaps, and corrective actions. Avoid attributing deliberate wrongdoing without supporting evidence, and avoid using a single incident to conclude that all CVD processes have failed.

A disagreement among vendors should be escalated to the coordinator or another neutral third party where appropriate. A downstream participant should not independently break an agreed embargo solely because another participant has made an error, without first reassessing the practical consequences for users. Conversely, no participant should be required to keep users uninformed when earlier disclosure is necessary to reduce serious risk.

Open-source sustainability and emerging workloads

Multi-party CVD depends on work carried out by people: investigating reports, reproducing issues, reviewing patches, preparing backports, running release infrastructure, answering downstream questions, and maintaining advisories. In many open-source projects, a small group of maintainers performs these tasks for software used by organisations far larger than the project itself.

The increasing use of automated and AI-assisted vulnerability discovery and reporting can create genuine benefits, but also substantial triage costs when submissions are duplicated, unsupported, unverified, or generated at scale. A project should assess reports on technical merit, not merely on whether AI was involved. Reporters and organisations operating automated reporting systems should make reasonable efforts to validate findings, avoid excessive duplicate submissions, provide reproducible evidence, and offer a way to clarify their reports. Non-public vulnerability information should not be sent to external AI services without an explicit assessment of confidentiality and data-handling implications, as described in the main BCP.

Organisations that depend substantially on open-source components, particularly commercial platforms and large software consumers, should contribute to the sustainability of their security maintenance. Contributions can include funded maintainer time, engineering assistance, patch review, backporting, testing infrastructure, reproducible build facilities, security coordination staff, or financial support for independent projects and shared response infrastructure.

Support should strengthen the ecosystem without purchasing preferential embargo access, control over disclosure decisions, or an exclusive right to fixes. Coordinators and security communities should maintain forums in which upstream maintainers, independent packagers, large consumers, CERTs/CSIRTs, and platform operators can discuss operational bottlenecks and make concrete commitments. This responsibility extends beyond individual vulnerability cases and should be reviewed regularly.

Evaluating whether coordination worked

A coordinated disclosure should not be judged solely by whether an embargo stayed secret. A case can be handled responsibly while still encountering an unforeseen leak or late package. Equally, the absence of a public incident does not by itself prove that users received effective protection.

A post-disclosure review should consider whether:

• The materially affected upstream and downstream parties were reached in time to act.
• Participants had actionable technical information and clear sharing rules.
• Fixes and mitigations were tested, obtainable, and correctly communicated across relevant distribution channels.
• Users could determine whether their actual installed package or product was vulnerable or fixed.
• New evidence caused timely reassessment of disclosure and user risk.
• Reporting and coordination workloads were sustainable, and preventable delays or information exposure were addressed.

The aim is continuous improvement of a generally useful CVD process, not a presumption that confidentiality is always preferable or that every deviation invalidates the model. Trust is earned through responsible participation, proportionate information sharing, credible release commitments, and honest follow-up.

Relationship to BCP-02 and other guidance

This appendix supplements the sections Roles and Responsibilities, Coordinated Vulnerability Disclosure, Publishing Advisories, and Best Practices. It does not modify regulatory reporting obligations in Appendix A. A confidential coordination arrangement must not be interpreted as permission to miss a legally required notification or to withhold urgent protection advice when disclosure is necessary.