Mark Hermeling

In der Software-Entwicklung haben sich zahlreiche Standards für sichere und zuverlässige Software etabliert. Auch wenn sich diese Vorgaben auf besonders heikle Bereiche wie Avionik beziehen, können sich Entwickler daraus Anregungen für bessere Produkte holen.

Die statische Analyse von Quellcode ist in den meisten Entwicklungs-Teams mittlerweile ein Standardprozess. Doch wie sieht es mit Code aus, der binär von Dritten zugeliefert wird? Hier gelangen die gängigen Test- und Analyse-Verfahren schnell an ihre Grenzen. Dennoch ist eine Analyse der Binaries wichtig - und mit dem richtigen Werkzeug auch möglich.

Code Reviews (oder Inspektionen) sind eine effektive Möglichkeit, die Zahl der der Defekte in Softwareprojekten zu reduzieren. Tatsächlich ist eine Defektentfernungsrate von bis zu 75% möglich, was nichts anderes bedeutet, als dass zwei Drittel aller Bugs während der Entwicklungsphase eines Projekts entfernt werden. Führt man sich die Kosten der Fehlerbehandlung an bereits ausgelieferten Produkten vor Augen, wird deutlich, dass Codeinspektionen fester Bestandteil einer jeden guten Entwicklungsarbeit sein sollten.

Moderne statische Analysetools sind beliebt, weil sie schwere Programmierfehler finden können. Im Gegensatz zur traditionellen dynamischen Prüfung wird der Code nie ausgeführt, also sind keine Testfälle notwendig. Das ermöglicht ihren Einsatz schon früh im Entwicklungsprozess.

Grammatechs CodeSonar ist mehr als ein ‚Defekterkennungs-Werkzeug‘. Tatsächlich erkennt und erläutert das Tool Softwaredefekte und bietet Fähigkeiten zum Verstehen von Code, was wiederum Hilfestellung bei der Untersuchung von Defekten leistet.

Die Antwort auf die Frage, wann die statische Analyse zum Einsatz kommen sollte, ist relativ einfach: „Immer dann, wenn Code entwickelt wird.“ Eigentlich müsste es aber heißen: „Als Bestandteil eines strukturierten, sicheren Entwicklungsprozesses.“

Die Verheißungen der statischen Analyse sind zweifellos überzeugend, doch die meistgestellte Frage lautet: „Wo fangen wir an?“ Weil das Thema Security allerhöchste Priorität hat, heißt es auch oft: „Wie verwundbar ist unsere Software, und wo setzen wir an, um die Schwachstellen zu beseitigen?“ Dieser Text beschreibt einen sinnvollen Ansatzpunkt und eine Vorgehensweise, wie man bestehende Schwachstellen verstehen und die statische Analyse als Bestandteil eines kontinuierlichen Verbesserungsprozesses nutzen kann.

Unabhängig davon, ob Sie auf das Credo des ‚Test Driven Development‘ setzen und das Testen an die erste Stelle setzen, gelten automatisierte Modultests doch generell als etwas, was der Softwarequalität dienlich ist.

Verkehrssysteme und insbesondere Eisenbahnsysteme sind Wachstumsmärkte, in denen Software zur Befehlsgabe, Kommunikation und Steuerung immer stärkeren Einsatz findet. Weil Fehler und Unfälle schwerwiegende Folgen nach sich ziehen, untersteht die Entwicklung dieser Software strengen Normen wie der EN 50128, die den Einsatz sicherer Praktiken, Tools und Techniken beim Programmieren sehr genau definiert.

Der IEC 62304 Standard definiert einen Risiko- und Qualitäts-bewußten Software-Entwicklungsprozess. Er entstand aus der Erkenntnis, dass Software in medizinischen Geräten eine tragende Rolle spielt, und dass die SW-Qualität und Schadensverhütung bei der SW-Entwicklung entscheidend sind. Von der Medizintechnik erwartet man, dass sie auf breiter Entwicklungspraxis basiert (unter dem Schirm eines Good Manufacturing Process). Software-Entwicklungstools und speziell statische Analysetools sind Teil einer guten Softwareentwicklungspraxis und unterstützen Medizingerätehersteller, um sichere und zuverlässige Software zu erzielen.

Im Industrial Internet of Things (IIoT) sind Geräte, die industrielle Steuerungssysteme bilden, oft wegen Einschränkungen bei Design und Kapazität nicht sicher. Das gilt auch für die eingesetzten Protokolle, so dass das blinde Vertrauen in die physische Sicherheit ziemlich gewagt ist (z.B. Anschuss von Geräten an einem lokalen Netzwerk). Abhilfe schafft die Implementierung von Sicherheit auf Systemlevel, als Teil des sicheren Softwaredesigns und –entwicklung. Hier bieten statische Analysetools Hilfestellung bei der Verbesserung der Softwaresicherheit – auch für IIoT-Geräte.

Sie haben es also geschafft, Ihren C/C++-Code in gut organisierte Kompilierungseinheiten aufzuteilen, halten Ihre Header und Implementierungen fein säuberlich getrennt und modularisiert, und Ihr Build-System ist schlank und rundum gelungen. Trotzdem müssen Sie eines Tages C++-Templates intensiv nutzen, und plötzlich ist es mit der schönen Ordnung vorbei. Bei meinem Ausflug in die Template-Programmierung fragte ich mich sehr bald: Warum kann ich meine Methodenrümpfe nicht in eine cpp-Datei packen?

Bedingt durch den Siegeszug der Mehrkern-Technologie im Verlauf der letzten zehn Jahre sehen sich immer mehr Entwickler mit der Herausforderung konfrontiert, parallele Software zu programmieren.
Multithreading ist eine der gängigsten Architekturen für die Entwicklung paralleler Software. Stabile Anwendungen mit Multithreading-Fähigkeiten zu entwickeln, ist jedoch alles andere als trivial.

Als Mitglied der Marketingabteilung eines Unternehmens, das im Bereich der Cybersicherheit forscht, bin ich häufig verblüfft, wie wenig sich normale Menschen um dieses Thema kümmern.
Natürlich kommen Unternehmen mit den Cyber-Security-Risiken zurecht – aber wie steht es mit den einzelnen Menschen?

Bedingt durch den Siegeszug der Mehrkern-Technologie im Verlauf der letzten zehn Jahre sehen sich immer mehr Entwickler mit der Herausforderung konfrontiert, parallele Software zu programmieren.
Multithreading ist eine der gängigsten Architekturen für die Entwicklung paralleler Software. Stabile Anwendungen mit Multithreading-Fähigkeiten zu entwickeln, ist jedoch alles andere als trivial.

Unabhängig davon, ob Sie auf das Credo des ‚Test Driven Development‘ setzen und das Testen an die erste Stelle setzen, gelten automatisierte Modultests doch generell als etwas, was der Softwarequalität dienlich ist.

Verkehrssysteme und insbesondere Eisenbahnsysteme sind Wachstumsmärkte, in denen Software zur Befehlsgabe, Kommunikation und Steuerung immer stärkeren Einsatz findet. Weil Fehler und Unfälle schwerwiegende Folgen nach sich ziehen, untersteht die Entwicklung dieser Software strengen Normen wie der EN 50128, die den Einsatz sicherer Praktiken, Tools und Techniken beim Programmieren sehr genau definiert.

Die Antwort auf die Frage, wann die statische Analyse zum Einsatz kommen sollte, ist relativ einfach: „Immer dann, wenn Code entwickelt wird.“ Eigentlich müsste es aber heißen: „Als Bestandteil eines strukturierten, sicheren Entwicklungsprozesses.“

Sie haben es also geschafft, Ihren C/C++-Code in gut organisierte Kompilierungseinheiten aufzuteilen, halten Ihre Header und Implementierungen fein säuberlich getrennt und modularisiert, und Ihr Build-System ist schlank und rundum gelungen. Trotzdem müssen Sie eines Tages C++-Templates intensiv nutzen, und plötzlich ist es mit der schönen Ordnung vorbei. Bei meinem Ausflug in die Template-Programmierung fragte ich mich sehr bald: Warum kann ich meine Methodenrümpfe nicht in eine cpp-Datei packen?

Code Reviews (oder Inspektionen) sind eine effektive Möglichkeit, die Zahl der der Defekte in Softwareprojekten zu reduzieren. Tatsächlich ist eine Defektentfernungsrate von bis zu 75% möglich, was nichts anderes bedeutet, als dass zwei Drittel aller Bugs während der Entwicklungsphase eines Projekts entfernt werden. Führt man sich die Kosten der Fehlerbehandlung an bereits ausgelieferten Produkten vor Augen, wird deutlich, dass Codeinspektionen fester Bestandteil einer jeden guten Entwicklungsarbeit sein sollten.