Software-Safety-Case für militärische Systeme nach MIL-STD-882

Ein System, das ohne Software-Safety-Case betrieben wird, arbeitet auf Vertrauen — Vertrauen darauf, dass die Gefährdungsanalyse vollständig war, dass die Designkontrollen korrekt sind und dass die Verifikationsnachweise ausreichen. Bei einem kommerziellen Produkt ist dieses Vertrauen vertretbar. Bei einem militärischen System, dessen Ausfallmodi energetische Freisetzungen, Plattformverlust oder Eigenbeschuss umfassen, nicht. MIL-STD-882E, die DoD-Norm für System Safety, liefert den strukturierten Prozess, mit dem dieses Vertrauen durch dokumentierte, geprüfte und akzeptierte Nachweise ersetzt wird. Der Software-Safety-Case ist das Artefakt, das diese Nachweise festhält und das Argument führt, dass das Restrisiko akzeptabel ist.

Dieser Artikel ist ein Praxisleitfaden zum Aufbau eines Software-Safety-Case nach MIL-STD-882E. Er behandelt die Aufgabenstruktur der Norm und ihre softwarebezogenen Bestimmungen, die Gefährdungsanalysekette von der vorläufigen Identifikation bis zur Software Hazard Analysis (SwHA), die Ableitung von Software Safety Requirements (SSRs) aus Gefährdungsursachen, die Designkontrollen, die diese Anforderungen umsetzen, die Verifikationsnachweise, die ihre korrekte Implementierung belegen, und den Risikoakzeptanzprozess, der den Fall abschließt. Ingenieure, die neu in Verteidigungssicherheitsprogrammen sind, finden hier eine Landkarte des Geländes; erfahrene Praktiker finden eine Referenz für die spezifischen Ergebnisse und die Rückverfolgbarkeit, die staatliche Prüfer erwarten.

MIL-STD-882E-Überblick: Systemsicherheit vom Konzept bis zur Entsorgung

MIL-STD-882E definiert Systemsicherheit als einen geplanten, disziplinierten Ansatz zur Identifikation und Verwaltung von Gefährdungen über den gesamten Lebenszyklus eines Systems — von der Konzeptexploration bis zur Entsorgung. Die Norm gliedert ihre Anforderungen in Aufgaben, die in fünf Kategorien gruppiert sind: Program Management and Control, Design Requirements, Supportability, Training und Assessments. Die beschaffende Stelle wählt Aufgaben passend zum Risikoprofil des Programms und legt sie im Statement of Work fest. Der Auftragnehmer führt diese Aufgaben aus und liefert die Ergebnisse als Contract Data Requirements List-Positionen.

Bei softwareintensiven militärischen Systemen dominieren fünf Aufgaben den Engineering-Aufwand:

• Task 205 — Software Safety Requirements Analysis: Identifikation aller sicherheitskritischen Softwarefunktionen und Ableitung von Software Safety Requirements zur Kontrolle identifizierter Gefährdungsursachen.
• Task 206 — Software Safety Design Analysis: Analyse des Softwareentwurfs, um zu prüfen, dass Sicherheitsanforderungen korrekt zugeordnet sind und dass keine neuen Gefährdungsursachen durch Designentscheidungen eingeführt werden.
• Task 301 — Safety Assessment: eine meilensteingesteuerte Bewertung, ob das Restrisiko akzeptabel ist, dokumentiert in einem Safety Assessment Report (SAR).
• Task 302 — Test and Evaluation Safety: Sicherstellen, dass Sicherheitskontrollen vorhanden sind, bevor eine Testaktivität mit gefährlicher Energie oder Betriebsmodi beginnt.
• Task 303 — System Safety Program Reviews: formelle Prüfungen, bei denen die System Safety Working Group (SSWG) dem Programmbüro Gefährdungsstatus, offene Risikopunkte und Nachweise der Kontrollwirksamkeit vorstellt.

