Introduce a CoordinatedVulnerabilityDisclosure (CVD) plan object for PSIRT/third-party reporting and multi-party coordination

[github-actions]

Motivation

Automotive vulnerability disclosure frequently involves multi-party coordination (researchers, Tier‑n suppliers, OEMs, CSIRTs, national authorities). BEST PRACTICE guidance (FIRST, CERT, ISO 29147/30111) asks vendors to publish policies, timelines, and run CVD processes. RDX currently points to a security vulnerability reporting mechanism (RDX-083) but lacks a structured CVD object to represent intake metadata, reporter contact, acknowledgement timeline, embargo/embargo-exceptions, coordination partners, and disclosure timeline. A machine-readable CVD object improves PSIRT automation, audit evidence for R155 and regulatory submissions, and enables downstream consumers to programmatically determine disclosure status.

Proposed change

1. Add an optional coordinatedDisclosure object (or cvds[]) under riskSet with fields similar to the following:

• id (string)
• vulnerabilityRefs[] — CVE/CWE/third-party advisory references
• reporter: { name, contact, affiliation, anonAllowed }
• receivedDate (date-time)
• acknowledgedDate (date-time)
• triageSeverity — vendor-assigned severity (Low/Medium/High/Critical) and mapping to CVSS if available
• cveRequested (boolean), cveAssigned (boolean), cveId
• coordinators[] — list of coordination bodies (CERT/CC, national CSIRT, FIRST, OEM PSIRT, supplier PSIRT) with contact info and role
• proposedDisclosureDate and agreedDisclosureDate (date-times) — null if not agreed
• embargo: { start, end, terms } — optional embargo metadata
• communicationPlan: { channels: [email, advisory-portal, vendor-advisory], stakeholders: ["customers","authorities","researcher"] }
• status — enum: reported|acknowledged|in_progress|coordinating|public_notice|closed
• notes[] — freeform chronological notes (actor, timestamp, message)
• publicAdvisoryRef — link to published advisory when status==public_notice

2. Normative behavior: When a coordinatedDisclosure object exists, exporters must include it in any regulatory evidence bundle for R155/R156 audits and optionally include the object in CycloneDX metadata.properties when sharing RDX with vendors/authorities.

3. Provide example export mapping to ISO/IEC 29147 and FIRST multi-party coordination guidance: include agreedDisclosureDate, coordinators[], and cveId fields in the example.

Related RDX requirements:

• Relates to RDX-083 (Provide security vulnerability reporting mechanism).
• Relates to RDX-004 (data quality & governance) and RDX-060 (provenance tracking) by requiring intake/acknowledgement metadata and coordinators.

New requirement introduced: RDX-202 (new requirement) — "RDX SHOULD include a CoordinatedVulnerabilityDisclosure object to capture structured intake, triage, coordination, and disclosure timeline data for PSIRT and multi‑party CVD workflows."

References

• FIRST: Guidelines and Practices for Multi-Party Vulnerability Coordination and Disclosure (v1.0 / v1.1). https://www.first.org/global/sigs/vulnerability-coordination/multiparty/guidelines-v1.1
• CERT/CC: Guide to Coordinated Vulnerability Disclosure. https://certcc.github.io/CERT-Guide-to-CVD/
• ISO/IEC 29147 (Vulnerability disclosure) / 30111 (vulnerability handling) — normative background for disclosure fields.
• UNECE R155 (vulnerability handling expectations for automotive PSIRTs) — summary and context. https://cyberlifehacks.dev/r155/VehicleTypeApproval

Acceptance criteria

• Schema: spec/json/rdx.schema.json and spec/xml/rdx.xsd include coordinatedDisclosure (or cvds[]) with the fields and types described. CVE fields and dates must be validated (CVE pattern, ISO 8601).
• Examples: Add examples/rdx-cvd-example.json showing (a) an external researcher report accepted and acknowledged and (b) a multi-party coordinated disclosure where CERT/CC and a supplier are coordinators and an agreed disclosure date exists. Example must validate.
• Documentation: Update methodology/UseCases.md and REQUIREMENTS.md to reference RDX-202 and describe how PSIRTs should populate the object, expectations for embargo handling, and how authorities/OEMs should consume it during audits.
• Interop: Provide an appendix mapping coordinatedDisclosure fields to ISO/IEC 29147 disclosure artifacts and to FIRST coordination roles.
• Backwards compatibility: The new fields are optional; documents without them remain valid.
• Tools: Provide tools/validate_cvd.py or CI test snippets that assert required fields (e.g., receivedDate <= acknowledgedDate <= agreedDisclosureDate) and flag missing cveId when cveAssigned==true.

---

Generated by tools/ai_idea_scout.py via the AI Idea Scout workflow.
Review the proposal, refine the title/body/labels, and close if not desired.