Softwaretests
Code analysieren, Risiken minimieren
Fachbeitrag | Die einschlägigen Vorschriften für Software in der Medizintechnik fordern hohe Qualitätsstandards bei Sicherheit und Zuverlässigkeit. Testing alleine reicht hier nicht aus. Der Code selbst muss auch auf Fehler und Schwachstellen hin untersucht werden – in allen Phasen der Entwicklung.
| Auf einen Blick |
|---|
Der Einsatz der statischen Analyse als automatisierter, integraler Bestandteil in der medizinischen Software-Entwicklung hilft dabei, sicherheitsrelevante Fehler früh zu erkennen und noch vor dem Testing zu beheben. Damit kann neben einer Steigerung der Code-Qualität die Markteinführung eines Produkts signifikant beschleunigt werden, da Aufwand und Kosten für die Fehlerbereinigung spürbar geringer sind. Vor allem die Möglichkeit, auch binären Code zu analysieren, unterstützt eklatant bei der Erfüllung der Norm. Bei Produkten, die bereits am Markt eingeführt wurden, hilft die statische Analyse dabei, potenzielle Sicherheitsprobleme an der bestehenden Code-Basis und an Änderungen genau zu verstehen. Dadurch können die real existierenden Risiken, beurteilt und Pfade zur Beseitigung erarbeitet werden – bevor ein Fehler in freier Wildbahn Schäden verursacht. |
»Gefahr entsteht, wenn der Mensch sich in seiner Position sicher fühlt.« Sicher hatte der chinesische Philosoph Konfuzius nicht die Software-Entwicklung im Sinn, als er diesen Gedanken formulierte. Aber vor allem bei kritischen Embedded-Systemen sollte er das übergeordnete Motto der Entwickler-Teams sein. Denn Fehler lassen sich nicht vermeiden.
Verschiedene Studien zeigen, dass kommerzielle Software im Durchschnitt einen Fehler pro 1000 Code-Zeilen aufweist. Open-Source-Software ist durch die Kontrolle der Communities und die Offenheit etwas besser, hier gehen Experten von 0,68 Fehlern pro 1000 Zeilen aus. Das klingt nach wenig. Doch in der Medizintechnik kann das bereits zu viel sein. Fehler bei Herzschrittmachern, Probleme bei CGM-Systemen – regelmäßig wird in den Medien über Probleme bei lebenswichtigen medizinischen Geräten berichtet.
Die wichtigsten Software-Normen
Nicht umsonst sehen die einschlägigen Vorschriften wie das Medizinproduktegesetz (MPG), die EU-Richtlinie 2017/745 oder die für die Software-Entwicklung in diesem Bereich übliche Normen IEC 62304 und IEC 81304 strenge Qualitätskontrollen vor. Entscheidend für den zu betreibenden Aufwand sind die allen Vorgaben gemeinsamen Risikoklassen. Auch wenn diese im Detail leicht unterschiedlich definiert sind.
Sobald Software oder das Gerät versagen und zu Schäden für den Patienten oder des medizinischen Personals führen können, sind für alle Phasen des Software Development Lifecycles (SDLC) strenge Regeln einzuhalten. Im Falle der für Embedded-Systeme relevanten IEC 62304 fällt jedes System zunächst unter die höchste Risikoklasse C – hier drohen bei einem Fehler schwere Verletzungen oder gar Tod. Für eine Herabstufung auf B oder A muss nachgewiesen werden, dass – sollte die Anwendung versagen – kein oder kein schwerwiegender Schaden entsteht.
Dynamisches Testing oder statische Code-Analyse
Um den Anforderungen gerecht zu werden, die besonders an Software der Klassen B und C gestellt werden, muss die Anwendung validiert und verifiziert werden. Die Norm IEC 62304 fordert in Abschnitt 5.5.2, dass der Hersteller einen Software Unit Verification Process etabliert. Genauer: Er muss eine Strategie, Methoden und Abläufe einführen, um jeden Teil der Software zu verifizieren. Üblicherweise geschieht das durch zwei Methoden: dynamisches Testing und statische Code-Analyse.
Das Testing ist unverzichtbar, hat jedoch zwei Schwachpunkte. Zum einen muss ein lauffähiger Code vorliegen, der getestet werden kann. Zum anderen müssen präzise Testfälle entwickelt und geschrieben werden, um mögliche Fehler aufzuspüren. Um einen Fehler zu erkennen, müssen drei Bedingungen erfüllt sein: Der betreffende Code-Teil wird vom Testfall durchlaufen, der Testfall führt zu einer Error Condition und die Error Condition führt zu einem von der Erwartung abweichenden Ergebnis.
Statische Code-Analyse: Testen am Modell
Anders bei der statischen Code-Analyse: Hier wird die Software nicht wie beim Testing dynamisch durchlaufen. Die Analyse basiert auf einem Modell, das vom Analyse-Tool anhand des Source-Codes erzeugt wird. Die statische Analyse untersucht das Modell mittels sogenannter »Checker auf Fehler« Schwachstellen und Abweichungen von definierten Programmierstandards. Buffer Overruns, Null-Pointer Dereferenzierungen oder Zugriffe auf potenziell unsichere Datenquellen können so erkannt und frühzeitig behoben werden. Dazu muss kein lauffähiger Code vorliegen.
Zudem lässt sich das Verfahren automatisieren und so direkt in die Tool-Chain und das Build-System integrieren. Das Vorgehen ähnelt der Arbeitsweise eines Compilers: Aus den geparsten Quellen erzeugt das Analyse-Tool die Intermediate Representation (IR). Während ein Compiler aus der IR den Objektcode erzeugen würde, nutzt die statische Analyse die IR, um alle Daten- und Steuerungsflüsse durch das Programm zu untersuchen. Damit findet die statische Analyse auch Probleme, die im dynamischen Testing eventuell unentdeckt bleiben, da sie den Ausgang der Testfälle nicht beeinflussen. Dabei unterstützt die statische Analyse fast alle in Sektion 5 der IEC 62304 (Software-Verifizierung) genannten Akzeptanzkriterien wie Data and Control Flow oder Memory Management.
| Statische Analyse mit CodeSonar |
|---|
Eine Besonderheit bei der statischen Analyse stellt das Tool »CodeSonar« von Gramma Tech dar: CodeSonar kann auch Dateien analysieren, die nur binär vorliegen und deswegen nicht einfach in eine IR überführt werden können. Das betrifft vor allem Code von Zulieferer, der zwar immer mehr auch in der Embedded-Entwicklung eingesetzt wird, aber nur extrem schwer auf Bugs oder andere Qualitätsprobleme hin untersucht werden kann. Denn der Code enthält nach dem Disassemblieren zu wenig Informationen, um in seinen Steuerungs- und Datenflüssen nachvollziehbar zu sein. Mehr Informationen finden Sie unter www.grammatech.com/products/codesonar |
Mehr Sicherheit dank Automatisierung
Innerhalb eines nach IEC 62304 ausgerichteten Entwicklungsprozesses sollten die meisten Maßnahmen zur Qualitätssicherung weitgehend automatisiert ablaufen. Diese Forderung wird von der Norm zwar nicht explizit erhoben, ergibt sich aber aus zwei Überlegungen. Automatische Prozesse sind deutlich weniger fehleranfällig als manuelle Abläufe, zudem senkt die Automatisierung Aufwand und Kosten.
Auch setzen sich agile Entwicklungsansätze wie Continuous Integration/Continuous Deployment immer mehr durch. Hierbei ist die automatisierte Qualitätskontrolle unumgänglich, um rasche Integrationen und kurze Build-Times zu erzielen. Je früher innerhalb des Entwicklungszyklus die automatisierte Analyse einsetzt, desto einfacher und kostengünstiger lassen sie dabei gefundene Probleme beseitigen. Ideal ist es, statische Analyse und erste Testverfahren bereits innerhalb der Entwicklungsumgebung am Arbeitsplatz des Entwicklers zu verankern und so den kompletten SDLC abzudecken.
Erst analysieren, dann testen
hre Wirkung innerhalb des SDLC am besten entfalten kann die statische Analyse, wenn sie dem Testing vorangeht. Analyse-Tools liefern dem Entwickler oder Auditor genaue Informationen darüber, wo sich ein potenzieller Fehler im Code versteckt, wie kritisch er ist und welche Probleme genau bestehen. Angewandt auf überschaubare Code-Menge, etwa die tägliche Integration, ist zudem der Zeitaufwand sehr gering.
Damit kann sichergestellt werden, dass das komplexere Testing nicht durch vermeidbare Fehler verzögert wird. Oder es beim Einsatz agiler Entwicklungsmethoden zu einem fehlgeschlagenen Build kommt, der dann mit Priorität bearbeitet werden muss. Zudem können Abweichungen von internen oder allgemein vorgegebenen Programmierregeln vor dem Build behoben und so Inkonsistenzen im Quellcode vermieden werden.
Risiko-Management über den Lebenszyklus
Neben der Qualitätssicherung während der Entwicklung erwarten die Vorschriften auch Sicherheits-Reviews und deren Dokumentation bei Produkten, die bereits am Markt sind. Denn was heute Stand der Technik ist, kann morgen bereits überholt sein. So ist zum Beispiel zu beobachten, dass viele ursprünglich nichtvernetzte Geräte heute mit Konnektivitätskomponenten nachgerüstet werden. Dadurch treten Risiken auf, die bei der Entwicklung nicht absehbar waren. Das zwingt den Hersteller, seine Hard- und Software neu zu validieren und zu verifizieren.
In der EU-Richtlinie ist explizit gefordert, dass Hersteller von Produkten der dortigen Klassen IIa, IIb und III – vergleichbar mit den Klassen B und C der IEC 62304 – für jedes Produkt regelmäßig aktualisierte Sicherheitsberichte erstellen müssen. Innerhalb dieser Wartungs- und Risikomanagement-Prozesse hilft die statische Analyse eher in der Rolle eines Audit- und Dokumentations-Tools. Sie unterstützt dabei, bei Security-Reviews und -Audits den aktuellen Sicherheitsstatus besser zu beurteilen und so eine Roadmap für Verbesserungen festzulegen.
Dieser Aspekt sollte innerhalb des Softwarelebenszyklus nicht vernachlässigt werden. Denn durch regelmäßige Reviews können potenzielle Probleme erkannt werden, die sich durch Updates, funktionale Erweiterungen oder den Austausch von Komponenten ergeben. Es ist sowohl im Sinne des Herstellers als auch der Kunden, dass diese möglichen Risiken kontrolliert adressiert werden – und nicht als Schwachstellen im regulären Betrieb auftauchen.
Autor: Mark Hermeling ist Senior Director Product Marketing bei Gramma Tech
Schlagworte: Softwaretests, Statische Code-Analyse, Software-Entwicklung, IEC 62304
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
