Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Proposal: CycloneDX Safety Perspective for SRAC and safety impact workflows

Aperta
  • Qualcosa non va?
#1,122 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
json
Ambito
documentation

Direzione di ricerca

Start with this issue's CycloneDX 2.0 field mapping and example assessment, then review how the referenced risk, blueprint, declaration, and evidence data fit together. Done means reaching agreement on a reusable Safety Perspective pattern and documenting examples for all ten trigger scenarios without adding a competing SRAC object.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

cap: perspective-registry

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, and polarity.
  • 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.
Lingua principale
XSLT
Stelle
558
Fork
93
Merge medio
14h 57m
PR unite (30g)
22

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di CycloneDX/specification

Tutte le issue di CycloneDX/specification

Issue simili

Altre issue su Documentation

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.