Embedded Medical | Softwaresicherheit
Statische Codeanalyse schützt Medizinprodukte
Softwarefehler in Medizingeräten können Menschenleben gefährden. Statische Codeanalyse mittels »abstrakter Interpretation« ermöglicht den formalen Nachweis, dass kritische Schwachstellen nicht existieren – eine Schlüsseltechnologie für medizinische Safety und Security.
Wurde Software in der Medizintechnik früher lediglich als kleiner Zusatz zur elektronischen Hardware wahrgenommen, übernimmt sie inzwischen wichtige Teile der Funktionalität und trägt im »software-defined medical device« zu einem Großteil der Wertschöpfung bei. Insbesondere wird auch immer mehr sicherheitskritische Funktionalität durch Software realisiert.
Ein weiterer wichtiger Aspekt ist die zunehmende Vernetzung der Geräte, durch die sich die Gefahr von Cyberattacken massiv erhöht. Eine Fehlfunktion oder bösartige Manipulation der Steuerungssoftware kann im Extremfall Menschenleben gefährden, aber auch in weniger kritischen Systemen hohe Kosten verursachen – nicht zuletzt durch Rückrufaktionen.
Ein aktuelles Beispiel hierfür ist der im November 2025 erfolgte permanente Rückruf der Life2000-Ventilatoren von Baxter durch die US-Behörde für Lebens- und Arzneimittel (FDA) aufgrund der Schwachstelle CVE-2024-48973 – eine kritische Cybersecurity-Schwachstelle durch einen offenen Debug-Port ohne Authentifizierung, durch die an dem Beatmungsgerät Einstellungen verändert und auf sensible Gerätedaten zugegriffen werden konnte. Weltweit waren über 4.800 Geräte betroffen.
Sicherheitskritische Medizinsoftware
Prinzipiell sind bei der Entwicklung sicherheitskritischer Software (sowohl im Sinne von Safety als auch Security) branchenspezifische Normen und gesetzliche Vorgaben zu berücksichtigen. Zu den für Medizintechnik relevanten Normen gehören die IEC 62304 sowie deren Basisnorm IEC 61508 außerdem die Normen IEC 81001-5-1, IEC TR 60601-4-5 und BSI TR03161. Juristisch gelten das Medizinproduktegesetz, die EU-Verordnung 2017/745 (MDR), das Medizinprodukte-EU-Anpassungsgesetz (MPEUAnpG) und die kommende Neufassung des Produkthaftungsgesetzes basierend auf der EU-Richtlinie 2024/2853. Die Neufassung bezieht digitale Produkte und Komponenten vollumfänglich in die Produkthaftung ein und betrachtet unzureichende Cybersecurity-Maßnahmen als Produktfehler. Eine ähnliche Verschärfung gilt auch im US-Markt durch den Food and Drug Omnibus Reform Act (FDORA) von 2022, der bei Zulassungsanträgen umfassende Cybersecurity-Konzepte fordert.
Nicht ohne Safety und Security
Safety- und Cybersecurity-Anforderungen gehen hierbei Hand in Hand. Wie der White House Report »A Path Toward Secure and Measurable Software« (2024) ausführt, ist der Großteil der schwerwiegenden Cybersecurity-Schwachstellen der vergangenen Jahrzehnte auf mangelnde Speichersicherheit zurückzuführen. Zu diesen Schwachstellen zählen Pufferüberläufe, Lesezugriffe auf uninitialisierte Variablen und ungültige Zeigerzugriffe in C/C++-Programmen. Pufferüberläufe werden von der Cybersecurity and Infrastructure Security Agency (CISA), dem FBI und weiteren Behörden sogar als »unverzeihliche Defekte« eingestuft. Passend hierzu fordert der Europäische Cyber Resilience Act (CRA), dass ab dem Jahr 2027 auch außerhalb regulierter Sektoren jegliche Produkte mit digitalen Komponenten ohne bekannte ausnutzbare Schwachstellen ausgeliefert werden müssen.
Grundlagen der statischen Codeanalyse
Für Medizinsoftware wie auch für andere sicherheitskritische Software bedeutet dies, dass nicht nur Safety-by-Design, sondern auch Security-by-Design bereits bei der Entwicklung realisiert werden muss. Teil der notwendigen Maßnahmen ist die Entdeckung und Behebung von Schwachstellen im Quellcode. Die wichtigste Technik hierfür ist die statische Analyse, im Kontext der Software-Sicherheit häufig als SAST (Static Application Security Testing) bezeichnet. Der Begriff »statische Analyse« umfasst eine breite Klasse unterschiedlicher Verfahren, die gemeinsam haben, dass die Ergebnisse ohne Programmausführung, rein durch Inspektion des Programmcodes, ermittelt werden. Je nach Tiefe und Strenge der Analyse lassen sich drei Kategorien unterscheiden: rein syntaktische Verfahren, »unsichere« semantische Verfahren und »sichere« semantische Analysen durch »Abstrakte Interpretation«.
Zum Stand der Technik gehört die Einhaltung von Codierstandards wie MISRA C/C++, SEI CERT C/C++ oder CWE (Common Weakness Enumeration). Diese haben zum Ziel, eine Programmierweise zu fördern, die das Risiko kritischer Fehler reduziert. Rein syntaktische statische Methoden können viele Regeln automatisiert prüfen – im Fall von MISRA C sind die Regeln als »entscheidbar« (decidable) kategorisiert. Die Einhaltung der Regeln reduziert das Fehlerrisiko zwar, verhindert Fehler jedoch nicht zuverlässig. Semantische Analysen zielen auf die Entdeckung von Laufzeitfehlern durch undefiniertes / unspezifiziertes Verhalten wie Pufferüberläufe, uninitialisierte Variablen, Feldgrenzenverletzungen oder Datenwettläufe. Da semantische Analysen komplexitätstheoretisch unentscheidbar sind, kann es kein Verfahren geben, das für beliebige Programme alle vorhandenen Laufzeitfehler meldet, ohne Fehlalarme zu produzieren. »Unsichere« (engl. unsound) semantische Verfahren können Laufzeitfehler übersehen (Falsch-Negative) und Fehlalarme (Falsch-Positive) produzieren. Alle Codierstandards beinhalten semantische Regeln; im Fall von MISRA C sind diese als »undecidable« kategorisiert.
Die »Abstrakte Interpretation« ist eine formale Methodik für semantikbasierte Codeanalyse, bei der nachweislich keine Falsch-Negative auftreten, also keine Defekte übersehen werden (engl. Soundness). Die Wohldefiniertheit (Soundness) der Analyse wird mathematisch bewiesen und garantiert, dass sämtliche potenziellen Variablenwerte und Kontrollpfade, einschließlich aller möglichen Ziele von Funktions- und Datenzeigern, berücksichtigt werden. Wohldefinierte Analysen können als zuverlässige Analysen bezeichnet werden, da sie vollständige Daten- und Kontrollabdeckung liefern und Schlussfolgerungen erlauben, die für sämtliche Programmläufe und -Eingaben gültig sind.
Durch »Abstrakte Interpretation« lassen sich bestimmte Klassen von Schwachstellen formal als nicht vorhanden nachweisen, sodass entsprechende Angriffe fundamental ausgeschlossen werden können. In Fällen wie klassischen Buffer Overflows lässt sich der Verstoß direkt als undefiniertes Verhalten der Programmiersprache erkennen. In anderen Szenarien ergibt sich das Risiko erst aus der Weitergabe von Werten zwischen Komponenten oder Geräten sowie aus daraus resultierenden Daten- oder Kontrollflussabhängigkeiten – weshalb die Analyse flexibel an spezifische Angriffsmodelle anpassbar sein muss.
Astrée in der Praxis
Die Funktionsweise und der praktische Einsatz dieser Methodik wird im Folgenden anhand des Astrée-Analysators von AbsInt erläutert, der zu der Kategorie von Laufzeitfehleranalysatoren auf Basis der Abstrakten Interpretation gehört. Der Hauptzweck von Astrée besteht darin, Programmierfehler zu melden, die aus undefiniertem oder unspezifiziertem Verhalten in C/C++ resultieren. Hierzu gehören sequentielle Programmierdefekte wie z. B. Division durch Null, Feldgrenzenverletzungen, fehlerhafte Zeigerzugriffe (z. B. Buffer Overflows, Nullpointer-Dereferenzierungen, Dangling Pointer) oder Zugriffe auf uninitialisierte Variablen.
Darüber hinaus bietet Astrée eine wohldefinierte Nebenläufigkeits-Semantik und ist somit in der Lage, auch Fehler, die sich aus der Interaktion nebenläufiger Threads ergeben, sicher zu erfassen, darunter Data Races, Fehler bei Lock/Unlock-Mechanismen und Deadlocks. Das Tool analysiert damit nicht nur den Daten- und Kontrollfluss innerhalb eines einzelnen Threads, sondern berücksichtigt auch Interferenzen zwischen Threads und deren Auswirkungen auf den Gesamtablauf. Da die Analyse rein statisch ist, lässt sie sich leicht automatisieren und in Versionsverwaltungen, Entwicklungsumgebungen sowie CI/CD- und DevOps-Pipelines integrieren.
Sowohl Laufzeitfehleranalyse als auch Daten- und Kontrollflussanalyse sind Anforderungen der funktionalen Sicherheit und der Cybersecurity. Mit derselben Analyse können daher sowohl Safety- als auch Security-Anforderungen abgedeckt werden – ein wichtiger Beitrag zur Entwicklungseffizienz.
Wechselwirkungsfreiheit
Auf der Basis einer zuverlässigen Laufzeitanalyse kann eine sichere Taint-Analyse durchgeführt werden, mit deren Hilfe sich die Propagation bestimmter Werte durch den Programmfluss nachverfolgen lässt, bzw. bewiesen werden kann, dass ein bestimmter Wert keinen Einfluss auf eine bestimmte Speicherstelle oder Programmstelle haben kann – dies wird als Nicht-Interferenz-Analyse bezeichnet.
Mit Hilfe einer sicheren Taint-Analyse kann eine sichere Überapproximation der Interferenz erfolgen. Bildlich gesprochen wird dabei Farbe in einen Fluss geschüttet und geprüft, an welche Stellen oder in welche anderen Flüsse die Farbe fließen kann. In Astrée können Benutzer mit Hilfe einer Taint-Source-Direktive angeben, dass an einer bestimmten Programmstelle eine Variable mit einer bestimmten Farbe gefärbt wird, etwa beim Aufruf einer API-Funktion, die möglicherweise nicht vertrauenswürdige Werte zurückliefert. Die Propagation der Farben durch die möglichen Programmflüsse wird von der Analyse automatisch durchgeführt. Eine Taint-Sink-Direktive instruiert den Analysator, Alarme zu produzieren, wenn Farben zu unerwünschten Stellen fließen. Durch eine Taint-Cleaning-Direktive kann z. B. in Authentifizierungsfunktionen angegeben werden, dass eine bestimmte Farbe entfernt werden soll. Mit Hilfe dieser Direktiven lassen sich auf einfache Weise anwendungsspezifische Taint-Analysen definieren.
Auf diese Weise lassen sich anwendungsspezifische Eigenschaften aus dem Bereich Safety und Security modellieren, z. B. ob fehlerhafte oder nicht-vertrauenswürdige Werte zu kritischen Berechnungen oder Programmteilen gelangen können, oder ob ohne Authentifizierung kritische Daten verändert oder ausgelesen werden können. Konkrete Beispiele sind die Prüfung auf bzw. der Ausschluss von flussabhängigen Security-Verwundbarkeiten wie z. B. CWE-78 (OS Command Injection) oder CWE-319 (Cleartext Transmission of Sensitive Information). Zusätzlich können die Pfade, auf denen eine bestimmte Farbe propagiert wird, ausgegeben und visualisiert werden.
Unverzichtbare Sicherheit über die Pipelines
Gerade für software-definierte Medizinprodukte, bei denen Software die zentrale Funktionalität des Geräts bestimmt, ist statische Codeanalyse unverzichtbar. Bei diesen Produkten hängt die Sicherheit des Patienten direkt von der Qualität des Codes ab – eine nachträgliche Fehlersuche kann im regulierten Umfeld der Medizintechnik erhebliche Zulassungsverzögerungen verursachen. Die Integration zuverlässiger statischer Analysetools in den gesamten Entwicklungszyklus – von der initialen Implementierung über kontinuierliche Code-Reviews bis hin zur finalen Validierung – ermöglicht es, Schwachstellen frühzeitig zu erkennen und zu beheben. Durch die Automatisierung der Analyse in CI/CD-Pipelines wird die Codequalität kontinuierlich überwacht, sodass Entwickler unmittelbar Feedback erhalten. Die formale Nachweisbarkeit der Abwesenheit bestimmter Schwachstellenklassen durch Abstrakte Interpretation erfüllt dabei nicht nur regulatorische Anforderungen, sondern schafft auch die notwendige Vertrauensbasis für den sicheren Einsatz vernetzter, softwaregesteuerter Medizinprodukte. In einer Zeit, in der Cyberangriffe zunehmen und regulatorische Anforderungen verschärft werden, ist systematische statische Codeanalyse die Grundlage für sicheres Software-Engineering in der modernen Medizintechnik. (uh)
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
