CI/CD-конвеєр для оборонного ПЗ: автоматизоване тестування та розгортання для систем військового класу

Комерційна команда розробників може випустити нову функцію у виробництво за лічені хвилини: запит на злиття проходить автоматизовані тести, рецензент схвалює, CI-конвеєр збирає та розгортає. Для команд, що розробляють оборонне програмне забезпечення, той самий шлях доставки змушений долати принципово інший простір обмежень: експортні регуляції ITAR, що обмежують доступ до артефактів збірки, вимоги відповідності STIG, які визначають конфігурацію кожного рівня стеку, мандати SBOM, що вимагають машиночитаного реєстру кожної залежності, а також середовища розгортання, що можуть не мати підключення до Інтернету взагалі. У результаті багато оборонних програм або повністю відмовляються від CI/CD на користь ручних, багаторівневих процесів випуску — або впроваджують комерційний CI/CD-інструментарій без відповідного обв'язування вимог і створюють ризики під час аудиту.

Жоден із цих результатів не є неминучим. CI/CD-конвеєр для оборонного ПЗ, що задовольняє вимоги ITAR, виробляє STIG-сумісні артефакти, генерує підписані SBOM і розгортається в ізольованих середовищах, цілком досяжний за допомогою доступного програмного забезпечення з відкритим кодом і чіткого архітектурного шаблону. У цій статті описується такий шаблон з охопленням вибору інфраструктури конвеєра, етапів автоматизованого тестування, генерації SBOM, зміцнення контейнерів, розгортання в ізольованих середовищах, процедур відкату та вимог до ланцюжка аудиту.

Обмеження оборонного ПЗ: ITAR, STIG і робота з рівнями секретності в CI

Міжнародні правила торгівлі зброєю (ITAR) регулюють експорт оборонних виробів і послуг, включаючи технічні дані, пов'язані з оборонними системами. Програмне забезпечення, що реалізує контрольований функціонал — алгоритми наведення, комунікаційні протоколи, логіку злиття даних сенсорів — є технічними даними, підконтрольними ITAR. У контексті CI/CD це означає, що вихідний код, артефакти збірки та результати тестів можуть підпадати під експортний контроль, а доступ має бути обмежений особами зі США (громадянами, постійними резидентами або тими, хто має відповідні ліцензії).

Практичний наслідок для інфраструктури конвеєра: виконавці збірки, що обробляють підконтрольний ITAR код, повинні працювати в системах, де доступ забезпечується на рівні інфраструктури, а не лише на рівні застосунку. Хмарно розміщений CI-виконавець — керовані GitHub виконавці, спільні виконавці GitLab.com, хмара CircleCI — не підходить, оскільки операційний персонал хмарного провайдера може мати доступ до середовища виконання. Правильний шлях — самостійно керовані виконавці на власному обладнанні або виконавці в хмарному анклаві FedRAMP High або DoD IL4/IL5 з задокументованими засобами контролю доступу.

Технічний план контролю (TCP) програми — документ відповідності ITAR, що описує захист підконтрольних технічних даних — повинен включати CI/CD-інфраструктуру до своєї сфери охоплення. Це означає документування того, де працюють виконавці, як контролюється доступ, як зберігаються артефакти і як вони передаються між середовищами. Оновлення TCP при зміні інфраструктури конвеєра так само важливе, як і оновлення при зміні архітектури продукту.

Обробка рівнів секретності додає додаткове обмеження для програм, що обробляють секретну інформацію. Сам CI/CD-конвеєр працює на найвищому рівні секретності будь-якого артефакту, який він виробляє. Конвеєр, що виробляє як несекретні результати (документацію, компоненти відкритого коду), так і результати з позначкою CUI (Controlled Unclassified Information), повинен або повністю працювати в середовищі CUI, або впроваджувати засоби контролю потоків інформації між сегментами — складність, якої більшість програм уникає, запускаючи єдиний конвеєр на рівні CUI.

Архітектура конвеєра: GitLab on-premises проти SaaS, міркування щодо ізольованих середовищ

GitLab з самостійним управлінням є домінуючим вибором CI/CD-платформи для конфіденційних оборонних програм. Він повністю працює в інфраструктурі під вашим контролем, підтримує повністю офлайн-встановлення (через офлайн-пакет), інтегрується з Active Directory і LDAP для контролю доступу та має широку базу встановлень у програмах DoD. Platform One — DevSecOps-платформа DoD — побудована на GitLab і надає референсну реалізацію, яку багато програм застосовують безпосередньо.

