Proposal: Safety Relevance Metadata as a Missing Layer in Automotive SBOM — Bridging Static Inventory and Operational Risk

[devashridatta-dotcom]

Submitting a proposal for discussion in an upcoming OpenChain Automotive session — feedback welcome.

---

Discussion Title

Proposal: Safety Relevance Metadata as a Missing Layer in Automotive SBOM — Bridging Static Inventory and Operational Risk

---

Background

Automotive software systems are increasingly governed by frameworks such as ISO 26262 (functional safety) and UN Regulation No. 155 (cybersecurity management systems). As Automotive SBOM approaches its Version 1.0 release, a structural gap remains: standard SBOM formats provide comprehensive component inventory, but they do not encode which components actively participate in safety-critical execution paths.

This gap has meaningful implications. A vulnerability affecting a non-safety-relevant logging library is operationally distinct from one affecting a braking control stack — yet current SBOM/VEX structures treat both identically at the metadata level. The result is triage overhead, misprioritized remediation, and compliance artifacts that do not reflect real operational risk.

---

Proposal Summary

I propose a focused discussion (and optionally a formal working session) on introducing Safety Relevance metadata as a standardized annotation layer for Automotive SBOM.

The Safety Relevance Index and Labeling (SRIL) framework introduces structured classification of software components based on their role in safety-critical execution:

Class	Definition
SR-0	No safety function; excluded from safety analysis
SR-1	Adjacent to safety paths; indirect risk
SR-2	Participates in safety-critical execution paths
SR-3	Directly controls safety-critical outputs (e.g., brake, steer, throttle)

Illustrative Automotive Component Mapping

Component	Automotive Role	SRIL Class	VEX Implication
openssl 3.x	TLS for OTA update delivery	SR-1	Prioritize only if OTA pathway is active/exposed
zlib 1.2.x	Compression in infotainment stack	SR-0	No safety path; deprioritize for safety triage
FreeRTOS kernel	RTOS for ADAS sensor fusion	SR-3	Any RCE/DoS → immediate safety escalation
TensorFlow Lite	Lane-keeping inference runtime	SR-2	Requires AI-specific risk analysis (AIVEX extension)
log4cxx	Diagnostic logging daemon	SR-0	Standard patch cadence; no safety linkage

Key Benefits

• Context-aware VEX triage
• Functional safety traceability
• Regulatory alignment (UN R155, CRA)
• AI/ML coverage via AIVEX

---

Why Now

The Automotive SBOM v1.0 timeline (target October 2026) presents an ideal window to address this gap. After v1.0 stabilization, safety relevance becomes a versioning extension rather than a design-layer consideration.

Relevant ongoing discussions:

• SPDX Issue #1354 (Safety Relevance metadata)
• CycloneDX Issue #954 (AIVEX)

---

Proposed Session Format

Option A — Live Session (15 min)
Overview + mapping + examples + discussion

Option B — Async feedback via this discussion

---

About the Proposer

Devashri Datta — Independent researcher in software supply chain security governance.

---

References

• Feedback on SPDX 3.1-rc1 — SBOM Lifecycle, Safety, and Governance Enhancements spdx/spdx-spec#1354
• Proposal: Safety Relevance Metadata for CycloneDX CycloneDX/specification#954

https://www.linkedin.com/in/devashri-datta-522b364b/
``

[Masato-oss]

@devashridatta-dotcom
Thanks so much for your Proposal. I'll add your topic to July meeting.