The Little Sidecar That Learned to Walk
In less than two weeks, a question about software safety moved from coffee-call conversation to an OpenSSF issue, a community schema, a validator, and active alignment with CycloneDX and SPDX. That speed is interesting. The way it happened is more interesting.
I think in documents.
Not because documents are sacred. Most documents are one version away from being wrong, and many achieve that distinction before anyone finishes writing them.
I think in documents because conversation needs somewhere to land.
A person says something in a meeting. Someone else recognizes the shape of it. A note becomes a diagram. The diagram gets criticized. The criticism becomes a better question. The question gets placed where other people can disagree with it. Before long, the original thought has acquired names, boundaries, examples, code, and a small community of people who now care whether it works.
That is roughly what happened to the Safety Relevance Assertion Profile, or SRAP.
The visible paper trail covers about twelve days.
That is not enough time to create an international standard, and SRAP is not one. It is currently a community review draft and active proposal.
It is, however, enough time for an idea to become real.
The Question SBOMs Do Not Answer
A Software Bill of Materials can tell you that OpenSSL is present in a product.
A VEX document can tell you whether a particular vulnerability is considered exploitable in that product.
Neither necessarily tells you what happens to people when that component fails in this particular deployment.
That is the gap.
More from Chris Blask:
Chris Blask
Chris Blask
OpenSSL in a photo-sharing application is not the same thing as OpenSSL supporting authenticated therapy commands in an infusion pump. The package name and version may be identical. The safety consequences are not.
The same component might appear in:
- a brake-by-wire controller governed by ISO 26262;
- a medical device governed by IEC 62304;
- an industrial control system governed by IEC 61508;
- an ordinary consumer application with no identified safety-significant function.
The software does not carry one permanent safety value inside itself.
Its significance depends on where it is, what it is doing, which safety function it supports, what configuration is active, and who is making the claim.
The sentence that eventually became SRAP’s defining principle is:
Safety relevance is not a permanent property of software. It is an attributable, context-specific claim about whether, where, and how that software participates in a safety-significant function.
That one sentence rules out several tempting mistakes.
An upstream library maintainer cannot reasonably label a package “safety critical” for every possible use. A redundant component does not become safety-irrelevant merely because another component can take over. A certificate reference is not proof that every component-level claim made beside it is correct. And a safety classification from one domain cannot simply be translated into another because the labels look ordinally similar.
Context matters.
Authority matters.
Evidence matters.
Unknowns matter.
The First Pass
By July 1, Devashri Datta, the instigator and originator of the SRAP conversation, was already defending the essential shape of the idea in an OpenSSF Technical Advisory Council issue.
Safety relevance, she argued, should be asserted downstream by product manufacturers and system integrators - the people who know the deployed system - not treated as an intrinsic upstream property of a library.
She was also explicit about what she was not trying to create.
- Not another parallel compliance universe.
- Not a competing framework beside SBOM, VEX, and SLSA.
- Not a magical scoring algorithm that converts every safety domain into one reassuring number.
The early framing was wonderfully narrow:
- SBOM describes what is present.
- VEX describes vulnerability applicability.
- SLSA describes build provenance.
- Safety-relevance metadata describes deployment consequence context.
That narrowing mattered. Standards work often fails by arriving with too much ontology before it has earned the right to name anything.
The initial advice was therefore simple: make the problem legible, build a short discussion deck, and take it toward the communities already working on SPDX safety, ELISA, OpenSSF SBOMs, VEX, and deployment context.
A Safety Bundle and short alignment deck appeared on July 6. The deck explicitly called itself a discussion seed, not a competing standard.
Then the conversation accelerated.
The Useful Kind of Disagreement
On July 10, Devashri presented the idea to the SBOM Everywhere Special Interest Group.
The group did what a good technical community should do: it made the idea less comfortable and more useful.
- Should safety relevance be a property on a component, or a relationship between a component and a system?
- How should the model represent a component that is important to a safety function but protected by redundancy?
- What is the difference between an unassessed component and one that has been assessed as not relevant?
- Should ASIL, SIL, DAL, and IEC 62304 classes be flattened into a common severity scale?
- What evidence supports the assertion?
- Who reviewed it?
- Can it be revoked?
These were not objections to the existence of the idea. They were pressure applied to its weak joints.
The relationship model won.
That was the crucial move.
A component is not universally safety-relevant. It is safety-relevant to a function, in a system, under a configuration, during a period of time.
From there, other distinctions followed:
- mitigation must remain separate from relevance;
- native safety-standard vocabularies must be preserved;
- known unknowns must be structured records, not a Boolean;
- safety goals and safety functions need explicit references;
- an assertion needs an identity, issuer, authority role, evidence, review state, and lifecycle;
- disagreement must remain visible unless one assertion explicitly supersedes another.
The proposal was becoming less like a label and more like an accountable claim.
Give the Claim Somewhere to Travel
The next architectural decision was practical: use a sidecar.
An SRAP sidecar is a YAML file that travels beside an existing SBOM.
- It does not rewrite the SBOM.
- It does not rewrite the VEX document.
- It identifies the parent SBOM, references one or more components inside it, and adds the deployment-specific safety context those artifacts do not carry.
A directory might look like this:
my-product/
sbom.cdx.json
srap-assertions.yaml
vex.json
The SRAP sidecar can say:
- which system and deployment the assertion covers;
- which exact SBOM artifact it belongs to;
- which component is referenced;
- which safety classifications apply;
- which safety goal and function the component supports;
- whether it implements, monitors, isolates, authenticates, or recovers;
- under which conditions the assertion remains valid;
- which failure consequences matter;
- which mitigations exist;
- what remains unknown;
- who made the assertion;
- what evidence supports it;
- whether it is draft, reviewed, accepted, superseded, revoked, or expired.
That last sequence is not administrative decoration.
Reviewed is not accepted.
Accepted is not permanent.
Superseded is not erased.
Revoked is not forgotten.
The current sidecar specification also binds the assertion to the exact parent SBOM using a digest, rather than trusting that a filename will always point to the same artifact. It preserves conflicts rather than silently letting the “most specific” claim win. It allows explicit applicability conditions and exclusions. And it keeps evidence references attributable without pretending that the existence of a reference proves the claim.
Then CycloneDX Answered
This is where the story became particularly enjoyable.
Steve Springett, creator of CycloneDX, mapped the emerging SRAP vocabulary field by field against CycloneDX 2.0 work in progress.
Much of the needed structure was already present or emerging:
- blueprints for system and deployment scope;
- assets, data flows, use cases, and behavior models;
- party models for attributable roles;
- attestations and external references for evidence;
- annotations and exclusions for known unknowns;
- risk-impact categories;
- safety-integrity-level structures.
That did not mean SRAP disappeared into CycloneDX.
It meant the two efforts could align rather than compete.
CycloneDX could provide a rich native representation. SRAP could provide a narrow, format-neutral sidecar usable across CycloneDX, SPDX, and other inventory ecosystems.
The mapping also improved SRAP itself.
Safety classifications became an array because real systems can carry more than one applicable certification. Custom safety schemes became structured objects rather than arbitrary strings. Scheme casing and level normalization were corrected. A preprocessing approach replaced premature schema tricks.
This is what healthy standards evolution looks like.
Not a committee defending the first draft.
A draft becoming more accurate because reality and other people are allowed to touch it.
Twelve Days Later
By the evening of July 12, Devashri had produced a standalone SRAP Sidecar Specification v2.0 draft and was incorporating feedback into a shared alignment document.
The current community review draft names Devashri Datta and Chris Blask as co-authors, acknowledges contributions from Allan Friedman, Nicole Pappler, and Pavel Shukhman, and records Steve Springett’s CycloneDX review. It includes a canonical YAML structure, medical and automotive examples, a non-safety example, token-normalization rules, conditional validator requirements, open alignment items, and a validator identified as version 0.3.
That is a significant amount of evolution for something that was still being framed as a missing context layer days earlier.
Again, it is not a ratified standard.
That distinction matters.
But it now exists strongly enough to be criticized, implemented, tested, mapped, signed, broken, corrected, and improved.
That is a different state of being from “someone has an idea.”
The Real Story Is the Method
The cybersecurity story here is safety relevance.
The more general story is how useful things get made now.
- A practitioner notices a gap.
- A coffee-call community provides social surface area.
- An issue gives disagreement a durable home.
- A slide deck makes the gap visible.
- A working group supplies pressure.
- A few people contribute distinctions.
- An established specification community maps the proposal against existing machinery.
- Language systems help turn conversations into schemas, examples, comparisons, and revisions.
- Humans continue deciding what the words are allowed to mean.
Nobody needs to wait for a five-year program to begin before doing useful work. Nobody needs to declare victory after generating a YAML file.
The work moves by alternating between imagination and correction.
- Conversation and artifact.
- Proposal and review.
- Local coherence and external pressure.
That is the measure I find most interesting.
Not how quickly a model can produce a specification-shaped object.
How quickly a group of humans and language systems can produce an object, expose it to people with different knowledge, preserve the disagreements, revise the structure, and return with something more useful than any participant originally held.
SRAP is a small sidecar with a large idea inside it:
- Software does not know where it is allowed to matter.
- People operating systems do.
The job of the artifact is to let them say so clearly, attributably, and without collapsing context into inventory.
The goal is alignment, not competition.
One safety model.
Several compatible representations.
No collapse of meaning.
And now the little sidecar has learned to walk.
