Repository navigation
Proposal: CycloneDX Safety Perspective for SRAC and safety impact workflows #1122
Description
Summary
This issue proposes a CycloneDX Safety Perspective for SRAC-style safety impact workflows.
The Safety Perspective is a stakeholder view over CycloneDX 2.0 risk, blueprint, declaration, and evidence data. It helps safety, product security, release, and GRC teams understand whether a change affects a safety-relevant context, what impact was assessed, what evidence supports the assessment, and what release decision follows.
This proposal builds on #1120. It does not propose a competing SRAC object. The goal is to document a reusable CycloneDX-native pattern.
Purpose
The Safety Perspective should help answer:
- What safety-relevant context is affected?
- What event triggered the reassessment?
- What component, asset, function, requirement, or behavior is affected?
- What safety impact or damage scenario was considered?
- What evidence supports the assessment?
- What is the assessment status?
- What release decision or conclusion follows?
Common SRAC graph
Each safety scenario should follow the same graph:
trigger
-> safety context
-> affected element
-> damage scenario / impact
-> evidence
-> assessment status
-> conclusion / release decision
CycloneDX field mapping
| SRAC / safety need | CycloneDX 2.0 field |
|---|---|
| Safety context | blueprints[].assets[].classification.safetyIntegrityLevels[] |
| Trigger / event | risks.assessments[].triggeredBy[] |
| Affected element | risks.risks[].affects[] |
| Harm or damage scenario | risks.damageScenarios[] |
| Impact | inherentRisk.impact / residualRisk.impact |
| Likelihood | inherentRisk.likelihood / residualRisk.likelihood |
| Optional prioritization | inherentRisk.score / residualRisk.score / overallRisk.score |
| Evidence | declarations.evidence[], declarations.claims[], externalReferences[] |
| Assessment status | risks.assessments[].status |
| Release decision | risks.assessments[].conclusion and summary |
Safety trigger scenarios
The perspective should include examples for these ten trigger scenarios. These are not ten schema additions. They are ten example patterns over the same CycloneDX graph.
| # | Scenario | Example trigger | Expected use |
|---|---|---|---|
| 1 | Product-line requirement value change | Requirement or change record | Reassess requirement, safety context, and validation impact |
| 2 | CVE in a safety-relevant component | Vulnerability or VEX record | Assess whether the vulnerability affects a safety function |
| 3 | Field incident after deployment | Incident or service ticket | Determine requirement, test, design, or safety-case impact |
| 4 | Customer or hospital report | CAPA, MDR, QMS, or customer report | Engineer review, evidence, and possible corrective action |
| 5 | Lab finding | Lab or pen-test report | Evidence-driven reassessment |
| 6 | Validation test failure | Test report or regression signal | Validation change, rerun, or requirement update |
| 7 | Configuration change | Runtime setting or threshold change | Context-specific reassessment |
| 8 | Environmental change | Latency, power, EMI, or site context change | Assumption or safety-case review |
| 9 | Hardware or supplier change | Part substitution or supplier notice | Design and validation reassessment |
| 10 | Regulatory or safety bulletin | FAA, recall, MDR, or regulator notice | Impact analysis and closure evidence |
Example pattern
{
"risks": {
"assessments": [
{
"bom-ref": "assessment-validation-failure",
"type": ["safety"],
"cadence": "triggered",
"triggeredBy": ["test-report-123"],
"risks": ["risk-dose-limit-failure"],
"status": "completed",
"conclusion": "unacceptable",
"summary": "Validation failure affects a Class C therapy path. Release is blocked until corrective action and revalidation complete."
}
]
}
}Notes
- Safety integrity is not a score. It identifies the classified safety context, such as ASIL-D, SIL-3, DAL-A, or IEC 62304 Class C.
- Impact expresses the severity of harm, using fields such as
impact.level,categories, andpolarity. - Score is optional prioritization. If used, it should remain in the risk model and be tied to the organization or methodology that defines the scale.
- Richer change-management primitives may be future 2.1 work. For 2.0, the perspective can use
triggeredBy, annotations, external references, and properties where needed.
Activity
devashridatta-dotcom commentedon Oct 3, 2026
Clarification: relationship between VEX and SRAC safety context
VEX and SRAC answer different questions:
Safety relevance must not, by itself, alter a VEX status or provide a
not_affectedjustification. It can influence product-risk prioritization, response urgency, and whether a safety-impact analysis or safety-case update is required.Authority model
Expected behavior
affectedaffectednot_affectedunder_investigationA safety mechanism such as a watchdog or redundant channel qualifies as an exploitability mitigation only when it actually prevents exploitation; containing a resulting failure is not, by itself, a VEX
not_affectedjustification.CycloneDX transport and model direction
A CycloneDX VEX record should be able to reference the applicable SRAC assertion using a structured identity and digest while preserving provenance and review state. Existing
externalReferenceswith hash verification can provide an extension point for the sidecar transport.analysis.detailmay provide human-readable context, but it should not be the sole structured carrier of the relationship.For the current work split:
The key invariant is: VEX determines vulnerability applicability; SRAC supplies safety context. Safety context can change priority and required response, but it does not replace the exploitability decision.
devashridatta-dotcom commentedon Oct 3, 2026
To complement the VEX/SRAC clarification above, I have consolidated the wider
transport and adoption model into one architecture view:
The diagram distinguishes the current extension-point transport from future
native semantics:
externalReferencecan identify the SRAC artifactand use the native hash field for integrity verification;
the sidecar mapping; and
safety context that may change priority and required response.
PR #1120 is shown as the concrete model direction, while this issue provides
the Safety Perspective and lifecycle context. Feedback on whether this
separation accurately reflects the intended CycloneDX direction would be
appreciated.