Everyone builds on open source. But put OSS into a machine that needs a CE mark and a functional safety argument, and the questions start: Who wrote this? Can you trust it? Can you prove it?

This talk is about using open source software in safety- and security-critical systems and still getting through CE conformity and functional safety (FuSA). It's an engineering talk, not a legal one: concrete integration strategies, real tooling, and a worked example.

The Regulatory Landscape

Two legal instruments define the playing field for machinery in the EU:

■  Directive 2006/42/EC (Machinery Directive) sets the essential health and safety requirements. It barely mentions software, but it expects software not to compromise the machine's safety.
■  Regulation (EU) 2023/1230 (Machinery Regulation) replaces the Directive and applies from 20 January 2027. It is explicit about software safety, cybersecurity, risk assessment, documentation, and traceability. If you ship OSS inside a machine, this one is written for you.

Two standards tell you how to actually get there:

■  EN 50742 (still a draft, prEN 50742) covers protection of machinery against corruption: accidental, intentional, or malicious manipulation that can compromise safety. It concretizes the Regulation's cybersecurity requirements and is expected to be published and harmonized before the Regulation applies.
■  IEC 62443 is the established series for cybersecurity in industrial automation and control systems. Not harmonized under the Regulation, but the most robust framework available for securing software components, OSS included.

Three Ways to Integrate OSS

Whether a given OSS project is fit for a safety-critical system comes down to licensing, community, documentation quality, and your risk assessment. From there, you have three options.

1. Build from scratch. Don't use the OSS directly; treat it as a reference and write your own component. You get full control and a clean route to ISO 26262 or IEC 61508 compliance. You also get the full bill. Worth it when nothing suitable exists.

2. Fork and adapt. Take an existing project and add the safety features and documentation it's missing. You reuse years of development and testing work, but you own the fork forever: keeping it current, resolving licensing questions, and running a gap analysis to show your changes didn't introduce new risks.

3. Contribute upstream. Get the safety and security improvements into the original project. The community carries the maintenance, and everyone benefits. The hard part is getting changes accepted, aligning them with the project's goals, and documenting that they hold up.

The right path depends on the safety integrity level, the project's maturity, the license, and your budget.

There's a fourth move, orthogonal to the other three: shrink the problem. NVIDIA's safety work on the Linux kernel for Drive OS shows it at scale. Certifying even a stripped-down kernel traditionally means a couple million lines of code; their estimate lands at over a thousand engineer-years and hundreds of millions of dollars. Nobody does that. Instead, they scope safety to the code that actually carries safety requirements and isolate it from the rest of the kernel with per-integrity-level page table contexts, so a bug in the unqualified majority can't corrupt the qualified minority. Their assessor expects the concept, implemented as described, to meet ASIL B under ISO 26262. Open source foundation, deliberately drawn safety boundary, evidence behind the claim. That's the pattern this talk generalizes for machinery.

Compliance Is an Evidence Problem

HARAs, TARAs, requirements, architecture decisions, and V&V results have to stay consistent, linked, and auditable, including for OSS you don't control. Documents on a shelf don't survive that. Code does.

I'll show the docs-as-code setup I use in my projects. Sphinx-Needs models requirements, hazards, threats, mitigations, and verification evidence as typed, linked objects that live next to the code, with traceability matrices generated and consistency enforced in CI. On top of that, the Eclipse Trustable Software Framework (TSF) structures the trust argument itself: "this release can be trusted" gets broken down into tenets and assertions, each backed by evidence that's evaluated on every release instead of once at certification time.

The worked example is taktora, my open-source Rust runtime for real-time industrial systems. Its safety case (HARA, safety goals, requirements, architecture, verification) lives in the repository as code. The same workflow carries the HARA and TARA deliverables in my commercial projects.

Key Takeaways

■  OSS works in safety- and security-critical systems, but only with a systematic, risk-based approach. 

■  Scratch, fork, or upstream: the right integration path depends on integrity level, project maturity, licensing, and resources.

■  You don't certify everything you ship. Scope the safety boundary, isolate it technically, and back the claim with evidence. NVIDIA's Drive OS work on the Linux kernel shows the pattern, with an assessor-confirmed path to ASIL B.

■  The practical steps are risk assessment, documentation, V&V, cybersecurity measures, community engagement, and certification. The talk presents them as a specific, actionable list.

■  Docs-as-code traceability (Sphinx-Needs) plus a structured trust argument (Eclipse TSF) turns compliance evidence into versioned, reviewable artifacts that evolve with the code.

■  Directive 2006/42/EC, Regulation (EU) 2023/1230, EN 50742, and IEC 62443 are all reachable with OSS. It takes planning, rigorous testing, and transparent documentation. None of it happens by accident.

Short Bio:

Patrick Dahlke is an independent consultant and principal engineer for functional safety and product security in embedded and industrial systems (ISO 26262, IEC 62443, ISO/SAE 21434, EU CRA, Machinery Regulation). He is the initial developer of taktora, an open-source Rust runtime for real-time industrial systems, contributes to the Sphinx-Needs docs-as-code ecosystem, and helps machine builders get OSS-based systems through CE conformity.