Skip to content
Explanation

Annex B Worked Example: Multi-Party CVD

The whole specification on one page

The specification is also published as a single page that holds every section and annex in order, for printing or for searching the whole text at once.

This page holds informative Annex B of the Vultron Protocol Specification: a Coordinated Vulnerability Disclosure (CVD) case with a coordinator and a second vendor. Its two-letter message codes, such as RS for Report Submission, are defined in §4.1 Report Management Messages through §4.3 Case State Messages.

Annex B — Worked Example: Multi-Party CVD [I]

This annex extends Annex A to a case with a coordinator and a second vendor. It shows the coordinator acting as proxy for the reporter, a participant joining a case that already has an active embargo, and the teardown-publish-close sequence across three parties.

Coordination With a Coordinator

The next two diagrams show the process of a Reporter engaging a Coordinator, who, in turn, engages a Vendor. The process begins in the first diagram with the Reporter sending a report along with an embargo proposal to the Coordinator (\(RS,EP\)). The Coordinator acknowledges receipt with an \(RK,EK\) response. After evaluating the proposed embargo, the Coordinator accepts it with an EA message. The Coordinator proceeds to validate and prioritize the report, emitting an RV and RA along the way.

---
title: Reporter Engages Coordinator
---
sequenceDiagram
    actor Reporter
    actor Coordinator

    Reporter ->> Coordinator: RS,EP
    note right of Coordinator: Report Received
    note right of Coordinator: Embargo Proposed
    Coordinator -->> Reporter: RK,EK
    Coordinator ->> Reporter: EA
    activate Coordinator
    activate Reporter
    note right of Coordinator: Embargo Active
    Reporter -->> Coordinator: EK
    Coordinator ->> Reporter: RV
    note right of Coordinator: Report Valid
    Reporter -->> Coordinator: RK
    Coordinator ->> Reporter: RA
    note right of Coordinator: Report/Case Accepted
    Reporter -->> Coordinator: RK
    deactivate Coordinator
    deactivate Reporter

Coordinator-as-proxy can be sub-optimal

In this scenario, we are showing the Coordinator acting as a proxy between the Reporter and the Vendor. While this reflects the way CVD has been practiced in the past, it is not necessarily the most efficient way to operate. CVD Platforms like VINCE have demonstrated that bringing CVD case participants into a shared space can make the process more efficient.

In the next diagram, the Coordinator now acts as a proxy for the Reporter, notifying the Vendor and passing along the embargo information through an \(RS,EP\) message of its own. The Vendor accepts the existing embargo (EA) and proceeds to validate (RV) and prioritize (RA) the report. Relevant responses from the Vendor are passed through to the Reporter. Having accepted the report for further work, the Vendor continues with creating a fix for the reported vulnerability. When complete, the Vendor conveys their readiness to the Coordinator, who in turn passes this information along to the Reporter through the CF message.

---
title: Coordinator Notifies Vendor
---
sequenceDiagram
    actor Reporter
    actor Coordinator
    actor Vendor

    Coordinator ->> Vendor: RS,EP
    Vendor -->> Coordinator: RK,EK,CV
    Coordinator ->> Reporter: CV
    Vendor --> Vendor: Evaluate Embargo
    Reporter -->> Coordinator: CK
    activate Vendor
    note right of Vendor: Embargo Active
    Vendor ->> Coordinator: EA
    activate Coordinator
    Coordinator ->> Reporter: EA
    activate Reporter
    Vendor --> Vendor: Validate Report
    Coordinator -->> Vendor: EK
    Reporter -->> Coordinator: EK

    note right of Vendor: Report Valid
    Vendor ->> Coordinator: RV
    Vendor --> Vendor: Prioritize Report
    Coordinator -->> Vendor: RK

    note right of Vendor: Report/Case Accepted
    Vendor ->> Coordinator: RA
    Vendor --> Vendor: Create Fix
    Coordinator -->> Vendor: RK

    note right of Vendor: Fix Ready
    Vendor ->> Coordinator: CF
    Coordinator ->> Reporter: CF

    Coordinator -->> Vendor: CK
    Reporter -->> Coordinator: CK
    deactivate Vendor
    deactivate Coordinator
    deactivate Reporter

