Tool-Chain-Qualifikation Zertifizierungsbereit

Die Tool-Chain muss auch für die Zertifizierung 
eng verknüpft sein.
Die Tool-Chain muss auch für die Zertifizierung eng verknüpft sein.

Entwickler, die eine Zertifizierung ihrer Software im sicherheitskritischen Bereich anstreben, müssen häufig auch die korrekte Funktion der genutzten Werkzeuge nachweisen. Manuell ist die Qualifizierung aus kaum möglich. Doch es gibt Hilfestellungen, die den Prozess erheblich vereinfachen.

Dass eine Anwendung vor der Auslieferung auf Herz und Nieren getestet wird, ist zumindest im Embedded-Umfeld selbstverständlich. Statische und dynamische Verfahren sollen sicherstellen, dass das Produkt unter allen Umständen seine Aufgaben erfüllt. Etwas anders sieht es bei den Tools aus, die innerhalb des Software-Development-Lifecycles (SDLC) zum Einsatz kommen. Hier basiert das Vertrauen der Entwickler oft darauf, dass ein bestimmtes Tool in der Vergangenheit zuverlässig funktioniert hat. Mit diesem Ansatz werden die Entwicklerteams jedoch der jüngsten Entwicklung nicht gerecht: Software, vor allem für Embedded-Systeme, wird zunehmend kritisch. Für Geschäftsmodelle, ganze Unternehmen und nicht zuletzt auch für das Leben der Menschen.

»In Märkten, in denen Leben und Gesundheit auf dem Spiel stehen, ist es deswegen vorgeschrieben, dass Software vor dem Markteintritt zertifiziert wird«, betont Mark Hermeling, Senior Director Product Marketing von GrammaTech. »In der Medizintechnik, im Transportwesen oder in der Luftfahrt regeln entsprechende Normen, wie diese Zertifizierung zu erlangen ist und welche Stellen ein gültiges Zertifikat ausstellen dürfen. IEC 61508, ISO 26262 oder EN 50128 geben die Richtlinien vor.« Wie dieser Rahmen konkret ausgestaltet werden muss, ergibt sich aus den Gefahren, die von einem nichtfunktionierenden Produkt ausgehen.

Allerdings stellt der Nachweis, dass die Entwicklungswerkzeuge korrekt arbeiten, bislang nur selten einen Aspekt der Zertifizierung dar. Es ist aber damit zu rechnen, dass formale Validierungen in Zukunft häufiger gefordert werden. So verlangt die für die Luftfahrt geltende Norm DO-178C/ED-12C schon seit vielen Jahren eine durchgängige Qualifizierung der Entwicklungswerkzeuge. »DO-178C/ED-12C unterteilt dafür die möglichen Folgen einer Fehlfunktion der Software in unterschiedliche Kategorien. Je gravierender die Auswirkungen sein können, desto strengere Vorgaben gelten auch bei der Tool-Qualifizierung«, erläutert Mark Hermeling. »Damit nimmt die Luftfahrtnorm eine Vorreiterrolle ein – verständlich, denn ein Flugzeugabsturz kann sehr viele Menschenleben kosten.« Doch heute sind auch andere Anwendungsbereiche so kritisch, dass zahlreiche Menschenleben gefährdet sein können – sei es in der Medizintechnik, in der Automobilbranche oder bei der Energieversorgung.

Der Grundsatz dieser strengen Vorgaben ist, dass Tools, die Prozesse bei der Entwicklung und Verifizierung von Software ganz oder teilweise automatisieren, nachweisen müssen, dass sie mindestens ebenso zuverlässig sind wie der bestehende Prozess. Wie das zu geschehen hat, wurde mit jeder neuen Version von DO-178 weiter präzisiert. Auch die amerikanische Gesundheitsbehörde FDA bietet bereits seit einiger Zeit genaue Richtlinien an, wie die eingesetzten Werkzeuge im Rahmen einer Software-Zertifizierung qualifiziert werden können. Dabei gilt der Grundsatz, dass alle Maßnahmen und Ergebnisse reproduzierbar und revisionssicher dokumentiert sind.