GitHub Enterprise Server є життєздатною альтернативою для програм, що вже перебувають в екосистемі GitHub, пропонуючи розміщення на власних серверах із тим самим синтаксисом робочих процесів, що й GitHub.com. Jenkins залишається у використанні в застарілих програмах, хоча його екосистема безпекових плагінів є більш фрагментованою порівняно з вбудованими можливостями GitLab. Для нових програм GitLab з самостійним управлінням або побудована на ньому платформа — найбільш чіткий шлях до відповідності вимогам.

Реєстр артефактів — де зберігаються результати збірки, образи контейнерів і пакети розгортання — також повинен працювати в інфраструктурі під вашим контролем. Harbor — це контейнерний реєстр відкритого коду, що отримав статус випускника CNCF, з вбудованим скануванням вразливостей. Artifactory або Nexus виступають реєстрами пакетів для залежностей мовної екосистеми (npm, Maven, PyPI, Go modules). Обидва мають бути заповнені залежностями та базовими образами із зовнішніх джерел через контрольований процес, оскільки в ізольованих середовищах немає вихідного Інтернет-трафіку для вирішення залежностей.

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

Етапи автоматизованого тестування: від модульних до сканування на відповідність STIG

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

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

SAST (Static Application Security Testing) запускається з кожним запитом на злиття. Semgrep є інструментом вибору завдяки своїй швидкості (менше 30 секунд на кодових базах середнього розміру), підтримці авторства власних правил і формату виведення SARIF. Власні правила для оборонно-специфічних заборон — криптографічні примітиви, застарілі в CNSA, заборонені виклики функцій у критично важливому для безпеки коді, жорстко закодовані маркери секретності — фіксуються в репозиторії разом із кодом і розвиваються разом із кодовою базою. SonarQube є альтернативою, що надає постійну панель знахідок, корисну для відстеження тенденцій боргу в безпеці між релізами.

DAST (Dynamic Application Security Testing) запускається проти розгорнутого тестового екземпляра застосунку. OWASP ZAP у безголовому (daemon) режимі є стандартним інструментом. Конвеєр розгортає застосунок у тимчасове тестове середовище, запускає ZAP з автентифікованим скануванням проти API-ендпоінтів застосунку і блокує на знахідках високої серйозності. DAST виявляє класи вразливостей, які SAST не може — ін'єкційні дефекти, що проявляються лише під час виконання, слабкі місця автентифікації, неправильну конфігурацію CORS — і його знахідки є більш безпосередньо дієвими, оскільки включають перевірені пари запит/відповідь.

Сканування відповідності STIG — це шлюз, якого більшість комерційних конвеєрів повністю позбавлена. DISA STIGs визначають обов'язкові вимоги до конфігурації для кожної технологічної категорії, що використовується в системах DoD — операційна система, веб-сервер, база даних, Kubernetes, середовище виконання контейнерів — і відповідність є жорсткою вимогою для ATO. InSpec з опублікованими DISA профілями STIG забезпечує програмну перевірку відповідності, що виконується як етап конвеєра. Образи контейнерів збираються на базі зміцнених STIG базових образів і скануються під час збірки; інфраструктура як код (Terraform, Ansible) сканується на порушення STIG перед застосуванням. Будь-яке відхилення від базового рівня STIG завершує конвеєр помилкою та видає знахідку зі специфічним ідентифікатором елемента керування, роблячи усунення дієвим, а не розпливчастим.

Генерація SBOM: CycloneDX/SPDX, Grype/Trivy, відповідність ліцензій

Перелік програмного забезпечення (Software Bill of Materials) більше не є необов'язковим для закупівлі оборонного ПЗ. Розділ 1655 NDAA (FY2023) зобов'язав DoD розробити настанови, що вимагають SBOM від постачальників програмного забезпечення, а Стратегія модернізації програмного забезпечення DoD називає SBOM вимогою безпеки ланцюжка постачання. Практичний результат: програми повинні мати можливість виробляти машиночитаний SBOM для кожного релізу програмного забезпечення, і цей SBOM має бути актуальним, підписаним і пов'язаним із конкретною збіркою, що його виробила.

Генерація SBOM під час збірки — а не як ручна документаційна вправа — є єдиним підходом, що залишається актуальним. Syft (від Anchore) і cdxgen є двома провідними генераторами SBOM з відкритим кодом. Syft аналізує результати збірки (образи контейнерів, бінарні пакети, мовно-специфічні lock-файли) і виробляє SBOM у форматі CycloneDX або SPDX. cdxgen має кращу підтримку полімовних кодових баз і генерує SBOM з відношеннями між компонентами, що задовольняють рекомендовані CISA мінімальні елементи SBOM.

