Vultron Process Models
Vultron Process Models
---
title: Each Process Interacts With the Other Two
---
flowchart TD
RM[[Report Management]]
EM[[Embargo Management]]
CS[[Case State]]
RM --> EM
RM --> CS
EM --> RM
EM --> CS
CS --> EM
CS --> RMThe Vultron Protocol describes a Coordinated Vulnerability Disclosure (CVD) case with three process models:
- Report Management (RM) tracks each Participant's handling of the report.
- Embargo Management (EM) tracks whether the case has an agreement to keep the vulnerability private for a time.
- Case State (CS) tracks what has happened to the vulnerability itself, such as whether a fix is ready or the public is aware.
Each model is a deterministic finite automaton (DFA): a state machine with a fixed set of states in which every action leads from one state to exactly one next state. The inset at right shows that each process interacts with the other two in the context of a CVD case.
A CVD case is coordinated by multiple agents, such as Reporters, Vendors, and Coordinators, each running these processes in parallel and interacting with each other. The diagram below shows two such agents, each running all three processes and exchanging messages with the other.
---
title: Vultron Protocol Agents Interacting
---
flowchart LR
subgraph Agent2
RM2[[Report Management]]
EM2[[Embargo Management]]
CS2[[Case State]]
end
subgraph Agent1
RM1[[Report Management]]
EM1[[Embargo Management]]
CS1[[Case State]]
end
RM1 --> EM1
RM1 --> CS1
EM1 --> RM1
EM1 --> CS1
CS1 --> EM1
CS1 --> RM1
RM2 --> EM2
RM2 --> CS2
EM2 --> RM2
EM2 --> CS2
CS2 --> EM2
CS2 --> RM2
Agent1 --> Agent2
Agent2 --> Agent1Report Management process
The RM process covers how each Participant receives, validates, prioritizes, works on, and closes a report. Each Participant has its own RM state, and only that Participant changes it. Anyone familiar with IT service management workflows, such as incident or problem management, will recognize its shape. The diagram below shows the seven RM states and the actions that move a report between them.
---
title: Report Management State Diagram
---
stateDiagram-v2
direction LR
S: Start
R: Received
I: Invalid
V: Valid
D: Deferred
A: Accepted
C: Closed
[*] --> S
S --> R : receive
R --> I: invalidate
R --> V : validate
I --> V : validate
V --> A : accept
V --> D : defer
A --> D : defer
D --> A : accept
R --> C : close
A --> C : close
D --> C : close
I --> C : close
C --> [*]Read more about Report Management
Embargo Management process
The EM process covers how the Participants propose, agree to, revise, and end an embargo. There is one EM state per case, shared by all its Participants. An embargo-eligible case begins with an Active embargo when the case is created. The diagram below shows the EM states and the actions that move the case between them.
---
title: Embargo Management State Diagram
---
stateDiagram-v2
direction LR
[*] --> None
state Pre-Embargo {
None --> Proposed : propose
Proposed --> Proposed : propose
Proposed --> Proposed : reject
Proposed --> None : reject
}
state Active_Embargo {
Active --> Revise : propose
Revise --> Active : accept
Revise --> Active : reject
Revise --> Revise : propose
Revise --> Revise : accept
Revise --> Revise : reject
Revise --> eXited : terminate
Active --> eXited : terminate
}
state Post-Embargo {
eXited
}
Proposed --> Active : accept
Proposed --> Revise : accept
eXited --> [*]The diagram shows every move of the EM transition table. A self-loop on reject or accept is the move made while another proposal is still open, and accept from Proposed reaches Revise when the other open proposals become revisions of the embargo now in force.
Read more about Embargo Management
Case State process
The CS model tracks six facts about a vulnerability: whether the Vendor is aware of it, whether a fix is ready, whether the fix is deployed, whether the public is aware, whether an exploit is public, and whether attacks have been observed. The first three are tracked per Vendor, while the last three are facts about the case as a whole. The diagram below shows the two parts side by side.
---
title: Case State Diagram showing Participant-Agnostic and Participant-Specific Aspects
---
stateDiagram-v2
direction LR
CS: Case State Model
state CS {
ps: Participant-Specific
state ps {
[*] --> vfd
vfd --> Vfd : V
Vfd --> VFd : F
VFd --> VFD : D
VFD --> [*]
}
--
g: Participant-Agnostic
state g {
[*] --> pxa
pxa --> Pxa : P
pxa --> pXa : X
pxa --> pxA : A
pXa --> PXa : P
pXa --> pXA : A
pxA --> PxA : P
pxA --> pXA : X
Pxa --> PxA : A
Pxa --> PXa : X
pXA --> PXA : P
PXa --> PXA : A
PxA --> PXA : X
PXA --> [*]
}
}
[*] --> CS
CS --> [*]Read more about the Case State model
How the models fit together
Model Interactions describes the constraints the three models place on each other, such as when an embargo may be negotiated relative to a report's validation. The formal protocol builds on all three models and their interactions to define the messages Participants exchange. The Vultron Protocol Specification is the normative source for each model's states and transitions.
Reading path: You handle vulnerability reports and coordinate cases with other organizations
This page is part of See how a case moves.
Before this page:
After this page:
Reading path: You study how vulnerability disclosure works and want the models behind it
This page is part of Work with the models.
Before this page:
After this page: