Dosar de siguranță software pentru sisteme militare MIL-STD-882

Un sistem care operează fără un dosar de siguranță software operează pe bază de încredere — încrederea că analiza pericolelor a fost completă, că controalele de proiectare sunt corecte și că dovezile de verificare sunt suficiente. Pentru un produs comercial, această încredere este apărabilă. Pentru un sistem militar ale cărui moduri de eșec includ eliberări de energie, pierderea platformei sau fratricidul, nu este. MIL-STD-882E, standardul Departamentului Apărării pentru Siguranța Sistemului, oferă procesul structurat prin care acea încredere este înlocuită cu dovezi documentate, revizuite și acceptate. Dosarul de siguranță software este artefactul care captează acele dovezi și formulează argumentul că riscul rezidual este acceptabil.

Acest articol este un ghid practic pentru construirea unui dosar de siguranță software conform MIL-STD-882E. Acoperă structura de sarcini a standardului și prevederile sale specifice software-ului, lanțul de analiză a pericolelor de la identificarea preliminară până la analiza pericolelor software (SwHA), derivarea Cerințelor de Siguranță Software (SSR) din cauzele de pericol, controalele de proiectare care implementează acele cerințe, dovezile de verificare care demonstrează implementarea lor corectă și procesul de acceptare a riscului care închide dosarul. Inginerii noi în programele de siguranță din apărare vor găsi aici o hartă a terenului; practicienii experimentați vor găsi o referință pentru ieșirile specifice și trasabilitatea așteptate de revizorii guvernamentali.

Prezentare MIL-STD-882E: siguranța sistemului de la concept la casare

MIL-STD-882E definește siguranța sistemului ca o abordare planificată și disciplinată de identificare și gestionare a pericolelor pe parcursul ciclului de viață al unui sistem — de la explorarea conceptului până la casare. Standardul își organizează cerințele în sarcini grupate în cinci categorii: Managementul și Controlul Programului, Cerințe de Proiectare, Susținabilitate, Instruire și Evaluări. Activitatea contractantă selectează sarcinile adecvate profilului de risc al programului și le specifică în Documentul de Lucru. Contractantul efectuează acele sarcini și livrează rezultatele ca elemente ale Listei de Cerințe de Date Contractuale.

Pentru sistemele militare intensiv software, cinci sarcini domină efortul de inginerie:

• Sarcina 205 — Analiza Cerințelor de Siguranță Software: identificarea tuturor funcțiilor software critice pentru siguranță și derivarea Cerințelor de Siguranță Software pentru controlul cauzelor de pericol identificate.
• Sarcina 206 — Analiza Proiectării de Siguranță Software: analiza proiectării software pentru a verifica că cerințele de siguranță sunt corect alocate și că deciziile de proiectare nu introduc cauze noi de pericol.
• Sarcina 301 — Evaluarea Siguranței: o evaluare condusă de repere privind acceptabilitatea riscului rezidual, documentată într-un Raport de Evaluare a Siguranței (SAR).
• Sarcina 302 — Siguranța Testării și Evaluării: asigurarea că controalele de siguranță sunt în vigoare înainte de orice activitate de testare care implică energie periculoasă sau moduri operaționale.
• Sarcina 303 — Revizuirile Programului de Siguranță a Sistemului: revizuirile formale la care Grupul de Lucru pentru Siguranța Sistemului (SSWG) prezintă starea pericolelor, elementele de risc deschise și dovezile eficacității controalelor către biroul de program.

Matricea de risc din centrul MIL-STD-882E trasează Severitatea față de Probabilitate. Severitatea merge de la Catastrofic (Categoria I: deces, pierderea sistemului, daune severe mediului) prin Critic (Categoria II: vătămare gravă, daune majore sistemului) și Marginal (Categoria III: vătămare minoră, daune minore sistemului) până la Neglijabil (Categoria IV: vătămare sau daune mai puțin decât minore). Probabilitatea merge de la Frecvent (probabil să apară des de-a lungul vieții sistemului) prin Probabil, Ocazional, Rar și Improbabil. Fiecare celulă din matricea rezultată de 4×5 poartă un Index de Risc al Pericolului (HRI) care determină cine trebuie să accepte riscul rezidual după aplicarea controalelor.

