Proposal: Safety Integrity Classification (SIC) — A Cross-Domain Normalized Abstraction for CycloneDX 2.0

Start by reviewing the CycloneDX 2.0 risk, perspective, criticality, assetClassification, blueprint, component, and VEX constructs described in the proposal. Determine whether a normalized safety-integrity abstraction fits the existing model; done requires an agreed roadmap and concrete specification scope before implementation can begin.

Thanks again for the detailed feedback @stevespringett . Based on your comments, a more focused proposal is a Safety Integrity Classification (SIC) that complements the existing 2.0 risk, perspective, and criticality constructs rather than introducing separate safety metadata.

Motivation

CycloneDX 2.0 already provides:

• Safety and societal impact categories
• Safety-oriented domains
• Component-to-risk relationships
• VEX integration
• Criticality and asset classifications

What appears to be missing is a machine-readable abstraction for expressing safety integrity levels across industries.

Goal

Provide a normalized classification that can represent industry-specific safety assurance schemes while remaining attached to existing CycloneDX constructs.

Examples include:

A normalized abstraction could look like:

safetyIntegrity:

  classification:
      scheme: ISO26262
      level: ASIL-D

  normalizedLevel:
      HIGH

or

safetyIntegrity:

  classification:
      scheme: IEC61508
      level: SIL-3

  normalizedLevel:
      HIGH

Integration with Existing 2.0 Constructs

Rather than existing independently, safetyIntegrity would attach to existing constructs such as:

• assetClassification
• risk
• blueprint
• component

For example:

component:
  name: brake-controller

assetClassification:
    criticality: critical

safetyIntegrity:

    classification:
        scheme: ISO26262
        level: ASIL-D

risk:

    domain:
        automotive-safety

    impact:
        physical

relatedVulnerabilities:
    - CVE-XXXX

vex:
    state: affected

This enables downstream tooling and policy engines to reason about safety context.

Example:

if safetyIntegrity.normalizedLevel >= HIGH
and vex.state == affected
then priority = immediate

I think this preserves the existing CycloneDX 2.0 design while introducing a common abstraction for safety assurance levels across domains. Interested to hear whether this direction aligns with the 2.0 roadmap.