Die Risikomatrix im Zentrum von MIL-STD-882E trägt Severity gegen Probability auf. Severity reicht von Catastrophic (Kategorie I: Tod, Systemverlust, schwere Umweltschäden) über Critical (Kategorie II: schwere Verletzung, größerer Systemschaden) und Marginal (Kategorie III: leichte Verletzung, geringer Systemschaden) bis Negligible (Kategorie IV: weniger als leichte Verletzung oder Schaden). Probability reicht von Frequent (wahrscheinlich häufig über die Lebensdauer des Systems) über Probable, Occasional und Remote bis Improbable. Jede Zelle der resultierenden 4×5-Matrix trägt einen Hazard Risk Index (HRI), der bestimmt, wer das Restrisiko nach Anwendung der Kontrollen akzeptieren muss.

Der HRI ist kein mathematisches Produkt — er ist eine ordinale Rangfolge, die durch die Risikomatrix des Programms definiert ist, die der SSPP festlegt. Eine Catastrophic/Frequent-Gefährdung (HRI 1) erfordert Akzeptanz durch die Milestone Decision Authority; eine Negligible/Improbable-Gefährdung (HRI 20) ist auf Arbeitgruppenebene akzeptabel. Die praktische Konsequenz für Softwareingenieure ist, dass die Analyseprodukte, die sie erzeugen — Gefährdungsarbeitsblätter, SwHA-Zeilen, SSRs, Verifikationsprotokolle — direkt in einen Risikomanagementprozess mit definierten Autoritätsebenen einfließen. Lücken in der Analyse lassen Risiken auf einem unbestimmten Niveau, das keine Autorität akzeptieren kann.

Vorläufige Gefährdungsanalyse: sicherheitskritische Softwarefunktionen finden

Die Preliminary Hazard Analysis (PHA) wird früh in der Systementwicklung durchgeführt, typischerweise bevor detaillierte Anforderungen finalisiert sind, auf Basis der funktionalen Zerlegung des Systems und der Dokumentation des Betriebskonzepts. Ihr Zweck ist die Identifikation von Gefährdungen auf Systemebene, die Zuordnung erster Schwere- und Wahrscheinlichkeitsstufen und die Bestimmung, welche Systemfunktionen — Hardware, Software, Mensch oder Verfahren — zu jeder Gefährdung beitragen. Die PHA erfordert keine detaillierten Designkenntnisse; sie arbeitet auf der Ebene von „Was kann dieses System tun, das Menschen, Ausrüstung oder die Umwelt schädigen könnte?“.

PHA-Eingaben umfassen typischerweise:

• Systemkonzept der Operationen (CONOPS) und Einsatzszenarien
• Systemfunktionale Anforderungen und Architektur der obersten Ebene
• Energiequellen und Inventar gefährlicher Stoffe
• Schnittstellendefinitionen (zu Nachbarsystemen, zu Bedienern, zur Umwelt)
• Historische Gefährdungsdaten vergleichbarer Systeme

PHA-Ergebnisse umfassen ein gefülltes Hazard Log mit eindeutigen Gefährdungskennungen, Gefährdungsbeschreibungen in natürlicher Sprache, anfänglichen HRI-Stufen und einer Liste beitragender Funktionen. Bei einem Feuerleitsystem könnte die PHA „Unbeabsichtigte Waffenfreigabe“ als Catastrophic-Gefährdung (Kategorie I) identifizieren und als beitragende Funktionen aufführen: die Feuerfreigabesoftware, den Waffenfreigabebefehlskanal, die Zündungsverriegelungslogik und die Bedienerschnittstelle. Diese Liste beitragender Funktionen ist der Einstiegspunkt für alle nachfolgenden Software-Sicherheitsanalysen.

Der Unterschied zwischen einer Gefährdung und einem Ausfallmodus ist hier wichtig. Eine Gefährdung ist eine Bedingung mit Schädigungspotenzial — „unbeabsichtigte Waffenfreigabe“ ist eine Gefährdung. Ein Ausfallmodus ist ein Mechanismus, mit dem eine Komponente fehlfunktionieren kann — „Scheinsetzen der Ausgabe FIRE_COMMAND“ ist ein Ausfallmodus. Die PHA identifiziert Gefährdungen; nachfolgende Analysen identifizieren die Ausfallmodi, die zu ihnen beitragen. Die Gleichsetzung beider im Gefährdungsprotokoll ist der häufigste strukturelle Fehler in der Sicherheitsanalyse früher Programmphasen und pflanzt sich in SwHA-Tabellen fort, die schwer nachverfolgbar sind.

