Як обрати постачальника з розробки оборонного програмного забезпечення

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

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

ISO 27001 та сертифікати якості як базовий рівень

ISO 27001 (управління інформаційною безпекою) та ISO 9001 (управління якістю) є необхідними, але недостатніми умовами. Постачальника без цих сертифікатів слід виключати з розгляду для програм, що обробляють засекречені або чутливі дані — не тому, що самі сертифікати гарантують якість, а тому, що відсутність формальних систем управління безпекою та якістю є надійним індикатором того, що безпека та якість не є організаційними пріоритетами.

Розглядайте ISO 27001 як підлогу, а не стелю. Запитайте про область застосування сертифікації: чи охоплює вона середовище розробки, де буде написано ваш код? Розробників, які будуть працювати над вашою програмою? DevOps-інфраструктуру? Сертифікація, що охоплює лише корпоративний офіс, але не команду розробників, має обмежену актуальність. Запросіть Заяву про застосовність — документ, що перераховує реалізовані засоби контролю та виключення. Довгий список виключень зі слабким обґрунтуванням є попереджувальним сигналом.

Для програм, що передбачають інформацію під грифом NATO, перевірте, чи має постачальник Промисловий допуск безпеки (ISC), виданий відповідним національним органом. Вимоги до ISC різняться залежно від країни, але зазвичай передбачають допуск об'єкта, перевірку особового складу та задокументовані процедури безпеки для роботи з секретними матеріалами.

Досвід NATO та STANAG як сигнал

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

Запитайте конкретно: які стандарти STANAG вони реалізовували? До яких програм NATO вони здійснювали постачання? Чи брали участь у навчаннях або заходах NATO з тестування сумісності (таких як Coalition Warrior Interoperability eXploration, eXperimentation, eXamination, eXercise — CWIX)? Відповіді на ці питання можна перевірити — участь у CWIX задокументована, а досвід у програмах NATO можна підтвердити за посиланнями.

Послужний список оперативних розгортань

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

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

У пост-2022 Європі оперативне розгортання в контексті українського конфлікту стало особливо значимим підтвердженням. Темп, інтенсивність і рівень протидії противника в цьому середовищі перевірили оборонне ПЗ способами, які навчання не можуть відтворити. Системи, розроблені та вдосконалені в цьому контексті, мають іншу категорію оперативної достовірності.

Допуски безпеки команди

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

Запитайте, які розробники мають допуск безпеки і на яких рівнях. Для програм із суворими вимогами безпеки запросіть індивідуальні підтвердження допуску безпеки (резюме, а не повні деталі перевірки) для запропонованих членів команди. Якщо постачальнику потрібно отримати допуск для програми, запитайте про терміни та їх досвід у національному процесі перевірки безпеки. Процеси видачі допуску в більшості країн NATO займають 6–18 місяців; постачальник, який не розпочав цей процес, не може укомплектувати засекречену програму за розкладом.

Право власності на ІВ та ескроу вихідного коду

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

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

SLA підтримки в оперативних середовищах

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

Для оперативних систем розгляньте вимогу до постачальника підтримувати перевірену команду підтримки з доступністю 24/7 та задокументованими сценаріями для найбільш імовірних відмов. Вартість цієї можливості реальна; постачальник, який пропонує її дешево, або не може її підтримувати, або нечесний щодо своєї моделі витрат.

Червоні прапори, на які слід звертати увагу

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