Process Implementation Notes
This page is not normative
This page is not considered a core part of the Vultron Protocol as proposed in the main documentation. Although within the page we might provide guidance in terms of SHOULD, MUST, etc., the content here is not normative.
Use this page to find where your existing workflow intersects the Vultron Protocol, so that each milestone your system already records emits the protocol message that reports it. Vultron does not replace a tracker, an embargo calendar, or a threat-intelligence feed; it asks each of them to speak at the moments the protocol cares about. You finish with a list of your own workflow's milestones, each paired with the message it emits and the guide that shows how to send it.
Scope of this page
This page is about integrating your system. For the architecture of the reference implementation — hexagonal boundaries, the ActivityStreams inbox pipeline, behavior tree orchestration — see Reference Implementation Architecture.
Prerequisites
- A workflow you already run for vulnerability reports, embargoes, or public-disclosure monitoring.
- Working knowledge of the three process models the protocol is built from: Report Management (RM), Embargo Management (EM), and Case State (CS). Each milestone below is a transition in one of them.
- The formal message names the transitions carry. Each one is paired below with the activity guide that shows how to send it on the wire.
Map your report workflow onto RM
The RM process is close to an ordinary IT Service Management (ITSM) incident or service-request workflow, so a ticketing system, a Kanban board, or a bug tracker can carry it with few changes. The change that is needed is at the milestones: intercept each one and emit the RM message that reports it.
| When your workflow records that… | Emit | How |
|---|---|---|
| a report has arrived | Report Acknowledgment (RK) | How to Acknowledge a Report |
| validation is complete | Report Valid (RV) or Report Invalid (RI) | How to Report a Vulnerability |
| prioritization is complete | Report/Case Accepted (RA) or Report/Case Deferred (RD) | How to Advance a Case Through Report Management |
| the report or case is closed | Report Closed (RC), or the case closure | How to Advance a Case Through Report Management |
If your workflow has a validation step but no explicit prioritization step, treat the decision to assign the ticket to an engineer as prioritization and emit RA there.
Share pre-publication drafts through the case
Participants in a multi-party case often share advisory drafts during the embargo. The protocol does not prescribe that exchange, because the case can complete without it. If your workflow has a draft-review step, carry it as case notes: the General Inquiry (GI) and General Acknowledgment (GK) messages are enough, and How to Post a Status Update or a Case Note shows the activity. The ISO/IEC 29147:2018 crosswalk maps that standard's advisory-publication clauses onto the same messages.
Map your embargo handling onto EM
The EM process fixes when publication restrictions lift. It does not schedule what each participant publishes afterwards. Most participants publish at their own pace shortly after the embargo ends, and when closer coordination is needed the participants arrange it among themselves.
- If your system tracks an embargo end date, emit the proposal, acceptance, and termination messages from that record — see How to Establish an Embargo and How to Revise or Terminate an Embargo.
- If your system labels sensitive information with the Traffic Light Protocol (TLP), keep doing so. An embargo declaration can carry the label: "This case is TLP:AMBER until 2024-03-31 23:59:59 UTC, at which time it becomes TLP:CLEAR." The CERT Guide to Coordinated Vulnerability Disclosure (CVD) covers TLP in CVD in more detail.
Map your fix and monitoring workflows onto CS
The CS model has two halves, and they attach to different parts of your organization. The Vendor Awareness, Fix Readiness, and Fix Deployed substates are specific to each Vendor or Deployer; the Public Awareness, Exploit Public, and Attacks Observed substates are shared by the whole case. All six emit CS messages, and How to Post a Status Update or a Case Note shows the activity for each.
The fix path
Changes to a Vendor's development process are small and sit at three milestones.
| When your workflow records that… | Emit |
|---|---|
| the report has reached you as the Vendor | Vendor Awareness (CV) |
| a fix is ready | Fix Readiness (CF), and consider terminating any active embargo so publication can proceed |
| the fix has been deployed, where you also deploy | Fix Deployed (CD) |
A Deployer that is not the Vendor has one integration point: emit CD when deployment is complete. Deployers other than the Vendor are rarely case participants, but the message exists for when they are.
The public-awareness path
The other half of the CS model depends on watching public and private sources for leaked information, research publications, and adversary activity. That is the work a threat-intelligence or threat-analysis function already does, so wire it to emit the message for what it finds.
| When your monitoring detects… | Emit |
|---|---|
| the vulnerability has been published | Public Awareness (CP) |
| an exploit has been published | Exploit Public (CX) |
| attacks are being observed | Attacks Observed (CA) |
Some of that detection can be automated:
- analysts or search agents watch for early publication of the vulnerability,
- Intrusion Detection System (IDS) and Intrusion Prevention System (IPS) signatures deployed before the fix is available give early warning of adversary activity, and
- code-publication and malware-analysis platforms are watched for exploit publication or use.
Claim conformance
Once your milestones emit their messages, your system is a candidate for a conformance claim. A claim names the capability sets you provide and the roles you take on (§12.1 Conformance Model Overview in the specification), and conformance tests check it from the outside, in the four layers §12.5 Conformance Testing Approach defines. Independent implementations are tested against the first three; the fourth applies only to the reference implementation.
Reading path: You maintain a vulnerability tracker and want it to talk to your partners
This page is part of Understand the shape of the integration.
Before this page:
After this page: