Proposal: Safety Relevance Metadata for CycloneDX

[devashridatta-dotcom]

Summary

This proposal introduces an optional Safety Relevance metadata property for CycloneDX components.

The goal is to capture whether a component participates in safety-critical or mission-critical functions where compromise, malfunction, or misuse could contribute to:

• Physical harm
• Human safety risks
• Environmental damage
• Critical infrastructure disruption
• Societal impact

The proposal complements existing CycloneDX capabilities such as Vulnerability Disclosure, VEX, AI BOM, and dependency analysis by adding contextual information about the operational consequences of component failure.

Motivation

CycloneDX provides rich metadata describing:

• Component identity
• Dependencies
• Vulnerabilities
• VEX assertions
• Services
• AI and machine learning artifacts

However, it does not currently express whether a component is part of a safety-critical system.

Organizations in automotive, healthcare, robotics, industrial control systems, energy, and AI increasingly require this context to:

• Prioritize remediation
• Interpret VEX results
• Build safety cases
• Meet regulatory obligations
• Improve risk governance

Initial Proposal

Introduce optional metadata properties:

• cyclonedx:safety-relevance
• cyclonedx:safety-domain
• cyclonedx:safety-impact

Example:

safety-relevance = Critical

safety-domain = Medical

safety-impact = HumanSafety

Example Classification

• None
• Indirect
• Critical
• Unknown

Questions for the Community

1. Should Safety Relevance begin as custom properties or as a first-class schema object?
2. Are there existing use cases in medical, automotive, AI, or industrial systems?
3. How should Safety Relevance interact with VEX and vulnerability analysis?
4. Would a common taxonomy benefit downstream tooling and SBOM consumers?

Next Steps

If there is interest, I can:

• Draft a formal schema proposal
• Provide example BOMs
• Develop mappings to VEX and AI BOM
• Collaborate with the community on taxonomy and governance

[stevespringett]

Thanks for this proposal, @devashridatta-dotcom. Safety relevance is squarely in scope for where CycloneDX is heading, and a good deal of what you describe is already taking shape in the 2.0 line (in development), so this is well-timed. Here is where each part maps today and where the gap is.

What already exists in 2.0

Safety impact (physical harm, human safety, environmental damage, societal impact): the 2.0 risk model already enumerates these as impact categories. impact.categories includes safety, physical, environmental, societal, health, and psychological, and the risk domain taxonomy includes safety, environmental, health, societal, and human-rights. The consequence types your proposal lists are first-class.

Safety domain (Medical, Automotive, and so on): the 2.0 perspective model carries a domain taxonomy with a dedicated safety cluster, including automotive-safety, aviation-safety, functional-safety, machinery-safety, maritime-safety, nuclear-safety, patient-safety, process-safety, railway-safety, and environmental-safety, alongside sector domains such as healthcare, medical-devices, critical-infrastructure, industrial-control-systems, robotics, and energy-utilities. Several reference the relevant standards (for example automotive-safety notes ISO 26262 and ASIL).

Safety relevance level and component linkage: a component's safety weight is expressible through criticality (minimal to critical), which a blueprint attaches to an asset through assetClassification, and through a risk whose affects references the component while carrying a safety domain and a safety or physical impact rating. So "this component participates in a safety-critical function, and here is the consequence if it fails" is representable now, with the degree carried by the rating rather than a single flag.

VEX and vulnerability interaction (your question 3): this is already wired. A risk can reference both the affected component (affects) and the vulnerabilities that inform it (relatedVulnerabilities), and the vulnerability model carries the VEX analysis. That lets a consumer prioritize remediation by safety impact and interpret VEX in a safety context, which is the workflow you describe.

Where the gap is

What 2.0 does not yet model first-class is a standards-aligned safety integrity level. Your None / Indirect / Critical scale is a coarse proxy for what safety-critical industries express as ASIL (ISO 26262), SIL (IEC 61508), DAL (DO-178C), or software safety class (IEC 62304). A common, machine-readable safety-integrity classification, attachable to a component or asset and mappable to those standards, is the genuinely net-new piece, and it is where a common taxonomy would most help downstream tooling (your question 4).

On your questions

1. Custom properties or first-class: I would not start with cyclonedx:* custom properties, since the substance (impact, domain, criticality, VEX linkage) is already first-class in 2.0 and custom properties would fragment it. The first-class addition worth designing is the safety-integrity classification.
2. Use cases: yes, across automotive (ISO 26262), aviation (DO-178C), industrial (IEC 61508), medical (IEC 62304), rail (EN 5012x), and nuclear. The perspective safety domains were added with these in mind.
3. VEX interaction: covered by risk.relatedVulnerabilities plus the VEX analysis on the vulnerability, as above.
4. Common taxonomy: yes. The impact and domain taxonomies already exist; a safety-integrity-level taxonomy is the high-value addition.

Suggested next step

Rather than a separate component metadata block, the most durable path is to use the existing risk, perspective, and criticality constructs for impact, domain, and component linkage, and to collaborate on a small safety-integrity classification (ASIL, SIL, DAL, and IEC 62304 mappings) targeted at the 2.0 line. Example BOMs showing a safety-critical component expressed with risk plus perspective plus criticality today, alongside a sketch of the safety-integrity field, would be a great starting point.

[devashridatta-dotcom]

Thank you for the detailed explanation and for mapping the proposal to the CycloneDX 2.0 model.

This is very helpful. After reading your response, I agree that much of what I described is already expressible through the existing constructs of risk, perspective, criticality, and VEX. The impact categories, safety domains, and risk-to-component/vulnerability relationships appear to provide the right foundation.

The gap you highlighted around a standards-aligned safety integrity classification is particularly interesting. My original None / Indirect / Critical scale was intended as a simple way to express whether a component participates in a safety-critical function, but I agree that safety-critical industries already have richer models such as ASIL (ISO 26262), SIL (IEC 61508), DAL (DO-178C), and IEC 62304 software safety classes.

A common, machine-readable abstraction that can represent and map these integrity levels across domains seems like a valuable addition for downstream tooling and policy engines.

I’ll spend some time putting together a few example BOMs showing:

• how safety-related components can already be represented using the current 2.0 constructs, and
• what a possible Safety Integrity Classification model could look like while remaining compatible with those constructs.

Thanks again for the guidance. This gives me a much clearer direction for refining the proposal.