5 Tipps zur statischen und dynamischen Analyse in Medizinproduktesoftware

Da Cybersicherheit zu einem starken FDA-Schwerpunkt mit spezifischen Anforderungen an die statische und dynamische Code-Analyse wird, müssen Ingenieure diese Praktiken automatisieren und in vorhandene Entwicklungsworkflows integrieren. In diesem Gastblog teilt Andrey Shastin von Auriga einige Tricks aus dem Handel.

Bei Auriga liefern wir seit fast zwei Jahrzehnten viele Softwareentwicklungsprojekte für medizinische Geräte – von relativ einfachen Blutzuckermessgeräten bis hin zu komplexeren Systemen wie Infusionspumpen, Patientenmonitoren und Lungenbeatmungsgeräten. Die Implementierung statischer und dynamischer Codeanalysepraktiken und deren Einsatz in diesen Projekten ist ein wesentlicher Bestandteil unseres Prozesses, und hier werde ich darauf eingehen Statische vs. dynamische Codeanalyse und teilen Sie einige Tipps aus unseren praktischen Erfahrungen und Herausforderungen.

Statische Code-Analyse

Bei der statischen Analyse wird automatisch die Einhaltung bekannter Codierungsrichtlinien (z. B. MISRA, CERT, AUTOSAR, JSF) überprüft und potenzielle Fehler wie Nullzeiger-Dereferenzierung, Division durch Null und Pufferüberläufe erkannt. Moderne statische Analysewerkzeuge ergänzen auch die traditionelle Praxis der Codeüberprüfung, indem sie den manuellen Aufwand um mindestens 30% reduzieren.

In den meisten Fällen zeigt der erste Durchlauf eines statischen Analysetools für Ihren aktuellen Code Tausende von Fehlern (beim ersten Durchlauf sind sogar mehr als 20,000 aufgetreten), was natürlich unglaublich überwältigend sein kann, wie es scheint Jahre, um sie alle zu reparieren. Hier sind einige Tipps unserer Experten, um das Problem zu lösen.

Tipp 1: Der Compiler ist Ihr Freund

Disziplinierte Entwicklungsteams kompilieren normalerweise mit –Wall und –Werror (in GCC) oder / Wall / WX (in Visual Studio) oder verwenden ähnliche Optionen in anderen Compilern. Das Beheben von Compiler-Warnungen ist eine einfache und kostengünstige Möglichkeit, sich auf die Ausführung statischer Analysen vorzubereiten. Wir haben festgestellt, dass das Überprüfen der Ausgabe Ihres Compilers in einem "paranoiden" Modus das Gesamtvolumen der Verstöße gegen die statische Analyse verringern kann.

Obwohl es eine gute Sache ist, alle Compiler-Warnungen zu korrigieren, gibt es viele Projekte, bei denen die Verwendung eines Compilers aus Compliance-Gründen nicht ausreicht und sogar eine akzeptable Option darstellt.

Verwenden Sie nach dem Trocknen Ihres Compilers statische Analysewerkzeuge, die viel tiefer in den Code eintauchen und Ihnen viel mehr Hinweise geben sollen.

Tipp 2: Nehmen Sie die statische Analyse früh im Prozess an

Wenn Sie derzeit Software für medizinische Geräte entwickeln, sollten Sie darauf vorbereitet sein, die Frage einer automatisierten statischen Code-Analyse zu beantworten. Die statische Analyse ist fast garantiert Gegenstand einer Diskussion während eines internen / externen Audits oder sogar einer Einreichung vor dem Inverkehrbringen.

Der Schlüssel besteht darin, das Tool so einzusetzen, dass die Entwicklung nicht an Geschwindigkeit verliert, während sie sich auf die Verbesserung der Qualität konzentriert und sich nicht mit Tool-Eigenheiten und Rauschen befasst. Dies ist ein Balanceakt, der Übung und Fachwissen erfordert, die die Auriga-Ingenieure im Laufe der Jahre erworben haben. Wir haben jedoch festgestellt, dass Sie bei der Ermittlung der Grundursache der gemeldeten Fehler wahrscheinlich feststellen werden, dass viele von ihnen leicht zu beheben sind .

Hier sind nur einige Beispiele aus statischen Analyseberichten, die einfach mit einem einfachen Skript oder gut ausgebildeten Praktikanten behoben werden können:

1) Aufruf klarer Funktionen in Destruktoren:

ein. Der Destruktor '~ CTitle' sollte nicht die Funktion 'clear_' aufrufen, die sich nicht im try-Kontext befindet

b. Der Destruktor '~ THelper' sollte die Funktion 'removeModule' nicht aufrufen, die sich nicht im try-Kontext befindet

2) Auf NULL prüfen:

ein. "PMP" kann möglicherweise null sein

b. "((NPage *) this) -> pSysCfg_" kann möglicherweise null sein

3) Möglicherweise Erklärung im falschen Abschnitt:

ein. Die Datenelemente 'D_FILE_1' werden als 'öffentlich' deklariert.

4) Nicht konstante Argumente:

ein. Das String-Literal "MCollection" wird an die Funktion 'FixedBlockHeap' als Zeiger auf ein nicht konstantes Objekt übergeben

Viele Verstöße gegen vorhandenen Code können Sie beiseite legen und beheben, wenn Sie Ausfallzeiten haben. Es ist jedoch wichtig, beim Entwickeln von Code KEINE neuen Verstöße (technische Abteilung) einzuführen. Beispielsweise, Parasoft C / C ++ test verfügt über Funktionen, mit denen Ingenieure das Rauschen filtern und sich auf die Behebung der kritischsten Verstöße gegen die statische Analyse konzentrieren können.

Dynamische Analyse

Während die statische Analyse den Quellcode als Text interpretiert und alle Schlussfolgerungen basierend auf der Parser-Ausgabe zieht, ohne eine einzige Anweisung auszuführen, Dynamic Application Security Testing oder DAST bietet eine andere Perspektive auf den Code. Es untersucht die Laufen Code, der die Codeabdeckung, die Ausreichend- keit und die Qualität von Komponententests, Speicherlecks und anderen potenziellen Schwachstellenproblemen anzeigt.

Tipp 3: Seien Sie flexibel mit Ihrer Laufzeitumgebung

Der Begriff „eingebettet“ umfasst viele Geräte: von 8-Bit-MCU mit Kilobyte RAM und Flash bis hin zu 64-Bit-Multicore-CPU mit Gigabyte RAM und Hochgeschwindigkeits-SSD. Für den Fall, dass der tägliche Betrieb des Geräts nur minimalen Speicher- und Verarbeitungsaufwand erfordert, entscheiden sich die Hersteller wahrscheinlich für Hardware, die nur auf die Anforderungen der Größe, des Gewichts oder der Kosten ausgerichtet ist. Obwohl sie normalerweise eine gewisse Kapazität für Software-Updates und -Wartung lassen, kann dies für das dynamische Analysetool, das die Software instrumentiert, immer noch unzureichend sein, da der Prozess eine große Menge an RAM (im Vergleich zum normalen Betriebsmodus) und Speicherplatz erfordert Sammeln Sie Test- und Codeabdeckungsergebnisse.

Wenn die Speichermenge auf dem Gerät zu gering ist, um Tests durchzuführen und die Codeabdeckung zu erfassen, ist die Zielplattform möglicherweise nicht zum Sammeln der Codeabdeckung für Einheiten- und Integrationstests geeignet.

Wenn Ihre Hauptzielplattform nicht sofort unterstützt wird, suchen Sie nach gültigen Alternativen. Möglicherweise gibt es eine Schwesterplattform mit mehr Schnittstellen und Speicher, die von einem dynamischen Analysetool unterstützt werden, sodass Sie sie für Unit- und einige Integrationstests verwenden können. Eine andere Alternative ist die Verwendung von Hardware-Simulatoren, auf denen ARM Fast Models und QEMU ausgeführt werden.

Während das Ausführen von Tests auf der Zielplattform am wünschenswertesten ist, entscheiden sich Teams häufig dafür, Unit- und einige Anwendungsintegrationstests auf der Workstation des Entwicklers (wie Linux, Mac, Windows) durchzuführen, um von einem schnelleren Entwicklungszyklus und einer größeren Anzahl verfügbarer Tools zu profitieren für allgemeine Entwicklungsplattformen. In diesem Fall müssen Sie Ihren eingebetteten Code portieren, um mit einem Host-Compiler zu kompilieren, was einige Herausforderungen mit sich bringen kann.

Es gibt viele Compiler, Build-Tools, Frameworks und Methoden, um sie auszuführen. Dynamische Analysetools unterstützen einige gängige Build-Techniken mit internen Annahmen darüber, wie Entwickler sie anwenden könnten. Selbst wenn der Code portabel ist, benötigt das Projektteam daher höchstwahrscheinlich zusätzliche Zeit, um die Einstellungen eines dynamischen Analysetools abhängig von der Funktionsweise des Build-Systems des Projekts anzupassen.

Es wird dringend empfohlen, alle Anstrengungen im Voraus zu schätzen, um den besten Ansatz für die zukünftige Entwicklung und Unterstützung auf lange Sicht zu finden.

Tipp 4: Verlassen Sie sich nicht zu sehr auf automatisch generierte Testfälle

Moderne dynamische Analysewerkzeuge generieren automatisch Sätze von Komponententests, um die Codeabdeckung zu erhöhen. Tools sind jedoch nur Tools - sie sind unabhängig von verschiedenen Szenarien, wie der Produktionscode verwendet werden soll, insbesondere wenn Sie versuchen, die Codeabdeckung zu erhöhen und eine Grenze zwischen reinen Komponententests und Integrationstests zu überschreiten. Sie müssen die generierten Komponententests weiterhin manuell aktualisieren und sogar neue schreiben, da nur Sie wissen, was der Code für positive und negative Testergebnisse tun soll.

Nach unserer Erfahrung können für eine Reihe ausgewählter Dateien in einem kritischen Bereich automatisch generierte Komponententests in einem Bereich von 40% bis 100% für jede Datei erstellt werden. Im Durchschnitt können die Zahlen für das gesamte Projekt zwischen 25% und 60% variieren.

Darüber hinaus können automatisch generierte Komponententests, bei denen nur Quellcode als Eingabe verwendet wird, auf einem fehlerhaften Code häufig perfekt ausgeführt werden. Die automatische Generierung sollte als ein guter Weg verwendet werden, um den Prozess des Komponententests zu starten. Das manuelle Erstellen von Testfällen verbessert die Qualität des Codes, da zusätzliche Codeüberprüfungen erzwungen werden und ein anderer Blickwinkel auf das Design geboten wird.

Tipp 5: Unterschätzen Sie nicht den Aufwand für die Qualifizierung / Validierung von Werkzeugen

Die FDA verlangt, dass jedes Tool, das während der formalen Entwicklung verwendet wird, für den beabsichtigten Gebrauch gültig ist, um sicherzustellen, dass es die erwarteten Maßnahmen ausführt und die richtigen Ergebnisse liefert. Normalerweise ist dies ein spezielles Testprotokoll namens IUV (Intended Use Validation).

Branchenführende Anbieter von statischen und dynamischen Analysetools helfen bei der Erstellung der erforderlichen Verfahren und Dokumentationen. Dies ist äußerst hilfreich, um Ihren Aufwand zu minimieren. Parasofts sind besonders wertvoll, da sie einen großen Teil des Prozesses automatisieren. Wie bei jedem anderen generischen Paket möchten Sie möglicherweise einen Teil Ihrer Bemühungen zur Überprüfung und Anpassung von Dokumenten vorbehalten, um sie mit Ihren eigenen QMS-Verfahren zu synchronisieren. Beispielsweise bietet die Tool Qualification-Software von Parasoft eine Reihe von Testfällen, die in Ihrer Umgebung ausgeführt werden können, um die statischen und dynamischen Analysefunktionen zu validieren.

Zusammenfassend

1. Behandeln Sie Compiler-Warnungen als Fehler. Warnungen können später zu Fehlern für die neuere Version desselben Compilers werden. Warnungen bedeuten oft, dass der Compiler implizit etwas tut.
2. Führen Sie statische Analysetools zu Beginn des Projekts aus und beheben Sie auftretende Probleme.
3. Halten Sie den Code tragbar. Auch wenn Sie nicht vorhaben, Ihr Produkt auf eine andere Plattform zu portieren, ist dies möglicherweise in Zukunft eine Option. Auf der anderen Seite hilft dies auch dabei, Ihren Code sauber, wartbar und lesbar zu halten, was immer gut für die Überprüfung und weitere Unterstützung ist.
4. Verlassen Sie sich nicht zu sehr auf automatisch generierte Testfälle, um die Codequalität zu verbessern.
5. Unterschätzen Sie nicht die Notwendigkeit und den Aufwand, das Tool für eine beabsichtigte Verwendung zu validieren.

Wenn Sie Hilfe bei der Einführung statischer und dynamischer Analysen benötigen, kontaktieren Sie uns bitte unter Wagenlenker.

„MISRA“, „MISRA C“ und das Dreieckslogo sind eingetragene Marken von The MISRA Consortium Limited. ©The MISRA Consortium Limited, 2021. Alle Rechte vorbehalten.