ISO/IEC 5230 · ISO/IEC 18974 · OpenChain · OpenSSF
Open source used to be a question for the legal department, asked once, shortly before a product shipped. The Cyber Resilience Act turned it into a continuing regulatory obligation with deadlines attached.
Most embedded products are now mostly other people’s code. That was already a licensing problem and a due-diligence problem. It is now also a safety problem and a reporting problem — and the four are the same problem, because they all depend on being able to say precisely what is in a given build.
Two specifications
May you ship it, and can you defend it
The OpenChain Project maintains two international standards that answer different questions about the same code. Most organisations have built something for the first and almost nothing for the second — which is unfortunate, because the second is where the regulatory pressure is now landing.
ISO/IEC 5230
Licence compliance
A programme that reliably identifies what you are using and what each licence obliges you to do. Deliberately about process rather than legal opinion: the standard asks whether your organisation can be trusted to get this right repeatedly, not whether one product happened to be clean.
ISO/IEC 18974
Security assurance
The same idea applied to security: can you find out that a component you depend on is vulnerable, decide what it means for your product, and act — as a routine capability rather than a fire drill. This is the specification the CRA’s vulnerability-handling duties map onto most naturally.
What we do
Programme setup · gap analysis
Assess where you stand against either specification, build the missing parts, and size the programme to your organisation rather than to the standard. Conformance is a by-product of a programme that works, not a target to aim at directly.
The OpenChain CRA checklist
The OpenChain Project has published a CRA compliance framework that doubles as a self-certification checklist, covering programme governance, SBOM quality, vulnerability handling, regulatory reporting, open-source stewardship and the technical file. It is released under CC0, so you can adopt and adapt it without asking anyone.
It is a good starting structure and it is not a compliance programme. Working through it tells you quickly which obligations you have no answer for — which is exactly what a gap analysis should produce. We use it as a common reference so that a workshop starts from an agreed list rather than an argument about scope.
SBOM
A capability, not a document
An SBOM produced once, by hand, to satisfy a customer questionnaire is worth almost nothing. The question it has to answer is asked years later, under time pressure: what exactly was in the build that is currently in the field?
The CRA expects manufacturers to identify and document the components in their products, and to keep handling vulnerabilities across the support period. When an advisory lands, the clock starts — and everything after that depends on whether the bill of materials was generated by the build or assembled by a person. One of those is still accurate in year six. The other was already wrong at hand-over.
We work on the generation path rather than the artefact: SPDX or CycloneDX produced in CI, tied to a specific build and archived with it, complete enough down the dependency tree to be useful, and matched to a triage process that can turn a CVE into a decision. For safety-relevant products this is also what makes a post-SOP safety impact analysis possible at all.
Upstream
Not your code, still your problem
Regulators do not distinguish between the code you wrote and the code you picked up. If a component you depend on is unmaintained, has no disclosure process and is signed by nobody, that is your risk to carry — and increasingly your obligation to have noticed.
The Open Source Security Foundation has done most of the useful work here, and there is little point inventing your own version of it. Scorecard gives you a repeatable read on how a project is maintained. SLSA gives you a vocabulary for build integrity and provenance that suppliers can be held to. The Best Practices Badge gives upstream projects something concrete to be measured against. We help you decide which of these actually change a decision in your context, wire them into selection and monitoring, and avoid the failure mode where a dashboard is produced that nobody acts on.
Selection and monitoring
Criteria for adopting a dependency that go beyond whether it compiles, and a watch that notices when a healthy project stops being one.
Supplier requirements
Clauses your Tier-2 can actually meet, asking for the SBOM and the disclosure contact rather than a signature under a paragraph nobody reads.
Giving back
Contribution and stewardship policy — including where the CRA’s provisions for open-source stewards change what your own upstream activity means.
What we do not do: legal advice
We work on the process, the tooling and the evidence. Interpreting what a particular licence obliges you to do in a particular case is a lawyer’s job, and we will say so rather than guess. In practice the two divide cleanly: a good compliance programme means your lawyer is asked a small number of well-prepared questions instead of a large number of vague ones.
Where the obligations come from: Cyber Resilience Act →