DevSecOps для оборонних програм: безпека в кожному спринті

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

Оборонні програми мають додаткові вимоги порівняно з комерційними DevSecOps: відповідність STIG (Security Technical Implementation Guides), аудиторські сліди для акредитаційних органів, управління секретами для класифікованих систем та суворі вимоги до цілісності ланцюга постачання для кодових артефактів, що розгортаються в критичних системах. Ці вимоги змінюють конфігурацію та пріоритети пайплайну DevSecOps, але не змінюють базову архітектуру.

Статичний аналіз коду: Semgrep та інструменти SAST

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

Semgrep забезпечує визначення правил за допомогою простого YAML-синтаксису, що дозволяє командам безпеки кодифікувати специфічні для домену патерни безпеки. Для оборонних програм це включає правила, специфічні для домену: перевірка шифрування класифікованих даних, виявлення небезпечних мережевих підключень у контексті класифікованих систем та виявлення патернів доступу до даних, що порушують обов'язкові правила контролю доступу (MAC).

Розширені інструменти SAST для Java/Kotlin (SpotBugs з плагіном find-sec-bugs), C/C++ (Coverity, Codesonar) та Go (gosec) доповнюють Semgrep більш глибоким аналізом специфічних для мов вразливостей. Для оборонних програм C/C++ — де переповнення буфера та вразливості пам'яті залишаються актуальними класами вразливостей — спеціалізовані аналізатори C/C++ є необхідними, а не бажаними.

Динамічне тестування: OWASP ZAP та DAST у пайплайні

DAST (Dynamic Application Security Testing) тестує запущені програми, відправляючи шкідливі вхідні дані та спостерігаючи за поведінкою, виявляючи вразливості, що виникають з взаємодій між компонентами, а не з ізольованого вихідного коду. OWASP ZAP (Zed Attack Proxy) є стандартним інструментом DAST з відкритим кодом для інтеграції в CI/CD пайплайни. ZAP в режимі daemon надає REST API, що дозволяє пайплайнам запускати автоматизовані сканування, отримувати звіти та виходити з ненульовим кодом за знахідками, що перевищують порогові значення.

Для оборонних додатків DAST сканування повинні охоплювати специфічні для оборони вектори атак: вразливості аутентифікації в системах з обов'язковим контролем доступу, SQL-ін'єкції в базах даних оперативних даних, вразливості сесійного управління в системах з кількома рівнями класифікації. Визначення активних сканів ZAP повинні включати кастомні правила для цих специфічних для домену вразливостей на додаток до стандартного набору правил OWASP Top 10.

Аналіз компонентів: SCA та виявлення вразливостей

SCA (Software Composition Analysis) ідентифікує відомі вразливості у сторонніх залежностях — бібліотеках з відкритим кодом та комерційних компонентах, що включені до кодової бази. Grype та Trivy є стандартними інструментами SCA у DevSecOps пайплайнах: вони сканують пакети залежностей (Maven, npm, pip, Go modules) та образи контейнерів на відповідність базам даних вразливостей (NVD, GitHub Advisory Database, дистрибутивні рекомендаційні бази даних).

Для оборонних програм SCA є особливо важливим з двох причин: компоненти стороннього виробника є найбільш поширеним джерелом вразливостей у зрілих кодових базах, і вимоги до ланцюга постачання оборонних програм (EO 14028, вимоги до SBOM) вимагають повного інвентаризації та документації сторонніх компонентів.

Виявлення секретів: Gitleaks та захист pre-commit

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

Gitleaks та detect-secrets є стандартними інструментами сканування секретів у DevSecOps пайплайнах: вони аналізують git-репозиторії (включаючи git-history) на наявність патернів, що відповідають відомим форматам секретів. Pre-commit хуки, що запускають Gitleaks, надають перший захисний бар'єр, запобігаючи commit-у, що містить виявлені секрети. CI/CD перевірки надають другий бар'єр, сканування push-у до централізованого репозиторію.

Безпека контейнерів: підписання образів та реєстр

Образи контейнерів, що розгортаються в оборонних системах, повинні бути верифіковані на цілісність: образ, що виконується на рівні класифікації, повинен бути тим, який затверджено та підписано авторизованим пайплайном збірки, а не підробленим або підміненим образом, що містить шкідливий код. Cosign (від Sigstore проєкту) надає підписання та верифікацію образів контейнерів: пайплайн збірки підписує образ з криптографічним ключем після успішного проходження всіх безпекових перевірок; Kubernetes admission webhook перевіряє підпис перед дозволом деплойменту образу.

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

Відповідність STIG: автоматизація перевірки

STIG (Security Technical Implementation Guides), опубліковані DISA (Defence Information Systems Agency), визначають специфічні технічні вимоги до конфігурації безпеки для систем Міністерства оборони. OpenSCAP надає автоматизовану перевірку відповідності STIG: він порівнює конфігурацію систем із STIG-специфікаціями (у форматі XCCDF/OVAL) та генерує звіти відповідності, що ідентифікують конфігураційні знахідки Категорії I (критичні), II (середні) та III (низькі).

Для CI/CD пайплайнів перевірки відповідності STIG можуть бути автоматизовані в рамках збірки образу контейнера: після збірки базового образу, але перед push-ом до реєстру, OpenSCAP запускає відповідний профіль STIG проти образу. Знахідки Категорії I провалюють збірку; знахідки Категорії II та III можуть генерувати попередження або вимагати задокументованих відхилень з обґрунтуванням.