Der Beitrag von Software zu Systemgefährdungen ist qualitativ anders als der von Hardware. Eine Hardwarekomponente hat eine physikalische Ausfallrate, die aus Felddaten oder beschleunigtem Testen geschätzt werden kann. Softwarefehler sind deterministisch: Bei bestimmten Eingaben erzeugt eine fehlerhafte Funktion immer die falsche Ausgabe. Software nutzt sich nicht ab und hat im selben Sinne wie ein Relais oder ein Ventil keine aussagekräftige mittlere Zeit zwischen Ausfällen. Die Wahrscheinlichkeit, die einem Softwarebeitrag zu einer Gefährdung zugeordnet wird, ist daher eine Einschätzung darüber, wie wahrscheinlich die Software einen für diese Gefährdung relevanten Defekt enthält, gewichtet mit der Wahrscheinlichkeit, dass die spezifischen Eingabebedingungen, die ihn auslösen würden, im Betrieb auftreten. Diese Einschätzung stützt sich auf Softwarekomplexität, die Strenge des Entwicklungsprozesses und die Testtiefe — nicht auf empirische Ausfalldaten.

Software-Gefährdungsanalyse: Software auf Gefährdungen abbilden

Software Hazard Analysis (SwHA) ist die Aufgabe, die das Gefährdungsprotokoll auf Systemebene mit spezifischem Softwareverhalten verbindet. Für jede Gefährdung in der PHA, die eine Softwarefunktion als Beitragenden nennt, fragt die SwHA: Was muss die Software falsch tun (oder nicht tun), damit diese Gefährdung eintritt? Die Antwort zählt Softwareausfallmodi auf, die zu den Kausalitätsketten werden, die SSRs adressieren müssen.

Softwareausfallmodi fallen in fünf kanonische Kategorien:

• Falsche Ausgabe: Die Funktion wird ausgeführt und erzeugt eine Ausgabe, aber der Ausgabewert ist falsch — ein Befehl außerhalb des gültigen Bereichs, ein Statusflag, das gesetzt ist, obwohl es gelöscht sein müsste, oder ein Rechenergebnis mit einem Rechenfehler.
• Keine Ausgabe (Auslassung): Die Funktion erzeugt keine Ausgabe, von der das System abhängt — ein Watchdog, der nicht mehr zurücksetzt, ein Gesundheitsmonitor, der einen Fehler nicht meldet, eine Sicherheitsverriegelung, die das Sperrsignal nicht setzt.
• Verspätete Ausgabe: Die Funktion erzeugt die korrekte Ausgabe, aber nicht im geforderten Zeitfenster — eine Verletzung der Echtzeitbedingung, die dazu führt, dass das System mit einer veralteten oder fehlenden Eingabe fortfährt.
• Scheinausgabe: Die Funktion erzeugt eine Ausgabe, die nicht angefordert war oder zu einem Zeitpunkt auftritt, zu dem sie nicht gültig ist — ein unerbetener Befehl, der einen Stellantrieb in einem Modus auslöst, in dem dieser Befehl gefährlich ist.
• Ausgabe an das falsche Ziel: Die Funktion leitet eine gültige Ausgabe an eine falsche Schnittstelle weiter — ein für ein Teilsystem bestimmter Befehl wird wegen eines Routing- oder Adressierungsfehlers an ein anderes ausgeliefert.

Die Struktur des SwHA-Arbeitsblatts folgt einem Standardmuster. Jede Zeile entspricht einem Tripel (Gefährdung, Softwarefunktion, Ausfallmodus). Die Spalten erfassen die Gefährdungskennung, die Gefährdungsbeschreibung, den Namen der Softwarefunktion, die Ausfallmoduskategorie, die Wirkung des Ausfallmodus auf die Systemgefährdung, den Schweregrad der resultierenden Schädigung, die Wahrscheinlichkeit (als qualitative Bewertung), den HRI und die abgeleitete SSR-Kennung, die diese Zeile adressiert. Eine SwHA-Tabelle für ein Flugsteuerungssystem kann mehrere hundert Zeilen haben; für ein einfacheres Command-and-Control-Terminal vielleicht dreißig bis sechzig.