HRI-ul nu este un produs matematic — este o clasificare ordinală definită de matricea de risc a programului, pe care SSPP-ul o stabilește. Un pericol Catastrofic/Frecvent (HRI 1) necesită acceptarea de către Autoritatea de Decizie a Reperelor; un pericol Neglijabil/Improbabil (HRI 20) este acceptabil la nivelul grupului de lucru. Implicația practică pentru inginerii software este că produsele analizei pe care le produc — fișe de lucru de pericole, rânduri SwHA, SSR-uri, înregistrări de verificare — alimentează direct un proces de management al riscului cu niveluri de autoritate definite. Lipsurile din analiză lasă riscul la un nivel nedeterminat pe care nicio autoritate nu îl poate accepta.

Analiza preliminară a pericolelor: identificarea funcțiilor software critice pentru siguranță

Analiza Preliminară a Pericolelor (PHA) este efectuată devreme în dezvoltarea sistemului, de obicei înainte de finalizarea cerințelor detaliate, folosind descompunerea funcțională a sistemului și documentația conceptului operațional. Scopul său este identificarea pericolelor la nivel de sistem, atribuirea ratingurilor inițiale de severitate și probabilitate și identificarea funcțiilor sistemului — hardware, software, umane sau procedurale — care contribuie la fiecare pericol. PHA-ul nu necesită cunoștințe detaliate de proiectare; lucrează la nivelul „ce poate face acest sistem care ar putea dăuna oamenilor, echipamentelor sau mediului?”

Intrările PHA includ de obicei:

• Conceptul de operațiuni al sistemului (CONOPS) și scenariile operaționale
• Cerințele funcționale ale sistemului și arhitectura de nivel superior
• Inventarul surselor de energie și al materialelor periculoase
• Definițiile interfețelor (către sistemele adiacente, către operatori, către mediu)
• Date istorice despre pericole din sisteme similare

Ieșirile PHA includ un Jurnal de Pericole populat, cu identificatori unici de pericol, descrieri ale pericolelor în limbaj natural, ratinguri HRI inițiale și o listă a funcțiilor care contribuie. Pentru un sistem de control al focului, PHA-ul ar putea identifica „eliberarea neintenționată a armelor” ca pericol Catastrofic (Categoria I) și ar lista ca funcții care contribuie: software-ul de autorizare a angajării, canalul de comandă pentru eliberarea armelor, logica de interblocare a armării și interfața operatorului. Acea listă a funcțiilor care contribuie este punctul de intrare pentru toată analiza ulterioară de siguranță software.

Distincția dintre un pericol și un mod de eșec contează aici. Un pericol este o condiție cu potențial de vătămare — „eliberarea neintenționată a armelor” este un pericol. Un mod de eșec este un mecanism prin care o componentă poate funcționa defectuos — „asertarea falsă a ieșirii FIRE_COMMAND” este un mod de eșec. PHA-ul identifică pericolele; analizele ulterioare identifică modurile de eșec care contribuie la ele. Confundarea celor două în jurnalul de pericole este cea mai comună eroare structurală în analiza de siguranță de început de program și se propagă înainte în tabele SwHA greu de trasat.

Contribuția software-ului la pericolele sistemului este calitativ diferită de cea a hardware-ului. O componentă hardware are o rată de eșec fizică care poate fi estimată din date de teren sau testare accelerată. Defectele software sunt deterministe: date fiind intrări specifice, o funcție defectă produce întotdeauna ieșirea greșită. Software-ul nu se uzează și nu are un timp mediu între eșecuri semnificativ în același sens ca un releu sau o supapă. Probabilitatea atribuită unei contribuții software la un pericol este, prin urmare, o judecată privind probabilitatea ca software-ul să conțină un defect relevant pentru acel pericol, ponderată cu probabilitatea ca condițiile specifice de intrare care l-ar declanșa să apară în operare. Această judecată este informată de complexitatea software-ului, rigoarea procesului de dezvoltare și profunzimea testării — nu de date empirice de eșec.

Analiza pericolelor software: maparea software-ului pe pericole

