Entdecken Sie das TÜV-zertifizierte GoogleTest mit Agentic AI für C/C++-Tests!
Details ansehen »
Zum Abschnitt springen
Parasoft-Blog
Die Entwicklung sicherheitskritischer Software ist mit hohen Kosten verbunden. Dies kann jedoch durch Automatisierung und Shift-Left-Tests von Software reduziert werden, um die Fehlerquote zu senken. Lesen Sie weiter, um mehr zu erfahren.
Zum Abschnitt springen
Wir befinden uns in einer Kostenkrise bei sicherheitskritischer Software. Der gestiegene Funktionsumfang übersteigt mittlerweile die finanziellen Möglichkeiten für die Entwicklung. Das Boeing-787-Programm beispielsweise benötigte 6.5 Millionen Codezeilen, deren Entwicklung und Tests 4 Milliarden US-Dollar kosteten. Die Kosten für Boeings 777X -Programm wurden nicht veröffentlicht, und die Kosten für Boeings 737 MAX wurden ursprünglich auf 3.6 Milliarden US-Dollar geschätzt, stiegen aber auf 6.3 Milliarden US-Dollar – ohne die Milliardenkosten für Fehlschläge.
Der Trend bei großen sicherheitskritischen Projekten zeigt ein exponentielles Wachstum der Gesamtkosten, wobei Software von Jahr zu Jahr einen größeren Anteil des gesamten Entwicklungsbudgets ausmacht. Das nächste große Luft- und Raumfahrtprogramm wird wahrscheinlich unerschwinglich sein, wenn man dieselben Techniken verwendet, die in früheren Programmen verwendet wurden. Also was können wir tun?
Die Sicherheitszertifizierung sowie die erforderlichen Tests und Verifizierungen beanspruchen einen Großteil des Softwareentwicklungsbudgets. Das Vorverlegen von Tests in frühere Phasen des Softwareentwicklungszyklus (SDLC) – also Tests, die frühzeitig im Testprozess stattfinden – und der Einsatz von Automatisierung zahlen sich hinsichtlich Kosten, Risiko und Zeitaufwand deutlich aus. Die folgende Abbildung zeigt die Kosten in Millionen US-Dollar pro tausend Codezeilen für die Softwareentwicklung in der kommerziellen Luftfahrt und verdeutlicht den exponentiellen Kostenanstieg.
Abbildung 1: Kosten der Softwareentwicklung pro Codezeile in kommerziellen Luftfahrtprojekten. Die Daten wurden den Projektmetriken von Airbus und Boeing entnommen.
Es überrascht nicht, dass die meisten Fehler in einem Projekt zu Beginn entstehen , noch bevor die erste Codezeile geschrieben ist. Die meisten Bugs werden während der Testphase gefunden und behoben. Ein beträchtlicher Anteil, bis zu 20 %, wird jedoch erst im laufenden Betrieb entdeckt, nachdem das Produkt bereits verkauft und ausgeliefert wurde.
In zertifizierten Systemen bedeutet dies entweder einen extrem teuren Fix-Test-Rezertifizierungszyklus oder Betreiber-Workarounds für das Problem. Die nächste Grafik zeigt den relativen Prozentsatz der eingeführten und erkannten Fehler in jeder Phase des Softwareentwicklungslebenszyklus.
Abbildung 2: Diagramm, das den Prozentsatz der in verschiedenen Entwicklungsphasen eingeführten und erkannten Fehler zeigt. Quelle: Applied Software Measurement: Global Analysis of Productivity and Quality, Capers Jones, 2008.
Mängel lassen sich am günstigsten zu Beginn des Lebenszyklus beheben. Im Laufe der Projektdauer wird es exponentiell teurer, sie zu finden und zu reparieren. Im Betrieb ist die Reparatur eines Produkts am teuersten, nachdem es in die Hände des Kunden gelangt ist. Die Kosten für die Fehlerbehebung nach der Bereitstellung sind konservativ und beinhalten keine Schäden an Ihrer Marke und keine Haftung durch Sicherheitsvorfälle vor Ort.
Die folgende Grafik zeigt die relativen Kosten für die Behebung eines Defekts in jeder Phase des Lebenszyklus. Das Ziel besteht eindeutig darin, die erkannten und behobenen Mängel zu einem früheren Zeitpunkt im Lebenszyklus zu verschieben. Mit anderen Worten, nach links verschieben. Darüber hinaus ist es wünschenswert, die Anzahl der Mängel, die zum Kunden gelangen, zu reduzieren, was in jedem Bereich Realität ist.
Abbildung 3: Relative Kosten für die Suche und Behebung von Fehlern in jeder Entwicklungsphase. Bei Anforderungen und Design handelt es sich um die Basislinie (1x) und den kostengünstigsten Ort zur Behebung von Fehlern. Quelle für Abbildungen 2 und 3: SAVI-Präsentation auf der INCOSE SE-Konferenz 2012.
Die sicherheitskritische Softwareindustrie erkennt die Notwendigkeit an, die Art und Weise zu ändern, wie Dinge getan werden. Zu viele Projekte erfinden das Rad neu und die Zertifizierung brandneuer Software ist zeitaufwändig und teuer. Das Wachstum der Konnektivität und Funktionalität neuer Produkte bedeutet, dass sich die Methoden ändern müssen. In diesem Beitrag werden wir nicht alle vorgeschlagenen Techniken behandeln, sondern uns auf die Rolle konzentrieren, die die Testautomatisierung bei der Verlagerung, Erkennung und Behebung von Fehlern und Sicherheitslücken nach links spielt.
Ein wesentlicher Bestandteil jedes sicherheitskritischen Projekts ist das Testen. Automatisierung ist unerlässlich, um die Ziele in Bezug auf Sicherheit und Qualität zu erreichen. Im Folgenden finden Sie Beispiele dafür, wie Testautomatisierungstools moderne Softwareentwicklungsmethoden unterstützen und die Produktivität beim Testen und der Dokumentation steigern.
Die Probleme mit der Wasserfallmethode sind bekannt und viele Teams nutzen modernere Entwicklungsmethoden, um Qualität und Sicherheit zu verbessern. Die Testautomatisierung ist ein wichtiger Bestandteil jeder iterativen Entwicklungsmethode, da Testsuiten bei jeder neuen Iteration eines Moduls, einer Komponente usw. ausgeführt werden.
Die Testautomatisierung unterstützt diese Methoden durch wiederholbare automatisierte Tests und liefert Berichte auf verschiedenen Ebenen für jeden einzelnen Test sowie kumulative Ergebnisse im Zeitverlauf. Diese Tools sind zudem für die Zusammenarbeit mit CI-Prozessen konzipiert und integrieren sich in die Aufgabenverfolgung, das Anforderungsmanagement, Build-Systeme und Quellcodeverwaltungssysteme. Dynamische Analysetools sind unerlässlich, um schwer erkennbare Laufzeitfehler aufzudecken. Die statische Analyse spielt eine wichtige Rolle bei der Fehlererkennung vor Testbeginn.
Eine der besten Methoden zur Beseitigung von Fehlern zu Beginn des Entwicklungslebenszyklus sind Inspektionen. Inspektionen bedeuten, alles zu überprüfen, nicht nur den Quellcode. Beispielsweise ist die Überprüfung der Anforderungen und des Designs von entscheidender Bedeutung, um die Hauptfehlerquelle im System zu verhindern. Siehe Abbildung 2. Viele Fehler sind buchstäblich in das System eingebaut. Tools spielen in dieser Phase eine untergeordnete Rolle, erhöhen jedoch die Effektivität von Codeüberprüfungen.
Automatisierte Unit-Tests, dynamische Fehlererkennung und statische Analyse sorgen für eine deutlich verbesserte Fehlererkennung in den frühen Codierungsphasen eines Projekts. Die Ergebnisse automatisierter Tests können in Codeüberprüfungen präsentiert werden, wodurch die Abhängigkeit von der manuellen Fehlererkennung verringert wird und mehr Zeit für die Erkennung falscher Anforderungen und Designentscheidungen bleibt.
Manuelle Tests sind mühsam und schwer reproduzierbar. Die Ergebniserfassung kann willkürlich erfolgen, und trotz scheinbar korrekter Ergebnisse kann ein Fehler übersehen werden. Die Erreichung der erforderlichen Codeabdeckung , die je nach Sicherheitsstandards und Kritikalität des Projekts variiert, ist schwer nachzuverfolgen.
Die Testautomatisierung macht das Testen nicht nur viel weniger mühsam und wiederholbar, sondern die Berichtsfunktionen fortschrittlicher Testtools liefern auch wichtige Managementinformationen über den Status des Projekts. Durch das Hinzufügen einer dynamischen Analyse, die den Code während der Ausführung analysiert, um knifflige Laufzeitfehler zu erkennen, und einer statischen Analyse, die den Code vor seiner Ausführung analysiert, wird die Fehlererkennungsfähigkeit von Testtools erheblich erhöht.
Viele sicherheitskritische Projekte erfordern Quellcode-Standards. MISRA beispielsweise ist in der Automobilsoftware weit verbreitet, hat sich aber auch in anderen Branchen durchgesetzt. Einige Standards erfordern, dass der Code einem Unternehmensstandard entspricht, der bestimmte Ziele erfüllt. In jedem Fall ist die manuelle Durchsetzung der Codierungskonformität mühsam und fehleranfällig. Statische Analysetools sind ideal für die Durchsetzung von Compliance und erweiterte Tools gehen noch einen Schritt weiter, indem sie Fehler erkennen, die über Formatverstöße hinausgehen.
Ein großer Teil des Arbeitsaufwands beim Erreichen von Software-Sicherheitszertifizierungen besteht in der Dokumentation von Prozessen, der Validierung und Verifizierung. Durch die Testautomatisierung werden die Kosten für die Dokumentation der Testergebnisse und die Abdeckungsanalyse erheblich gesenkt.
Eine Schlüsselstrategie zur Produktivitätssteigerung ist die Wiederverwendung von Software. Idealerweise lassen sich bereits zertifizierte Komponenten nutzen, um die Entwicklungskosten für diese Untereinheiten zu senken. Die automatisierte Bewertung bestehender Software mithilfe statischer und dynamischer Analysetools verringert das Risiko bei der Verwendung dieser Komponenten.
Selbst strenge Testverfahren können kritische Fehler übersehen. Die Codeabdeckung allein reicht nicht aus, um beispielsweise bei Sicherheitsangriffen oder Multithread-Code ein ordnungsgemäßes Verhalten sicherzustellen. Statische Analysetools können Fehler im Quellcode erkennen, ohne einen spezifischen Test durchzuführen, und können Fehler wie Sicherheitslücken finden, die bei Unit- oder Systemtests schwer zu entdecken sind.
Dynamische Analysetools können Fehler beim Ausführen von Code während Tests erkennen, die sich möglicherweise in Testergebnissen widerspiegeln, z. B. ein langsamer Speicherverlust. Durch Fuzzing und Penetrationstests während des Systemtests können Fehler gefunden werden, die unter normalen Betriebsbedingungen übersehen wurden. Insgesamt tragen die zusätzlichen Fehler und Sicherheitslücken, die moderne Tools finden, dazu bei, Kosten, Risiken und viele der etwa 20 % Fehler, die in die Produktion gelangen, zu reduzieren.
Es ist klar, dass etwas getan werden muss, um die in Abbildung 2 deutlich dargestellten Probleme zu lösen. Zu viele Fehler werden eingeführt und bleiben zu Beginn des Lebenszyklus unentdeckt. Und zu viele verbleiben im Produkt, wenn es hergestellt wird und in den Händen der Kunden bzw. in Flugzeugen oder Autos. Die Einführung moderner Entwicklungsmethoden, die Wiederverwendung von Komponenten, die Nutzung von COTS und Open Source sowie die Automatisierung von Werkzeugen sind wichtige Schritte zur Verbesserung der Entwicklungsproduktivität.
Geht man von einem Entwicklungsprozess mit modernsten Tools aus, bei dem das Testen nach links verlagert wird und mehr Fehler früher im Lebenszyklus erkannt und behoben werden, sind Unit-Tests äußerst effektiv und tragen dazu bei, dass weniger Fehler in die Produktion gelangen. In Abbildung 4 zeigt ein hypothetisches Beispiel die Veränderung der Fehlererkennung im Laufe des Lebenszyklus, wobei der Großteil der Fehlererkennung und -behebung früher im Lebenszyklus nach links verschoben wird.
Abbildung 4: Ein Diagramm, das einen hypothetischen, verbesserten Entwicklungsprozess zeigt, der die Erkennung von Fehlern und Sicherheitslücken zu einem früheren Zeitpunkt im Lebenszyklus verlagert.
Aus Abbildung 3 oben wissen wir, dass die Kosten in jeder Entwicklungsphase erheblich steigen. Abbildung 5 unten zeigt den Vergleich der Kosten für die Behebung von Fehlern bei der herkömmlichen Methode mit der modernen Methode in Abbildung 4. Wenn die Suche und Behebung von Fehlern nach links verlagert wird, sind die Kosten geringer als bei der späteren Behebung. In der hier dargestellten Situation beträgt der Gesamtkostenunterschied etwa 40 % zugunsten des Shift-Left-Ansatzes.
Abbildung 5: Eine Grafik, die die relativen Kosten für die Behebung von Fehlern beim herkömmlichen Ansatz im Vergleich zum Shift-Left-Ansatz zeigt. Auch bei gleicher Gesamtfehlerzahl werden durch die Früherkennung die Kosten deutlich gesenkt.
Der Einsatz automatisierter Werkzeuge in sicherheitskritischen Projekten erfordert Vertrauen in die Werkzeuge selbst. Es liegt in der Verantwortung des Produktherstellers, sicherzustellen, dass die zur Softwareentwicklung verwendeten Prozesse und Werkzeuge den Normen entsprechen. Werkzeuganbieter können hierbei unterstützen, indem sie ihre Werkzeuge vor dem Verkauf an die Hersteller von Normungsorganisationen zertifizieren lassen oder, falls eine solche Vorzertifizierung nicht möglich ist, Qualifizierungsunterstützung anbieten. Die Hersteller können die Zertifizierungsnachweise des Werkzeuganbieters dann für ihren eigenen Zertifizierungsantrag nutzen und so ihren Aufwand reduzieren. Beispielsweise wurde Parasoft C/C++test vom TÜV SÜD für die Entwicklung sicherheitsrelevanter Software gemäß den Normen IEC 61508 und ISO 26262 zertifiziert.
In einigen Softwaresicherheitsstandards wie DO-178C erfolgt die Zertifizierung auf Systemebene und einzelne Tools und Software werden nicht unabhängig voneinander zertifiziert. In diesen Fällen stellt der Anbieter des Tools Qualifizierungskits und Unterstützung in Form von Dokumentation und professionellen Dienstleistungen zur Verfügung, wodurch die Kosten und der Aufwand für die Qualifizierung der Tools für den Einsatz im Projekt erheblich reduziert werden.
Sicherlich steckt sicherheitskritische Software in einer Kostenkrise. Die Entwicklung neuer, großer sicherheitskritischer Projekte wird zu teuer, sodass sie möglicherweise nicht mehr rentabel sind. Zur Entwicklung sicherheitskritischer Software sind moderne Methoden erforderlich, und dieser Aufwand muss die Anzahl der Fehler reduzieren, die spät im Softwareentwicklungslebenszyklus gefunden werden. Ganz nach links reduziert die Erkennung und Behebung von Mängeln und Sicherheitslücken so früh wie möglich im Lebenszyklus die Kosten erheblich. Die Testautomatisierung spielt eine Schlüsselrolle bei der Verbesserung der Testeffizienz und -ergebnisse. Es ist ein wichtiger Teil des modernen Ansatzes für die Entwicklung sicherheitskritischer Software.
„MISRA“, „MISRA C“ und das Dreieckslogo sind eingetragene Marken von The MISRA Consortium Limited. ©The MISRA Consortium Limited, 2021. Alle Rechte vorbehalten.
Weiterführende Inhalte
