Budowa uzasadnienia bezpieczeństwa oprogramowania wg MIL-STD-882

System działający bez uzasadnienia bezpieczeństwa oprogramowania działa na zaufaniu — zaufaniu, że analiza zagrożeń była kompletna, że elementy kontroli projektu są poprawne i że dowody weryfikacji są wystarczające. Dla produktu komercyjnego takie zaufanie jest bronione. Dla systemu wojskowego, którego tryby awarii obejmują wyzwolenie energii, utratę platformy lub ostrzał własnych wojsk — nie. MIL-STD-882E, standard Departamentu Obrony dotyczący bezpieczeństwa systemu, dostarcza ustrukturyzowanego procesu, w którym to zaufanie zastępuje się dowodami udokumentowanymi, przejrzanymi i zaakceptowanymi. Uzasadnienie bezpieczeństwa oprogramowania jest artefaktem, który te dowody gromadzi i formułuje argument, że ryzyko resztkowe jest akceptowalne.

Niniejszy artykuł to przewodnik praktyka po budowie uzasadnienia bezpieczeństwa oprogramowania według MIL-STD-882E. Obejmuje strukturę zadań standardu i jego przepisy dotyczące oprogramowania, łańcuch analizy zagrożeń od identyfikacji wstępnej przez analizę zagrożeń oprogramowania (SwHA), wyprowadzanie Wymagań Bezpieczeństwa Oprogramowania (SSR) z przyczyn zagrożeń, elementy kontroli projektu realizujące te wymagania, dowody weryfikacji wykazujące ich prawidłową implementację oraz proces akceptacji ryzyka, który zamyka sprawę. Inżynierowie nowi w programach bezpieczeństwa obronnego znajdą tu mapę terenu; doświadczeni praktycy — odniesienie do konkretnych wyników i identyfikowalności oczekiwanych przez rządowych recenzentów.

MIL-STD-882E w zarysie: bezpieczeństwo systemu od koncepcji po wycofanie

MIL-STD-882E definiuje bezpieczeństwo systemu jako planowane, zdyscyplinowane podejście do identyfikowania i zarządzania zagrożeniami w całym cyklu życia systemu — od eksploracji koncepcji po wycofanie z eksploatacji. Standard porządkuje wymagania w zadania zgrupowane w pięciu kategoriach: Zarządzanie i Sterowanie Programem, Wymagania Projektowe, Wsparcie Eksploatacji, Szkolenie oraz Oceny. Zamawiający wybiera zadania odpowiednie do profilu ryzyka programu i określa je w Opisie Prac. Wykonawca realizuje te zadania i dostarcza wyniki jako pozycje Listy Wymagań Danych Umownych.

Dla wojskowych systemów intensywnie wykorzystujących oprogramowanie nakład inżynierski koncentruje się na pięciu zadaniach:

• Zadanie 205 — Analiza Wymagań Bezpieczeństwa Oprogramowania: identyfikacja wszystkich funkcji oprogramowania krytycznych dla bezpieczeństwa i wyprowadzenie Wymagań Bezpieczeństwa Oprogramowania w celu kontroli zidentyfikowanych przyczyn zagrożeń.
• Zadanie 206 — Analiza Projektu Bezpieczeństwa Oprogramowania: analiza projektu oprogramowania w celu potwierdzenia, że wymagania bezpieczeństwa są prawidłowo przydzielone i że decyzje projektowe nie wprowadzają nowych przyczyn zagrożeń.
• Zadanie 301 — Ocena Bezpieczeństwa: ocena sterowana kamieniami milowymi, czy ryzyko resztkowe jest akceptowalne, udokumentowana w Raporcie z Oceny Bezpieczeństwa (SAR).
• Zadanie 302 — Bezpieczeństwo Testów i Oceny: zapewnienie, że elementy kontroli bezpieczeństwa są wdrożone przed każdą działalnością testową związaną z niebezpieczną energią lub trybami operacyjnymi.
• Zadanie 303 — Przeglądy Programu Bezpieczeństwa Systemu: formalne przeglądy, na których Grupa Robocza Bezpieczeństwa Systemu (SSWG) przedstawia biuru programowemu stan zagrożeń, otwarte pozycje ryzyka oraz dowody skuteczności kontroli.