»Das grundlegende Problem dabei ist jedoch, dass die Qualifizierung einer Tool-Chain sehr aufwändig ist«, erklärt Mark Hermeling. »Mit einigen wenigen Tests ist es nicht getan, denn es kommt immer auf die aktuelle Implementierung der Tool-Chain an.«

Im Embedded-Bereich zum Beispiel wird die Zuverlässigkeit von Entwicklungs-Tools in der Regel über Simulatoren oder Emulatoren auf einem Host getestet, da der Test auf einem echten Target extrem aufwändig und zeitraubend sein kann. Auch kommen beim Test der Tools immer wieder andere Optionen zum Einsatz als im echten Projekt. »Damit wird das zu validierende Werkzeug nicht in der gleichen Implementierung getestet, das Ergebnis ist also nur bedingt aussagekräftig«, betont Mark Hermeling. »Der erzeugte Code oder die Ergebnisse einer statischen Analyse können in einer anderen Implementierung unter Umständen anders aussehen.« Zudem hat in vielen Fällen die gesamte Tool-Chain Einfluss auf den erzeugten Code. Vor allem kleinere Entwicklerteams dürften kaum die Ressourcen haben, um die Tools in jeder Implementierung ausgiebig und nachweisbar zu testen.

Die meisten Tool-Anbieter haben das Problem erkannt und stellen Lösungen bereit, um den Qualifizierungsaufwand so gering wie möglich zu halten. Dazu bieten Unternehmen wie GrammaTech sogenannte Qualifizierungs-Kits an. Im Gegensatz zu einem Zertifikat ist das Qualification-Kit selbst kein Nachweis der sicheren Funktionen. Es unterstützt das Entwicklerteam in erster Linie dabei, den individuellen Einsatz eines Tools nachvollziehbar zu beschreiben und die Qualifizierungsmaßnahmen zu dokumentieren. Im Idealfall umfassen Qualifizierungs-Kits neben zahlreichen relevanten Informationen zur Qualifizierung Testmethoden, die für das jeweilige Tool bewährt und einfach zu implementieren sind. Ebenso gehören die notwendigen Best-Practice-Prozesse und Richtlinien zum Kit, um das korrekte Funktionieren des Tools gegenüber den Zertifizierungsstellen nachzuweisen.

Noch einfacher geht das, wenn ein Werkzeug selbst zertifiziert ist. Das ist zum Beispiel beim Tool für statische Analyse „CodeSonar“ von GrammaTech der Fall. Der Hersteller hat sein Produkt nach der Norm IEC 61508 vom TÜV Süd zertifizieren lassen. Gerade bei Tools ist eine Zertifizierung nach der grundlegenden Sicherheitsnorm für kritische Systeme sinnvoll; fast alle anderen Rahmenwerke sind mehr oder weniger Ableitungen dieses Standards. Dadurch vereinfacht sich der Qualifizierungsprozess deutlich.

Mit der zunehmenden Komplexität der Anwendungen steigt auch der Aufwand für die Qualitätssicherung. »Ohne robuste Tools, die diese Prozesse weitgehend automatisieren, ist eine wirtschaftliche Software-Entwicklung kaum möglich«, betont Mark Hermeling. »Doch jedes Tool kann auch eine potenzielle Fehlerquelle sein.« Noch ist die Tool-Chain-Qualification in den meisten Fällen optional. Für sichere Software in kritischen Bereichen sollte dieser Ansatz jedoch unabhängig von Normen und Standards genutzt werden. Denn letztlich sind die Entwickler dafür verantwortlich, wenn die eingesetzten Tools in einer bestimmten Implementierung Fehler produzieren – aber der Kunde ist der Leidtragende. »Vorgaben wie DO-178C/ED-12C sind sicher in vielen Bereichen übertrieben. Aber es ist sinnvoll, einzelne Gedanken daraus zu übernehmen und im SDLC zu verankern«, resümiert Mark Hermeling. »Denn in einer digitalen Welt sollte kein Platz für fehlerhafte Software sein.«