Repository navigation
Proposal: Safety Relevance Metadata for CycloneDX #954
Description
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
- Should Safety Relevance begin as custom properties or as a first-class schema object?
- Are there existing use cases in medical, automotive, AI, or industrial systems?
- How should Safety Relevance interact with VEX and vulnerability analysis?
- 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
Activity
stevespringett commentedon Jun 19, 2026
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.categoriesincludessafety,physical,environmental,societal,health, andpsychological, and the risk domain taxonomy includessafety,environmental,health,societal, andhuman-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, andenvironmental-safety, alongside sector domains such ashealthcare,medical-devices,critical-infrastructure,industrial-control-systems,robotics, andenergy-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 throughassetClassification, and through ariskwhoseaffectsreferences 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
riskcan 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
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.risk.relatedVulnerabilitiesplus the VEX analysis on the vulnerability, as above.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 commentedon Jun 19, 2026
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 / Criticalscale 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:
Thanks again for the guidance. This gives me a much clearer direction for refining the proposal.
stevespringett commentedon Jul 11, 2026
@devashridatta-dotcom Thanks for the continued work on this, and for the SRAP v0.1 gist and the routing through ossf/tac#624. I have mapped the proposal, field by field, against CycloneDX 2.0, which is in active development and approaching its RFC period. The short version: nearly everything SRAP asks for is already first-class in the 2.0 line, and the one element that is genuinely missing is small. We may have a solution that fills the gaps with very little change to CycloneDX 2.0 at all.
Where each SRAP field lands in 2.0 today:
consequence_classsafety,physical,health,environmental, andsocietalare first-class values, and the perspective model carries a dedicated safety domain taxonomy (patient-safety,automotive-safety,functional-safety, and others).declared_scopeintegration_scopeclassification_sourcemanufacturer,integrator,operator,auditor, andregulator, and they sign the documents that carry their assertions, so authority is cryptographically attributable rather than a self-labeled string.evidence_basisknown_unknowns,review_statussafety_relevancelevelcriticalityplus a rated risk today, and the integrity-level classification below replaces the coarse none/indirect/critical scale with what regulated industries actually exchange.The genuinely net-new piece is the one the gist itself flags: a standards-aligned safety integrity classification. We have a drafted and validated schema change for it. It is a small
{scheme, level}object in which the scheme structurally gates the permitted levels (ISO 26262 QM through ASIL D, IEC 61508 SIL 1 to 4, DO-178C DAL A to E, IEC 62304 Class A to C, EN 50128 SIL 0 to 4, plus a custom option for schemes beyond those five), reusing the same validation pattern the 2.0 threat model uses to gate categories by taxonomy. It attaches to an asset's classification within a blueprint and to requirements. Attaching it in the blueprint rather than on the bare component is deliberate, and it is your own core argument made structural: an integrity level is a property of a component in a system context, asserted by the party with system knowledge.The OpenSSL infusion pump record from your materials, expressed in 2.0:
{ "componentRef": "comp-openssl", "type": "module", "classification": { "criticality": "critical", "safetyIntegrityLevels": [ { "scheme": "IEC-62304", "level": "class-c" } ] } }A validator rejects
{ "scheme": "ISO-26262", "level": "sil-3" }outright, so the vocabulary is enforced by schema rather than by tooling convention.Three enum additions ride along with it:
EPSSas a first-class vulnerability scoring method, andhazard-analysisandsafety-caseexternal reference types for the evidence artifacts SRAP points at. Everything is additive, roughly 230 lines of schema across four files, and a complete worked example (the pump deployment, including the known unknown declared as an annotation and a scope exclusion) validates against the prototype.On the original questions in this issue: custom properties are the wrong vehicle, since the substance is already first-class and properties would fragment it. The taxonomy that most helps downstream tooling is the scheme and level vocabulary above, and I would like to keep that vocabulary aligned with the SPDX Safety Profile work so both ecosystems name levels identically even where the carriers differ. Alignment, not competition.
If you can review the scheme set and the level vocabularies against what you are seeing in the ELISA and SPDX Safety Profile discussions, that feedback would land at exactly the right time given where 2.0 is in its lifecycle.
fragment-safetyIntegrityLevel.json
meridian-infusion-pump.cdx.json
proposed-changes.patch
devashridatta-dotcom commentedon Jul 11, 2026
@stevespringett — this is exemplary. Thank you for the field-by-field mapping and for building the schema fragment, the worked example, and the patch. Seeing the infusion pump record expressed in 2.0 makes the integration path concrete in a way the proposal alone could not.
The community discussion that followed the July 10 SBOM Everywhere SIG presentation is being tracked at ossf/sbom-everywhere#144, where Chris Blask has contributed additional schema refinements — including assertion provenance, safetyGoalRef / safetyFunctionRef, relationship roles (implements/supports/monitors / isolates/recovers), and structured knownUnknowns. The thread may be useful context as you finalize the 2.0 schema, particularly on the governance and provenance layer.
A few reactions from the ELISA and SPDX Safety Profile discussions on July 10:
On the scheme/level vocabulary: The five schemes you've defined — ISO 26262, IEC 61508, DO-178C, IEC 62304, EN 50128 cover the domains that came up in both the SBOM Everywhere and SPDX Safety Profile sessions. Kate Stewart specifically noted she wants to keep CycloneDX and SPDX level naming identical to avoid cross-ecosystem fragmentation. Your statement "alignment, not competition" maps exactly to what she said.
On the blueprint as scope carrier: Allan Friedman's relationship-based framing from the July 10 session that safety relevance should be expressed as a relationship from system to component rather than a property on the component aligns perfectly with attaching the integrity level to an asset classification within a blueprint. This is the structural answer to the question he raised.
On known unknowns: The annotation approach for declaring unassessed paths is exactly what the SBOM Everywhere discussion converged on. Pavel Shukhman (Reliza) specifically raised the need to express "this path has not been assessed" as a first-class state.
One question: For the custom scheme option, is there a mechanism to register custom schemes in a versioned taxonomy, or is it free text? This came up in the SPDX Safety Profile discussion as a concern for tooling interoperability.
I will review the patch and the full example against the SPDX Safety Profile draft vocabulary and report back. Will also share this with Kate Stewart so she can assess alignment from the SPDX side.
devashridatta-dotcom commentedon Jul 11, 2026
Thank you again for the detailed guidance. Following your suggested path, I've put together two example BOMs showing the same OpenSSL component expressed using existing CycloneDX 2.0 constructs risk, perspective, assetClassification, and criticality alongside a sketch of how the safetyIntegrity field would attach to those constructs.
Example 1 Automotive (ISO 26262 / ASIL-D)
{ "bomFormat": "CycloneDX", "specVersion": "2.0", "metadata": { "timestamp": "2026-07-11T00:00:00Z", "component": { "type": "firmware", "name": "brake-by-wire-ecu", "version": "3.1.2", "manufacturer": "acme-automotive" } }, "components": [ { "type": "library", "name": "openssl", "version": "3.2.1", "purl": "pkg:generic/openssl@3.2.1", "bom-ref": "openssl-3.2.1" } ], "blueprints": [ { "bom-ref": "bp-brake-ecu", "assetClassification": { "criticality": "critical" }, "component": { "ref": "openssl-3.2.1" } } ], "perspectives": [ { "bom-ref": "persp-automotive", "domains": [ { "name": "automotive-safety", "description": "ISO 26262 — road vehicles functional safety", "standards": ["ISO 26262"] } ] } ], "risks": [ { "bom-ref": "risk-brake-openssl", "affects": [ { "ref": "openssl-3.2.1" } ], "domain": { "ref": "persp-automotive" }, "impact": { "categories": ["safety", "physical"], "rating": "critical" }, "relatedVulnerabilities": [], "description": "Compromise of OpenSSL in brake-by-wire TLS path could interfere with actuator command integrity" } ], "x-safetyIntegrity": { "_comment": "SIC sketch — proposed net-new field per #955", "ref": "openssl-3.2.1", "classification": { "scheme": "ISO26262", "level": "ASIL-D" }, "normalizedLevel": "CRITICAL", "mitigationModifier": { "redundancyPresent": true, "isolationLevel": "hardware-enforced", "description": "dual-channel lockstep CPU with hardware watchdog" }, "assertionBasis": { "assertedBy": "acme-automotive", "method": "certified", "reference": "TÜV-SÜD-2024-1187", "assertionDate": "2024-11-01" } } }Example 2 Medical (IEC 62304 / Class-C)
{ "bomFormat": "CycloneDX", "specVersion": "2.0", "metadata": { "timestamp": "2026-07-11T00:00:00Z", "component": { "type": "device", "name": "infusion-pump-controller", "version": "2.4.0", "manufacturer": "medtech-inc" } }, "components": [ { "type": "library", "name": "openssl", "version": "3.2.1", "purl": "pkg:generic/openssl@3.2.1", "bom-ref": "openssl-3.2.1" } ], "blueprints": [ { "bom-ref": "bp-pump-ctrl", "assetClassification": { "criticality": "critical" }, "component": { "ref": "openssl-3.2.1" } } ], "perspectives": [ { "bom-ref": "persp-medical", "domains": [ { "name": "patient-safety", "description": "IEC 62304 — medical device software lifecycle", "standards": ["IEC 62304", "FDA 21 CFR Part 820"] } ] } ], "risks": [ { "bom-ref": "risk-pump-openssl", "affects": [ { "ref": "openssl-3.2.1" } ], "domain": { "ref": "persp-medical" }, "impact": { "categories": ["safety", "health"], "rating": "critical" }, "relatedVulnerabilities": [], "description": "Compromise of OpenSSL in drug delivery TLS path could interfere with infusion rate commands — potential patient harm" } ], "x-safetyIntegrity": { "_comment": "SIC sketch — proposed net-new field per #955", "ref": "openssl-3.2.1", "classification": { "scheme": "IEC62304", "level": "Class-C" }, "normalizedLevel": "CRITICAL", "mitigationModifier": { "redundancyPresent": false, "isolationLevel": "software-only", "description": "software watchdog with alarm escalation only" }, "assertionBasis": { "assertedBy": "medtech-inc", "method": "self-declared", "reference": "FDA-510k-2024-K241892", "assertionDate": "2025-01-15" } } }devashridatta-dotcom commentedon Jul 12, 2026
On reflection, I have placed x-safetyIntegrity as a top-level extension in the examples above for readability, but per your guidance, the correct attachment point is within the blueprint's assetClassification block, matching your meridian-infusion-pump.cdx.json example. The corrected automotive example:
{ "blueprints": [ { "bom-ref": "bp-brake-ecu", "assetClassification": { "criticality": "critical", "safetyIntegrityLevels": [ { "scheme": "ISO-26262", "level": "ASIL-D" } ] }, "component": { "ref": "openssl-3.2.1" } } ] }devashridatta-dotcom commentedon Jul 12, 2026
One open question from the cross-ecosystem alignment work in ossf/sbom-everywhere#144 that I would like to raise here for CycloneDX's input:
Token case normalization proposed shared regex pattern
The SRAP sidecar and SPDX Safety Profile preserve native regulatory typography (IEC 62304, Class C, ASIL-D). CycloneDX 2.0 enforces lowercase kebab-case (iec-62304, class-c, asil-d). Policy engines translating between formats currently have no agreed normalization rule.
Proposed regex patterns as a shared reference:
The SRAP validator (srap_validator.py v0.2) implements these patterns and normalizes to CycloneDX kebab-case at output. The question for CycloneDX: should the 2.0 schema accept these patterns via a regex constraint, or should a normalization pre-processor be the agreed standard approach before schema validation?
stevespringett commentedon Jul 12, 2026
Preprocessor, not regex in the schema. 2.0 keeps exact match enums with one canonical token per value;
srap_validator.pynormalizing at output is the right division of labor.Three structural reasons. The scheme gates its permitted levels through conditional validation on exact tokens, which is what lets a validator reject
{"scheme": "ISO-26262", "level": "sil-3"}; patterns dissolve that gating.meta:enumdocumentation keys on exact strings. And multiple accepted spellings of one fact break comparison, deduplication, signing, and the reversible rename into generated formats such as Protocol Buffers.One correction to the table: CycloneDX does not lowercase everything. Standard identifiers keep canonical casing, so schemes are
ISO-26262,IEC-62304, and so on; only levels are kebab (asil-d,class-c).ASIL-Das a level fails the draft schema.Native typography already has a first class home: the perspective model maps JSONPath expressions to a
nativeName, so a functional safety perspective rendersasil-das "ASIL D" without touching the machine vocabulary. We can publish a canonical functional safety perspective alongside the schema and carry your regex table as informative crosswalk material. Shared vocabulary and crosswalk, per serialization token rules: that is the achievable form of naming alignment.stevespringett commentedon Jul 12, 2026
Related to #955
devashridatta-dotcom commentedon Jul 12, 2026
Thank you for the correction on scheme casing and the preprocessor guidance. Updating the SRAP sidecar specification and validator accordingly scheme identifiers keep canonical casing (ISO-26262, IEC-62304) and only levels are kebab (asil-d, class-c).
To make the SRAP to CycloneDX 2.0 mapping explicit, here is the full field-by-field reference based on your guidance on this thread and the three attached files which you shared
safety_goal_ref and safety_function_ref were contributed by Chris Blask during schema co-design on ossf/sbom-everywhere#144. They explain why a component matters to a specific safety goal and function the "why it matters" layer that sits above "what classification applies."
devashridatta-dotcom commentedon Aug 8, 2026
Update: SRAP was formally presented to the SPDX Functional Safety SIG on August 7, 2026. The group directed repositioning SRAP as a standardised communication format for change impact analysis, which aligns directly with the evidence model in #333.
Meeting notes: https://docs.google.com/document/d/18BotF5QsrxT0dY4Ibq-SiADd0nYddMJkvHUU0qi4oxE
jkowalleck commentedon Aug 10, 2026
@devashridatta-dotcom , the file is private - requested viewer/commenter access to it. You should have received my request notes.
devashridatta-dotcom commentedon Aug 21, 2026
Update for cross-ecosystem alignment: SPDX 3 model PR spdx/spdx-3-model#1436 has merged.
The SPDX-side model now includes:
SafetyContextRelationshipas a lifecycle-scoped relationshipsafetyIntegrityLevelSafetyIntegrityLevelTypevocabulary covering ASIL, SIL, DAL,other, andnoAssertionThis aligns with the core modeling direction discussed here: safety integrity and safety relevance are context/relationship-scoped assertions, not intrinsic component properties.
The useful next alignment point is vocabulary/crosswalk consistency: SPDX now has relationship-scoped ASIL/SIL/DAL labels, while the CycloneDX 2.0 discussion here has focused on scheme/level safety-integrity classification in system context. The SPDX merge gives a concrete counterpart for keeping the ecosystems aligned.
devashridatta-dotcom commentedon Aug 29, 2026
Follow-up proposal: document-level profile conformance for SRAP
Building on this safety relevance proposal, I think the cleanest CycloneDX path is to separate two concerns:
declarations,claims,evidence,risks,perspectives,definitions, andproperties.This avoids making "safety relevance" only a component-level property and gives validators a standard hook for profile-specific validation.
Describe the feature
Add an optional document-level profile conformance declaration to CycloneDX. Proposed primary location:
{ "metadata": { "profileConformance": [ { "name": "SRAP", "version": "2.2", "canonicalId": "https://spdx.dev/profiles/srap/2.2", "schema": "https://example.org/srap-cdx-profile-2.2.schema.json", "schemaDialect": "https://json-schema.org/draft/2020-12/schema", "conformance": "strict", "hashes": [ { "alg": "SHA-256", "content": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855" } ] } ] } }The declaration means:
It does not mean every component in the BOM is safety-relevant. Component-level and assertion-level safety relevance should remain expressed in the BOM content itself.
For CycloneDX 2.0-dev, SRAP content appears to map naturally to existing structures:
declarations.claimsfor SRAP assertions such asChangeTrigger,ChangeImpactAnalysis, andRequirementVerificationdeclarations.evidencefor supporting evidencerisks.risks[]for safety risksperspectives[]for safety context views, usingmappings[].expressiondefinitions.standards[].requirementsfor safety requirementspropertiesor structuredext:*extensions such asext:spdx.dev:srapfor SRAP-specific fieldsPossible solution
Define a reusable profile conformance object with fields such as:
name: short profile identifier, for exampleSRAPversion: profile versioncanonicalId: stable version-pinned IRI for the profileschema: IRI of the profile JSON Schema documentschemaDialect: JSON Schema dialect URIconformance:strictoradvisoryhashes: cryptographic hashes of the schema documentIn
strictmode, I recommend thathashesbe required. Without schema integrity checking, a profile declaration can be weakened by substituting the schema source, which is a real attack surface in regulated environments.Schema sketch:
{ "profileConformance": { "type": "array", "uniqueItems": true, "description": "Declares that this BOM claims conformance to one or more external profiles and identifies the schema used to validate that claim.", "items": { "type": "object", "required": ["name", "version", "schema"], "additionalProperties": false, "if": { "properties": { "conformance": { "const": "strict" } }, "required": ["conformance"] }, "then": { "required": ["name", "version", "schema", "hashes"], "properties": { "hashes": { "minItems": 1 } } }, "properties": { "name": { "type": "string", "minLength": 1 }, "version": { "type": "string", "minLength": 1 }, "canonicalId": { "type": "string", "format": "iri-reference" }, "schema": { "type": "string", "format": "iri-reference" }, "schemaDialect": { "type": "string", "format": "iri-reference" }, "conformance": { "type": "string", "enum": ["strict", "advisory"], "default": "advisory" }, "hashes": { "type": "array", "minItems": 1, "items": { "$ref": "cyclonedx-common-2.0.schema.json#/$defs/hash" } } } } } }Validator behavior could be:
schemaIRI.hashesare present, verify the resolved schema before applying it.conformanceisstrictand hashes are absent, fail validation.conformanceisstrictand the schema cannot be resolved, fail validation or returnindeterminatefor validators that support tri-state results.conformanceisadvisoryand the schema cannot be resolved, warn and continue base CycloneDX validation.Alternatives
One alternative is to place this under the existing root-level
profilesobject as:{ "profiles": { "conformanceProfiles": [] } }That may be preferable if maintainers want all profile-related concepts grouped together. My only concern is that CycloneDX 2.0-dev already appears to use root-level
profilesas a catalog of reusable characterizations such asdataProfilesandthreatProfiles, while this proposal is a conformance declaration about the BOM document itself.Another alternative is to keep SRAP entirely in
propertiesorext:*extensions. That works for producers and consumers that already agree out of band, but it does not give validators a standard way to discover which external profile is in use or which schema should be applied.Additional context
This proposal is intentionally not asking CycloneDX maintainers to own SRAP semantics. The SRAP companion schema could be maintained by SRAP maintainers, an SPDX Functional Safety group, or another external profile owner. CycloneDX would only provide the standard declaration hook.
This would also help organizations that exchange CycloneDX BOMs but do not exchange SPDX documents. They could still preserve SRAP-style safety relevance assertions in CycloneDX while making the profile claim and validation rules explicit.
Open questions for maintainers:
metadata.profileConformance, or under rootprofilesasprofiles.conformanceProfiles?strictconformance requirehashes? I recommend yes.risksandperspectivesfor CycloneDX 2.0-dev?devashridatta-dotcom commentedon Sep 1, 2026
Revised Proposal Based on discussion:
Proposed direction
srap:*orext:*only as compatibility/profile terms, notcyclonedx:*draft properties.Field-level mapping
metadata.profileConformanceorprofiles.conformanceProfilesname,version,canonicalId,schema,conformance,hashesSafetyContextRelationship,relationshipType,scope,from,tosafetyIntegrityLevels[]with{ scheme, level }ChangeTrigger,triggerType,source,triggerRefChangeImpactAnalysis,status,impactLevel,affectedRefs,rationaledeclarations.attestations[].map[], conformance, confidence, evidenceRequirementVerification,verificationMethod,evaluationResultdeclarations.claims[].evidence[],counterEvidence[], and external referencesEvidenceRelationship,supports,contradicts,investigates,verifiesCompatibility path
For CycloneDX 1.7 and current tooling, SRAP can be represented without changing the base schema by using
metadata.properties,component.properties,definitions.standards[].requirements[],declarations.claims[],declarations.attestations[].map[], anddeclarations.evidence[].For CycloneDX 2.0, I think the proposal should avoid adding a separate safety metadata block. The preferred direction seems to be using
risks,perspectives, blueprints,criticality, declarations, claims, attestations, and evidence, with only the missing safety integrity classification vocabulary added or standardized.Open questions
profileConformancelive undermetadata, or under root-levelprofiles?safetyIntegrityLevels[]attach to blueprint asset classification, requirements, or both?This keeps SRAP aligned with SPDX safety work while respecting CycloneDX's existing model and 2.0 direction.
devashridatta-dotcom commentedon Sep 1, 2026
Alignment update: #1041 as the narrow implementation candidate
I updated PR #1041 to align with the direction discussed here.
The key change in framing is that #1041 is intentionally narrow. It does not try to add the full SRAP vocabulary to CycloneDX core, and it does not treat safety relevance as a flat component-level property. Instead, it focuses on the small native gap identified in this discussion: standards-aligned safety integrity classification.
How I see the split now
safetyIntegrityLevels[].SafetyContextRelationship,ChangeTrigger,ChangeImpactAnalysis,RequirementVerification, andEvidenceRelationship.Existing CycloneDX carriers
For the broader SRAP model, CycloneDX 2.0 already appears to provide the right carriers:
risksfor safety impact and risk linkage.perspectivesand blueprints for system/context views.criticalityfor contextual asset importance.vulnerabilitiesand VEX analysis for vulnerability impact.declarations,claims,attestations, andevidencefor assertion and evidence chains.definitions.requirementsfor safety requirements.Narrow native gap
The piece that still appears useful in CycloneDX core is a reusable, machine-readable safety integrity classification:
{ "safetyIntegrityLevels": [ { "scheme": "ISO-26262", "level": "asil-d" } ] }PR #1041 currently models this with scheme-gated levels for ISO 26262, IEC 61508, DO-178C, IEC 62304, and EN 50128, plus a custom scheme option.
This keeps CycloneDX aligned with automotive/product-risk work while allowing SRAP to stay compatible with SPDX safety work at the profile layer.
Question for maintainers: is #1041 the right narrow shape to prepare for RFC, while #954 continues as the design thread for broader SRAP profile guidance?
kaylinloose commentedon Sep 23, 2026
@devashridatta-dotcom I think that in addition to the consequence classes you have listed you should consider adding information disclosure and denial of service. For some softwares and their components those are the worst things that can happen, it doesn't necessarily concern physical safety as much as privacy. I think this is a really great addition thank you.
devashridatta-dotcom commentedon Sep 23, 2026
@kaylinloose Thank you, that is a good point. I agree that information disclosure and denial of service are important consequences, especially for software where the primary harm is privacy loss, confidentiality loss, or service unavailability rather than physical safety.
I think the clean CycloneDX mapping is to represent those through the broader risk model rather than as safety integrity levels themselves:
confidentialityandprivacy, with impact categories such asprivacy,regulatory, orfinancialdepending on the case.availability, with impact categories such asoperational, and potentiallysafetyorhealthif service loss can lead to harm.So I agree these should be considered in the examples and guidance. For SRAC/safety, they become especially important when the disclosure or service loss affects a safety-relevant context.
jkowalleck commentedon Sep 28, 2026
RFC notice sent on 21 September 2026.
RFC period ends on 19 October 2026.
feat: safety impact of changes on classified contexts (#954, #1041)
feat: safety impact of changes on classified contexts (#954, #1041)
devashridatta-dotcom commentedon Oct 20, 2026
Thank you to everyone who contributed to this discussion and implementation. PR #1120 has now merged into 2.0-dev; it explicitly closes this issue and supersedes my implementation proposal #1041. Closing this issue as completed. Any remaining SRAP profile guidance or examples can be tracked separately.