Macierz ryzyka w centrum MIL-STD-882E zestawia Ciężkość z Prawdopodobieństwem. Ciężkość biegnie od Katastrofalnej (Kategoria I: śmierć, utrata systemu, poważne szkody środowiskowe) przez Krytyczną (Kategoria II: ciężki uraz, poważne uszkodzenie systemu) i Marginalną (Kategoria III: lekki uraz, drobne uszkodzenie systemu) do Znikomej (Kategoria IV: uraz lub szkoda mniejsza niż lekka). Prawdopodobieństwo biegnie od Częstego (prawdopodobnego do częstego występowania w okresie eksploatacji systemu) przez Prawdopodobne, Okazjonalne i Mało prawdopodobne do Nieprawdopodobnego. Każda komórka powstałej macierzy 4×5 niesie Wskaźnik Ryzyka Zagrożenia (HRI), który decyduje, kto musi zaakceptować ryzyko resztkowe po zastosowaniu elementów kontroli.

HRI nie jest iloczynem matematycznym — to ranking porządkowy zdefiniowany przez macierz ryzyka programu, którą ustanawia SSPP. Zagrożenie Katastrofalne/Częste (HRI 1) wymaga akceptacji przez Organ Decyzyjny Kamienia Milowego; zagrożenie Znikome/Nieprawdopodobne (HRI 20) jest akceptowalne na poziomie grupy roboczej. Praktyczna konsekwencja dla inżynierów oprogramowania polega na tym, że produkty ich analiz — arkusze zagrożeń, wiersze SwHA, SSR, zapisy weryfikacji — trafiają wprost do procesu zarządzania ryzykiem z zdefiniowanymi poziomami uprawnień. Luki w analizie pozostawiają ryzyko na poziomie nieokreślonym, którego żaden organ nie może zaakceptować.

Wstępna analiza zagrożeń: wyszukiwanie funkcji oprogramowania krytycznych dla bezpieczeństwa

Wstępną Analizę Zagrożeń (PHA) przeprowadza się wcześnie w rozwoju systemu, zazwyczaj przed sfinalizowaniem szczegółowych wymagań, na podstawie dekompozycji funkcjonalnej systemu oraz dokumentacji koncepcji eksploatacji. Jej celem jest identyfikacja zagrożeń na poziomie systemu, przypisanie początkowych ocen ciężkości i prawdopodobieństwa oraz wskazanie, które funkcje systemu — sprzętowe, programowe, ludzkie lub proceduralne — przyczyniają się do każdego zagrożenia. PHA nie wymaga wiedzy o szczegółowym projekcie; działa na poziomie pytania „co ten system może zrobić, co mogłoby zaszkodzić ludziom, wyposażeniu lub środowisku?”.

Dane wejściowe PHA typowo obejmują:

• Koncepcję działania systemu (CONOPS) i scenariusze operacyjne
• Wymagania funkcjonalne systemu i architekturę najwyższego poziomu
• Inwentarz źródeł energii i materiałów niebezpiecznych
• Definicje interfejsów (do systemów sąsiednich, do operatorów, do środowiska)
• Historyczne dane o zagrożeniach z podobnych systemów

Wyniki PHA obejmują wypełniony Rejestr Zagrożeń z unikalnymi identyfikatorami zagrożeń, opisami zagrożeń językiem naturalnym, początkowymi ocenami HRI oraz listą funkcji przyczyniających się. Dla systemu kierowania ogniem PHA może zidentyfikować „niezamierzone użycie broni” jako zagrożenie katastrofalne (Kategoria I) i wymienić jako funkcje przyczyniające się: oprogramowanie autoryzacji zaangażowania, kanał rozkazu użycia broni, logikę blokady uzbrajania oraz interfejs operatora. Ta lista funkcji przyczyniających się jest punktem wejścia dla wszystkich późniejszych analiz bezpieczeństwa oprogramowania.

Rozróżnienie między zagrożeniem a trybem awarii ma tu znaczenie. Zagrożenie to stan o potencjale szkody — „niezamierzone użycie broni” to zagrożenie. Tryb awarii to mechanizm, w jaki komponent może ulec awarii — „zakłócone zgłoszenie wyjścia FIRE_COMMAND” to tryb awarii. PHA identyfikuje zagrożenia; późniejsze analizy identyfikują tryby awarii, które się do nich przyczyniają. Mylenie obu pojęć w rejestrze zagrożeń jest najczęstszym błędem strukturalnym wczesnej analizy bezpieczeństwa programu i przenosi się dalej na tabele SwHA, których trudno jest śledzić.