Analiza Pericolelor Software (SwHA) este sarcina care conectează jurnalul de pericole la nivel de sistem la comportamentele software specifice. Pentru fiecare pericol din PHA care listează o funcție software ca și contribuitor, SwHA-ul întreabă: ce trebuie să facă greșit software-ul (sau să nu facă) pentru ca acest pericol să apară? Răspunsul enumeră modurile de eșec software, care devin lanțurile cauzale pe care SSR-urile trebuie să le abordeze.

Modurile de eșec software se încadrează în cinci categorii canonice:

• Ieșire incorectă: funcția se execută și produce o ieșire, dar valoarea ieșirii este greșită — o comandă în afara intervalului valid, un fanion de stare setat când ar trebui să fie șters, sau un rezultat de calcul cu o eroare aritmetică.
• Fără ieșire (omisiune): funcția nu reușește să producă o ieșire de care sistemul depinde — un watchdog care se oprește din resetare, un monitor de sănătate care nu raportează o defecțiune, o interblocare de siguranță care nu asertează semnalul de inhibare.
• Ieșire întârziată: funcția produce ieșirea corectă, dar nu în fereastra de timp cerută — o încălcare a constrângerii de timp real care face ca sistemul să procezeze cu o intrare învechită sau absentă.
• Ieșire falsă: funcția produce o ieșire care nu a fost cerută sau care apare la un moment în care nu este validă — o comandă nesolicitată care declanșează un actuator într-un mod în care comanda respectivă este periculoasă.
• Ieșire către destinația greșită: funcția direcționează o ieșire validă către o interfață incorectă — o comandă destinată unui subsistem este livrată altuia din cauza unei erori de rutare sau de adresare.

Structura fișei de lucru SwHA urmează un tipar standard. Fiecare rând corespunde unui triplu (pericol, funcție software, mod de eșec). Coloanele înregistrează identificatorul pericolului, descrierea pericolului, numele funcției software, categoria modului de eșec, efectul modului de eșec asupra pericolului de sistem, severitatea vătămării rezultate, probabilitatea (ca evaluare calitativă), HRI-ul și identificatorul SSR derivat care abordează acest rând. Un tabel SwHA pentru un sistem de control al zborului ar putea avea câteva sute de rânduri; pentru un terminal de comandă și control mai simplu, poate treizeci până la șaizeci.

Trasabilitatea este metrica operațională a calității SwHA. Fiecare pericol PHA cu contribuție software trebuie să apară în SwHA. Fiecare funcție software listată în PHA trebuie să aibă cel puțin un rând SwHA. Fiecare rând SwHA trebuie să se lege de cel puțin un SSR. Și fiecare SSR trebuie să se trasă înapoi la cel puțin un rând SwHA. Lipsurile de trasabilitate descoperite în timpul revizuirilor guvernamentale de siguranță sunt cea mai comună cauză a re-lucrării SwHA în ciclul de revizuire.

SwHA-ul identifică, de asemenea, cerințe software care servesc funcții de siguranță nu pentru că previn direct un pericol, ci pentru că permit unui monitor de siguranță să detecteze un precursor al pericolului. Aceste cerințe de monitorizare sunt la fel de importante ca cerințele de control direct — un monitor care eșuează silențios elimină capacitatea sistemului de a trece la starea sigură înainte de apariția unui pericol. Ele necesită aceeași formulare SSR și aceeași rigoare de verificare ca cerințele de inhibare directă. Consultați și: verificarea formală pentru software-ul de apărare pentru tehnici care pot demonstra matematic absența unor moduri de eșec specifice în modulele critice pentru siguranță.

Identificarea funcțiilor critice pentru siguranță și Cerințele de Siguranță Software

O funcție software critică pentru siguranță este orice funcție al cărei mod de eșec apare în SwHA ca și contribuitor la un pericol Catastrofic sau Critic. Identificarea funcțiilor critice pentru siguranță este precondiția pentru alocarea unei rigori suplimentare de proiectare: ținte mai mari de acoperire a codului, revizuire obligatorie de către colegi, verificare independentă și analiză formală.

