# Proposal: Safety Relevance Metadata for OpenSSF

[devashridatta-dotcom]

Summary

This proposal introduces a new metadata signal, Safety Relevance, to complement OpenSSF's existing ecosystem metrics such as Criticality Score and Scorecard.

Safety Relevance captures whether a software project participates in safety-critical or mission-critical functions where compromise, malfunction, or misuse could result in:

• Physical harm to people
• Environmental damage
• Critical infrastructure disruption
• Large-scale societal impact

The goal is not to replace existing metrics, but to provide an orthogonal dimension describing the real-world consequences associated with software systems.

Motivation

OpenSSF currently provides valuable signals around:

• Security best practices (Scorecard)
• Ecosystem importance (Criticality Score)
• Supply-chain transparency (SBOM initiatives)

However, these efforts do not capture whether software is used in systems whose failure could cause harm beyond cybersecurity consequences.

Examples include:

• Autonomous systems
• Medical devices
• Industrial control systems
• Energy and utility infrastructure
• AI systems with safety implications

A Safety Relevance signal would help organizations prioritize security and governance efforts based not only on technical risk, but also on real-world impact.

Initial Proposal

Introduce a Safety Relevance metadata classification:

• None
• Indirect
• Critical
• Unknown

Potential signals could include:

• Deployment in safety-critical environments
• Dependency centrality in critical infrastructure
• Potential harm surface
• Regulatory or industry classifications
• Declared usage context

Relationship to Existing OpenSSF Initiatives

Safety Relevance is intended to complement:

• Criticality Score: ecosystem importance
• Scorecard: security practices
• SBOM initiatives: component inventory and provenance

Safety Relevance provides an additional dimension describing operational and societal consequences.

Questions for TAC

1. Should Safety Relevance be incubated as a new initiative or under an existing Working Group?
2. Which Working Group is the natural home (Securing Critical Projects, AI/ML Security, or SBOM Everywhere)?
3. Should this begin as metadata and later evolve into a scoring model?
4. What governance and review process would be appropriate for project classifications?

Next Steps

If there is community interest, I can:

• Draft a formal specification
• Develop example use cases and taxonomy
• Engage with relevant Working Groups
• Present the proposal in a TAC or WG meeting

[steiza]

There's quite a bit here!

I think often the question is less "what else can we measure" and instead "how can we use a measurement to make people more secure?" We have no shortage of data and signal from various sources, but helping people use those signals to make good security decisions is more of a challenge.

That aside, there are existing industry standards that include a concept of safety, see for example the safety section of https://www.first.org/cvss/v4.0/specification-document. I would be hesitant to start a new framework from scratch here without understanding why existing frameworks aren't suitable.

Speaking of which, one of the lessons learned from the past 20 years of the CVSS framework is that it's almost impossible to define risk in terms of the software itself - the risk comes from how the software is used and the environment it's deployed in. For example, a MPEG decoding library sitting on npm doesn't have much inherent risk. If that library is part of an internet-connected MRI machine, that risk changes substantially. But crucially that risk assessment comes from the library users not the library maintainers.

[lehors]

I see @steiza and I are aligned. I was about to ask how a project can determine whether it "participates in safety-critical or mission-critical functions". Aren't only users of the software in a position to make that determination?

[devashridatta-dotcom]

Thanks for the thoughtful feedback. I agree that safety is highly contextual and that existing artifacts such as SBOM already provide extensibility mechanisms.

The intent of this proposal is not to introduce a competing inventory format or replace deployment-specific analysis. Rather, it is to explore whether the ecosystem would benefit from a common vocabulary for expressing safety relevance as an additional decision signal.

A few clarifications:

1. Safety Relevance is orthogonal to ecosystem criticality and security posture.

   • Criticality answers: "How important is this project to the ecosystem?"
   • Scorecard answers: "How well does this project follow security best practices?"
   • Safety Relevance asks: "Could compromise or failure of software using this component contribute to physical harm, safety hazards, or mission-critical failures?"