Rückverfolgbarkeit ist die operative Metrik der SwHA-Qualität. Jede PHA-Gefährdung mit Softwarebeitrag muss in der SwHA erscheinen. Jede in der PHA aufgeführte Softwarefunktion muss mindestens eine SwHA-Zeile haben. Jede SwHA-Zeile muss mit mindestens einer SSR verknüpft sein. Und jede SSR muss auf mindestens eine SwHA-Zeile zurückführbar sein. Rückverfolgbarkeitslücken, die bei staatlichen Sicherheitsprüfungen entdeckt werden, sind die häufigste Ursache für SwHA-Nacharbeit im Prüfzyklus.

Die SwHA identifiziert auch Softwareanforderungen, die Sicherheitsfunktionen dienen, nicht weil sie eine Gefährdung direkt verhindern, sondern weil sie einem Sicherheitsmonitor ermöglichen, einen Gefährdungsvorläufer zu erkennen. Diese Überwachungsanforderungen sind ebenso wichtig wie direkte Steuerungsanforderungen — ein still ausfallender Monitor nimmt dem System die Fähigkeit, vor Eintritt einer Gefährdung in den sicheren Zustand zu wechseln. Sie erfordern dieselbe SSR-Formulierung und Verifikationsstrenge wie direkte Sperranforderungen. Siehe auch: formal verification for defense software für Techniken, die die Abwesenheit bestimmter Ausfallmodi in sicherheitskritischen Modulen mathematisch belegen können.

Identifikation sicherheitskritischer Funktionen und Software Safety Requirements

Eine sicherheitskritische Softwarefunktion ist jede Funktion, deren Ausfallmodus in der SwHA als Beitrag zu einer Catastrophic- oder Critical-Gefährdung erscheint. Die Identifikation sicherheitskritischer Funktionen ist die Voraussetzung für die Zuweisung zusätzlicher Designstrenge: höhere Code-Coverage-Ziele, verpflichtendes Peer Review, unabhängige Verifikation und formale Analyse.

Der Software Criticality Index (SCI) formalisiert dies. Jeder sicherheitskritischen Funktion wird basierend auf der schlimmstmöglichen Folge ihres Ausfalls eine Kritikalitätskategorie zugeordnet: Kategorie I (Catastrophic), Kategorie II (Critical), Kategorie III (Marginal), Kategorie IV (Negligible). Der SCI steuert die Auswahl der Softwaresicherheitsanforderungen und die Tiefe der Verifikation für jede Funktion. Eine Funktion der Kategorie I — etwa die finale Autorisierungsprüfung vor einem Waffenfreigabebefehl — verdient die strengste Behandlung, die das Programm anwenden kann. Eine Funktion der Kategorie IV — ein Diagnoseprotokollschreiber — verdient keine der zusätzlichen Strenge.

Software Safety Requirements (SSRs) werden direkt aus SwHA-Zeilen abgeleitet. Für jeden identifizierten Ausfallmodus spezifiziert die SSR das Softwareverhalten, das diesen Ausfallmodus verhindert, erkennt oder mildert. Die kanonischen SSR-Formen sind:

• Positive Einschränkung: „Die Software muss die Ausgabe SAFE_STATE innerhalb von 50 ms nach Erkennen des Verlusts eines gültigen Heartbeat vom Primärsensor setzen.“ (Adressiert: verspäteter/fehlender Ausgabemodus in der Sensorüberwachungsfunktion.)
• Negative Einschränkung: „Die Software darf WEAPONS_RELEASE_COMMAND nicht setzen, es sei denn, ARM_CONFIRMED, TARGET_VALIDATED und OPERATOR_AUTHORIZED wurden alle mindestens 500 ms lang ununterbrochen gesetzt.“ (Adressiert: Scheinausgabe-Ausfallmodus in der Freigabeautorisierungsfunktion.)
• Bereichseinschränkung: „Die befohlene Azimutausgabe muss innerhalb von ±180 Grad liegen. Jeder berechnete Wert außerhalb dieses Bereichs muss die Software in den Zustand FAULT_HOLD versetzen, ohne den Befehl auszugeben.“ (Adressiert: falscher Ausgabemodus in der Feuerleitrechenfunktion.)
• Überwachungsanforderung: „Die Software muss in jedem 10-ms-Zyklus den befohlenen Schub mit dem gemessenen Schub vergleichen und THRUST_FAULT_FLAG setzen, wenn die Differenz in drei aufeinanderfolgenden Zyklen 15 % überschreitet.“ (Ermöglicht die Erkennung von Gefährdungsvorläufern.)

