Побудова обґрунтування безпеки ПЗ військових систем за MIL-STD-882

Система, що працює без обґрунтування безпеки ПЗ (software safety case), працює на довірі — довірі до того, що аналіз небезпек був повним, що проєктні засоби контролю коректні, а докази верифікації достатні. Для комерційного продукту така довіра виправдана. Для військової системи, режими відмови якої включають вивільнення енергії, втрату платформи або ураження своїх військ, — ні. MIL-STD-882E, стандарт Міністерства оборони США з безпеки систем (System Safety), надає структурований процес, за допомогою якого цю довіру замінюють задокументованими, перевіреними та прийнятими доказами. Обґрунтування безпеки ПЗ — це артефакт, що фіксує ці докази й подає аргумент, що залишковий ризик є прийнятним.

Ця стаття — практичний посібник із побудови обґрунтування безпеки ПЗ за MIL-STD-882E. Вона охоплює структуру завдань стандарту та його положення, специфічні для ПЗ, ланцюг аналізу небезпек від попередньої ідентифікації до аналізу програмних небезпек (SwHA), виведення вимог безпеки ПЗ (SSR) із причин небезпек, проєктні засоби контролю, що реалізують ці вимоги, докази верифікації, які демонструють їх коректну реалізацію, і процес прийняття ризику, що завершує обґрунтування. Інженери, нові в оборонних програмах безпеки, знайдуть у ній карту місцевості; досвідчені практики — довідник щодо конкретних результатів і простежуваності, яких очікують державні рецензенти.

Огляд MIL-STD-882E: безпека системи від концепції до утилізації

MIL-STD-882E визначає безпеку системи як запланований, дисциплінований підхід до ідентифікації небезпек і керування ними впродовж усього життєвого циклу системи — від дослідження концепції до утилізації. Стандарт організовує свої вимоги в завдання, згруповані в п'ять категорій: керування програмою та контроль (Program Management and Control), вимоги до проєкту (Design Requirements), підтримуваність (Supportability), навчання (Training) та оцінювання (Assessments). Замовник за контрактом обирає завдання, що відповідають профілю ризику програми, і зазначає їх у технічному завданні (Statement of Work). Підрядник виконує ці завдання й передає результати як позиції переліку вимог до даних за контрактом (Contract Data Requirements List).

Для військових систем з інтенсивним використанням ПЗ інженерні зусилля зосереджені переважно на п'яти завданнях:

• Task 205 — аналіз вимог безпеки ПЗ (Software Safety Requirements Analysis): ідентифікація всіх критичних для безпеки функцій ПЗ і виведення вимог безпеки ПЗ для контролю виявлених причин небезпек.
• Task 206 — аналіз проєктних рішень безпеки ПЗ (Software Safety Design Analysis): аналіз проєкту ПЗ, щоб перевірити, що вимоги безпеки коректно розподілені й що проєктні рішення не вносять нових причин небезпек.
• Task 301 — оцінка безпеки (Safety Assessment): оцінка, прив'язана до етапів програми, того, чи є залишковий ризик прийнятним, що документується у звіті з оцінки безпеки (Safety Assessment Report, SAR).
• Task 302 — безпека під час випробувань і оцінювання (Test and Evaluation Safety): забезпечення наявності засобів контролю безпеки до початку будь-якої випробувальної діяльності, пов'язаної з небезпечною енергією чи небезпечними режимами роботи.
• Task 303 — огляди програми безпеки системи (System Safety Program Reviews): офіційні огляди, на яких робоча група з безпеки системи (System Safety Working Group, SSWG) доповідає програмному офісу про стан небезпек, відкриті питання ризику та докази ефективності засобів контролю.

Матриця ризиків, що лежить в основі MIL-STD-882E, співвідносить тяжкість з імовірністю. Тяжкість простягається від катастрофічної (Catastrophic; Категорія I: загибель людей, втрата системи, значна шкода довкіллю) через критичну (Critical; Категорія II: тяжка травма, значне пошкодження системи) і помірну (Marginal; Категорія III: легка травма, незначне пошкодження системи) до незначної (Negligible; Категорія IV: менше ніж легка травма чи пошкодження). Імовірність простягається від частої (Frequent; ймовірно, виникатиме часто протягом життя системи) через ймовірну (Probable), випадкову (Occasional), віддалену (Remote) до малоймовірної (Improbable). Кожна комірка отриманої матриці 4×5 містить індекс ризику небезпеки (Hazard Risk Index, HRI), який визначає, хто має прийняти залишковий ризик після застосування засобів контролю.

