Lesedauer

4 Minuten

Datum

Verfasser

Senior Software Engineer

Was ist eine statische Codeanalyse und was ist der Anwendungsbereich davon?

Insight in Brief

Die statische Codeanalyse hilft die Softwarequalität auf hohem Niveau zu halten. Viele Firmen wissen eine hohe Softwarequalität zu schätzen, denn sie lindert zum Beispiel die Störungsanfälligkeit der Software und unterstützt gleichzeitig die Wartbarkeit.

Dieser Artikel umfasst die folgende Fragestellung und wird durch unsere Experten beantwortet:

  • Was sind statische Tests und was sind die Unterschiede zu dynamischen Tests?
  • Was sind die Vorteile bei der Verwendung eines Tools für die statische Codeanalyse?
  • Ist ein Compiler auch ein statisches Codeanalyse Tool?
  • Wie gut lässt sich modernes C++ mit statischen Codeanalyse Tools testen?
  • Was gilt es bei der statische Codeanalyse im Medizingeräte Umfeld zu beachten?

Einleitung

Die Firma IMT AG strebt eine möglichst gute Softwarequalität und -sicherheit an, weshalb sie unter anderem auf die statische Codeanalyse setzt und geeignete statische Codeanalyse Tools dafür einsetzt. Diese Tools unterstützen die IMT in den unterschiedlichsten Projekten, wobei sie gerade in der Medizinaltechnik als gute Ergänzung zum Erfüllen der Forderungen der Norm IEC 62304, MDR oder FDA sind.

Der Begriff statische Codeanalyse beschreibt typischerweise den Einsatz eines Tools zur Durchführung von statischen Tests. Allerdings gehören z.B. auch Code Reviews dazu.

1. Was sind statische Tests?

Softwaretests sind in zwei Kategorien unterteilt, die statischen und dynamischen Tests.

  1. Der statische Test wird ohne die Applikation auszuführen durchgeführt. Sehr verbreitet ist der statische Test von Source Code. Unter die statischen Tests fallen nebst der Analyse von Source Code auch die Tests von Objectfiles, Libraries und Executables (Binaries). Der Begriff statischer Test wird häufig implizit mit dem statischen Testen von Source Code verwendet. In den folgenden Kapiteln wird die statische Code Analyse nur im Zusammenhang mit der Source Code Analyse betrachtet.Genau genommen fallen nebst den statischen Analysetools auch eine Teilfunktionalität der Compiler unter die statischen Tests. Mehr dazu im Kapitel 3.3. Der Hauptzweck von statischen Tests ist die Überprüfung des Codes auf seine Konformität, Sicherheit und Zuverlässigkeit.
  2. Unter dynamische Tests fallen alle Tests, bei denen die Applikation oder Teile der Applikation ausgeführt werden, um die korrekte Funktionalität zu testen. Um Fehler zu entdecken, muss zuerst eine (Test-) Applikation gebaut werden.

2. Wieso ein statisches Codeanalyse-Tool einsetzen?

  1. Im Vergleich zu manuellen Code Reviews können Tools den Code automatisiert und reproduzierbar analysieren. Dadurch ergibt sich ein Zeitvorteil eines Tools gegenüber der manuellen Untersuchung.
  2. Die Automatisierung ermöglicht eine einfache Einbindung in den Continuous Integration (Was ist Continuous Integration? | Atlassian) Prozess und damit die automatisierte Generierung der Analyse-Reports bzw. eine automatisierte Erkennung möglicher Software-Defekte. Mit entsprechenden Einstellungen kann sogar ein Merge-Request (Getting started with merge requests | GitLab) nicht abgeschlossen werden, sollten noch Defekte durch die statische Codeanalyse erkannt worden sein.
  3. Aus Qualitätssicherungssicht spricht aus oben genannten Beispielen viel für die Verwendung eines statischen Codeanalyse Tools. Ein Nachteil könnte die benötigte Zeit für das korrekte Aufsetzen des Tools sein. Sobald dieses aufgesetzt ist, sind Änderungen an der Konfiguration erfahrungsgemäss eher selten.
  4. Da typischerweise nur beim Aufsetzen des statischen Codeanalyse Tool viel Zeit investiert werden muss, empfiehlt es sich das Tool möglichst früh im Projekt aufzusetzen. Die statische Codeanalyse ist typischerweise ein Teil des Build-Prozesses. Der Build-Prozess wird vor dem (dynamischen) Test-Prozess ausgeführt, da die Applikation und Testapplikation zuerst gebuildet werden muss. Durch die statische Codeanalyse erhöht sich die Wahrscheinlichkeit einen Fehler schon während dem Build-Prozess zu finden, um z.B. Zeit zu sparen.
  5. Oft bieten statische Codeanalysetools noch weitere Features, die zur Codeanalyse herangezogen werden können. Darunter gehören z.B.:
    • Code Metriken: Berechnen von Code Metriken, um auf kritische Stellen aufmerksam zu machen
    • «Dead code» Erkennung: Signalisiert, falls sich Code im Source Code befindet, der niemals ausgeführt werden kann, respektive ausgeführt wird.
    • Design Analysis: Abgleich eines Softwaredesign und der Implementation im Source Code. Allfällige Abweichung wie z.B. Querbeziehungen sind so automatisiert auffindbar.
    • Aufruf-Zyklen: Erkennung zyklischer Aufrufe, welche potenziell zu Speicherüberläufen und damit einem kompletten Ausfall der Software führen können.

3. Sind Compiler auch statische Analyse-Tools?

Um diese Frage zu beantworten, soll folgendes Beispiel der Veranschaulichung dienen:

Codeausschnitt 1 Entdecken Sie die Unschönheiten im Code?
Codeausschnitt 1 Entdecken Sie die Unschönheiten im Code?

Was fällt auf beim Betrachten des Codeausschnitt 1 auf?

In einem Code Review dürften folgende Punkte auftauchen:

Tabelle 1 Findings / Defects vom Code Review über Codeausschnitt 1
Tabelle 1 Findings / Defects vom Code Review über Codeausschnitt 1

Haben Sie alle Defekte gefunden? Bravo! Inwiefern helfen hier der Compiler respektive statische Codeanalyse Tools weiter? Eine Zusammenfassung zeigt die untenstehende Tabelle. Als Codeanalyse Tools wurden Clang-Tidy und Axivion verwendet.

Tabelle 2 Vergleich der Findings von statische Codeanalyse Tools
Tabelle 2 Vergleich der Findings von statische Codeanalyse Tools

Die Ausführung von Clang erfolgte mit den zusätzlichen Parametern -Wall, -pedantic. Diese sind nötig, damit der Compiler möglichst viele Fehler findet respektive anzeigt. Ohne -Wall und -pedantic verhält sich der Compiler mit Warnungen eher bedeckt. Wenn es darum geht, eine (nicht eigens geschriebene) Applikation zum Laufen zu bringen, könnte -Wall, -pedantic sogar eher hinderlich sein. Hier zeichnet sich ein erstes Fazit ab. Sobald der Code einem statischen Test unterzogen wird, sollen die Compiler Warnung (wie -Wall) bereits eingeschaltet werden. Nach dem Motto: Alle Defects die der Compiler schon findet und dann bereits beseitigt werden, tauchen später in der statischen Code Analyse nicht mehr auf, egal ob mit einem Code Review oder einem Analyse Tool.

Clang++ findet nur einen Defect. Die beiden statischen Code Analyse Tools erkennen mehr. Der Unterschied zwischen Clang-Tidy und der Axivion Suite kann durch die Anwendung von verschiedenen Regelsätzen begründet werden. Der Check Clang-Tidy lief mit allen Regelsätzen (ausser lllvmlibc-*) die zur Verfügung standen (kein Autosar). Bei der Axivion Suite war hauptsächlich der Autosar Regelsatz aktiv. An dieser Stelle geht es nicht um einen Vergleich der verschiedenen Tools, hier soll lediglich angemerkt sein, dass verschiedene Regelsätze und somit auch verschiedene Tools verschiedene Defekte finden können oder eben nicht.

Fazit

Zurück zur Eingangsfrage: «Ist ein Compiler ein statisches Codeanalyse Tool?» Kurz gesagt: Nein. Der Compiler kann zwar gewisse Fehler im Code statisch erkennen, jedoch fehlt ihm die Funktionalität zur Prüfung mittels eines Regelwerks (egal ob standardisiertes oder eigenes Regelwerk).

4. «Modern C++» und statische Codeanalyse

Typischerweise hinken die in sicherheitsrelevanten Anwendungen eingesetzten Regelwerke oft hinter den C++ Standards nach. D.h. die aktuellen C/C++ Standards wie C++17 und C++20 sind kaum durch Regelwerke wie in der untenstehenden Tabelle aufgelistet abgedeckt. Hier eine Zusammenfassung von verbreiteten Standard Coding Styleguides und der C/C++ Dialekt Unterstützung:

Tabelle 3 Coding Standards und deren unterstütze C/C++ Dialekte
Tabelle 3 Coding Standards und deren unterstütze C/C++ Dialekte

Ein Lichtblick bezüglich der Aktualität dürfte der MISRA C++:202X Coding Standard werden. Zur Zeit der Erfassung dieses Artikels befand sich dieser Standard noch in der Review Phase.

5. Statische Codeanalyse im Medizingerät-Umfeld

Für Software in der Medizinaltechnik sind im Zusammenhang mit statischer Codeanalyse die Norm IEC 62304, die MDR und die FDA zu berücksichtigen.

 

MDR

Gemäss der Medizinprodukterichtlinie MDD (93/42/EWG):

„Bei Produkten, zu deren Bestandteilen Software gehört, oder bei Produkten in Form einer Software wird die Software entsprechend dem Stand der Technik entwickelt und hergestellt, wobei die Grundsätze des Software-Lebenszyklus, des Risikomanagements einschließlich der Informationssicherheit, der Verifizierung und der Validierung zu berücksichtigen sind.“

Im Falle eines Rechtsstreits wird ein Sachverständiger wahrscheinlich bestätigen, dass die Verwendung von Coding Standards zum „Stand der Technik“ gehört.

 

FDA

Im Software Validation Guidance Dokument der FDA steht:

The software design specification should include: […] Development procedures and coding guidelines (or other programming procedures); […]  Firms frequently adopt specific coding guidelines that establish quality policies and procedures related to the software coding process. Source code should be evaluated to verify its compliance with specified coding guidelines. Such guidelines should include coding conventions regarding clarity, style, complexity management, and commenting. Code comments should provide useful and descriptive information for a module, including expected inputs and outputs, variables referenced, expected data types, and operations to be performed. Source code should also be evaluated to verify its compliance with the corresponding detailed design specification. Modules ready for integration and test should have documentation of compliance with coding guidelines and any other applicable quality policies and procedures.

Die FDA fordert somit nicht ausdrücklich, dass Coding Standards verwendet respektive eingehalten werden müssen.

 

IEC 62304

Wie die FDA fordert auch die IEC 62304 nicht explizit die Verwendung respektive Einhaltung von Coding Standards. Die Verwendung einer statischen Codeanalyse kann jedoch zur Unterstützung der Einhaltung dienen.

Im Zusammenhang mit der statischen Codeanalyse sind folgende Kapitel der ISO 62304 von Bedeutung:

 

5.1.12 Identification and avoidance of common software defects

The MANUFACTURER shall include or reference in the software development plan a procedure for:

  1. identifying categories of defects that may be introduced based on the selected programming technology that are relevant to their SOFTWARE SYSTEM; and
  2. documenting evidence that demonstrates that these defects do not contribute to unacceptable RISK.

 

5.5.2 Establish SOFTWARE UNIT VERIFICATION PROCESS

The MANUFACTURER shall establish strategies, methods and procedures for verifying the SOFTWARE UNITS. Where VERIFICATION is done by testing, the test procedures shall be EVALUATED for adequacy. [Class B, C]

 

5.5.3 SOFTWARE UNIT acceptance criteria

The MANUFACTURER shall establish acceptance criteria for SOFTWARE UNITS prior to integration into larger SOFTWARE ITEMS as appropriate, and ensure that SOFTWARE UNITS meet acceptance criteria. [Class B, C]

NOTE Examples of acceptance criteria are:

  • does the software code implement requirements including RISK CONTROL measures?
  • is the software code free from contradiction with the interface design of the software unit?
  • does the software code conform to programming procedures or coding standards.

 

5.5.4 Additional SOFTWARE UNIT acceptance criteria

When present in the design, the MANUFACTURER shall include additional acceptance criteria as appropriate for:

  1. proper event sequence;
  2. data and control flow;
  3. planned resource allocation;
  4. fault handling (error definition, isolation, and recovery);
  5. initialisation of variables;
  6. self-diagnostics;
  7. memory management and memory overflows; and
  8. boundary conditions.

[Class C]

 

Zu Kapitel 5.1.12:

Ein verbreiteter Regelsatz wie in Kapitel 3.4 beschrieben, kann zur Vermeidung von häufigen Softwarefehlern helfen und soll deshalb zwingend im Softwareentwicklungsplan erwähnt werden.

 

Zu Kapitel 5.5.2

Hier kann die statische Codeanalyse als Methode zur Verifizierung von Software Units angesehen werden.

 

Zu Kapitel 5.5.3:

In diesem Kapitel geht es hauptsächlich um den letzten Satz bezüglich Coding Standards. Dieser Satz ist jedoch lediglich als Beispiel aufgeführt.

 

Zu Kapitel 5.5.4:

Mittels geeigneten Coding Standards können unter anderem folgende aufgezählten Punkte abgedeckt werden:

  • (planned) resource allocation
  • Initialisation of variables
  • Memory management and mermory overflows
  • Boundary conditions
  • Control Flow
Fazit

In keinen der erwähnten Verordnungen, Behörden oder Normen wird eine Verwendung von Coding Guidelines explizit verlangt. Die Verwendung könnte jedoch als Stand der Technik angesehen werden, was eine Nutzung fordert. Eine Aufzählung von geeigneten Coding Guidelines wird nicht mitgeliefert.

Die Firma IMT AG stützt sich auf Regelwerke wie:

  • MISRA (Motor Industry Software Reliability Association)
  • AUTOSAR (AUTomotive Open System ARchitecture)
  • SEI CERT (Software Engineering Institut – Computer Emergency Response Team)

Zusammenfassung

Die Verwendung einer statischen Codeanalyse mit Unterstützung eines statischen Codeanalyse Tools macht für alle Softwareprojekte Sinn und sollte möglichst von Beginn weg eingesetzt werden. Ein Softwarehersteller im Medizinal Umfeld muss aus «Stand der Technik» Sicht eine Coding Guideline einsetzen. Ein statisches Codeanalyse Tool kann den Code gegen ein Regelwerk (Coding Guideline) automatisiert testen.

Das sind die Top IMT Best Practices zur statischen Codeanalyse:

  • Wenn SCA eingesetzt wird, dann auch alle Compilerwarnungen einschalten
  • Das SCA Tool möglichst früh im Projekt aufsetzen und in die CI/CD Pipeline integrieren
  • Im Medizinal Bereich (Norm ISO 62304, MDR, FDA) wird die Verwendung von Coding Guidelines verlangt, weshalb wir statische Codeanalyse Tools zum automatisierten statischen Testen (u.a. der Coding Guidelines) stark empfehlen.
    Passende Regelsätze sind:
    • MISRA (Motor Industry Software Reliability Association),
    • AUTOSAR (AUTomotive Open System ARchitecture) und
    • SEI CERT (Software Engineering Institut – Computer Emergency Response Team).

Zurück

Neuste Artikel
Kostspielige Rückrufe verhindern mit Qualitätsmanagement-systeme

Verbesserte Projektsicherheit und Kundenvertrauen durch ISO 27001-Zertifizierung

Zukunftsweisendes Engineering dank Schweizer SLS-3D-Drucker

Ununterbrochene Stromversorgung in lebenserhaltenden medizinischen Geräten

Sind Sie an weiteren Beiträgen interessiert?

Hinterlassen Sie hier Ihre E-Mail-Adresse und wir informieren Sie, sobald wir neue Beiträge veröffentlichen.

Subscribe for Email Updates

Add a descriptive message telling what your visitor is signing up for here.

Weitere Expert Blog Beiträge

Lassen Sie sich inspirieren von unseren erfolgreich realisierten Kundenprojekten im Bereich der Medizintechnik.

Lesedauer

4 Minuten

Datum

Kostspielige Rückrufe verhindern mit Qualitätsmanagement-systeme

Lesedauer

3 Minuten

Datum

Verbesserte Projektsicherheit und Kundenvertrauen durch ISO 27001-Zertifizierung

Lesedauer

4 Minuten

Datum

Zukunftsweisendes Engineering dank Schweizer SLS-3D-Drucker