Jede SSR ist mit einer eindeutigen Kennung versehen (z. B. SSR-FC-007), einer bestimmten Softwarekomponente in der Architektur zugeordnet und in der Rückverfolgungsmatrix eingetragen, die sie mit ihren übergeordneten SwHA-Zeilen verknüpft. Während des detaillierten Entwurfs muss jede SSR weiter einer bestimmten Anforderung in der Software Requirements Specification (SRS) oder im Software Design Document (SDD) zugeordnet werden. Die SRS/SDD-Anforderung erbt das SSR-Tag und ermöglicht automatisierten Rückverfolgungswerkzeugen, die Sicherheitskennzeichnung durch die Anforderungshierarchie bis in die Testfallauswahl zu propagieren.

SSRs, die nicht durch Test oder Analyse verifizierbar sind, sind Indikatoren für ein Architekturproblem. Lässt sich das Sicherheitsverhalten nicht unabhängig bestätigen, entweder weil die Softwarearchitektur den relevanten Zustand nicht zur Beobachtung freigibt oder weil die SSR in nicht messbaren Begriffen formuliert ist. Beide Probleme müssen gelöst sein, bevor der Entwurf in die Implementierung übergeht. Eine SSR ohne durchführbare Verifikationsmethode ist keine Sicherheitskontrolle — sie ist eine Absichtserklärung.

Software-Designkontrollen für die Sicherheit

Designkontrollen sind die architektonischen und implementierungsnahen Muster, die die von SSRs geforderten Softwareverhalten in Gegenwart von Fehlern zuverlässig machen. Jede Designkontrolle wird anhand des adressierten Ausfallmodus und der Folgeschwere dieses Ausfallmodus ausgewählt. Es gibt kein universelles Muster — die geeignete Kontrolle hängt von der Systemarchitektur und der spezifischen Gefährdungsursache ab, die gemildert wird.

Die am breitesten anwendbaren Muster in militärischer Software sind:

Watchdog-Überwachung. Ein Hardware- oder unabhängiger Software-Watchdog verlangt von der sicherheitskritischen Anwendung, in jedem Verarbeitungszyklus aktiv ein Rücksetzsignal zu setzen. Unterbleibt das Rücksetzen — weil die Anwendung abgestürzt ist, in eine Endlosschleife geraten ist oder anderweitig nicht reagiert —, läuft der Watchdog in einen Timeout und erzwingt den Übergang in den sicheren Zustand. Der sichere Zustand wird durch Hardware definiert: Ausgänge entenergisieren, Sperren setzen, Ventile schließen. Der Watchdog muss nicht verstehen, warum die Anwendung ausgefallen ist; er muss nur wissen, dass der normale Betrieb aufgehört hat.

Positive Arming-Sequenzen. Gefährliche Befehle erfordern, dass mehrere unabhängige Freigabebedingungen gleichzeitig erfüllt sind, bevor der Befehl ausgegeben werden kann. Kein einzelner Softwarefehler, kein einzelner Sensorausfall und kein einzelner Bedienfehler kann alle Bedingungen gleichzeitig erfüllen. Das klassische Beispiel ist eine Waffenzündungs- und Freigabesequenz: Die Zündung erfordert einen separaten Hardware-Zündkreis, einen Software-Autorisierungszustand, eine Nähe- oder Zielbedingung und eine Bedienerbestätigung, alles innerhalb eines Zeitfensters. Fällt eine davon weg, entfällt die Möglichkeit zu feuern.

Fail-Safe-Zustandsautomaten. Sicherheitskritische Steuerungslogik wird als expliziter endlicher Zustandsautomat mit definiertem sicheren Standardzustand implementiert. Jede Eingabe, die einen ungültigen Zustandsübergang auslösen würde, wird auf den sicheren Zustand abgebildet statt auf undefiniertes Verhalten. Der Zustandsautomat ist so entworfen, dass Stromausfall, Kommunikationsverlust und Verlust der Sensorvalidität alle im sicheren Zustand zusammenlaufen — es gibt keinen Weg von einer Fehlerbedingung zu einem gefährlichen Befehl. Betrachten Sie ein vereinfachtes Beispiel für einen Verriegelungscontroller:

