The ELISA Fund added two projects on 5 October 2026. Cregit and stress-ng now sit under the umbrella of the Linux Foundation community that works on Linux functional safety. The announcement was clear about the benefit: broader collaboration across code analysis, testing, and reliability.
It was equally clear, in the fine print of how ELISA works, about what it is not. ELISA does not certify software. It builds shared tools, methods, and documentation that companies can use when preparing a specific system for a safety assessment. Adding a tool to the umbrella is not evidence that anything using it has passed.
That distinction is the whole story. It is also easy to miss.
What ELISA actually added
Cregit analyses the history of Linux kernel code at the level of individual tokens. It shows who introduced which code and how it changed over time. Its co-creators include Daniel German, a University of Victoria professor, and Bram Adams. It uses the same algorithm as git blame, so it inherits the same attribution limits.
stress-ng is a stress-testing tool. Its principal developer, Colin Ian King, describes more than 390 stress tests that exercise subsystems and kernel interfaces under load. He is also careful to note that it is not a precise benchmark suite. ELISA has partially supported the tool for some time.
Neither tool changed. The announcement describes no new code, no combined workflow, and no timetable for folding either into ELISA guidance.
Why Linux functional safety is so hard
Linux was not built to a functional safety standard. It has no safety requirements and no safety case. Its development process targets overall quality, not safety. Those are not small gaps. They are why a decade of effort has gone into making Linux usable in cars, aircraft, and industrial systems without ever certifying the kernel itself.
ISO 26262, the automotive standard, expects safety requirements to flow into design, then code, then verified tests. Upstream Linux offers informal intent in commit messages and an architecture shaped by continuous evolution. The two paradigms do not line up.
The standard also refuses to argue about software in the abstract. It requires reasoning about a specific version and configuration. That single requirement rules out the phrase “we use Linux” as a safety claim.
The numbers behind the difficulty
The scale is the problem. A kernel spans tens of millions of lines. One widely cited industry analysis put the cost of qualifying a meaningful subset for ASIL-B at roughly $300m. That estimate assumed about 1,226 engineers working for a year to cover 1.8 million lines, or 5% of the kernel.
Progress is real but narrow. Red Hat reached ASIL-B functional safety certification for a mixed-criticality group of subsystems in its in-vehicle operating system, working with exida. The achievement covers defined subsystems, not the whole kernel. It also rests on demonstrating freedom from interference, which is hard in a monolithic kernel where everything shares one address space and one privilege level.
The supervision argument
A rival approach abandons the certification goal for the kernel. Elektrobit argues that proving a general-purpose operating system safe by traditional standards is a wild-goose chase. Its alternative places Linux under an external monitor. The safety claim then rests on the monitor’s ability to detect and contain misbehaviour, not on Linux’s correctness. The company says the approach has been assessed by TUV Nord up to SIL2 and ASIL-B.
Both paths share a discipline. Pin the exact version and configuration, and write down the assumptions. ISO/PAS 8926:2024 gives a structure for arguing about a pre-existing software element inside a target architecture, rather than about an open-source project in the abstract.
What the additions do and don’t mean
Cregit and stress-ng are useful additions to that work. Cregit helps a team investigate provenance and evolution. stress-ng helps them exercise behaviour under load. Both feed evidence into a safety argument.
Neither produces one. That is the point ELISA keeps making, and the point worth repeating as more tooling arrives under the banner. A tool can support a safety case. It cannot stand in for one.
Editor’s Note
This analysis draws on the 5 October 2026 ELISA announcement, ELISA’s published scope and FAQ, and independent material on Linux functional safety from Red Hat, NVIDIA, Elektrobit, and ISO 26262 practitioners. Where a figure comes from an industry presentation rather than a standard, we say so.