Add a safety↔security mapping object to link ISO 26262 safety goals / ASILs to RDX damage scenarios and controls

[github-actions]

Motivation

RDX already models damageScenarios, threatScenarios, and controls; it also includes CAL/TAF and aims for ISO/SAE 21434 alignment. However, safety engineering (ISO 26262) remains a separate discipline with its own work products (safety goals, ASIL assignments). Regulators and toolchains increasingly require traceability between safety goals and cybersecurity outcomes (UNECE WP.29, R155/R156 and co‑engineering guidance). Adding a structured safetyMapping object enables explicit traceability: which safety goals are affected by which damage scenarios, how security controls affect safety, and where safety and security requirements must be reconciled.

Related RDX requirements: RDX-043 (itemDefinition mapping), RDX-045 (damageScenarios), RDX-051 (risk treatment decisions), RDX-106 (future compatibility with R155/R156). Proposed new requirement: RDX-203 (safetySecurityMapping). (new requirement)

Proposed change

Introduce an optional safetyMappings[] array at riskSet level. Each mapping object SHOULD include:

• id (string)
• safetyStandard (string) — e.g., ISO 26262 (free text) with optional version.
• safetyGoalId (string) — the originating safety artifact id (could be a URN or ASIL registry id).
• safetyGoalTitle (string)
• asil (enum/string) — QM, ASIL-A, ASIL-B, ASIL-C, ASIL-D, or unknown.
• relatedDamageScenarioIds (array[string]) — link to damageScenarios[].id describing how the safety goal is impacted by cybersecurity events.
• relatedThreatScenarioIds (array[string], optional)
• relatedControlIds (array[string]) — controls that contribute to safety preservation (links to controls[].id).
• conflictRisk (string, optional) — describes known safety/security tension (e.g., "timing impact of crypto affects braking latency").
• mitigationRecommendations (array[string]) — recommended resolution approaches or design constraints.
• evidenceRefs (array[string]) — references to safety case artifacts, test reports, or external evidence (CycloneDX BOM-Link allowed).

Schema/encoding and doc updates:

• Add safetyMappings[] to JSON Schema and XSD (optional).
• Add examples/rdx-safety-security-mapping.json demonstrating:
  • A safety goal from ISO 26262 (with ASIL-D) mapped to a damageScenario describing loss of braking integrity.
  • Controls that must be coordinated (e.g., low-latency integrity checks) and a short conflictRisk note.
• Add methodology/Safety-Security-Mapping.md explaining usage patterns and how this supports UNECE/R155 traceability and whole-vehicle TARA.

References

• UNECE WP.29 / UN R155 & R156 — requirements for cybersecurity engineering and the need for cross-disciplinary traceability. https://unece.org/transport/road-transport/reference-documents and WP.29 documents. (unece.org)
• Complying with ISO 26262 and ISO/SAE 21434: a safety & security co-analysis method (example research & approach). https://www.ncbi.nlm.nih.gov/pmc/articles/PMC10975927/. (pmc.ncbi.nlm.nih.gov)
• Survey and literature on safety-security co-engineering. (see: "Cybersecurity and Safety Co-Engineering of Cyberphysical Systems" and related reviews). https://www.mdpi.com/1999-5903/12/4/65. (mdpi.com)

Acceptance criteria

1. Schema: add optional safetyMappings[] to JSON Schema and XSD; add RDX-203 to REQUIREMENTS.md.
2. Examples: add examples/rdx-safety-security-mapping.json showing at least one mapping from an ASIL safety goal to damageScenarios and controls and demonstrating conflictRisk and evidenceRefs via BOM-Link.
3. Documentation: add methodology/Safety-Security-Mapping.md describing authoring guidance, how tooling should present conflicts, and recommended fields for traceability to ISO 26262 artifacts.
4. Tests: add schema validation tests and an integration test demonstrating that a consumer can programmatically follow safetyMappings[] to produce a traceability matrix (safetyGoal → damageScenario → threatScenario → controls).
5. Regulatory alignment: provide a short mapping doc (in methodology/) showing how safetyMappings supports UNECE R155/R156 audit evidence and where to place referenced safety case artifacts.
6. Backwards compatibility: documents without safetyMappings remain valid; tooling not supporting safety maps ignores the object.

---

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.