HRI — не математичний добуток, а порядковий ранг, що визначається матрицею ризиків програми, яку встановлює SSPP. Катастрофічна/часта небезпека (HRI 1) потребує прийняття Milestone Decision Authority; незначна/малоймовірна небезпека (HRI 20) прийнятна на рівні робочої групи. Практичний висновок для інженерів ПЗ: аналітичні продукти, які вони створюють, — таблиці небезпек, рядки SwHA, SSR, записи верифікації — безпосередньо живлять процес керування ризиками з визначеними рівнями повноважень. Прогалини в аналізі залишають ризик на невизначеному рівні, який жоден орган не може прийняти.

Попередній аналіз небезпек: пошук критичних для безпеки функцій ПЗ

Попередній аналіз небезпек (Preliminary Hazard Analysis, PHA) виконують на ранньому етапі розроблення системи, зазвичай до остаточного затвердження детальних вимог, використовуючи функціональну декомпозицію системи та документацію концепції застосування. Його мета — ідентифікувати небезпеки на системному рівні, призначити початкові оцінки тяжкості й ймовірності та визначити, які функції системи — апаратні, програмні, людські чи процедурні — сприяють кожній небезпеці. PHA не потребує докладного знання проєкту; він працює на рівні запитання: «що ця система може робити такого, що могло б завдати шкоди людям, обладнанню чи довкіллю?».

Вхідні дані PHA зазвичай включають:

• Концепцію застосування системи (CONOPS) та оперативні сценарії
• Функціональні вимоги до системи та архітектуру верхнього рівня
• Джерела енергії та перелік небезпечних матеріалів
• Визначення інтерфейсів (із суміжними системами, з операторами, із довкіллям)
• Історичні дані про небезпеки аналогічних систем

Результати PHA включають заповнений журнал небезпек з унікальними ідентифікаторами небезпек, описами небезпек природною мовою, початковими оцінками HRI та переліком функцій, що сприяють небезпеці. Для системи керування вогнем PHA може визначити «Ненавмисне вивільнення озброєння» як катастрофічну небезпеку (Категорія I) і назвати як функції, що їй сприяють: ПЗ авторизації ураження цілі, канал команди на вивільнення озброєння, логіку блокування взведення та інтерфейс оператора. Цей перелік функцій, що сприяють небезпеці, є точкою входу для всього подальшого аналізу безпеки ПЗ.

Тут важливо розрізняти небезпеку та режим відмови. Небезпека — це умова з потенціалом заподіяння шкоди: «ненавмисне вивільнення озброєння» є небезпекою. Режим відмови — це механізм, за яким компонент може вийти з ладу: «хибна активація виходу FIRE_COMMAND» є режимом відмови. PHA ідентифікує небезпеки; подальші аналізи ідентифікують режими відмови, що сприяють їм. Змішування цих двох понять у журналі небезпек — найпоширеніша структурна помилка в аналізі безпеки на ранніх етапах програми, і вона переходить далі в таблиці SwHA, які важко простежувати.

Внесок ПЗ в системні небезпеки якісно відрізняється від внеску апаратури. Апаратний компонент має фізичну інтенсивність відмов, яку можна оцінити за польовими даними або прискореними випробуваннями. Дефекти ПЗ детерміновані: за конкретних вхідних даних дефектна функція завжди видає неправильний результат. ПЗ не зношується й не має значущого середнього часу між відмовами в тому самому сенсі, що реле чи клапан. Тому ймовірність, що призначається внеску ПЗ в небезпеку, — це судження про ймовірність того, що ПЗ містить дефект, релевантний цій небезпеці, зважене на ймовірність того, що конкретні вхідні умови, які його спровокують, виникнуть в експлуатації. Це судження ґрунтується на складності ПЗ, ретельності процесу розробки та глибині тестування, а не на емпіричних даних про відмови.

Аналіз програмних небезпек: зіставлення ПЗ з небезпеками

Аналіз програмних небезпек (SwHA) — завдання, що пов'язує журнал небезпек системного рівня з конкретною поведінкою ПЗ. Для кожної небезпеки в PHA, серед причетних функцій якої названо функцію ПЗ, SwHA ставить запитання: що ПЗ має зробити неправильно (або чого не зробити), щоб ця небезпека виникла? Відповідь перелічує режими відмови ПЗ, які стають причинно-наслідковими ланцюгами, що їх мають охоплювати SSR.

Режими відмови ПЗ поділяються на п'ять канонічних категорій:

• Некоректний вихід: функція виконується й видає вихідне значення, але воно неправильне — команда за межами допустимого діапазону, прапорець стану, встановлений тоді, коли його слід було скинути, або результат обчислення з арифметичною помилкою.
• Відсутній вихід (пропуск): функція не формує вихід, від якого залежить система, — сторожовий таймер, який більше не скидається, монітор справності, що не повідомляє про несправність, запобіжне блокування, що не активує сигнал заборони (inhibit).
• Запізнілий вихід: функція формує правильний вихід, але не в межах потрібного часового вікна — порушення обмеження реального часу, через яке система продовжує роботу із застарілими або відсутніми вхідними даними.
• Хибний вихід: функція формує вихід, який не запитувався або який з'являється тоді, коли він недійсний, — неініційована команда, що запускає виконавчий механізм у режимі, де ця команда небезпечна.
• Вихід не за призначенням: функція спрямовує дійсний вихід на неправильний інтерфейс — команда, призначена для однієї підсистеми, доставляється іншій через помилку маршрутизації чи адресації.

Структура таблиці SwHA відповідає стандартному шаблону. Кожен рядок відповідає одній трійці (небезпека, функція ПЗ, режим відмови). Стовпці фіксують ідентифікатор небезпеки, опис небезпеки, назву функції ПЗ, категорію режиму відмови, вплив режиму відмови на системну небезпеку, тяжкість отриманої шкоди, ймовірність (як якісну оцінку), HRI та виведений ідентифікатор SSR, що стосується цього рядка. Таблиця SwHA для системи керування польотом може мати кілька сотень рядків; для простішого термінала командування й управління — можливо, від тридцяти до шістдесяти.

Простежуваність — операційна метрика якості SwHA. Кожна небезпека PHA з внеском ПЗ має бути присутня в SwHA. Кожна функція ПЗ, зазначена в PHA, має мати щонайменше один рядок SwHA. Кожен рядок SwHA має бути пов'язаний щонайменше з однією SSR. І кожна SSR має простежуватися назад щонайменше до одного рядка SwHA. Прогалини в простежуваності, виявлені під час державних оглядів безпеки, — найпоширеніша причина доопрацювання SwHA в циклі огляду.

SwHA також виявляє вимоги до ПЗ, які виконують функції безпеки не тому, що безпосередньо запобігають небезпеці, а тому, що дають змогу монітору безпеки виявити передвісник небезпеки. Ці вимоги моніторингу так само важливі, як і вимоги прямого контролю: монітор, що відмовляє мовчки, позбавляє систему здатності перейти в безпечний стан до виникнення небезпеки. Вони потребують такого самого формулювання SSR і такої самої суворості верифікації, як і вимоги прямого блокування. Див. також: формальна верифікація для оборонного ПЗ — методи, що можуть математично довести відсутність конкретних режимів відмови в критичних для безпеки модулях.

Ідентифікація критичних для безпеки функцій і вимоги безпеки ПЗ

Критична для безпеки функція ПЗ — це будь-яка функція, режим відмови якої фігурує в SwHA як чинник катастрофічної або критичної небезпеки. Ідентифікація критичних для безпеки функцій є передумовою для запровадження додаткової суворості проєктування: вищих цільових показників покриття коду, обов'язкового рецензування, незалежної верифікації та формального аналізу.