Wkład oprogramowania w zagrożenia systemowe jest jakościowo inny niż wkład sprzętu. Komponent sprzętowy ma fizyczny wskaźnik awaryjności, który można oszacować z danych terenowych lub przyspieszonych testów. Defekty oprogramowania są deterministyczne: przy określonych danych wejściowych wadliwa funkcja zawsze zwraca zły wynik. Oprogramowanie nie zużywa się i nie ma sensownego średniego czasu między awariami w tym samym znaczeniu co przekaźnik czy zawór. Prawdopodobieństwo przypisane wkładowi oprogramowania w zagrożenie jest więc osądem dotyczącym tego, czy oprogramowanie zawiera defekt istotny dla danego zagrożenia, ważonym prawdopodobieństwem wystąpienia w eksploatacji tych konkretnych warunków wejściowych, które by go uruchomiły. Na ten osąd składają się złożoność oprogramowania, rygor procesu rozwoju i głębokość testów — nie empiryczne dane awaryjności.

Analiza zagrożeń oprogramowania: łączenie oprogramowania z zagrożeniami

Analiza Zagrożeń Oprogramowania (SwHA) to zadanie łączące rejestr zagrożeń na poziomie systemu z konkretnymi zachowaniami oprogramowania. Dla każdego zagrożenia w PHA, które wymienia funkcję oprogramowania jako przyczyniającą się, SwHA pyta: co oprogramowanie musi zrobić nieprawidłowo (lub czego nie zrobić), aby to zagrożenie wystąpiło? Odpowiedź wylicza tryby awarii oprogramowania, które stają się łańcuchami przyczynowymi, jakie muszą adresować SSR.

Tryby awarii oprogramowania mieszczą się w pięciu kategoriach kanonicznych:

• Nieprawidłowy wynik: funkcja wykonuje się i zwraca wynik, ale wartość wyniku jest błędna — rozkaz poza prawidłowym zakresem, flaga stanu ustawiona zamiast wyczyszczona lub wynik obliczenia z błędem arytmetycznym.
• Brak wyniku (pominięcie): funkcja nie zwraca wyniku, od którego zależy system — watchdog, który przestaje resetować, monitor stanu zdrowia niewywołujący zgłoszenia awarii, blokada bezpieczeństwa niezgłaszająca sygnału inhibit.
• Wynik spóźniony: funkcja zwraca prawidłowy wynik, ale nie w wymaganym oknie czasowym — naruszenie ograniczenia czasu rzeczywistego, które powoduje, że system działa na danych nieaktualnych lub ich braku.
• Wynik zakłócony: funkcja zwraca wynik, którego nie żądano, lub w momencie, gdy nie jest on ważny — niezamówiony rozkaz uruchamiający element wykonawczy w trybie, w którym ten rozkaz jest niebezpieczny.
• Wynik do niewłaściwego miejsca docelowego: funkcja kieruje prawidłowy wynik do niewłaściwego interfejsu — rozkaz przeznaczony dla jednego podsystemu trafia do innego z powodu błędu routingu lub adresowania.

Struktura arkusza SwHA odpowiada standardowemu wzorcowi. Każdy wiersz odpowiada jednej trójce (zagrożenie, funkcja oprogramowania, tryb awarii). Kolumny zapisują identyfikator zagrożenia, opis zagrożenia, nazwę funkcji oprogramowania, kategorię trybu awarii, skutek trybu awarii dla zagrożenia systemowego, ciężkość wynikającej szkody, prawdopodobieństwo (jako ocenę jakościową), HRI oraz wyprowadzony identyfikator SSR adresujący ten wiersz. Tabela SwHA dla systemu sterowania lotem może liczyć kilkaset wierszy; dla prostszego terminala dowodzenia i kontroli — około trzydziestu do sześćdziesięciu.

Identyfikowalność jest operacyjną miarą jakości SwHA. Każde zagrożenie PHA z udziałem oprogramowania musi pojawić się w SwHA. Każda funkcja oprogramowania wymieniona w PHA musi mieć co najmniej jeden wiersz SwHA. Każdy wiersz SwHA musi prowadzić do co najmniej jednego SSR. I każde SSR musi się cofać do co najmniej jednego wiersza SwHA. Luki w identyfikowalności wykryte podczas rządowych przeglądów bezpieczeństwa są najczęstszą przyczyną przeróbek SwHA w cyklu przeglądu.

