Linux und Open Source in sicherheitskritischen Systemen: Wie die IEC 61508 den Weg ebnet

DKE: Wie sehen Sie persönlich die Herausforderungen und Chancen der dritten Edition der IEC 61508 für funktional sichere Systeme, insbesondere im Kontext von Open Source?

Ahmann: Allgemein streben Standards, die maximale Sicherheit gewährleisten sollen, natürlich nach kontinuierlicher Weiterentwicklung. Neue Versionen entstehen, weil sich das Umfeld und die Anforderungen der Systeme verändern. Das gilt auch für die dritte Edition der IEC 61508. Gerade jetzt beobachten wir einen großen Aufschwung bei Open-Source-Lösungen in sicherheitskritischen Systemen – zum Beispiel in der Automobilindustrie. Hier kommen zunehmend Linux-basierte Systeme, die im asiatischen Raum entwickelt werden, ins Spiel. Sie werden sowohl für die Prototypenentwicklung als auch in Serienprodukten genutzt. Das bringt jedoch große Herausforderungen mit sich, insbesondere was die Anpassung der Entwicklungsprozesse betrifft. 

Klassische Entwicklungsmodelle, wie sie in vielen Normen vorgesehen sind, lassen sich nur schwer auf die Open Source-Welt übertragen. Die Normen setzen oft auf Checklisten und strikte Prozesse – das passt nicht ohne Weiteres zu den kollaborativen, oft iterativen Ansätzen der Open-Source-Entwicklung.

DKE: Welche Probleme sehen Sie in der Praxis, wenn Unternehmen versuchen, Open-Source-Projekte an die Anforderungen der IEC 61508 anzupassen?

Ahmann: Bisher lag der Fokus der IEC 61508, insbesondere bei der Route 3S, stark auf vorbestehender Software. Hier gibt es klare Vorgaben für Nachweise, die oft eine intensive Nacharbeit und Anpassung erforderlich machen. Diese strikten Anforderungen sind in einem Open-Source-Umfeld schwierig umzusetzen. Gleichzeitig haben wir in der Open-Source-Welt eine unglaubliche Vielfalt und Qualität an Softwarelösungen, die bereits in relevanten und sicherheitskritischen Systemen (Cyber-Sicherheit) eingesetzt werden. Aber diese Lösungen erfüllen nicht immer die formalen Erwartungen der Normen.

DKE: Woran liegt das und wie könnte sich das ändern lassen?

Ahmann: Bisher repräsentieren die Normen primär die Best Practices, die von Industrievertretern aus Unternehmen eingebracht wurden, und haben keinen direkten Bezug zu Open-Source-Software. Die Normen stehen somit vor der Aufgabe, Best Practices aus der Open-Source-Welt aufzugreifen und zu integrieren. Schließlich geht es darum, die Erfahrungen und die Qualität, die Open Source oft mitbringt, in die Maßstäbe der Normen einfließen zu lassen. 

Das ist besonders im Automobilbereich wichtig, wo die ISO 26262 als abgeleitete Norm der IEC 61508 weit verbreitet ist. Hier wurde mit ISO PAS 8926 ein Ansatz entwickelt, der speziell auf vorbestehende Software eingeht, weil die Standardvorgaben der Route 3S allein in vielen Fällen, beispielsweise in der Automobilindustrie, nicht ausreichend und gerade für komplexere Software schwer zu rechtfertigen sind.

DKE Tagung Funktionale Sicherheit: 13.05.2025 bis 14.05.2025 in Erfurt

Neue Technologien und Lösungen erobern die Welt – aber wie kann funktionale Sicherheit dabei Schritt halten? Eine berechtigte Frage, die wir diskutieren wollen und müssen! Und wo wäre das besser möglich als in Erfurt? Die "Erfurter Tage" haben sich mittlerweile als fester Begriff und Branchentreff etabliert. Alle zwei Jahren kommen Expertinnen und Experten im Kaisersaal zusammen und tauschen sich aus. Seien auch Sie dabei und freuen Sie sich auf zwei intensive Konferenztage!