Індекс критичності ПЗ (Software Criticality Index, SCI) формалізує це. Кожній критичній для безпеки функції присвоюється категорія критичності на основі найгіршого наслідку її відмови: Категорія I (катастрофічна), Категорія II (критична), Категорія III (помірна), Категорія IV (незначна). SCI визначає вибір вимог безпеки ПЗ і глибину верифікації, що застосовується до кожної функції. Функція Категорії I — скажімо, остаточна перевірка авторизації перед командою на вивільнення озброєння — заслуговує на найсуворіший підхід, який програма може застосувати. Функція Категорії IV — запис діагностичного журналу — не потребує жодного з додаткових рівнів суворості.

Вимоги безпеки ПЗ (SSR) виводяться безпосередньо з рядків SwHA. Для кожного виявленого режиму відмови SSR визначає поведінку ПЗ, що запобігає цьому режиму відмови, виявляє його або пом'якшує. Канонічні форми SSR такі:

• Позитивне обмеження: «ПЗ повинно активувати вихід SAFE_STATE протягом 50 мс після виявлення втрати чинного сигналу heartbeat від основного сенсора.» (Стосується: режиму відмови із запізнілим або відсутнім виходом у функції моніторингу сенсора.)
• Негативне обмеження: «ПЗ не повинно активувати WEAPONS_RELEASE_COMMAND, доки ARM_CONFIRMED, TARGET_VALIDATED і OPERATOR_AUTHORIZED усі не утримувалися активними безперервно щонайменше 500 мс.» (Стосується: режиму відмови із хибним виходом у функції авторизації вивільнення.)
• Обмеження діапазону: «Заданий вихід азимута повинен бути в межах ±180 градусів. Будь-яке обчислене значення за межами цього діапазону повинно змусити ПЗ перейти у стан FAULT_HOLD без видачі команди.» (Стосується: режиму відмови з некоректним виходом у функції обчислень керування вогнем.)
• Вимога моніторингу: «ПЗ повинно порівнювати задану тягу з виміряною в кожному 10-мілісекундному циклі й встановлювати THRUST_FAULT_FLAG, якщо різниця перевищує 15 % упродовж трьох послідовних циклів.» (Забезпечує виявлення передвісників небезпеки.)

Кожна SSR позначається унікальним ідентифікатором (наприклад, SSR-FC-007), розподіляється за конкретним програмним компонентом в архітектурі та вноситься до матриці простежуваності, що пов'язує її з батьківськими рядками SwHA. Під час детального проєктування кожну SSR слід далі розподілити на конкретну вимогу в специфікації вимог до ПЗ (Software Requirements Specification, SRS) або документі проєктування ПЗ (Software Design Document, SDD). Вимога SRS/SDD успадковує тег SSR, що дає змогу автоматизованим засобам простежуваності поширювати позначку безпеки по ієрархії вимог і далі на добір тестових випадків.

SSR, які неможливо верифікувати випробуванням чи аналізом, свідчать про архітектурну проблему. Якщо поведінку безпеки не можна незалежно підтвердити, то або архітектура ПЗ не відкриває відповідного стану для спостереження, або SSR сформульована в невимірюваних термінах. Обидві проблеми потребують вирішення до того, як проєктування перейде до реалізації. SSR без здійсненного методу верифікації не є засобом контролю безпеки — це лише декларація намірів.

Проєктні засоби контролю ПЗ для безпеки

Проєктні засоби контролю — це архітектурні та реалізаційні патерни, що роблять поведінку ПЗ, потрібну за SSR, надійною за наявності несправностей. Кожен проєктний засіб контролю обирають залежно від режиму відмови, якого він стосується, і тяжкості наслідків цього режиму відмови. Універсального патерну немає — належний засіб контролю залежить від архітектури системи та конкретної причини небезпеки, яку зменшують.

Найширше застосовні патерни у військовому ПЗ такі:

Нагляд сторожового таймера (watchdog). Апаратний або незалежний програмний сторожовий таймер вимагає від критичного для безпеки застосунку активно подавати сигнал скидання в кожному циклі обробки. Неподання сигналу скидання — чи то через збій застосунку, чи то через входження в нескінченний цикл, чи то через іншу втрату відгуку — призводить до спрацювання тайм-ауту сторожового таймера й примусового переходу в безпечний стан. Безпечний стан визначається апаратно: знеструмлення виходів, встановлення блокувань, закриття клапанів. Сторожовому таймеру не потрібно розуміти, чому застосунок відмовив; йому достатньо знати, що нормальна робота припинилася.

Послідовності позитивного взведення. Небезпечні команди вимагають одночасного виконання кількох незалежних умов дозволу, перш ніж команду можна буде видати. Жодна одинична програмна несправність, відмова одного сенсора чи помилка одного оператора не може одночасно задовольнити всі умови. Класичний приклад — послідовність взведення та вивільнення озброєння: взведення вимагає окремого апаратного кола взведення, стану програмної авторизації, умови близькості або наведення та підтвердження оператора, усього — в межах часового вікна. Усунення будь-якої з цих умов позбавляє можливості вести вогонь.

Відмовобезпечні автомати станів. Критична для безпеки логіка керування реалізується як явний скінченний автомат із визначеним безпечним станом за замовчуванням. Кожен вхід, що спричинив би недійсний перехід стану, відображається на безпечний стан, а не на невизначену поведінку. Автомат станів спроєктовано так, що втрата живлення, втрата зв'язку або втрата достовірності даних сенсора — усе це сходиться до безпечного стану: шляху від стану несправності до небезпечної команди немає. Розгляньмо спрощений приклад для контролера блокування:

Моніторинг правдоподібності. Незалежний процес моніторингу порівнює вихідні команди з фізичними обмеженнями. Задане прискорення, що перевищує задокументовану максимальну спроможність транспортного засобу, є неправдоподібним і може вказувати на помилку обчислення або пошкоджені вхідні дані. Монітор перехоплює й блокує неправдоподібну команду, журналює подію та сповіщає систему керування технічним станом (health management). Логіка моніторингу має бути незалежною від логіки обчислень — якщо обидві використовують той самий алгоритм, систематичний дефект однаково вражає обидві, і монітор не забезпечує жодного захисту.

Захисна валідація вхідних даних. Кожна критична для безпеки функція перевіряє свої вхідні дані на відповідність визначеним допустимим діапазонам, перш ніж їх обробляти. Вхідні дані поза допустимим діапазоном не призводять до обчислень на недійсних даних — вони змушують функцію активувати стан несправності та перейти на визначений шлях обробки помилок. Логіка валідації має охоплювати не лише перевірки діапазону, а й часову дійсність (це найновіше вибіркове значення чи застаріле показання?), дійсність джерела (чи надійшло це значення від очікуваного відправника?) та узгодженість (чи узгоджується це значення з підтверджувальними сенсорами в межах допуску?).

Кожен проєктний засіб контролю документується в документі проєктування ПЗ (Software Design Document) із явним перехресним посиланням на SSR, яку він реалізує. Процес огляду проєкту включає перевірку того, що для кожної SSR визначено проєктний засіб контролю, а кожен проєктний засіб контролю обґрунтовано як адекватний для режиму відмови, якого він стосується. Засоби контролю, адекватні для помірних небезпек, можуть бути неадекватними для критичних — аргумент адекватності має бути специфічним для тяжкості наслідків.

Докази верифікації безпеки

Докази верифікації безпеки — це сукупність записів, які демонструють, що кожен SSR коректно реалізовано в поставленому програмному забезпеченні. Доказова база має бути достатньою, щоб кваліфікований рецензент — державний інженер із безпеки, рада з розгляду безпеки або орган з прийняття ризику — міг дійти висновку, що програмне забезпечення поводиться так, як стверджує обґрунтування безпеки. Докази, які наявні, але не простежуються до SSR, або простежуються до SSR, але недостатні для демонстрації їх реалізації, не закривають обґрунтування безпеки.

Основні типи доказів для верифікації безпеки програмного забезпечення такі:

Тестові випадки, орієнтовані на безпеку. Для кожного SSR виводять один або кілька тестових випадків, які безпосередньо випробовують необхідну поведінку. Тестові випадки будують на основі видів відмов із SwHA: якщо рядок SwHA визначає «хибну активацію FIRE_COMMAND у режимі SAFE» як причину небезпеки, відповідний тестовий випадок задає конкретні вхідні умови, які були б потрібні для запуску цієї поведінки, і перевіряє, що вихідний сигнал не активується. Тестування на відсутність небезпечної поведінки вимогливіше за тестування на наявність коректної поведінки — інженер із тестування має проаналізувати всі шляхи входу, які можуть досягти функції безпеки, і підтвердити, що жоден із них не дає небезпечного виходу.

Покриття коду для критичних для безпеки модулів. Метрики покриття дають упевненість, що набір тестів задіює шляхи виконання коду, які реалізують SSR. Цільовий показник покриття для критичних для безпеки модулів (функції категорій I та II за SCI) — зазвичай щонайменше 100% покриття гілок, а для функцій, що реалізують багатоумовну логіку авторизації, потрібне модифіковане покриття умов/рішень (MC/DC). Звіт про покриття гілок, який показує непротестовані гілки в критичному для безпеки модулі, є відкритим зауваженням: або непротестована гілка — це мертвий код, який потрібно видалити, або бракує тестового випадку. Дані про покриття без відповідної карти простежуваності до SSR не є доказом верифікації безпеки — доказ полягає у зв'язку між покритим кодом і SSR, які цей код реалізує. Див. також: тестування програмного забезпечення військових систем — повний розгляд методології тестування для оборонних програм.