SwHA identyfikuje również wymagania oprogramowania, które służą funkcjom bezpieczeństwa nie dlatego, że bezpośrednio zapobiegają zagrożeniu, lecz dlatego, że umożliwiają monitorowi bezpieczeństwa wykrycie zwiastuna zagrożenia. Te wymagania monitorujące są równie ważne jak wymagania bezpośredniej kontroli — monitor, który zawodzi bezgłośnie, odbiera systemowi zdolność przejścia do stanu bezpiecznego przed wystąpieniem zagrożenia. Wymagają tego samego formułowania SSR i rygoru weryfikacji co wymagania bezpośredniego inhibit. Zobacz też: formalna weryfikacja oprogramowania obronnego — techniki, które matematycznie potrafią wykazać brak określonych trybów awarii w modułach krytycznych dla bezpieczeństwa.

Identyfikacja funkcji krytycznych dla bezpieczeństwa i Wymagania Bezpieczeństwa Oprogramowania

Funkcja oprogramowania krytyczna dla bezpieczeństwa to każda funkcja, której tryb awarii występuje w SwHA jako przyczynek do zagrożenia katastrofalnego lub krytycznego. Identyfikacja funkcji krytycznych dla bezpieczeństwa jest warunkiem wstępnym alokacji dodatkowego rygoru projektowego: wyższych celów pokrycia kodu, obowiązkowej recenzenckiej inspekcji kodu, niezależnej weryfikacji i analizy formalnej.

Wskaźnik Krytyczności Oprogramowania (SCI) formalizuje to podejście. Każdej funkcji krytycznej dla bezpieczeństwa przypisuje się kategorię krytyczności na podstawie najgorszego możliwego skutku jej awarii: Kategoria I (Katastrofalna), Kategoria II (Krytyczna), Kategoria III (Marginalna), Kategoria IV (Znikoma). SCI kieruje doborem wymagań bezpieczeństwa oprogramowania i głębokością weryfikacji stosowanej do każdej funkcji. Funkcja kategorii I — powiedzmy, końcowa kontrola autoryzacji przed rozkazem użycia broni — uzasadnia najbardziej rygorystyczne traktowanie, jakie program może zastosować. Funkcja kategorii IV — zapisywnik diagnostyczny — nie uzasadnia żadnego dodatkowego rygoru.

Wymagania Bezpieczeństwa Oprogramowania (SSR) wyprowadza się bezpośrednio z wierszy SwHA. Dla każdego zidentyfikowanego trybu awarii SSR określa zachowanie oprogramowania, które temu trybowi zapobiega, wykrywa go lub łagodzi. Kanoniczne formy SSR to:

• Ograniczenie pozytywne: „oprogramowanie musi zgłosić wyjście SAFE_STATE w ciągu 50 ms od wykrycia utraty prawidłowego sygnału bicia serca od czujnika podstawowego.” (Adresuje: tryb awarii spóźniony/brak wyjścia w funkcji monitorowania czujnika.)
• Ograniczenie negatywne: „oprogramowanie nie może zgłaszać WEAPONS_RELEASE_COMMAND, chyba że ARM_CONFIRMED, TARGET_VALIDATED i OPERATOR_AUTHORIZED są wszystkie nieprzerwanie zgłaszane przez co najmniej 500 ms.” (Adresuje: tryb awarii wyniku zakłóconego w funkcji autoryzacji użycia broni.)
• Ograniczenie zakresu: „zadane wyjście azymutu musi mieścić się w zakresie ±180 stopni. Każda obliczona wartość poza tym zakresem musi spowodować, że oprogramowanie wejdzie w stan FAULT_HOLD bez wydania rozkazu.” (Adresuje: tryb awarii nieprawidłowego wyniku w funkcji obliczeń kierowania ogniem.)
• Wymaganie monitorujące: „oprogramowanie musi porównywać zadany ciąg z mierzonym ciągiem w każdym cyklu 10 ms i ustawić THRUST_FAULT_FLAG, jeśli różnica przekracza 15% przez trzy kolejne cykle.” (Umożliwia wykrywanie zwiastuna zagrożenia.)

Każde SSR oznacza się unikalnym identyfikatorem (np. SSR-FC-007), przydziela do konkretnego komponentu oprogramowania w architekturze i wpisuje do macierzy identyfikowalności łączącej je z nadrzędnymi wierszami SwHA. Podczas projektowania szczegółowego każde SSR musi zostać dalej przydzielone do konkretnego wymagania w Specyfikacji Wymagań Oprogramowania (SRS) lub Dokumencie Projektu Oprogramowania (SDD). Wymaganie SRS/SDD dziedziczy znacznik SSR, co umożliwia narzędziom automatycznej identyfikowalności propagowanie oznaczenia bezpieczeństwa przez hierarchię wymagań aż do doboru przypadków testowych.

SSR, których nie da się zweryfikować testem ani analizą, sygnalizują problem architektoniczny. Jeśli zachowania bezpieczeństwa nie da się niezależnie potwierdzić, albo architektura oprogramowania nie udostępnia odpowiedniego stanu do obserwacji, albo SSR sformułowano w kategoriach niemierzalnych. Oba problemy wymagają rozstrzygnięcia, zanim projekt przejdzie do implementacji. SSR bez wykonalnej metody weryfikacji nie jest elementem kontroli bezpieczeństwa — to deklaracja zamiaru.

Elementy kontroli bezpieczeństwa w projekcie oprogramowania

Elementy kontroli projektu to wzorce architektoniczne i implementacyjne, które czynią zachowania oprogramowania wymagane przez SSR niezawodnymi w obecności usterek. Każdy element kontroli dobiera się na podstawie adresowanego trybu awarii i ciężkości skutków tego trybu. Nie ma wzorca uniwersalnego — odpowiednia kontrola zależy od architektury systemu i konkretnej przyczyny zagrożenia, którą łagodzi.

Najszersze zastosowanie w oprogramowaniu wojskowym mają następujące wzorce:

Nadzór watchdoga. Watchdog sprzętowy lub niezależny programowy wymaga, aby aplikacja krytyczna dla bezpieczeństwa aktywnie zgłaszała sygnał resetu w każdym cyklu przetwarzania. Brak zgłoszenia resetu — czy to dlatego, że aplikacja uległa awarii, weszła w nieskończoną pętlę, czy w inny sposób przestała odpowiadać — powoduje, że watchdog przekracza czas i wymusza przejście do stanu bezpiecznego. Stan bezpieczny definiuje sprzęt: odenerwowanie wyjść, ustawienie inhibit, zamknięcie zaworów. Watchdog nie musi rozumieć, dlaczego aplikacja zawiodła; musi tylko wiedzieć, że normalna praca ustała.

Pozytywne sekwencje uzbrajania. Niebezpieczne rozkazy wymagają jednoczesnego spełnienia wielu niezależnych warunków zezwolenia, zanim rozkaz może zostać wydany. Żadna pojedyncza awaria oprogramowania, pojedyncza awaria czujnika ani pojedynczy błąd operatora nie może spełnić wszystkich warunków jednocześnie. Klasyczny przykład to sekwencja uzbrajania i użycia broni: uzbrajanie wymaga osobnego sprzętowego obwodu uzbrajania, stanu autoryzacji oprogramowania, warunku zbliżeniowego lub naprowadzania oraz potwierdzenia operatora — wszystkiego w oknie czasowym. Usunięcie któregokolwiek z nich odbiera zdolność otwarcia ognia.

Maszyny stanów fail-safe. Logika sterowania krytyczna dla bezpieczeństwa jest zaimplementowana jako jawna skończona maszyna stanów z określonym bezpiecznym stanem domyślnym. Każde wejście, które spowodowałoby nieprawidłowe przejście stanu, jest odwzorowane na stan bezpieczny zamiast na zachowanie nieokreślone. Maszynę stanów projektuje się tak, aby utrata zasilania, utrata komunikacji lub utrata ważności danych czujnika zbiegały się w stanie bezpiecznym — nie istnieje droga ze stanu awarii do niebezpiecznego rozkazu. Rozważmy uproszczony przykład sterownika blokady:

Monitorowanie wiarygodności. Niezależny proces monitorujący porównuje rozkazy wyjściowe z ograniczeniami fizycznymi. Zadane przyspieszenie przekraczające udokumentowaną maksymalną zdolność pojazdu jest niewiarygodne i może wskazywać na błąd obliczeń lub uszkodzone dane wejściowe. Monitor przechwytuje i blokuje niewiarygodny rozkaz, rejestruje zdarzenie i powiadamia system zarządzania zdolnością do pracy. Logika monitorowania musi być niezależna od logiki obliczeń — jeśli obie używają tego samego algorytmu, defekt systematyczny wpływa na nie identycznie i monitor nie zapewnia żadnej ochrony.

Defensywna walidacja danych wejściowych. Każda funkcja krytyczna dla bezpieczeństwa waliduje dane wejściowe względem zdefiniowanych prawidłowych zakresów, zanim je przetworzy. Dane wejściowe poza prawidłowym zakresem nie powodują obliczeń na danych nieprawidłowych — powodują, że funkcja zgłasza stan awarii i wchodzi w zdefiniowaną ścieżkę obsługi błędów. Logika walidacji musi obejmować nie tylko kontrole zakresu, lecz także ważność czasową (czy to najnowsza próbkowana wartość, czy nieaktualny odczyt?), ważność źródła (czy ta wartość pochodzi od oczekiwanego nadawcy?) oraz spójność (czy ta wartość zgadza się w tolerancji z czujnikami potwierdzającymi?).

Każdy element kontroli projektu dokumentuje się w Dokumencie Projektu Oprogramowania z jawnym odsyłaczem do SSR, który realizuje. Proces przeglądu projektu obejmuje sprawdzenie, że każde SSR ma zidentyfikowany element kontroli projektu oraz że każdy element kontroli jest uzasadniony jako wystarczający dla adresowanego trybu awarii. Elementy kontroli wystarczające dla zagrożeń marginalnych mogą być niewystarczające dla zagrożeń krytycznych — argument wystarczości musi być specyficzny dla ciężkości skutków.

Dowody weryfikacji bezpieczeństwa

Dowody weryfikacji bezpieczeństwa to zbiór zapisów, które wykazują, że każde SSR jest prawidłowo zaimplementowane w dostarczonym oprogramowaniu. Baza dowodowa musi być wystarczająca, aby wykwalifikowany recenzent — rządowy inżynier bezpieczeństwa, komisja przeglądu bezpieczeństwa lub organ akceptacji ryzyka — mógł stwierdzić, że oprogramowanie zachowuje się tak, jak głosi uzasadnienie bezpieczeństwa. Dowody obecne, lecz niepowiązane z SSR, albo powiązane z SSR, lecz niewystarczające do wykazania ich implementacji, nie zamykają uzasadnienia bezpieczeństwa.

Podstawowe typy dowodów weryfikacji bezpieczeństwa oprogramowania to:

Testy bezpieczeństwa specyficzne. Dla każdego SSR wyprowadza się jeden lub więcej przypadków testowych bezpośrednio ćwiczących wymagane zachowanie. Przypadki testowe buduje się z trybów awarii SwHA: jeśli wiersz SwHA wskazuje „zakłócone zgłoszenie FIRE_COMMAND w trybie SAFE” jako przyczynę zagrożenia, odpowiedni przypadek testowy stosuje konkretne warunki wejściowe, które byłyby wymagane do wywołania tego zachowania, i sprawdza, że wyjście nie jest zgłaszane. Testowanie na brak zachowań niebezpiecznych jest bardziej wymagające niż testowanie na obecność zachowań poprawnych — inżynier testów musi rozważyć wszystkie ścieżki wejściowe, które mogą dotrzeć do funkcji bezpieczeństwa, i potwierdzić, że żadna nie generuje wyjścia niebezpiecznego.

Pokrycie kodu modułów krytycznych dla bezpieczeństwa. Metryki pokrycia dają pewność, że zestaw testów ćwiczy ścieżki kodu realizujące SSR. Cel pokrycia dla modułów krytycznych dla bezpieczeństwa (funkcje kategorii I i II według SCI) to zazwyczaj minimum 100% pokrycia gałęzi, z pokryciem zmienionych warunków/decyzji (MC/DC) wymaganym dla funkcji realizujących logikę autoryzacji wielowarunkowej. Raport pokrycia gałęzi wykazujący nieprzetestowane gałęzie w module krytycznym dla bezpieczeństwa jest otwartym ustaleniem — albo nieprzetestowana gałąź jest martwym kodem, który trzeba usunąć, albo brakuje przypadku testowego. Dane pokrycia bez odpowiadającej im macierzy identyfikowalności SSR nie stanowią dowodu weryfikacji bezpieczeństwa — dowód leży w powiązaniu między pokrytym kodem a SSR, które ten kod realizuje. Zobacz też: testowanie oprogramowania systemów wojskowych — pełne omówienie metodyki testów dla programów obronnych.

FMEA oprogramowania. Analiza Trybów i Skutków Awarii (FMEA) oprogramowania stosuje metodologię FMEA do modułów oprogramowania zamiast komponentów sprzętowych. Dla każdej funkcji w module krytycznym dla bezpieczeństwa FMEA rejestruje: cel funkcji, tryby awarii (w pięciu kategoriach kanonicznych ze SwHA), skutek każdego trybu awarii dla wyjścia oprogramowania, skutek dla zagrożenia systemowego, mechanizm wykrywania (watchdog, monitor, test, obserwacja operatora) oraz element kontroli kompensującej w projekcie. FMEA oprogramowania jest najcenniejsza jako kontrola krzyżowa SwHA — jeśli FMEA identyfikuje tryb awarii o niebezpiecznych skutkach, który nie występuje w SwHA, albo SwHA ma lukę, albo FMEA ma wynik fałszywie dodatni, który trzeba rozstrzygnąć. Oba rezultaty poprawiają uzasadnienie bezpieczeństwa.

Protokoły przeglądów kodu. Recenzencka inspekcja kodu krytycznego dla bezpieczeństwa z użyciem listy kontrolnej specyficznej dla bezpieczeństwa generuje dowody, że wykwalifikowani inżynierowie zbadali implementację pod kątem zgodności z SSR i elementami kontroli projektu. Pozycje listy kontrolnej powinny wprost odpowiadać wymaganym wzorcom projektowym — „reset watchdoga wywoływany w każdym cyklu”, „wszystkie wejścia zwalidowane przed użyciem”, „maszyna stanów nie ma niezdefiniowanych przejść”. Protokoły przeglądów wskazują wykryte defekty i ich rozstrzygnięcia; przegląd z zerem ustaleń wobec złożonego modułu krytycznego dla bezpieczeństwa jest albo oznaką wyjątkowo czystej implementacji, albo niewystarczająco rygorystycznego procesu przeglądu, a inżynier bezpieczeństwa programu powinien umieć odróżnić te przypadki.

Włączenie tych typów dowodów do DevSecOps dla potoków obronnych wymaga, aby testy bezpieczeństwa specyficzne, narzędzia pokrycia i arkusze FMEA były objęte kontrolą konfiguracji obok weryfikowanego kodu źródłowego. Wynik testu bez bazowej konfiguracji dokładnie identyfikującej testowaną wersję oprogramowania nie jest dowodem odtwarzalnym i nie może zostać złożony w Pakiecie Danych Bezpieczeństwa. Każdy artefakt dowodowy wymaga numeru dokumentu, rewizji, daty i odnośnika do bazy konfiguracji elementu oprogramowania, którą obejmuje.

Skompletowanie uzasadnienia bezpieczeństwa i akceptacja ryzyka resztkowego

Uzasadnienie bezpieczeństwa to ustrukturyzowany argument, że dostarczony system oprogramowania jest akceptowalnie bezpieczny w zamierzonym zastosowaniu. Nie twierdzi, że oprogramowanie jest wolne od defektów ani że wyeliminowano całe ryzyko — takie twierdzenia są nieosiągalne i nie tego wymaga MIL-STD-882E. Głosi, że: wszystkie racjonalnie przewidywalne zagrożenia zostały zidentyfikowane; zastosowano elementy kontroli sprowadzające każde zagrożenie do akceptowalnego poziomu ryzyka; elementy kontroli zweryfikowano jako prawidłowo zaimplementowane; a ryzyka resztkowe pozostałe po zastosowaniu kontroli zostały przejrzane i zaakceptowane przez właściwy organ.

Struktura dokumentu uzasadnienia bezpieczeństwa opiera się na hierarchii teza–argument–dowód. Notacja Goal Structuring Notation (GSN) jest powszechnie używana do wizualizacji tej hierarchii, choć nie jest wymagana — struktura musi istnieć niezależnie od tego, czy wyrażono ją w formie GSN. Typowa struktura najwyższego poziomu dla uzasadnienia bezpieczeństwa oprogramowania systemu kierowania ogniem:

Pakiet Danych Bezpieczeństwa (SDP) to zbiór artefaktów dostarczanych do biura programowego jako dowody uzasadnienia bezpieczeństwa. Jego zawartość określa Plan Programu Bezpieczeństwa Systemu jako lista pozycji CDRL z terminami dostaw powiązanymi z kamieniami milowymi programu. Typowa zawartość SDP:

• Plan Programu Bezpieczeństwa Systemu (SSPP)
• Raport z Wstępnej Analizy Zagrożeń (PHA)
• Raporty z Analizy Zagrożeń Podsystemu (SSHA)
• Arkusze Analizy Zagrożeń Oprogramowania (SwHA)
• Lista Wymagań Bezpieczeństwa Oprogramowania (SSR) i macierz identyfikowalności
• Raporty z Analizy Projektu Bezpieczeństwa Oprogramowania (Zadanie 206)
• Arkusze FMEA oprogramowania
• Przypadki testowe i wyniki testów oprogramowania krytycznego dla bezpieczeństwa
• Raporty pokrycia kodu modułów krytycznych dla bezpieczeństwa
• Protokoły przeglądów kodu modułów krytycznych dla bezpieczeństwa
• Raporty Decyzji o Ryzyku Zagrożenia (HRDR) dla zaakceptowanych ryzyk resztkowych
• Raport z Oceny Bezpieczeństwa (SAR)

Akceptacja ryzyka resztkowego to formalny akt, w którym organ akceptacji ryzyka potwierdza, że zagrożenie zostało sprowadzone do poziomu pozostającego powyżej akceptowalnego progu programu, przegląda dowody, że elementy kontroli są wystarczające i prawidłowo zaimplementowane, oraz przyjmuje odpowiedzialność za pozostałe ryzyko. Raport Decyzji o Ryzyku Zagrożenia jest instrumentem tego aktu. HRDR opisuje zagrożenie, zastosowane elementy kontroli, resztkowe HRI po zastosowaniu kontroli, dowody wspierające ocenę resztkowego HRI oraz rekomendację. Właściwy organ podpisuje HRDR, przekształcając go z rekomendacji w formalny zapis akceptacji ryzyka.

Uzasadnienie bezpieczeństwa jest dokumentem żywym. Za każdym razem, gdy oprogramowanie jest modyfikowane — zmieniają się wymagania, poprawiane są defekty, ewoluują interfejsy — uzasadnienie bezpieczeństwa trzeba przejrzeć, aby ustalić, czy zmiana wpływa na jakieś zagrożenie, SSR, element kontroli projektu lub pozycję dowodową. Zmiana zwiększająca prawdopodobieństwo lub ciężkość zaakceptowanego ryzyka resztkowego wymaga nowego HRDR podpisanego przez właściwy organ. Zmiana wprowadzająca nową przyczynę zagrożenia wymaga aktualizacji SwHA i potencjalnie nowego SSR. Zarządzanie konfiguracją artefaktów uzasadnienia bezpieczeństwa jest więc równie ważne jak zarządzanie konfiguracją kodu źródłowego — nieaktualne uzasadnienie bezpieczeństwa, które nie odzwierciedla bieżącej bazy konfiguracji oprogramowania, nie jest wcale uzasadnieniem bezpieczeństwa.

Najczęstszym trybem awarii programów bezpieczeństwa oprogramowania nie jest niewystarczająca analiza — lecz niewystarczające doprowadzenie spraw do końca. SwHA zostaje wykonane, SSR zostają napisane, elementy kontroli projektu zostają zaimplementowane, a potem planowanie testów przebiega bez systematycznego powiązania między SSR a przypadkami testowymi. Dane pokrycia zbiera się bez mapy odniesienia do modułów krytycznych dla bezpieczeństwa. FMEA powstaje po przeglądzie kodu, a nie przed nim. Efektem jest zbiór osobno prawdopodobnych artefaktów, które nie układają się w spójny argument. Zadanie skompletowania uzasadnienia bezpieczeństwa ujawnia te rozłączenia — a rozstrzygnięcie ich przed przeglądami programu, a nie w ich trakcie, stanowi różnicę między obronnym programem bezpieczeństwa a kosztownym cyklem przeróbek.