Zwischen Monolith und Modularität: Wie Linux' Komplexität den Aufstieg spezialisierter Open-Source-Lösungen befördert

DKE: Sie werden in Ihrem Vortrag bei der DKE Tagung Funktionale Sicherheit 2025 vier Open-Source-Projekte besprechen: Linux, Zephyr, Xen und ThreadX. Welche spezifischen Herausforderungen und Fortschritte sehen Sie bei jedem dieser Systeme?

Ahmann: Ich fange vielleicht mal mit dem größten und am häufigsten eingesetzten System an – Linux. Linux ist ein Rich Operating System, das auf leistungsstarken Mikroprozessoren läuft und in vielen Bereichen, von Servern bis hin zu bildverarbeitenden Anwendungen und eingebetteten Systemen, eingesetzt wird. Im Automobilbereich ist es gerade für die Prototypentwicklung interessant, da hier bereits zahlreiche Bibliotheken verfügbar sind. 

Gleichzeitig gibt es aber auch Herausforderungen. Die größte davon ist die Komplexität. Linux umfasst Millionen von Codezeilen, die als monolithische Struktur organisiert sind. Das erschwert es enorm, Anforderungen wie die Unabhängigkeit von Funktionen (Freedom from Interference) zu gewährleisten. Auch die Nachvollziehbarkeit von Anforderungen und Testergebnissen – sogenannte Traceability – ist schwierig. Obwohl Linux in sicherheitskritischen Systemen verwendet wird, liegt der Fokus bisher weitestgehend nicht auf Qualifizierungen im Sinne von funktionaler Sicherheit. Dennoch gibt es Fortschritte, wie die Einführung von Echtzeiterweiterungen, die weiche Echtzeit-Anwendungen ermöglichen. Das macht Linux in vielen Bereichen – von Automobilen bis zur Luftfahrt und Industrieautomatisierung – interessant.

DKE: Sie erwähnen die Herausforderungen von Traceability und Dokumentation. Wie lässt sich das mit Normen, wie der IEC 61508 oder ISO 26262, in Einklang bringen?

Ahmann: Das ist in der Tat komplex. In Projekten wie dem ELISA-Projekt (Enabling Linux in Safety Applications) der Linux Foundation, welches ich als Leiter des technischen Steuerkreises vertrete, haben wir verschiedene Normen verglichen und festgestellt, dass sich viele Anforderungen ähneln. Es geht dabei um nachvollziehbare Anforderungen, Design, Dokumentation, Tests und qualifizierte Entwickler. Diese Anforderungen gibt es auch in der IEC 61508 und der ISO 26262. Für Linux ist die schiere Größe des Systems jedoch eine große Hürde, weshalb kleinere und spezifischere Open-Source-Projekte wie Zephyr, Xen oder ThreadX hier attraktiver erscheinen.

Weniger Code – mehr Klarheit: Wie kleinere Open-Source-Systeme mit Transparenz und Zertifizierung überzeugen

DKE: Welche Vorteile bieten diese kleineren Systeme im Vergleich zu Linux?

Ahmann: Zephyr ist ein Echtzeitbetriebssystem, das von Anfang an mit Blick auf Sicherheitszertifizierungen entwickelt wurde. Es hat eine kleinere Community und einen überschaubareren Codeumfang, was die Nachvollziehbarkeit erleichtert. Xen ist ein Hypervisor, der ursprünglich nicht für funktionale Sicherheit gedacht war, aber durch seinen Fokus auf Cybersicherheit und hochwertige Entwicklungsstandards ein starkes Fundament hat. 

Und dann ist da noch ThreadX, das von Microsoft als proprietäres Produkt entwickelt und vor Kurzem als Open-Source-Lösung freigegeben wurde. Es ist bereits zertifiziert und bietet eine gute Basis für funktionale Sicherheit. Das Besondere bei ThreadX ist, dass es von einer neutralen Stiftung verwaltet wird, was die Entwicklung einer Community und die Anpassung an die Bedürfnisse von Open Source erleichtert. Hier zeigt sich, wie Open Source auf ein bestehendes, zertifiziertes System angewendet werden kann, um es weiterzuentwickeln.

