Add a structured RemediationPlan object to express CVE→risk→SUMS remediation lifecycle

[github-actions]

Motivation

UNECE R155 / R156, ISO/SAE 21434 and SUMS expectations require manufacturers to operate vulnerability handling, PSIRT, and software update management processes. RDX currently covers riskTreatmentDecisions (RDX-029) and links to controls and evidence, but lacks a focused, machine-readable remediation lifecycle object that maps discovered vulnerabilities (CVE/CPE), affected VINs or component ranges, fix plan (SUMS campaign), SLA/target dates, responsible party, verification criteria, and final verification evidence. A RemediationPlan object will enable automated reporting, regulatory evidence bundling for type-approval audits, and orchestration between PSIRT, SUMS, and suppliers.

Proposed change

1. Add a new top-level array remediationPlans[] to riskSet with the following (suggested) fields (JSON + XSD additions required):

• id (string, required)
• title (string)
• description (string)
• vulnerabilityRefs[] — list of objects linking to CVE/CWE/third-party advisories: { cve: "CVE-2026-...", cveSource: "NVD|GHSA|vendor", vulnId: "vendor-1234" }
• affectedComponentIds[] — references to itemDefinition.components[] or CycloneDX component bom-ref values
• affectedVINs (optional) or vehicleRange (string or VIN pattern) — to record scope for type-approval evidence
• riskValueRefs[] — links to RDX riskValues that motivated remediation
• owner — org/person responsible (id/email)
• psirtTicket — internal ticket reference
• sli / sla — numeric SLA days or policy label (e.g., "critical:30d")
• targetReleaseWindow — proposed calendar/time window for fix release (ISO 8601)
• sumsCampaignRef — link to SUMS campaign metadata (if managed by SUMS) — { id, documentRef, bomRef }
• mitigations[] — short-term mitigations (workarounds, configuration changes)
• fixStatus — enum: planned|in_progress|released|deferred|not_applicable
• verification: { method: "testcaseId|pen-test|OTA-verify", evidenceRefs[]: [signedEvidenceRef], verificationDate, verifier }
• disclosure: { cveAssigned: true/false, cveId, coordinatedDisclosure: boolean, publicDisclosureDate }
• evidenceStoreRef — optional external content-addressable evidence reference (CID, URL)
• auditTrail[] — optional chronological statements (actor, timestamp, action, comment)

2. Normative links: remediationPlans[].vulnerabilityRefs should interoperate with VEX/CSAF objects if present (link by CVE ID). affectedComponentIds should prefer CycloneDX BOM-Link bom-ref when the vulnerability affects a software/hardware component.

3. Add example examples/rdx-remediationplan-cve.json demonstrating a critical CVE affecting a gateway ECU, the linked riskValue, a SUMS campaign reference, SLA (30 days), and final verification evidence (signed attestation + bomRef hash).

Related RDX requirements:

• Extends RDX-029 (riskTreatmentDecisions) by providing a structured remediation lifecycle object to record operational treatment plans.
• Relates to RDX-052..RDX-056 (validation requirements) by introducing fields that must be validated and cross-referenced (CVE format, ISO 8601 dates).
• Relates to RDX-099 / RDX-100 (CycloneDX embedding / SBOM linkage) via affectedComponentIds and sumsCampaignRef.

New requirement introduced: RDX-201 (new requirement) — "RDX MUST support a machine-readable remediationPlan object to record vulnerability scope, remediation schedule, SUMS campaign linkage, responsible parties, SLAs, and verification evidence for regulatory and operational use."

References

• UNECE WP.29 R156 / SUMS (Software Update Management System) — regulation text and guidance on update planning and recording. https://unece.org/transport/documents/2021/03/standards/un-regulation-no-156-software-update-and-software-update
• UNECE R155 / CSMS guidance and expectations for vulnerability handling and PSIRT processes (informative). https://unece.org/sites/default/files/2024-03/R156e%20%282%29.pdf
• Industry guidance on vulnerability handling in automotive (monitoring, PSIRT, SUMS tie-in). CyberLifeHacks R155 summaries. https://cyberlifehacks.dev/r155/VehicleTypeApproval
• NIST incident response / patch management guidance (for verification / SLAs patterns): NIST SP 800-61 and SP 800-40. https://csrc.nist.gov/projects/incident-response and https://csrc.nist.gov/publications/detail/sp/800-40/rev-4/final

Acceptance criteria

• Schema: spec/json/rdx.schema.json and spec/xml/rdx.xsd include remediationPlans[] with the fields above, including types, enumerations, and format constraints (CVE pattern, ISO 8601 dates, enum values). New fields must be optional to preserve backwards compatibility.
• Examples: Add examples/rdx-remediationplan-cve.json and update templates/rdx-template.json with a commented remediationPlan skeleton. All new examples validate.
• Tests: Add CI tests that validate remediationPlan CVE format, required cross-references (if vulnerabilityRefs contains a CVE that exists in a vulnerabilities[] object in the doc, the reference must resolve), and that affectedComponentIds can reference CycloneDX BOM-Link bom-ref values.
• Documentation: Update methodology/UseCases.md, methodology/CAL-TAF-Integration.md to note how remediationPlans relate to SUMS campaigns and CAL assessments.
• Interop: Document mapping guidance for consumers exporting remediationPlans into regulatory evidence packages (R155/R156) and for linking to VEX/CSAF statements.
• Backwards compatibility: Existing RDX documents without remediationPlans remain valid; remediationPlans are optional add-ons for operational/regulatory workflows.

---

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.