SBOM підписується разом із артефактом збірки за допомогою Cosign або аналогічного інструментарію, причому ключ підписання зберігається у власному HSM або KMS. Підписаний SBOM супроводжує артефакт у реєстр і в кожен пакет розгортання, щоб оцінювачі могли отримати його на вимогу, а не потребуючи окремого запиту до команди розробників.

Аналіз вразливостей SBOM використовує Grype або Trivy, які перехресно посилаються на компоненти SBOM з базами CVE (NVD, OSV, GitHub Advisory) для виявлення відомих вразливостей. Результати додаються до SBOM як анотації VEX (Vulnerability Exploitability eXchange), що документують для кожного CVE, чи є компонент фактично ураженим з огляду на контекст використання програмою.

Зміцнення контейнерів: distroless-базові образи, виконання не від root, seccomp, підписання образів

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

Вибір базового образу є першим рішенням. Distroless-образи (проект Google distroless або Chainguard Images) містять лише середовище виконання застосунку та його прямі залежності — жодної оболонки, менеджера пакетів, утиліт, які зловмисник міг би використати після компрометації. Distroless-образи значно менші (зменшуючи поверхню атаки та кількість CVE у SBOM), але вимагають, щоб застосунок міг бути розгорнутий без скриптів оболонки під час запуску. Там, де оболонка дійсно потрібна, базові образи, зміцнені DISA STIG (доступні для RHEL, UBI та інших дистрибутивів), забезпечують попередньо зміцнену альтернативу з задокументованою відповідністю.

Виконання не від root є обов'язковим. Контейнери, що запускаються від root (UID 0), можуть підвищувати привілеї на хості через вразливості втечі з контейнера. Усі образи оборонних контейнерів повинні вказувати не-root USER у Dockerfile, налаштовувати кореневу файлову систему лише для читання і використовувати монтування записуваного тому лише для даних, що дійсно змінюються під час виконання. Контролери допуску забезпечують це під час планування — специфікація контейнера, що запитує виконання від root, відхиляється до запуску.

Профілі seccomp обмежують системні виклики Linux, доступні контейнеру, зменшуючи поверхню атаки для використання вразливостей ядра. Профіль seccomp RuntimeDefault (наданий середовищем виконання контейнерів) блокує найбільш поширено використовувані системні виклики. Підписання образів за допомогою Cosign або Notary v2 надає криптографічну впевненість у тому, що розгорнутий образ є точно тим образом, що виробив конвеєр.

Розгортання в секретних середовищах: передача через знімні носії, верифікація хешу, підписання маніфесту

Розгортання в ізольованому секретному середовищі з CI/CD-конвеєра — це двофазний процес: конвеєр виробляє пакет розгортання на несекретній або нижчій стороні, а окремий процес встановлення на секретній стороні використовує цей пакет. Конвеєр не може безпосередньо дотягнутися до секретного середовища — ізоляція забезпечується на мережевому рівні.

Пакет розгортання, виробленим конвеєром, містить усе необхідне для встановлення: підписані образи контейнерів або бінарні файли застосунку, SBOM і результати сканування вразливостей, атестацію походження SLSA, що пов'язує пакет із конкретним комітом і запуском конвеєра, маніфест розгортання, що документує конфігурацію цільового середовища, і файл хешу SHA-256, що охоплює весь вміст пакету. Весь пакет підписується ключем підписання релізу програми перед передачею.

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

Процедури відкату: blue-green для сервісів, знімки SQLite для вбудованих систем

Відкат в оборонних середовищах повинен бути надійним, швидким і піддатним аудиту. Розгортання blue-green є стратегією відкату для веб-сервісів і контейнеризованих застосунків: попередня версія продовжує працювати і приймати трафік; нова версія розгортається у неактивний слот; перевірка стану верифікує нову версію; трафік перемикається. Відкат — це перемикання трафіку назад на попередній слот — операція, що займає секунди і не вимагає перевстановлення.

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

Вимоги до ланцюжка аудиту: незмінні журнали, затвердження змін, відстеження вимог

Журнали конвеєра повинні бути незмінними — зберігатися в журнальному сховищі з одноразовим записом (наприклад, S3 з Object Lock або SIEM-індекс з лише-додаванням) і зберігатися відповідно до застосовного розкладу зберігання записів. Кожне розгортання повинно посилатися на затверджений квиток зміни. Шлюз конвеєра розгортання перевіряє, що поточний реліз пов'язаний із затвердженим квитком, перш ніж дозволити продовжити розгортання.

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