DKE: Wie schätzen Sie die Entwicklung dieser Projekte ein? Gibt es bereits funktional sichere Lösungen aus Open Source?

Ahmann: Ja, es gibt erste funktional sichere Open-Source-Lösungen, die von Unternehmen zertifiziert wurden. Das ist aber oft ein langwieriger Prozess, da Open-Source-Projekte normalerweise keine klassischen Entwicklungsmodelle nutzen. In den nächsten Jahren erwarte ich jedoch, dass wir mehrere solcher Lösungen sehen werden, da immer mehr Firmen hinter diesen Projekten stehen und deren Potenzial erkennen. Außerdem gibt es ein starkes Interesse Einblicke in den Code zu bekommen, den proprietäre Lösungen oft nicht bieten.

Offen, aber sicher – Wie Transparenz und Automatisierung den Widerspruch zwischen Open Source und funktionaler Sicherheit überwinden

DKE: Funktionale Sicherheit und Open Source stehen scheinbar im Widerspruch. Wie lässt sich dieser Konflikt überwinden?

Ahmann: Das ist tatsächlich eine spannende Frage, denn Open Source basiert auf Offenheit und Freiheit. Projekte entstehen oft aus dem Engagement von Freiwilligen, die ihre Ideen und Prototypen frühzeitig zur Verfügung stellen, um Rückmeldungen zu erhalten und andere zur Mitarbeit einzuladen. Das steht im Gegensatz zu sicherheitskritischen Systemen, bei denen Produkte robust, gehärtet und vollständig getestet sein müssen, bevor sie auf den Markt kommen. Trotzdem bilden sich in professionellen Open-Source-Projekten schnell Strukturen heraus. Es gibt formalisierte Prozesse, die sicherstellen, dass Beiträge geprüft werden, bevor sie in den Entwicklungszweig aufgenommen werden. 

Viele dieser Projekte setzen stark auf Automatisierung: Quality Gates, Check-Tests und Coding Guidelines sind längst etabliert. Das Interessante ist, dass Open Source oft ohne klassische Prozessdokumentation auskommt, aber dennoch sehr effiziente Abläufe entwickelt, die Tools begleiten und deren Einhaltung erzwingen. Das führt zu einer zentralen Frage: Wie definieren wir Anforderungen und verifizieren diese? Das ist typischerweise nicht formal dokumentiert in Form von Anforderungen und Traceability. Hier bietet Open Source aber enorme Vorteile, vor allem durch Transparenz. Man kann sehen, wie Software funktioniert, welche Daten verarbeitet werden, und potenzielle Schwachstellen identifizieren – etwas, das bei proprietärer Software oft nicht möglich ist. Daraus lassen sich Anforderungen ableiten und Traceabilty zu Dokumentation und Test etablieren.

Transparenz schlägt Blackbox – Open Source punktet in der Cybersicherheit, während funktionale Sicherheit noch nachjustiert werden muss

DKE: Das klingt, als könnte Open Source in puncto Cybersicherheit sogar proprietären Lösungen überlegen sein. Wie sehen Sie diesen Vergleich im Hinblick auf funktionale Sicherheit?

Ahmann: Richtig. In der Cybersicherheit hat sich Open Source mittlerweile etabliert. Es wird in sicherheitskritischen Bereichen wie dem Finanzsektor, auf den meisten Servern oder in nahezu jedem Smartphone genutzt. Die Transparenz ermöglicht es, Schwachstellen zu erkennen und zu beheben. Für die funktionale Sicherheit ist die Situation jedoch komplexer. Viele Open-Source-Projekte erfüllen die formalen Anforderungen der Normen noch nicht. Dennoch laufen Open-Source-Bibliotheken bereits in sicherheitskritischen Systemen. Auch einzelne Open-Source-Komponenten sind schon formal zertifiziert worden. 

Die Herausforderung besteht darin, wie wir die Qualität und Nachvollziehbarkeit dieser Software sicherstellen können. Im Vergleich dazu bleibt proprietäre Software oft eine ‚Blackbox‘. Wir können nicht hineinschauen und müssen darauf vertrauen, dass der Hersteller alle Standards erfüllt hat. Wären diese proprietären Produkte quelloffen und allen zugänglich, hätten wir die Möglichkeit, den Quellcode zu analysieren und potenzielle Schwachstellen selbst zu identifizieren – ein klarer Vorteil.

Mit unserem DKE Newsletter sind Sie immer top informiert! Monatlich ...

• fassen wir die wichtigsten Entwicklungen in der Normung kurz zusammen
• berichten wir über aktuelle Arbeitsergebnisse, Publikationen und Entwürfe
• informieren wir Sie bereits frühzeitig über zukünftige Veranstaltungen

Kein Angriff, sondern Kooperation – Wie Transparenz und Schwarmintelligenz die funktionale Sicherheit bereichern

DKE: Man könnte fast sagen, das ist ein Angriff auf proprietäre Lösungen in der funktionalen Sicherheit, oder?

Ahmann: Das würde ich nicht unbedingt als Angriff sehen. Proprietäre Software hat ihre Berechtigung, vor allem durch Haftung und die Einhaltung von Entwicklungsprozessen übernehmen die Hersteller Verantwortung. Aber Transparenz bietet zusätzliche Sicherheit. Wenn wir den Quellcode sehen können, finden wir Fehler, die wir sonst vielleicht übersehen hätten. 

Natürlich wird Open Source oft kritisiert, weil gefundene Fehler öffentlich sichtbar sind. Doch diese Fehler wären in proprietären Systemen möglicherweise unentdeckt geblieben. Hier greift außerdem die ‚Schwarmintelligenz‘ der Open-Source-Community: Sie erhöht die Chance, Schwachstellen zu finden und zu beheben, da eine vielfältige Gruppe von Expertinnen und Experten mit unterschiedlichen Perspektiven zur Verfügung steht. Das ist eine Stärke, die langfristig auch der funktionalen Sicherheit zugutekommen könnte.

DKE: Letzte Rückfrage dazu: Haben Projekte wie Zephyr oder ThreadX Linux-Elemente integriert?

Ahmann: Nicht direkt. Sie bedienen sich zwar einiger Konzepte oder Tools aus der Linux-Welt, aber sie sind eigenständige Systeme. Zum Beispiel wurde die Geräte- und Kernelkonfiguration von Linux auch in Zepyhr eingesetzt, aber der Kern dieser Systeme basiert nicht auf Linux. Zwischen dem Xen-Projekt, dem Zephyr-Projekt und dem ELISA-Projekt für Linux findet regelmäßig ein intensiver Austausch statt, um zu erörtern, wie funktionale Sicherheit in Open-Source-Projekten realisiert werden kann. Darüber hinaus werden Prototypen entwickelt, die diese Projekte zu einem integrierten System vereinen. Diese dienen als Blaupause, um Anwendern die Anpassung und Erstellung eigener Systeme zu erleichtern.

--- Ende von Teil 1 dieses Interviews ---

Hier endet die erste Gesprächsrunde mit Philipp Ahmann zur Anwendung von Open Source in sicherheitskritischen Systemen.

Teil 2 dieses Interviews wird am 03.03.2025 veröffentlicht.

DKE Tagung Funktionale Sicherheit 2025: Keynotes, Fachdiskussionen, Community

Sie möchten vom 13. bis 14. Mai 2025 an der Veranstaltung in Erfurt teilnehmen? Wir freuen uns auf Sie!

Core Safety & Information Technologies umschließt alle Aspekte der Sicherheit: grundlegende  Sicherheitsanforderungen, funktionale Sicherheit, Informationssicherheit sowie deren Wechselwirkungen. Außerdem befasst sich Core Safety mit wichtigen Querschnittsthemen und definiert grundlegende Anforderungen die allgemein einzuhalten sind – zum Beispiel für Elektromagnetische Verträglichkeit, Umwelt- und Ressourceneffizienz, Schadstoffe, Größen, Einheiten und Kennzeichnungen. Weitere Inhalte zu diesem Fachgebiet finden Sie im