2. This proposal does not assume the signal is an intrinsic property of a package.
   One possibility is that Safety Relevance is deployment- or product-context metadata attached through SBOM properties, VEX, or other attestations. The proposal is intentionally open to discussion on governance and ownership.

3. The goal is to identify whether OpenSSF sees value in a shared taxonomy and guidance, not necessarily to standardize a new artifact.

For example:
Consider the same cryptographic library deployed in two different products:

• Product A: a photo-sharing web application.
• Product B: an infusion pump used in a hospital.

Both products may use the exact same version of OpenSSL and therefore have:

• The same CVEs
• The same CVSS scores
• The same SBOM entries
• The same Scorecard results
• The same ecosystem Criticality Score

However, the consequences of exploitation are very different.

In Product A, compromise may lead to data exposure or service disruption.

In Product B, compromise could interfere with the operation of a medical device and potentially contribute to patient harm.

The proposed Safety Relevance signal is intended to capture this additional context.

This does not mean OpenSSL itself is inherently "safety critical." Rather, an integrator or manufacturer could assert:

{
  "component": "openssl",
  "safetyRelevance": {
    "level": "critical",
    "domain": "medical",
    "assertedBy": "manufacturer",
    "scope": "deployment"
  }
}

SBOM answers: "What software is present?"
CVSS answers: "How severe is the vulnerability?"
Scorecard answers: "How securely is the project developed?"
Criticality answers: "How important is the project to the ecosystem?"
Safety Relevance asks: "What are the real-world consequences if this component fails or is compromised in this deployment?"

I would be very interested in feedback on:

• Whether this signal is useful at all;
• Who should own or assert it (maintainers, vendors, integrators, or third parties);
• Whether existing SBOM/VEX extension mechanisms are sufficient to carry it.

I see this as an ecosystem discussion about improving risk prioritization for safety-critical domains rather than creating another inventory specification.

[chrisblask1]

Thanks for opening this. I strongly support the need for a Safety Relevance dimension.

One suggestion: I would treat Safety Relevance first as contextual metadata with explicit uncertainty, rather than only as a score.

A project may be “safe” in one deployment context and safety-relevant in another. For example, a library used in a consumer web app and the same library used inside medical, energy, transportation, or industrial systems may have very different real-world consequence profiles.

Possible fields worth considering:

• safety_relevance: none / indirect / critical / unknown
• declared_scope: what deployment or usage context the classification applies to
• evidence_basis: why this classification is believed
• classification_source: self-declared / maintainer-declared / downstream-declared / third-party reviewed
• known_unknowns: explicitly declared gaps or uncertainty
• review_status: draft / reviewed / disputed / accepted

The “Unknown” category is especially important. In supply-chain work, an unknown is not necessarily a defect. An undeclared known unknown is the defect.

This could complement SBOM work by helping distinguish between component inventory and real-world consequence. SBOM answers “what is present?” Safety Relevance helps answer “what might it mean if this fails or is compromised?”

[devashridatta-dotcom]

Hi @chrisblask1. Thank you; this is exactly the kind of grounding the proposal needs.
Your field decomposition maps closely to thinking I have been developing in a parallel framework (Safety Relevance Framework / SRF) that I have been prototyping alongside SBOM and VEX workflows in regulated environments. A few points of alignment and one extension:

On classification_source and evidence_basis
These two fields address what I consider the most important governance question in this space: who is asserting, and on what basis? In VEX, we have a well-established model for exploitability assertions with justification and impact_statement. Safety Relevance needs an analogous assertion provenance model. Your classification_source taxonomy (self-declared / maintainer-declared / downstream-declared / third-party reviewed) is a clean parallel to VEX's existing authority model and would make Safety Relevance assertions auditable in the same pipeline.
On known_unknowns
This is the field I would argue matters most for supply chain governance. In practice, most organizations deploying open source in safety-adjacent contexts cannot fully characterize their component safety relevance at ingestion time — they often discover it during integration or audit. An explicit known_unknowns field changes the governance posture from "classify everything or say nothing" to "declare what you know, declare what you don't." That shift alone makes the metadata actionable for downstream tooling and policy engines.
One proposed extension: assertion_scope

