Reference

ISO/IEC 29147:2018 Crosswalk

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.

ISO/IEC 29147:2018 Information technology — Security techniques — Vulnerability disclosure describes how a vendor receives reports from outside and publishes advisories. Clauses 5 through 9 overlap with the Vultron Protocol, which gives the receiving, coordinating, and publishing steps a shared state model and a message for each step.

Consistent Terminology

Our use of the following terms is consistent with ISO/IEC 29147:2018 §5.4 Systems, components, and services: Systems, Components, Products, Services, Vulnerability, and Product interdependency.

ISO/IEC 29147:2018 §5.5 Stakeholder Roles includes User, Vendor, Reporter, and Coordinator. We use Deployer instead of User; the rest are consistent. See CVD Roles and Participants and §2.2 Roles.

The table maps each clause to the explanation page that covers it and to the section of the Vultron Protocol Specification that states the requirement. Transitions are written as the state before and after, with the formal message name in parentheses. The protocol side names the Report Management (RM) and Embargo Management (EM) state machines, each participant's Participant Embargo Consent (PEC), and the two Case State (CS) dimensions: vendor aware, fix ready, fix deployed (VFD) and public aware, exploit public, attacks observed (PXA).

ISO/IEC 29147:2018 Clause	Sub-Clause	Vultron Protocol	Specification
5.6 Vulnerability handling process summary	5.6.1 General, 5.6.2 Preparation, 5.6.3 Receipt, 5.6.4 Verification, 5.6.5 Remediation development, 5.6.6 Release, 5.6.7 Post-release	These subsections recapitulate ISO/IEC 30111:2019 clause 7; see the corresponding rows of the ISO/IEC 30111 crosswalk.	§6 Report Management (RM) State Machine, §8 Case State (CS) Dimensions
	5.6.8 Embargo period	Embargo Principles and Default Embargoes.	§7 Embargo Management (EM) State Machine
5.7 Information exchange during vulnerability disclosure	send-report-to	The Reporter sends a Report Submission (RS); the receiver moves Start → Received. Before a case exists this message goes directly to the recipient rather than through a case.	§4.1 Report Management Messages, §5.4.2 Routing Topology
	release-advisory-to	Publishing an advisory is the fact the case records as Public Aware (Case Public, CP). The advisory document itself is outside the protocol; a note pointing at it can be added to the case. See General (GI) Messages.	§4.3 Case State Messages, §8.2 PXA — Public Aware, Exploit Public, Attacks Observed
5.8 Confidentiality		Embargo Management and each participant's embargo consent.	§7 Embargo Management (EM) State Machine, §9 Participant Embargo Consent (PEC) State Machine, §14.4 Confidentiality
5.9 Vulnerability advisories		The Public Awareness substate; publishing an advisory is what moves the case to Public Aware (CP).	§8.2 PXA — Public Aware, Exploit Public, Attacks Observed
5.10 Vulnerability exploitation		The Exploit Public and Attacks Observed substates; any participant may report either.	§8.2 PXA — Public Aware, Exploit Public, Attacks Observed, §12.4.2 Participant-Agnostic CS Transitions (PXA)
5.11 Vulnerabilities and risk		Interactions Between the Vultron Protocol and SSVC.	§4.1 Report Management Messages
6 Receiving vulnerability reports	6.1 General	The Report Management Model; receipt sets Vendor Awareness.	§6 Report Management (RM) State Machine, §8.1 VFD — Vendor Aware, Fix Ready, Fix Deployed
6.2 Vulnerability reports	6.2.1 General	The report is a VulnerabilityReport object; see Vultron AS Objects.	§5.2 Object Types
	6.2.2 Capability to receive reports	The Received state, entered on Report Submission (RS).	§6.1 States, §5.6 Transport Layer
	6.2.3 Monitoring	Each actor exposes an inbox that receives protocol messages. See ActivityPub Implementation.	§5.4 Addressing and Channels
	6.2.4 Report tracking	The Report Management Model and the Case Model.	§6.3 Per-Participant RM Tracking
	6.2.5 Report Acknowledgement	Report Acknowledgment (RK), the one per-message acknowledgment on the wire. See Faults and Acknowledgments.	§4.6 Error and Acknowledgment Messages
6.3 Initial assessment		Received → Valid (RV) or → Invalid (RI).	§6.2 Transitions and Guards
6.4 Further investigation		Work done in the Accepted state.	§6.1 States
6.5 On-going communication		Every case-scoped message is routed through the CASE_MANAGER and recorded in the case ledger, so all participants see the same history. See The Case Manager and the Case Ledger.	§5.4.2 Routing Topology
6.6 Coordinator involvement	-	RM Interactions Between CVD Participants, Working with Others, and Case Ownership Transfer when a coordinator takes over the case.	§11.2 Invitation and Acceptance, §11.3 Case Ownership Transfer
6.7 Operational security	-	ActivityPub Implementation.	§14 Security Considerations
7 Publishing vulnerability advisories	all	CVD Case Substates; publication is Case Public (CP).	§8.2 PXA — Public Aware, Exploit Public, Attacks Observed, §4.3 Case State Messages
	7.3 Advisory publication timing	Embargo Principles and Early Termination.	§7.2 Transitions and Guards, §10.2 Embargo Revision and Termination Cascades
	7.4 Advisory elements	Vultron AS Objects.	§5.2 Object Types
	7.5 Advisory communication	The case learns of publication through Case Public (CP); a note pointing at the advisory can be added to the case. See General (GI) Messages.	§4.3 Case State Messages
	7.6 Advisory format	The protocol does not fix an advisory format; see Vultron AS Objects for the same posture on reports.	§5.5 Serialization
	7.7 Advisory authenticity	ActivityPub Implementation.	§14.1 Trust Model
	7.8 Remediations	Fix Ready (CF) and Fix Deployed (CD).	§8.1 VFD — Vendor Aware, Fix Ready, Fix Deployed
8 Coordination	8.1 General	The Received and Accepted states; RM Interactions Between CVD Participants; Working with Others.	§3.1 Coordination Model, §11.2 Invitation and Acceptance
	8.2 Vendors playing multiple roles	A participant may hold several roles at once; a vendor that depends on another vendor's component is also a Reporter toward it.	§2.2 Roles, §12.3 Role Taxonomy
9 Vulnerability disclosure policy	9.2.2 Preferred contact mechanism	Each actor's inbox is its contact point. See ActivityPub Implementation.	§5.4 Addressing and Channels
	9.3.2 Vulnerability report contents	Case Model; Vultron AS Objects.	§5.2 Object Types
	9.3.3 Secure communication options	ActivityPub Implementation.	§5.6 Transport Layer, §14 Security Considerations
	9.3.4 Setting communication expectations	Default Embargoes; the response deadline on an embargo invitation.	§7.2 Transitions and Guards, §9.4 Deadlines and the Pocket Veto
	9.3.6 Publication	Publication moves the case to Public Aware (CP).	§8.2 PXA — Public Aware, Exploit Public, Attacks Observed
	9.4.3 Disclosure timeline	Embargo Management and Default Embargoes.	§7 Embargo Management (EM) State Machine