Explanation

Annex A Worked Example: Single-Vendor 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 A of the Vultron Protocol Specification: a two-party Coordinated Vulnerability Disclosure (CVD) case traced from first contact to closure. 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 A — Worked Example: Single-Vendor CVD [I]

This annex traces one two-party case from first contact to closure. Each step names the message sent and the state transition it reports, so the sequence can be read against the state machine sections (§6 Report Management (RM) State Machine through §9 Participant Embargo Consent (PEC) State Machine).

Four embargo outcomes are shown — accepted, rejected, countered, and accepted then revised — because embargo negotiation is where two-party cases most often diverge.

A Finder Becomes a Reporter

As mentioned in RM Interactions, Finders have a few hidden state transitions before the Coordinated Vulnerability Disclosure (CVD) process really begins. An example of this is shown in the figure below. The Finder must discover, validate, and prioritize their finding before initiating the CVD process.

---
title: Finder Pre-Report Steps
---
sequenceDiagram
    actor Finder
    Finder ->> Finder: Discover
    Finder ->> Finder: Validate
    Finder ->> Finder: Prioritize

Finders become Reporters when they report a vulnerability to someone else. The next figure shows a Finder sending a report (RS) in conjunction with an embargo proposal (EP) to a Vendor. The Vendor receives the report and updates their state accordingly. Then the Vendor replies to acknowledge receipt of the report and the embargo proposal, and confirms that they (i.e., the Vendor) are aware of the report (RK, EK, and CV, respectively). Note that the EK response is intended to convey receipt of the embargo proposal (EP) but does not constitute acceptance of the proposal. We will discuss that in the next subsection.

---
title: Finder Submits Report and Embargo Proposal
---
sequenceDiagram
    actor Finder
    actor Vendor
    Finder ->> Finder: Discover, Validate, Prioritize
    Finder ->> Vendor: RS, EP
    note right of Vendor: Report Received
    note right of Vendor: Embargo Proposed
    note right of Vendor: Vendor Aware
    Vendor -->> Finder: RK, EK, CV

Vendor Evaluates Embargo

In this section, we show a variety of responses a Vendor might have to an embargo proposal.

Vendor Accepts Embargo

First is a basic accept sequence in which the Vendor accepts the proposed embargo and tells the Reporter this through an EA message. The Reporter acknowledges this with an EK in response.

---
title: Vendor Accepts Embargo Proposal
---
sequenceDiagram
    actor Reporter
    actor Vendor

    Reporter ->> Vendor: EP
    note right of Vendor: Embargo Proposed
    Vendor -->> Reporter: RK
    Vendor ->> Reporter: EA
    activate Reporter
    activate Vendor
    note right of Vendor: Embargo Active
    Reporter -->> Vendor: EK
    deactivate Reporter
    deactivate Vendor

Vendor Rejects Embargo

Next we show a rejected proposal. As above, this is a simple sequence where the Vendor indicates their rejection of the proposal with an ER message, and the Reporter acknowledges this with an EK message.

---
title: Vendor Rejects Embargo Proposal
---
sequenceDiagram
    actor Reporter
    actor Vendor

    Reporter ->> Vendor: EP
    note right of Vendor: Embargo Proposed
    Vendor -->> Reporter: EK
    Vendor ->> Reporter: ER
    note right of Vendor: Embargo Rejected
    Reporter -->> Vendor: EK

Vendor Counterproposal

Here we demonstrate a Vendor embargo counterproposal. The Vendor responds to the Reporter's prior EP message with an EP message of their own. The Reporter initially acknowledges the counterproposal with an RK message and then evaluates it and accepts with an EA message. Finally, the Vendor acknowledges the acceptance with an EK message. Note, however, that there is no active embargo until the Reporter accepts it. This method of counterproposal might delay the establishment of an embargo.

---
title: Vendor Counterproposal
---
sequenceDiagram
    actor Reporter
    actor Vendor

    Reporter ->> Vendor: EP
    note right of Vendor: Embargo Proposed
    Vendor -->> Reporter: RK
    Vendor ->> Reporter: EP
    Reporter -->> Vendor: RK
    Reporter ->> Vendor: EA
    activate Vendor
    activate Reporter
    note right of Vendor: Embargo Active
    Vendor -->> Reporter: EK
    deactivate Vendor
    deactivate Reporter

Vendor Accepts then Proposes Revision

Yes, And...

"Yes-And" is a heuristic taken from improvisational theatre in which Participants are encouraged to agree with whatever their counterpart suggests and add to it rather than reject it outright. It serves as a good model for cooperation among parties who share an interest in a positive outcome.

Finally, the following diagram offers what we think is a better approach than a simple counterproposal. In this "Accept-then-Counter" sequence, we see that the Vendor initially accepts the Reporter's proposed embargo and immediately follows up with a revision proposal of their own. The difference is that by initially accepting the proposal, the Vendor ensures that they are in an active embargo state before attempting to renegotiate. The sequence shown here is intended to be consistent with the previous discussion surrounding default embargo strategies. One might think of this as the "Yes-And" rule for embargo negotiations.

---
title: Vendor Accepts then Proposes Revision
---
sequenceDiagram
    actor Reporter
    actor Vendor

    Reporter ->> Vendor: EP
    note right of Vendor: Embargo Proposed
    Vendor -->> Reporter: RK
    Vendor ->> Reporter: EA
    activate Vendor
    activate Reporter
    note right of Vendor: Embargo Active
    Reporter -->> Vendor: EK
    Vendor ->> Reporter: EV
    note right of Vendor: Embargo Revise
    Reporter -->> Vendor: RK
    Reporter ->> Vendor: EC
    note right of Vendor: Embargo Active
    Vendor -->> Reporter: EK 
    deactivate Vendor
    deactivate Reporter

Vendor Sets Priority

Here we show two responses from a Vendor in the course of prioritizing a report.

Vendor Accepts Report

This figure shows a Vendor accepting the report for further work (presumably to develop a patch) with an RA message.

---
title: Vendor Accepts Report
---
sequenceDiagram
    actor Reporter
    actor Vendor

    Vendor ->> Vendor: Receive, Validate, Prioritize
    Vendor ->> Reporter: RA
    note right of Vendor: Report/Case Accepted
    Reporter -->> Vendor: RK

Vendor Defers Report

On the contrary, this figure shows the Vendor deferring the report with an RD message. In both cases, the Reporter acknowledges the Vendor's messages with an RK message.

---
title: Vendor Defers Report
---
sequenceDiagram
    actor Reporter
    actor Vendor

    Vendor ->> Vendor: Receive, Validate, Prioritize
    Vendor ->> Reporter: RD
    note right of Vendor: Report/Case Deferred
    Reporter -->> Vendor: RK