Building on your declared_scope, I would suggest distinguishing between:

component_scope — the classification applies to the component itself across all deployments (rare, but applicable to e.g. a certified safety kernel)
deployment_scope — the classification applies to this component in this product or system context (the common case)
integration_scope — the classification applies to a specific interface or call path within the component

This mirrors how IEC 62304 and ISO/SAE 21434 actually treat software elements; classification is rarely binary and almost always context-bound.
On governance and ownership
I agree with your framing that the "undeclared known unknown is the defect." One governance model worth exploring: Safety Relevance assertions could follow the same custodianship model as VEX, meaning the integrator or manufacturer holds the assertion authority, not the upstream maintainer. This resolves the concern raised earlier in this thread about whether a library maintainer can know their downstream safety context. They cannot but the system integrator can, and should be required to declare it.

I would be glad to share a draft schema and illustrative SBOM annotations if that would help ground the discussion further.

[dwelch2344]

how a project can determine whether it "participates in safety-critical or mission-critical functions". Aren't only users of the software in a position to make that determination?

This is my biggest question. It seems feasible for end products, where deployment context is known, but much less so for upstream dependencies.

Modern software is a deep dependency graph. Most libraries have no visibility into how they’re ultimately deployed, so only downstream integrators can determine whether they’re participating in safety- or mission-critical systems. That implies most upstream projects would have to answer “unknown” or opt out, resulting in fragmented and potentially misleading data.

It also feels like creating this in parallel to SBOM/etc will necessitate more locally context-aware, composable attestations rather than a single global assertion. Conceptually this starts to resemble the existing SBOM + VEX + SLSA model, where upstream producers attest to what they know, and downstream consumers add deployment-specific context – which on one hand part of me likes the idea of specifying how to articulate and compose this across the graph, but on the other starts to feel like violating DRY and it's probably a metric/dimension that should fit in existing constructs. Maybe I'm just being lazy tho 😜

[devashridatta-dotcom]

Thanks for the pushback; this is exactly the right set of questions to pressure-test the proposal.

1. Ownership of the signal
   Safety Relevance is not intended to be an upstream-maintained property of a library. The assertion authority follows the same custodianship model as VEX:

System integrators and product manufacturers assert it
Third parties can optionally enrich it
It is never assumed to be intrinsic to the component itself

A library author asserting safety_relevance: critical would be a category error; they're not in a position to know. The classification_source field (self-declared / downstream-declared / third-party-reviewed) captures who is asserting and at what authority level. Most upstream libraries would correctly carry safety_relevance: unknown, and that is the honest, useful answer, not a failure state.
2. This is not a parallel system
The intent is not to introduce a new framework alongside SBOM/VEX/SLSA. The proposal explores whether safety relevance can be expressed as:

A standardized metadata field or extension
Attached to existing artifacts (SBOM, VEX, attestations)
Without requiring a new standalone framework or lifecycle

3. On fragmentation a reframe
   The normalization layer framing may resolve the DRY concern:

SBOM → describes components
VEX → describes vulnerability applicability
SLSA → describes build provenance
Safety Relevance → describes deployment consequence context, asserted downstream

The gap is not a new measurement system. It is a consistent expression of downstream safety context across tools and pipelines, so that policy engines, risk triage systems, and compliance workflows can consume it uniformly rather than encoding it differently in each organization.

5. Proposed narrowing based on this feedback: The most concrete and lowest-risk direction appears to be:

Define Safety Relevance as a VEX/SBOM extension profile only
Explicitly require downstream assertion source
Avoid defining any scoring or algorithm at this stage