Embargo Teardown, Publish, and Close

Any Participant can initiate an embargo teardown. We happened to show the case where the Coordinator initiates it in the following diagram, sending an embargo termination message (ET) to all parties in the case (Reporter and Vendor in this scenario). Recipients of the ET message acknowledge receipt and update their EM state accordingly.

Embargo Teardown, Publication, and Closure Can Start with Any Participant

Note that for all three scenarios in this section, there is no specific order in which Participants must act. We could just as easily have shown the Reporter initiating an embargo teardown because of a leaked media report or the Vendor exiting an embargo early because they had their fix ready sooner than expected.

---
title: Coordinator Initiates Embargo Teardown
---
sequenceDiagram
    actor Reporter
    actor Coordinator
    actor Vendor

    Coordinator ->> Reporter: ET
    Coordinator ->> Vendor: ET
    note right of Vendor: Embargo Terminated
    Reporter -->> Coordinator: EK
    Vendor -->> Coordinator: EK

Embargo Termination is not Publication

Our protocol only sets a discrete end to the embargo period, it intentionally does not address a publication schedule. Once the embargo has been exited, any Participant may publish at any time. Participants might choose to coordinate publication schedules more closely, but there is nothing in the protocol to require it. With the recognition that more concise publication scheduling might be needed in some situations, we revisit this concern in Process Implementation Notes.

Publishing After Embargo Teardown

Once the embargo has been exited, any Participant may now publish. In the following figure, we show the Vendor publishing first. They notify the Coordinator that they have published using a CP message to convey that information about the vulnerability is now public. The Coordinator relays this information to the Reporter. Both the Reporter and the Coordinator publish their own reports shortly thereafter.

---
title: Publishing After Embargo Teardown
---
sequenceDiagram
    actor Reporter
    actor Coordinator
    actor Vendor

    Vendor --> Vendor: Publish
    note right of Vendor: Public Aware
    Vendor ->> Coordinator: CP
    Coordinator ->> Reporter: CP
    Reporter -->> Coordinator: CK
    Reporter --> Reporter: Publish
    Reporter ->> Coordinator: CP
    Coordinator ->> Vendor: CP
    Coordinator -->> Reporter: CK
    Vendor -->> Coordinator: CK
    Coordinator --> Coordinator: Publish
    Coordinator ->> Reporter: CP
    Coordinator ->> Vendor: CP
    Reporter -->> Coordinator: CK
    Vendor -->> Coordinator: CK

Report Closure is a Per-Participant Choice

Report closure is a per-Participant choice. We chose to show a simple case where all Participants agreed at approximately the same time that there was nothing further to be done. This will not always be the case, nor is it necessary.

Closing the Case

Having no further work to be done on the case, the Reporter closes their report and tells the Coordinator using an RC message in the next diagram. This prompts the Coordinator to review their outstanding tasks and decide to initiate the closure of their own report. In turn, the Coordinator relays this to the Vendor, who also closes their report.

---
title: Participants Close Their Reports
---
sequenceDiagram
    actor Reporter
    actor Coordinator
    actor Vendor

    Reporter --> Reporter: Close
    Reporter ->> Coordinator: RC
    Coordinator -->> Reporter: RK
    Coordinator --> Coordinator: Close
    Coordinator ->> Vendor: RC
    Vendor -->> Coordinator: RK
    Vendor --> Vendor: Close
    note right of Vendor: Case Closed
    Vendor ->> Coordinator: RC
    Coordinator -->> Vendor: RK

Runnable scenarios

The reference implementation ships these flows as executable scenarios, which are the most current statement of what it supports: