Open Source in der funktionalen Sicherheit

Open Source in der funktionalen Sicherheit

| klss777 / stock.adobe.com & Yaruniv-Studio / stock.adobe.com
10.03.2025 Fachinformation

Zwischen Innovation und Stabilität: QM und Standards in der funktionalen Sicherheit

Im zweiten Teil des Interviews zeigte Philipp Ahmann auf, wie die Transparenz und Arbeitsweise der Open-Source-Community dazu beitragen können, funktionale Sicherheit im Linux-Kernel und darüber hinaus zu gewährleisten. Die Rolle der Software Maintainer und ihre Verantwortung für die Qualitätssicherung stehen dabei im Mittelpunkt. 

Im dritten Teil werfen wir einen Blick darauf, wie moderne Ansätze für das Qualitätsmanagement und Standards, wie die ISO 26262 und der ISO PAS 8926, dabei helfen können, die Anforderungen an komplexe Softwareprojekte auch für die Cybersicherheit zu erfüllen. Philipp Ahmann erklärt, wie agile Entwicklungsprozesse und Best Practices aus der Open-Source-Welt als Grundlage für einen neuen, zukunftsweisenden Qualitätsstandard dienen können.

Kontakt
Sascha Man-Son Lee
Zuständiges Gremium
Verwandte VDE Themen

Interview mit Philipp Ahmann – Teil 3

DKE: Welche Parallelen sehen Sie zwischen den Fortschritten in der Cybersecurity und den Herausforderungen der funktionalen Sicherheit?

Ahmann: Es gibt viele Parallelen, die deutlich machen, wie sich diese beiden Bereiche entwickeln. In der Cybersicherheit hat Open Source in den vergangenen 15 Jahren enorme Fortschritte gemacht und ist heute in diesem Bereich akzeptiert und oft sogar bevorzugt. Das war nicht immer so. Vor 15 Jahren hatten Produkte nicht das heutige Maß an Cybersicherheit. Sie waren weniger vernetzt, die Angriffsvektoren waren kleiner, und das Thema Sicherheit hatte noch einen ganz anderen Stellenwert. Heute läuft Open-Source-Software, wie Linux oder andere UNIX-Abkömmlinge, auf rund 99 Prozent der Server weltweit – auch in sicherheitskritischen Anwendungen. 

Das war früher undenkbar. Wenn man diese Entwicklung extrapoliert, könnte die funktionale Sicherheit in zehn Jahren an einem ähnlichen Punkt stehen. Ich denke, dass viele der Vorurteile und Befürchtungen, die wir heute in der funktionalen Sicherheit gegenüber Open Source sehen, ähnlich sind wie die, die es noch vor etwa einem Jahrzehnt in der Cybersicherheit von Open Source gab.

Fehler finden, Risiken minimieren – Der evolutionäre Weg von der Cyber- zur funktionalen Sicherheit

DKE: Wie sieht die Entwicklung in der funktionalen Sicherheit im Vergleich zur Cybersicherheit konkret aus?

Ahmann: Ein zentraler Punkt ist der Mangel an Expert*innen. In der Cybersicherheit gibt es nicht genügend Fachleute, um alle Anforderungen vollständig intern umzusetzen. Deshalb haben sich Open-Source-Lösungen durchgesetzt, die durch Community-Wissen und -Expertise auf ein sehr hohes Niveau gehoben wurden. Ähnliches sehen wir jetzt in der funktionalen Sicherheit. Die funktionale Sicherheit steht heute dort, wo die Cybersicherheit vor einigen Jahren war: Man führt Risikoanalysen durch, nimmt den Code auseinander, überprüft ihn und setzt ihn neu zusammen. 

Genau das passiert aktuell bei Projekten wie Zephyr oder Linux. Wir schauen hinein, analysieren mögliche Fehlerquellen und decken Schwachstellen auf – so wie es auch in der Cybersicherheit geschehen ist. Es ist ein Prozess, der Zeit braucht, aber der langfristig die Basis für robustere Systeme schaffen wird.

DKE: Aber auch in Cybersicherheit gibt es immer noch Schwachstellen. Was können wir daraus lernen?

Ahmann: Absolut, selbst in sehr robusten Systemen werden auch heute noch Sicherheitslücken gefunden. Das zeigt, dass Perfektion weder in der Cybersicherheit noch in der funktionalen Sicherheit erreichbar ist. Aber die kontinuierliche Verbesserung, die Offenheit für Überprüfung und die Lernprozesse aus der Community sind entscheidend. Ein schönes Bild dazu ist der Straßenverkehr: Selbst mit funktional sicheren Systemen wie Airbags, ABS oder Assistenzsystemen passieren immer Unfälle, aber zunehmend weniger. Perfekte Sicherheit gibt es nicht, aber wir kommen ihr schrittweise näher, indem wir Risiken minimieren und Systeme verbessern. 

Das Gleiche gilt für die funktionale Sicherheit. Wir werden Fehler entdecken, aber das ist Teil des Prozesses, um langfristig sicherere und robustere Systeme zu entwickeln. Wichtig bleibt dabei, dass wir auch eine Möglichkeit haben, diese Fehler oder neue Funktionen in bestehenden Systemen zu korrigieren. Bei Cybersicherheit ist das bereits durch gesetzliche Verordnungen gefordert. Automatische Updates über viele Jahre beispielsweise für Assistenzsysteme sind hingegen noch selten zu finden.


DKE Tagung Funktionale Sicherheit 2025

DKE Tagung Funktionale Sicherheit 2025

| VDE

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!

Jetzt anmelden!

Von starren Regeln zu agilen Lösungen: Wie z. B. ISO PAS 8926 den Umgang mit komplexer Software neu definieren

DKE: Wie unterstützen Standards wie ISO 26262-8 und ISO PAS 8926 die Umsetzung der IEC 61508?

Ahmann: Die IEC 61508 bietet mit der Route 3S einen Ansatz, der sich speziell auf vorbestehende Software konzentriert. Das ist auch die Grundlage für ähnliche Ansätze wie den Teil 8 Abschnitt 12 in der ISO 26262, der sich ebenfalls mit vorbestehender Software befasst, allerdings in seiner aktuellen Form für kleinere, wenig veränderte Softwarekomponenten gedacht war. 

Mit dem ISO PAS 8926 wird jedoch ein Ansatz entwickelt, der über diese starren Modelle hinausgeht und in der 3. Edition der ISO 26262 integriert werden soll. Er berücksichtigt die Komplexität moderner Software, insbesondere von Open-Source-Projekten, und stellt konkrete Anforderungen an die Qualität solcher Software. Hier geht es um Fragen wie: Welche Qualitätsstandards müssen erfüllt sein? Wie kann ich sicherstellen, dass Open Source den notwendigen Anforderungen entspricht? Der PAS 8926 bringt dabei neue Ideen ein, die sich auch in künftigen Editionen der IEC 61508 niederschlagen könnten.

DKE: Welche Herausforderungen ergeben sich aus der Integration komplexer Software wie Linux in diese Standards?

Ahmann: Die Integration komplexer Systeme wie Linux in sicherheitskritische Umgebungen ist ein gutes Beispiel für die Herausforderungen. Ein Projekt wie SIL2LinuxMP, das bis 2019 lief, hat gezeigt, dass es prinzipiell möglich ist, Linux auf ein Safety-Integrity-Level-2-Niveau nach IEC 61508 Route 3s-Argumentation zu heben. Allerdings stieß das Projekt an Grenzen, vor allem durch die Komplexität des Linux-Systems und den hohen Formalismus der Normen. 

Die Größe und Vielfalt von Open-Source-Projekten machen es schwer, ausreichende Evidenz für alle Aspekte bereitzustellen, die Normen wie die IEC 61508 oder die ISO 26262 fordern. Gleichzeitig erkennen wir in der Automobilbranche, dass wir diese Software zunehmend benötigen, um die Anforderungen aktueller Systeme und Hardware zu erfüllen und dadurch Wege finden müssen, ihre Qualität zu messen und sicherzustellen.

DKE: Welche Rolle spielen die neuen Ansätze wie der ISO PAS 8926 dabei?

Ahmann: Der PAS 8926 ist ein spannender Ansatz, da er sich mit der Qualitätssicherung komplexer Softwareprodukte befasst. Er bietet Kriterien, um die Qualität solcher Systeme zu bewerten und gibt Hinweise darauf, wie Nacharbeiten organisiert werden können. Besonders für agile Entwicklungsprozesse bietet er eine Basis, um Qualität iterativ und kontinuierlich zu sichern. Das ist eine Entwicklung, die auch für die IEC 61508 relevant werden könnte. 

Wenn man über eine neue Edition der Norm nachdenkt, sollte man Elemente wie die des PAS 8926 mit aufnehmen. Wichtig ist auch der Austausch zwischen den Normungsgremien, insbesondere zwischen denen der IEC 61508 und der ISO 26262. Denn trotz der branchenspezifischen Unterschiede teilen wir oft die gleichen Herausforderungen, insbesondere wenn es um Komplexität, Nachvollziehbarkeit und Qualitätssicherung geht.


DKE Newsletter-Seitenbild
sdx15 / stock.adobe.com

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
Ich möchte den DKE Newsletter erhalten!

Normen im Praxistest: Wie das ELISA-Projekt strenge Standards in flexible Entwicklungsansätze überführt

DKE: Könnten Sie ein Beispiel für diese gemeinsamen Herausforderungen nennen?

Ahmann: Im ELISA-Projekt der Linux Foundation, welches ich als Leiter des technischen Steuerkreises vertrete, arbeiten wir mit verschiedenen Industrien zusammen, darunter Automotive, Luftfahrt, Raumfahrt und Medizintechnik. Alle diese Bereiche kämpfen mit der Komplexität moderner Softwareprodukte und der Herausforderung, Normen wie die IEC 61508 oder ISO 26262 in der Praxis umzusetzen. Wir sehen, dass die Kernanforderungen der Standards sehr ähnlich sind, auch wenn sie branchenspezifisch angepasst wurden. Die geforderten Arbeitsprodukte umfassen nachvollziehbar dokumentierte Anforderungen, Designs sowie Spezifikationen und Tests. Je nach Norm wird zudem eine explizite Rückverfolgbarkeit der Artefakte gefordert. 

Auffällig ist, dass die Normen typischerweise einem Wasserfall- oder V-Modell folgen. In unserem Projekt hingegen interpretieren wir dies eher als eine Beschreibung der Rückverfolgbarkeit und der Verknüpfung von Artefakten, ohne es als festgelegten Entwicklungsablauf zu betrachten. Dies ermöglicht es gemeinsame Ansätze zu entwickeln, um diese Anforderungen effizienter zu erfüllen. Ein intensiver Austausch zwischen den Gremien könnte hier viel bewirken, um gute Praktiken zu teilen und gleichzeitig branchenspezifische Besonderheiten zu respektieren.

--- Ende von Teil 3 dieses Interviews ---

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

Der erste Teil dieses Interviews thematisiert den Grundgedanken von Open Source, aktuelle Projekte und die normative Berücksichtigung in der IEC 61508.

Der zweite Teil des Interviews geht unter anderem auf die Anforderungen an den Linux-Kernels ein sowie die Bedeutung und Rolle der Software Maintainer bei der Entwicklung von sicherheitskritischen Systemen.

Teil 4 dieses Interviews wird am 17.03.2025 veröffentlicht.

Wir bedanken uns für dieses Interview bei

Portraitfoto Philipp Ahmann

Philipp Ahmann

Senior OSS Community Manager, ETAS GmbH

Portraitfoto Philipp Ahmann

Senior OSS Community Manager, ETAS GmbH

Philipp Ahmann ist Senior Open Source Community Manager bei der ETAS GmbH, einem Unternehmen der Bosch-Gruppe. Mit über 15 Jahren Erfahrung in Linux-basierten Softwareplattformen für die Automobilindustrie bringt der Diplomingenieur und Master of Science für Elektrotechnik fundiertes Fachwissen in die Entwicklung sicherheitskritischer Anwendungen ein.

In seiner Rolle als Vorsitzender des technischen Steuerkreises des ELISA-Projekts (Enabling Linux in Safety Applications) der Linux Foundation leitet Ahmann die strategische Ausrichtung und die Systems-Arbeitsgruppe, um Linux in sicherheitskritischen Umgebungen zu etablieren. In der Eclipse Software Defined Vehicle Working Group unterstützt er die Entwicklung von Automotive Open Source Prozessen und die Erstellung eines sicheren Open-Source-basierten Middleware-Stacks. Darüber hinaus ist er Mitglied des Advisory Boards der Linux Foundation Europe, wo er die Weiterentwicklung von Open-Source-Initiativen unterstützt.


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!

Jetzt anmelden!

Interessiert an weiteren Inhalten zu Core Safety?

Fokusbild Core Safety & Information Technologies

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

DKE Arbeitsfeld Core Safety & Information Technologies

Relevante News und Hinweise zu Normen