Оцінка постачальників оборонного ПЗ: керівництво з технічного due diligence для офіцера із закупівель

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

Цей посібник надає структуровану систему технічного due diligence, спеціально розроблену для оцінки постачальників оборонного ПЗ. Він охоплює вісім сфер оцінки: чому комерційні підходи не спрацьовують, як оцінити технічну архітектуру, які сертифікати безпеки справді важливі, вимоги до депонування вихідного коду, оцінку SLA та підтримки для довгострокових програм, верифікацію референс-клієнтів, структуру PoC та контрактні права на дані.

Чому стандартна комерційна оцінка постачальника не підходить для оборони

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

Оборонні закупівлі додають обов'язкові виміри оцінки, які комерційні системи систематично ігнорують. Відповідність експортному контролю: постачальник, чиє ПЗ або чиї залежності сторонніх розробників підпадають під контроль ITAR, може бути юридично заблокований для деяких коаліційних програм. Вимоги до довговічності: оборонні платформи регулярно мають операційний термін 15–20 років. Постачальник ПЗ з трирічною операційною історією — це ризик безперервності бізнесу. Операційна безперервність в умовах загроз: плани відновлення після збоїв, розроблені для випадкової втрати даних, не охоплюють кібератаку з боку держави-суперника або радіоелектронну боротьбу. Акредитація на рівні класифікації розгортання: ПЗ, яке не може бути акредитовано на необхідному рівні класифікації, не може бути розгорнуто незалежно від технічної якості.

Перевірка технічної архітектури

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

Запросіть від кожного постачальника у короткому списку перед технічною оцінкою: діаграму архітектури компонентів, діаграму архітектури розгортання, документацію API, Специфікацію програмного забезпечення (SBOM) у форматі SPDX або CycloneDX, а також Architecture Decision Records (ADRs). Оцінюйте повноту і актуальність документації як індикатор дисципліни розробки — постачальники без актуальної документації не можуть управляти своїм власним ризиком ланцюга постачання.

Перевірка сертифікатів безпеки

ISO 27001 сертифікує, що постачальник має задокументовану, перевірену систему управління ризиками інформаційної безпеки. SOC 2 Type II оцінює операційні засоби контролю безпеки протягом операційного періоду. Відповідність ITAR — не сертифікат, а юридичне зобов'язання: для програм з вимогами коаліційного обміну потрібна незалежна юридична перевірка. NATO AQAP-2110 є стандартом НАТО для управління якістю ПЗ, обов'язковим при постачанні ПЗ за програмою НАТО або як субпідрядника для прайм-контрактора НАТО.

Депонування вихідного коду та безперервність бізнесу

Депонування вихідного коду — це контрактна угода, за якою постачальник передає вихідний код, скрипти збірки, набори тестів та документацію нейтральному агенту-депозитарію. Депозит вивільняється замовнику за визначених умов — банкрутство постачальника, поглинання або відмова від продукту. Для оборонних програм з терміном 15–20 років це не запобіжний захід — це майже гарантований сценарій планування.

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

Оцінка SLA та підтримки

Оцінка SLA для оборонних програм вимагає іншого підходу, ніж для комерційних IT. Оцінюйте: зобов'язання щодо часу відповіді за рівнями серйозності (P1 повинен вимірюватися годинами, а не робочими днями), частоту виправлень безпеки (CVE у сторонніх залежностях), тривалість вікна довгострокової підтримки (військові системи потребують мінімум 10–15 років), та потужність команди підтримки на випадок кризових ситуацій.

Верифікація референс-клієнтів

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

Структура пілоту та PoC

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

Контрактні питання: права на IP, дані та відповідність ITAR

Ключові положення контракту на оборонне ПЗ: право власності на IP та права на розробку, права на модифікацію (без необхідності схвалення постачальника), права на операційні дані та похідні розвідувальні продукти, відповідність ITAR в ланцюзі субпідрядників, а також положення про вихід та передачу (експорт даних у непатентованих форматах, допомога при переході).