Statische Analyse
Sicherheitskritische Software bezahlbar
Software wird in immer stärkerem Maße für sicherheitskritische Aufgaben eingesetzt. Während die Entwicklungskosten pro Codezeile gleich bleiben, steigt der Umfang des Codes exponentiell an. Mit geeigneten Entwicklungswerkzeugen lässt sich das Dilemma aber lösen.
Wachsende Komplexität und die zunehmende Abhängigkeit von Software bei der Ausführung einsatzkritischer Funktionen hat dazu geführt, dass man bei der Entwicklung sicherheitskritischer Software an eine Grenze in puncto Bezahlbarkeit gestoßen ist [1]. Die Produktivität der Software-Entwickler bei sicherheitskritischen Systemen hat sich mit fünf Programmzeilen (Lines of Code; LOC) pro Tag bzw. rund 1000 LOC pro Jahr kaum verändert [2]. In die Höhe geschossen ist dagegen der Codeumfang sicherheitskritischer Software infolge der zunehmenden Abhängigkeit von eben dieser Software. Die Bezahlbarkeit von Software ist ein echtes Problem, und nicht nur verschiedene Standards, sondern auch Experten im Bereich der sicherheitskritischen Software empfehlen die Verwendung von Statische-Analyse-Tools, um diesem Problem beizukommen.
Die Software hat sich zum dominierenden Kostenfaktor sicherheitskritischer Systeme entwickelt. Tatsächlich entfällt heute ein Drittel der Kosten eines neuen Flugzeugs auf die Software und ihre Entwicklung. Bei den Automobilen gehen 25 % der Kapitalaufwendungen für neue Fahrzeuge auf das Konto der Elektronik und der Software. Zweifellos sind durch Software beeindruckende neue Möglichkeiten entstanden. Ihr exponentielles Wachstum und die damit zusammenhängenden Kosten aber haben dafür gesorgt, dass sie effektiv unbezahlbar geworden ist (Bild 1).
Klar ist, dass es mit den wachsenden Entwicklungskosten für größere Systeme nicht so weitergehen kann. Verschiedene Vorgehensweisen und Techniken wurden als Abhilfe vorgeschlagen. Dazu gehört die Verwendung von Tools – insbesondere von Statische-Analyse-Tools – mit dem Ziel, die Testabdeckung zu verbessern und Defekte aufzudecken, die von traditionellen Tests nicht erfasst werden. Das Software Engineering Institute SEI [4] und die NASA [5] empfehlen die statische Analyse als Hilfsmittel bei der Entwicklung sicherheitskritischer Software.
Exponentielle Kosten durch Fehler
Die Kosten, die entstehen, wenn Software-Fehler erst in bereits produzierten und ausgelieferten Produkten entdeckt werden, sind ebenfalls immens hoch. Rückrufaktionen, Haftungsprobleme und Imageschäden gehören zu den möglichen Konsequenzen. Nehmen wir Toyota als Beispiel: Die vom Drive-by-Wire-System des Unternehmens ausgelöste, ungewollte Beschleunigung verursachte Kosten von bis zu 5 Mrd. US-Dollar an Entschädigungen und Einnahmeverlusten [5] – zweifellos ein herber Verlust und eine wichtige Lektion in Sachen Software-Sicherheit. Auch wenn dieses Beispiel extrem erscheinen mag, wird doch deutlich, dass ein ernster Software-Fehler nahezu grenzenlose finanzielle Folgen haben kann. Studien haben ergeben, dass die Beseitigung von Software-Fehlern während der Produktion 100-mal mehr kostet als in den frühen Phasen der Entwicklung.
Wie von Capers Jones beschrieben [6], ist es irreführend, allein auf die Kosten pro Fehler zu blicken, denn hierbei bleibt die Menge der Defekte ebenso unberücksichtigt wie die Tatsache, dass die Kosten zum Finden und Beheben eines Defekts über die Zeit häufig gleichbleibt – worauf Entwickler gern verweisen. Bei den sicherheitskritischen Embedded-Systemen sind die Reparaturkosten allerdings höher als in anderen Branchen. Wird ein sicherheitskritischer Defekt nicht rechtzeitig behoben – oder schlimmstenfalls sogar absichtlich verborgen – so können die finanziellen Folgen durch gesetzliche Haftung zunehmen und Auswirkungen auf künftige Einnahmen haben.
Anhand des in Bild 2 dargestellten V-Modells lässt sich der typische Software-Entwicklungs-Lebenszyklus und die relativen Vorteile der statischen Analyse in den einzelnen Entwicklungsphasen deutlich machen. Das V-Modell, das man in vielen Zertifizierungs-Standards für sicherheitskritische Software (z.B. ISO 61508 und 26262) findet, ist hier ein gutes Beispiel.
Betrachtet man auf traditionelle Weise die Kosten pro Defekt über die Zeit oder in verschiedenen Phasen, so ist dies laut Jones zwar mathematisch korrekt, geht aber an der Praxis vorbei. Aussagefähiger sind stattdessen die Kosten pro Defekt bezogen auf das relative Volumen an Defekten. Letzteres verringert sich mit der Zeit und von einer Entwicklungsphase zur anderen, wie nachfolgend deutlich wird.
Das Interessante an Bild 3 (beachten Sie die Reihenfolge der Entwicklungsphasen) ist, dass zwar die Kosten pro Defekt von einer Phase zur nächsten erwartungsgemäß zunehmen, dass die Gesamtkosten jedoch zurückgehen, weil die Zahl der Fehler insgesamt geringer wird. In der Praxis nimmt der Zeitaufwand zum Aufdecken und Beseitigen der Fehler nicht zu, aber die Kosten bleiben trotz der geringeren Fehlerhäufigkeit bestehen. Hervorzuheben ist ferner, dass bei einem Produkt, das bereits in Betrieb gegangen ist und gewartet wird (in der Grafik nicht berücksichtigt), die Kosten pro Defekt erheblich höher ausfallen, was sich aus dem Aufwand für die Wartung eines bereits in Kundenhand befindlichen Produkts erklärt. Zu berücksichtigen bleiben darüber hinaus weitere, nicht greifbare Kosten wie der Imageschaden und der Verlust künftiger Kunden und Einnahmen.
- Sicherheitskritische Software bezahlbar
- Normen fürs Funktionale
- Statische Analyse zahlt sich aus
Das könnte Sie auch interessieren
Mikrocontroller-Software aus einem Guss
Mit wenig Aufwand viel bewegen
Industrielles Cloud Computing
Bosch baut eigene IoT-Cloud