Програмний FMEA. Програмний аналіз видів і наслідків відмов (FMEA) застосовує методологію FMEA до програмних модулів, а не до апаратних компонентів. Для кожної функції в критичному для безпеки модулі FMEA фіксує: призначення функції, види відмов (за п'ятьма канонічними категоріями з SwHA), вплив кожного виду відмови на вихід програмного забезпечення, вплив на небезпеку системи, механізм виявлення (сторожовий таймер, монітор, тест, спостереження оператора) і компенсувальний засіб контролю в проєктному рішенні. Програмний FMEA найцінніший як перехресна перевірка SwHA — якщо FMEA виявляє вид відмови з небезпечними наслідками, якого немає в SwHA, то або в SwHA є прогалина, або FMEA містить хибнопозитивний результат, який необхідно розглянути й вирішити. Обидва результати покращують обґрунтування безпеки.

Записи рецензування коду. Рецензування критичного для безпеки коду колегами за контрольним переліком, специфічним для безпеки, дає докази того, що кваліфіковані інженери перевірили реалізацію на відповідність SSR і проєктним засобам контролю. Пункти контрольного переліку мають безпосередньо відповідати необхідним шаблонам проєктування — «скидання сторожового таймера викликається в кожному циклі», «усі входи перевіряються перед використанням», «автомат станів не має невизначених переходів». Записи рецензування фіксують виявлені дефекти та рішення щодо них; рецензування, яке не виявило жодного зауваження до складного критичного для безпеки модуля, свідчить або про надзвичайно чисту реалізацію, або про недостатньо ретельний процес рецензування, і інженер із безпеки програми має вміти розрізняти ці два випадки.

Інтеграція цих типів доказів у DevSecOps-конвеєри для оборонних програм вимагає, щоб критичні для безпеки тестові випадки, засоби вимірювання покриття та робочі аркуші FMEA перебували під конфігураційним контролем разом із вихідним кодом, який вони верифікують. Результат тесту без базової конфігурації, що точно визначає, яку версію програмного забезпечення було протестовано, не є відтворюваним доказом і не може бути поданий у складі Пакета даних із безпеки. Кожен артефакт доказів потребує номера документа, редакції, дати та посилання на базову конфігурацію елемента конфігурації програмного забезпечення, яку він охоплює.

Складання обґрунтування безпеки та прийняття залишкового ризику

Обґрунтування безпеки — це структурована аргументація того, що поставлена програмна система є прийнятно безпечною для передбачуваного використання. Воно не стверджує, що програмне забезпечення вільне від дефектів або що весь ризик усунуто, — такі твердження недосяжні й не є тим, чого вимагає MIL-STD-882E. Воно стверджує, що: усі небезпеки, які можна обґрунтовано передбачити, виявлено; застосовано засоби контролю, що знижують кожну небезпеку до прийнятного рівня ризику; перевірено, що засоби контролю реалізовано коректно; а залишкові ризики, які лишаються після застосування засобів контролю, розглянуто та прийнято відповідним уповноваженим органом.

Структура документа обґрунтування безпеки відповідає ієрархії «твердження — аргумент — докази». Нотація структурування цілей (GSN) зазвичай використовується для візуалізації цієї ієрархії, хоча нотація не є обов'язковою — структура має бути наявною незалежно від того, чи виражено її у формі GSN. Типова структура верхнього рівня для обґрунтування безпеки програмного забезпечення системи керування вогнем:

Пакет даних із безпеки (SDP) — це сукупність артефактів, які передаються до офісу програми як докази для обґрунтування безпеки. Його склад визначається в Плані програми системної безпеки як перелік CDRL із датами поставки, прив'язаними до віх програми. Типовий склад SDP:

• План програми системної безпеки (SSPP)
• Звіт попереднього аналізу небезпек (PHA)
• Звіти аналізу небезпек підсистем (SSHA)
• Робочі аркуші аналізу небезпек програмного забезпечення (SwHA)
• Перелік вимог безпеки до програмного забезпечення (SSR) і матриця простежуваності
• Звіти аналізу проєктних рішень безпеки програмного забезпечення (завдання 206)
• Робочі аркуші програмного FMEA
• Тестові випадки та результати тестування критичного для безпеки програмного забезпечення
• Звіти про покриття коду для критичних для безпеки модулів
• Записи рецензування коду критичних для безпеки модулів
• Звіти про рішення щодо ризику небезпеки (HRDR) для прийнятих залишкових ризиків
• Звіт з оцінки безпеки (SAR)

Прийняття залишкового ризику — це формальна дія, якою орган з прийняття ризику визнає, що небезпеку проконтрольовано до рівня, який залишається вищим за прийнятний поріг програми, розглядає докази того, що засоби контролю є адекватними та коректно реалізованими, і бере на себе відповідальність за ризик, що залишається. Інструментом цієї дії є Звіт про рішення щодо ризику небезпеки. HRDR описує небезпеку, застосовані засоби контролю, залишковий HRI після застосування засобів контролю, докази, що підтверджують оцінку залишкового HRI, і рекомендацію. Відповідний уповноважений орган підписує HRDR, перетворюючи його з рекомендації на формальний запис про прийняття ризику.

Обґрунтування безпеки — це живий документ. Щоразу, коли програмне забезпечення змінюється — змінюються вимоги, виправляються дефекти, розвиваються інтерфейси, — обґрунтування безпеки необхідно переглянути, щоб визначити, чи впливає зміна на будь-яку небезпеку, SSR, проєктний засіб контролю або елемент доказів. Зміна, що збільшує ймовірність або тяжкість прийнятого залишкового ризику, потребує нового HRDR, підписаного відповідним уповноваженим органом. Зміна, що вводить нову причину небезпеки, потребує оновлення SwHA і, можливо, нового SSR. Тому керування конфігурацією артефактів обґрунтування безпеки так само важливе, як і керування конфігурацією вихідного коду — застаріле обґрунтування безпеки, яке не відображає актуальної базової конфігурації програмного забезпечення, узагалі не є обґрунтуванням безпеки.

Найпоширеніший вид відмови програм безпеки програмного забезпечення — не недостатній аналіз, а недостатнє доведення розпочатого до кінця. SwHA виконано, SSR написано, проєктні засоби контролю реалізовано, а потім планування тестування триває без системного зв'язку між SSR і тестовими випадками. Дані про покриття збирають без карти відповідності критичним для безпеки модулям. FMEA пишуть після рецензування коду, а не до нього. Результатом стає сукупність окремо правдоподібних артефактів, які не складаються в узгоджену аргументацію. Завдання складання обґрунтування безпеки — це місце, де ці розриви стають видимими, а усунення їх до оглядів програми, а не під час них, — це різниця між програмою безпеки, яку можна відстояти, і дорогим циклом переробки.