Plausibilitätsüberwachung. Ein unabhängiger Überwachungsprozess vergleicht Ausgabebefehle mit physischen Grenzen. Eine befohlene Beschleunigung, die die dokumentierte Höchstfähigkeit des Fahrzeugs überschreitet, ist unplausibel und kann auf einen Rechenfehler oder eine beschädigte Eingabe hindeuten. Der Monitor unterbricht und blockiert den unplausiblen Befehl, protokolliert das Ereignis und alarmiert das Health-Management-System. Die Überwachungslogik muss unabhängig von der Rechenlogik sein — verwenden beide denselben Algorithmus, wirkt sich ein systematischer Defekt auf beide identisch aus und der Monitor bietet keinen Schutz.

Defensive Eingabevalidierung. Jede sicherheitskritische Funktion validiert ihre Eingaben vor der Verarbeitung gegen definierte Gültigkeitsbereiche. Eingaben außerhalb des gültigen Bereichs führen nicht zu einer Berechnung mit ungültigen Daten — sie veranlassen die Funktion, eine Fehlerbedingung zu setzen und einen definierten Fehlerbehandlungspfad zu betreten. Die Validierungslogik muss nicht nur Bereichsprüfungen abdecken, sondern auch zeitliche Gültigkeit (Ist dies der zuletzt abgetastete Wert oder eine veraltete Messung?), Quellengültigkeit (Kam dieser Wert vom erwarteten Sender?) und Konsistenz (Stimmt dieser Wert innerhalb der Toleranz mit bestätigenden Sensoren überein?).

Jede Designkontrolle wird im Software Design Document mit einer expliziten Querverweisung auf die von ihr implementierte SSR dokumentiert. Der Design-Review-Prozess umfasst eine Prüfung, dass jede SSR eine identifizierte Designkontrolle hat und jede Designkontrolle als ausreichend für den adressierten Ausfallmodus begründet ist. Kontrollen, die für Marginal-Gefährdungen ausreichen, reichen für Critical möglicherweise nicht aus — das Angemessenheitsargument muss spezifisch für die Folgeschwere sein.

Sicherheitsverifikationsnachweise

Sicherheitsverifikationsnachweise sind die Menge von Protokollen, die belegen, dass jede SSR in der ausgelieferten Software korrekt implementiert ist. Die Nachweisbasis muss für einen qualifizierten Prüfer — den staatlichen Sicherheitsingenieur, das Sicherheitsprüfungsboard oder die Risikoakzeptanzautorität — ausreichen, um zu dem Schluss zu kommen, dass sich die Software so verhält, wie der Safety Case es behauptet. Nachweise, die vorhanden, aber nicht auf SSRs zurückführbar sind, oder die auf SSRs zurückführbar, aber nicht ausreichend sind, um ihre Implementierung zu belegen, schließen den Safety Case nicht ab.

Die primären Nachweistypen für die Softwaresicherheitsverifikation sind:

Sicherheitsspezifische Testfälle. Für jede SSR werden ein oder mehrere Testfälle abgeleitet, die das geforderte Verhalten unmittelbar ausüben. Die Testfälle werden aus den SwHA-Ausfallmodi konstruiert: Identifiziert die SwHA-Zeile „Scheinsetzen von FIRE_COMMAND im Modus SAFE“ als Gefährdungsursache, legt der entsprechende Testfall die spezifischen Eingabebedingungen an, die zum Auslösen dieses Verhaltens nötig wären, und prüft, dass die Ausgabe nicht gesetzt wird. Testen auf Abwesenheit gefährlichen Verhaltens ist anspruchsvoller als Testen auf Vorhandensein korrekten Verhaltens — der Testingenieur muss alle Eingabepfade durchdenken, die die Sicherheitsfunktion erreichen könnten, und bestätigen, dass keiner eine gefährliche Ausgabe erzeugt.

Code-Coverage für sicherheitskritische Module. Coverage-Metriken geben Vertrauen, dass die Testsuite die Codepfade ausübt, die die SSRs implementieren. Das Coverage-Ziel für sicherheitskritische Module (Funktionen der Kategorien I und II unter dem SCI) ist typischerweise mindestens 100 % Zweigüberdeckung, mit Modified Condition/Decision Coverage (MC/DC) für Funktionen, die Mehrbedingungs-Autorisierungslogik implementieren. Ein Zweigüberdeckungsbericht, der ungetestete Zweige in einem sicherheitskritischen Modul zeigt, ist eine offene Feststellung — entweder ist der ungetestete Zweig toter Code, der entfernt werden muss, oder es fehlt ein Testfall. Coveragedaten ohne eine entsprechende SSR-Rückverfolgungskarte sind keine Sicherheitsverifikationsnachweise — der Nachweis liegt in der Verbindung zwischen abgedecktem Code und den SSRs, die dieser Code implementiert. Siehe auch: software testing military systems für eine vollständige Behandlung der Testmethodik für Verteidigungsprogramme.

Software-FMEA. Eine Software Failure Modes and Effects Analysis wendet die FMEA-Methodik auf Softwaremodule statt auf Hardwarekomponenten an. Für jede Funktion in einem sicherheitskritischen Modul erfasst die FMEA: den Zweck der Funktion, die Ausfallmodi (nach den fünf kanonischen Kategorien der SwHA), die Wirkung jedes Ausfallmodus auf die Softwareausgabe, die Wirkung auf die Systemgefährdung, den Erkennungsmechanismus (Watchdog, Monitor, Test, Bedienerbeobachtung) und die Ausgleichskontrolle im Design. Die Software-FMEA ist als Gegenprüfung zur SwHA am wertvollsten — identifiziert die FMEA einen Ausfallmodus mit gefährlichen Folgen, der in der SwHA nicht erscheint, hat entweder die SwHA eine Lücke oder die FMEA ein falsch positives Ergebnis, das entschieden werden muss. Beide Ergebnisse verbessern den Safety Case.

Code-Review-Protokolle. Peer Review von sicherheitskritischem Code mit einer sicherheitsspezifischen Checkliste erzeugt Nachweise, dass qualifizierte Ingenieure die Implementierung auf Konformität mit SSRs und Designkontrollen geprüft haben. Die Checklistenpunkte sollten direkt auf die geforderten Designmuster abgebildet sein — „Watchdog-Rücksetzen in jedem Zyklus aufgerufen“, „alle Eingaben vor Verwendung validiert“, „Zustandsautomat hat keine undefinierten Übergänge“. Prüfprotokolle nennen gefundene Defekte und ihre Dispositionen; eine Prüfung ohne Feststellungen zu einem komplexen sicherheitskritischen Modul ist entweder ein Hinweis auf eine außergewöhnlich saubere Implementierung oder auf einen nicht ausreichend strengen Prüfprozess, und der Programmsicherheitsingenieur sollte beides unterscheiden können.

Die Integration dieser Nachweistypen in die DevSecOps for defense pipelines erfordert, dass sicherheitskritische Testfälle, Coverage-Werkzeuge und FMEA-Arbeitsblätter konfigurationsgesteuert neben dem Quellcode liegen, den sie verifizieren. Ein Testergebnis ohne eine Konfigurationsbasislinie, die genau die getestete Softwareversion identifiziert, ist kein reproduzierbarer Nachweis und kann nicht in einem Safety Data Package eingereicht werden. Jedes Nachweisartefakt erfordert eine Dokumentnummer, eine Revision, ein Datum und einen Verweis auf die Software-Konfigurationselement-Basislinie, die es abdeckt.

Zusammenstellung des Safety Case und Restrisikoakzeptanz

Der Safety Case ist ein strukturiertes Argument, dass das ausgelieferte Softwaresystem für seinen vorgesehenen Einsatz akzeptabel sicher ist. Er behauptet nicht, die Software sei fehlerfrei oder jedes Risiko sei beseitigt — solche Behauptungen sind nicht erreichbar und nicht das, was MIL-STD-882E verlangt. Er behauptet: alle vernünftigerweise vorhersehbaren Gefährdungen sind identifiziert; Kontrollen sind angewandt, die jede Gefährdung auf ein akzeptables Risikoniveau senken; die Kontrollen sind als korrekt implementiert verifiziert; und die Restrisiken, die nach Anwendung der Kontrollen verbleiben, sind von der zuständigen Autorität geprüft und akzeptiert worden.

Die Dokumentstruktur des Safety Case folgt einer Hierarchie aus Behauptung-Argument-Nachweis. Goal Structuring Notation (GSN) wird häufig verwendet, um diese Hierarchie zu visualisieren, auch wenn die Notation nicht vorgeschrieben ist — die Struktur muss vorhanden sein, unabhängig davon, ob sie in GSN-Form ausgedrückt wird. Eine typische übergeordnete Struktur für einen Software-Safety-Case eines Feuerleitsystems:

Das Safety Data Package (SDP) ist die Sammlung von Artefakten, die dem Programmbüro als Nachweis für den Safety Case geliefert werden. Sein Inhalt ist im System Safety Program Plan als Liste von CDRLs mit Lieferterminen, die an Programm-Meilensteine gekoppelt sind, festgelegt. Typische SDP-Inhalte:

• System Safety Program Plan (SSPP)
• Bericht der Preliminary Hazard Analysis (PHA)
• Berichte der Subsystem Hazard Analysis (SSHA)
• Arbeitsblätter der Software Hazard Analysis (SwHA)
• Liste der Software Safety Requirements (SSR) und Rückverfolgungsmatrix
• Berichte der Software Safety Design Analysis (Task 206)
• Software-FMEA-Arbeitsblätter
• Sicherheitskritische Softwaretestfälle und Testergebnisse
• Code-Coverage-Berichte für sicherheitskritische Module
• Code-Review-Protokolle für sicherheitskritische Module
• Hazard Risk Decision Reports (HRDRs) für akzeptierte Restrisiken
• Safety Assessment Report (SAR)

Die Restrisikoakzeptanz ist der formelle Akt, mit dem die Risikoakzeptanzautorität anerkennt, dass eine Gefährdung auf ein Niveau kontrolliert wurde, das über der akzeptablen Schwelle des Programms liegt, die Nachweise prüft, dass die Kontrollen angemessen und korrekt implementiert sind, und die Verantwortung für das verbleibende Risiko übernimmt. Der Hazard Risk Decision Report ist das Instrument dieses Akts. Der HRDR beschreibt die Gefährdung, die angewandten Kontrollen, den Rest-HRI nach den Kontrollen, die den Rest-HRI stützenden Nachweise und eine Empfehlung. Die zuständige Autorität unterschreibt den HRDR und wandelt ihn von einer Empfehlung in einen formellen Risikoakzeptanznachweis um.

Der Safety Case ist ein lebendes Dokument. Jedes Mal, wenn die Software geändert wird — Anforderungen ändern sich, Defekte werden korrigiert, Schnittstellen entwickeln sich weiter —, muss der Safety Case geprüft werden, um festzustellen, ob die Änderung eine Gefährdung, SSR, Designkontrolle oder ein Nachweisobjekt betrifft. Eine Änderung, die die Wahrscheinlichkeit oder den Schweregrad eines akzeptierten Restrisikos erhöht, erfordert einen neuen HRDR, den die zuständige Autorität unterschreibt. Eine Änderung, die eine neue Gefährdungsursache einführt, erfordert eine SwHA-Aktualisierung und potenziell eine neue SSR. Das Konfigurationsmanagement der Safety-Case-Artefakte ist daher ebenso wichtig wie das Konfigurationsmanagement des Quellcodes — ein veralteter Safety Case, der die aktuelle Softwarebasislinie nicht widerspiegelt, ist überhaupt kein Safety Case.

Der häufigste Ausfallmodus von Softwaresicherheitsprogrammen ist nicht unzureichende Analyse — es ist unzureichende Umsetzung bis zum Ende. Die SwHA wird durchgeführt, die SSRs werden geschrieben, die Designkontrollen werden implementiert, und dann läuft die Testplanung ohne systematische Verbindung zwischen den SSRs und den Testfällen weiter. Die Coveragedaten werden ohne Karte zu den sicherheitskritischen Modulen gesammelt. Die FMEA wird nach dem Code Review geschrieben statt davor. Das Ergebnis ist eine Sammlung einzeln plausibler Artefakte, die sich nicht zu einem stimmigen Argument zusammensetzen. Die Aufgabe der Safety-Case-Zusammenstellung ist der Ort, an dem diese Brüche sichtbar werden — und sie vor Programmprüfungen statt währenddessen anzugehen, ist der Unterschied zwischen einem belastbaren Sicherheitsprogramm und einem teuren Nacharbeitszyklus.