Agile у розробці оборонного програмного забезпечення: реальні виклики та адаптації

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

Ця стаття розглядає, де Agile у своїй поширеній формі суперечить вимогам оборонного середовища, які адаптації виявилися ефективними та де загальноприйняті уявлення про Agile в обороні потребують оновлення на основі того, що насправді працює на практиці.

Де Agile суперечить вимогам оборонного середовища

Секретна класифікація та контроль доступу. Стандартний Agile передбачає, що всі члени команди можуть працювати над усіма частинами кодової бази та відвідувати всі церемонії. Оборонні програми з секретними компонентами можуть обмежувати, хто може працювати над якими підсистемами, залежно від рівня допуску до секретних відомостей. Це створює структури команди, які модель крос-функціональної команди Agile не передбачає: команда спринту може бути розподілена на сегменти з допуском і без нього, з обмеженою можливістю парного програмування або спільних перевірок коду через межі допуску.

Обмеження ITAR та експортного контролю. Для програм, що включають технологію США, підпорядковану Міжнародним правилам торгівлі зброєю (ITAR), склад команди обмежений вимогами до громадянства. Стандартні практики найму Agile — збирання найбільш здатної наявної команди — можуть суперечити вимогам ITAR, що обмежують доступ іноземних громадян до певних технічних даних.

Формальна акредитація та повноваження на експлуатацію (ATO). Системи оборонного програмного забезпечення зазвичай вимагають акредитації безпеки перед розгортанням в операційних середовищах. Процеси акредитації не є дружніми до спринтів: вони передбачають значну документацію, збір доказів, оцінку третьою стороною та формальне прийняття рішень. Це створює структурну невідповідність: Agile безперервно виробляє робоче програмне забезпечення, але розгортання обмежене часовими рамками акредитації, які можуть відставати від розробки на місяці.

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

Адаптації: перевірки безпеки на рівні спринту та CI/CD, орієнтований на акредитацію

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

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

CI/CD, орієнтований на акредитацію, вирішує проблеми ізоляції та часових рамок акредитації. Конвеєр розроблений з урахуванням кінцевого середовища акредитації: використовуються лише компоненти, що можуть бути дзеркально відображені в ізольованому середовищі; генеруються типи артефактів, які вимагатимуть акредитатори (SBOM, звіти про сканування вразливостей, результати статичного аналізу).

Вимоги до документації та Маніфест Agile

Маніфест Agile проголошує перевагу «робочого програмного забезпечення над вичерпною документацією». В оборонних програмах документація виконує функції, що виходять за межі фіксації поведінки програмного забезпечення: вона є юридичним записом того, що було укладено контрактом, що було поставлено та як це було верифіковано; це доказова база для дотримання нормативних вимог; та артефакт, що дозволяє довгоживучим оборонним системам обслуговуватися та модернізуватися майбутніми командами.

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

Що насправді працює на практиці

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