Indexul de Criticitate Software (SCI) formalizează acest lucru. Fiecare funcție critică pentru siguranță primește o categorie de criticitate pe baza consecinței în cel mai rău caz al eșecului său: Categoria I (Catastrofică), Categoria II (Critică), Categoria III (Marginală), Categoria IV (Neglijabilă). SCI-ul conduce selecția cerințelor de siguranță software și profunzimea verificării aplicate fiecărei funcții. O funcție de Categoria I — de exemplu, verificarea finală de autorizare înainte de o comandă de eliberare a armelor — justifică cel mai riguros tratament pe care programul îl poate aplica. O funcție de Categoria IV — un scriitor de jurnal de diagnostic — nu justifică niciuna dintre rigorile suplimentare.

Cerințele de Siguranță Software (SSR) sunt derivate direct din rândurile SwHA. Pentru fiecare mod de eșec identificat, SSR-ul specifică comportamentul software care previne, detectează sau atenuează acel mod de eșec. Formele canonice de SSR sunt:

• Constrângere pozitivă: „Software-ul va aserta ieșirea SAFE_STATE în maximum 50 ms de la detectarea pierderii semnalului de validitate de la senzorul principal.” (Abordează: modul de eșec de tip ieșire întârziată/absentă în funcția de monitorizare a senzorului.)
• Constrângere negativă: „Software-ul nu va aserta WEAPONS_RELEASE_COMMAND decât dacă ARM_CONFIRMED, TARGET_VALIDATED și OPERATOR_AUTHORIZED au fost toate asertate continuu cel puțin 500 ms.” (Abordează: modul de eșec de tip ieșire falsă în funcția de autorizare a eliberării.)
• Constrângere de interval: „Ieșirea de azimut comandată va fi în intervalul de ±180 grade. Orice valoare calculată în afara acestui interval va face ca software-ul să intre în starea FAULT_HOLD fără a emite comanda.” (Abordează: modul de eșec de tip ieșire incorectă în funcția de calcul al controlului focului.)
• Cerință de monitorizare: „Software-ul va compara tracțiunea comandată cu tracțiunea măsurată la fiecare ciclu de 10 ms și va seta THRUST_FAULT_FLAG dacă diferența depășește 15% pentru trei cicluri consecutive.” (Permite detectarea precursorilor de pericol.)

Fiecare SSR este marcat cu un identificator unic (de exemplu, SSR-FC-007), alocat unei componente software specifice din arhitectură și introdus în matricea de trasabilitate care îl leagă de rândurile SwHA părinte. În timpul proiectării detaliate, fiecare SSR trebuie să fie alocat în continuare unei cerințe specifice din Specificația Cerințelor Software (SRS) sau Documentul de Proiectare Software (SDD). Cerința SRS/SDD moștenește marcajul SSR, permițând instrumentelor automate de trasabilitate să propage desemnarea de siguranță prin ierarhia cerințelor și în selecția cazurilor de test.

SSR-urile care nu pot fi verificate prin test sau analiză sunt indicatori ai unei probleme de arhitectură. Dacă comportamentul de siguranță nu poate fi confirmat independent, fie arhitectura software nu expune starea relevantă pentru observare, fie SSR-ul este formulat în termeni care nu sunt măsurabili. Ambele probleme necesită rezolvare înainte ca proiectarea să avanseze spre implementare. Un SSR fără o metodă de verificare fezabilă nu este un control de siguranță — este o declarație de intenție.

Controale de proiectare software pentru siguranță

Controalele de proiectare sunt tiparele arhitecturale și de implementare care fac ca comportamentele software cerute de SSR-uri să fie fiabile în prezența defectelor. Fiecare control de proiectare este selectat pe baza modului de eșec pe care îl abordează și a severității consecinței acelui mod de eșec. Nu există un tipar universal — controlul adecvat depinde de arhitectura sistemului și de cauza specifică de pericol care este atenuată.

Tiparele cel mai larg aplicabile în software-ul militar sunt:

Supraveghere prin watchdog. Un watchdog hardware sau software independent cere aplicației critice pentru siguranță să aserteze activ un semnal de resetare la fiecare ciclu de procesare. Neasertarea resetării — fie pentru că aplicația s-a prăbușit, a intrat într-o buclă infinită sau a devenit altfel non-responsivă — face ca watchdog-ul să expire și să forțeze o tranziție către starea sigură. Starea sigură este definită de hardware: dezenergizarea ieșirilor, setarea inhibărilor, închiderea supapelor. Watchdog-ul nu are nevoie să înțeleagă de ce a eșuat aplicația; trebuie doar să știe că operarea normală a încetat.

Secvențe de armare pozitivă. Comenzile periculoase necesită ca mai multe condiții de activare independente să fie îndeplinite simultan înainte ca comanda să poată fi emisă. Niciun defect software singular, nicio defecțiune de senzor singulară și nicio eroare de operator singulară nu pot îndeplini toate condițiile simultan. Exemplul clasic este o secvență de armare și eliberare a armelor: armarea necesită un circuit hardware separat de armare, o stare de autorizare software, o condiție de proximitate sau de țintire și o confirmare a operatorului, toate într-o fereastră de timp. Eliminarea oricăreia dintre acestea elimină capacitatea de a trage.

Mașini de stări fail-safe. Logica de control critică pentru siguranță este implementată ca o mașină de stări finită explicită, cu o stare implicită sigură definită. Fiecare intrare care ar cauza o tranziție de stare invalidă este mapată la starea sigură, nu la un comportament nedefinit. Mașina de stări este proiectată astfel încât pierderea alimentării, pierderea comunicațiilor sau pierderea validității senzorului să convertească toate spre starea sigură — nu există nicio cale dintr-o stare de defecțiune către o comandă periculoasă. Luați în considerare un exemplu simplificat pentru un controler de interblocare:

Monitorizarea plauzibilității. Un proces de monitorizare independent compară comenzile de ieșire cu constrângerile fizice. O accelerație comandată care depășește capacitatea maximă documentată a vehiculului este implauzibilă și poate indica o eroare de calcul sau o intrare coruptă. Monitorul interceptează și blochează comanda implauzibilă, jurnalizează evenimentul și alertează sistemul de management al sănătății. Logica de monitorizare trebuie să fie independentă de logica de calcul — dacă ambele folosesc același algoritm, un defect sistematic afectează identic ambele, iar monitorul nu oferă nicio protecție.

Validare defensivă a intrărilor. Fiecare funcție critică pentru siguranță își validează intrările față de intervalele valide definite înainte de a le procesa. Intrările în afara intervalului valid nu cauzează calculul pe date invalide — determină funcția să aserteze o condiție de defecțiune și să intre într-o cale definită de gestionare a erorilor. Logica de validare trebuie să acopere nu doar verificările de interval, ci și validitatea temporală (este aceasta cea mai recentă valoare eșantionată sau o citire învechită?), validitatea sursei (a venit această valoare de la expeditorul așteptat?) și consistența (este de acord această valoare cu senzorii de coroborare în toleranță?).

Fiecare control de proiectare este documentat în Documentul de Proiectare Software cu o referință încrucișată explicită către SSR-ul pe care îl implementează. Procesul de revizuire a proiectării include o verificare că fiecare SSR are un control de proiectare identificat și că fiecare control de proiectare este justificat ca adecvat pentru modul de eșec pe care îl abordează. Controalele adecvate pentru pericolele Marginale pot să nu fie adecvate pentru cele Critice — argumentul de adecvare trebuie să fie specific severității consecinței.

Dovezi de verificare a siguranței

Dovezile de verificare a siguranței sunt setul de înregistrări care demonstrează că fiecare SSR este implementat corect în software-ul livrat. Baza de dovezi trebuie să fie suficientă pentru un revizor calificat — inginerul guvernamental de siguranță, comisia de revizuire a siguranței sau autoritatea de acceptare a riscului — pentru a concluziona că software-ul se comportă așa cum susține dosarul de siguranță. Dovada care este prezentă, dar netrasabilă la SSR-uri, sau trasabilă la SSR-uri, dar insuficientă pentru a demonstra implementarea lor, nu închide dosarul de siguranță.

Tipurile principale de dovezi pentru verificarea siguranței software sunt:

Cazuri de test specifice siguranței. Pentru fiecare SSR, se derivă unul sau mai multe cazuri de test care exercită direct comportamentul cerut. Cazurile de test sunt construite din modurile de eșec SwHA: dacă rândul SwHA identifică „asertarea falsă a FIRE_COMMAND în modul SAFE” ca o cauză de pericol, cazul de test corespunzător aplică condițiile specifice de intrare care ar fi necesare pentru a declanșa acest comportament și verifică că ieșirea nu este asertată. Testarea pentru absența comportamentului periculos este mai exigentă decât testarea pentru prezența comportamentului corect — inginerul de test trebuie să raționeze despre toate căile de intrare care ar putea ajunge la funcția de siguranță și să confirme că niciuna nu produce o ieșire periculoasă.

Acoperirea codului pentru modulele critice pentru siguranță. Metricile de acoperire oferă încrederea că suita de teste exercită căile de cod care implementează SSR-urile. Ținta de acoperire pentru modulele critice pentru siguranță (funcțiile de Categoria I și II conform SCI) este de obicei acoperirea 100% a ramurilor ca minim, cu Acoperirea Condiției/Deciziei Modificate (MC/DC) cerută pentru funcțiile care implementează logică de autorizare cu condiții multiple. Un raport de acoperire a ramurilor care arată ramuri netestate într-un modul critic pentru siguranță este o constatare deschisă — fie ramura netestată este cod mort care trebuie eliminat, fie un caz de test lipsește. Datele de acoperire fără o hartă de trasabilitate SSR corespunzătoare nu constituie dovadă de verificare a siguranței — dovada este în legătura dintre codul acoperit și SSR-urile pe care acel cod le implementează. Consultați și: testarea software-ului pentru sisteme militare pentru o tratare completă a metodologiei de testare pentru programele de apărare.

FMEA software. O Analiză a Modurilor de Eșec și a Efectelor (FMEA) software aplică metodologia FMEA modulelor software, nu componentelor hardware. Pentru fiecare funcție dintr-un modul critic pentru siguranță, FMEA-ul înregistrează: scopul funcției, modurile de eșec (folosind cele cinci categorii canonice din SwHA), efectul fiecărui mod de eșec asupra ieșirii software, efectul asupra pericolului de sistem, mecanismul de detectare (watchdog, monitor, test, observația operatorului) și controlul compensatoriu din proiectare. FMEA-ul software este cel mai valoros ca verificare încrucișată a SwHA — dacă FMEA-ul identifică un mod de eșec cu consecințe periculoase care nu apare în SwHA, fie SwHA-ul are o lipsă, fie FMEA-ul are un fals pozitiv care trebuie judecat. Ambele rezultate îmbunătățesc dosarul de siguranță.

Înregistrări de revizuire a codului. Revizuirea de către colegi a codului critic pentru siguranță, folosind o listă de verificare specifică siguranței, generează dovada că ingineri calificați au examinat implementarea pentru conformitate cu SSR-urile și controalele de proiectare. Elementele listei de verificare ar trebui să se mapăze direct pe tiparele de proiectare cerute — „resetarea watchdog-ului este apelată la fiecare ciclu”, „toate intrările sunt validate înainte de utilizare”, „mașina de stări nu are tranziții nedefinite”. Înregistrările de revizuire identifică defectele găsite și dispozițiile lor; o revizuire cu zero constatări pe un modul complex critic pentru siguranță este fie un indiciu al unei implementări excepțional de curate, fie al unui proces de revizuire insuficient de riguros, iar inginerul de siguranță al programului ar trebui să poată face diferența între cele două.

Integrarea acestor tipuri de dovezi în DevSecOps pentru conducte de apărare necesită ca cazurile de test critice pentru siguranță, instrumentele de acoperire și fișele de lucru FMEA să fie controlate prin configurație alături de codul sursă pe care îl verifică. Un rezultat de test fără o bază de configurație care identifică exact ce versiune a software-ului a fost testată nu este dovadă reproductibilă și nu poate fi transmisă într-un Pachet de Date de Siguranță. Fiecare artefact de dovadă necesită un număr de document, o revizie, o dată și o legătură cu baza elementului de configurație software pe care o acoperă.

Asamblarea dosarului de siguranță și acceptarea riscului rezidual

Dosarul de siguranță este un argument structurat că sistemul software livrat este acceptabil de sigur pentru utilizarea prevăzută. Nu susține că software-ul este lipsit de defecte sau că tot riscul a fost eliminat — astfel de revendicări nu sunt realizabile și nu sunt ceea ce cere MIL-STD-882E. El susține că: toate pericolele rezonabil previzibile au fost identificate; au fost aplicate controale care reduc fiecare pericol la un nivel de risc acceptabil; controalele au fost verificate ca fiind corect implementate; și riscurile reziduale care rămân după aplicarea controalelor au fost revizuite și acceptate de autoritatea corespunzătoare.

Structura documentului de dosar de siguranță urmează o ierarhie de tip revendică-argument-dovezi. Goal Structuring Notation (GSN) este folosită frecvent pentru a vizualiza această ierarhie, deși notația nu este obligatorie — structura trebuie să fie prezentă indiferent dacă este exprimată în formă GSN. O structură tipică de nivel superior pentru un dosar de siguranță software al unui sistem de control al focului:

Pachetul de Date de Siguranță (SDP) este colecția de artefacte livrate biroului de program ca dovadă pentru dosarul de siguranță. Conținutul său este specificat în Planul Programului de Siguranță a Sistemului ca o listă de CDRL-uri cu date de livrare legate de reperele programului. Conținut tipic al SDP-ului:

• Planul Programului de Siguranță a Sistemului (SSPP)
• Raportul Analizei Preliminare a Pericolelor (PHA)
• Rapoartele Analizei Pericolelor la nivel de Subsistem (SSHA)
• Fișele de lucru ale Analizei Pericolelor Software (SwHA)
• Lista Cerințelor de Siguranță Software (SSR) și matricea de trasabilitate
• Rapoartele Analizei Proiectării de Siguranță Software (Sarcina 206)
• Fișele de lucru FMEA software
• Cazurile de test și rezultatele testelor pentru software-ul critic pentru siguranță
• Rapoartele de acoperire a codului pentru modulele critice pentru siguranță
• Înregistrările de revizuire a codului pentru modulele critice pentru siguranță
• Rapoartele de Decizie privind Risc Pericolului (HRDR) pentru riscurile reziduale acceptate
• Raportul de Evaluare a Siguranței (SAR)

Acceptarea riscului rezidual este actul formal prin care autoritatea de acceptare a riscului recunoaște că un pericol a fost controlat la un nivel care rămâne peste pragul acceptabil al programului, revizuiește dovezile că controalele sunt adecvate și corect implementate și își asumă responsabilitatea pentru riscul rămas. Raportul de Decizie privind Risc Pericolului este instrumentul pentru acest act. HRDR-ul descrie pericolul, controalele aplicate, HRI-ul rezidual după controale, dovezile care susțin evaluarea HRI-ului rezidual și o recomandare. Autoritatea corespunzătoare semnează HRDR-ul, transformându-l dintr-o recomandare într-o înregistrare formală de acceptare a riscului.

Dosarul de siguranță este un document viu. De fiecare dată când software-ul este modificat — cerințele se schimbă, defectele sunt corectate, interfețele evoluează — dosarul de siguranță trebuie revizuit pentru a stabili dacă modificarea afectează vreun pericol, SSR, control de proiectare sau element de dovadă. O modificare care crește probabilitatea sau severitatea unui risc rezidual acceptat necesită un nou HRDR semnat de autoritatea competentă. O modificare care introduce o cauză nouă de pericol necesită o actualizare SwHA și, eventual, un nou SSR. Gestionarea configurației artefactelor dosarului de siguranță este la fel de importantă ca gestionarea configurației codului sursă — un dosar de siguranță învechit, care nu reflectă linia de bază software curentă, nu este deloc un dosar de siguranță.

Cel mai frecvent mod de eșec al programelor de siguranță software nu este analiza inadecvată — ci urmărirea inadecvată. SwHA este realizat, SSR-urile sunt scrise, controalele de proiectare sunt implementate, iar apoi planificarea testelor decurge fără o legătură sistematică între SSR și cazurile de testare. Datele de acoperire sunt colectate fără o hartă către modulele critice pentru siguranță. FMEA este scrisă după examinarea codului, nu înaintea acesteia. Rezultatul este o colecție de artefacte plauzibile individual, care nu se compun într-un argument coerent. Sarcina de asamblare a dosarului de siguranță este momentul în care aceste deconectări devin vizibile — și tratarea lor înainte de evaluările de program, nu în timpul acestora, face diferența între un program de siguranță apărabil și un ciclu costisitor de refacere.