SBOM для оборонних закупівель: прозорість ланцюга постачання програмного забезпечення

Специфікація складу програмного забезпечення (SBOM) — формальний інвентаризаційний документ, що перераховує кожен компонент, бібліотеку та залежність у програмному продукті — швидко перетворилася з технічної практики DevOps на регуляторну вимогу для оборонних закупівель. Виконавчий наказ США 14028 "Покращення кібербезпеки нації" (2021) вимагає від постачальників програмного забезпечення, що продають федеральним агентствам, надавати SBOM. Акт ЄС про кіберстійкість (Cyber Resilience Act, CRA), що набув чинності у 2024 році, вводить обов'язкові вимоги до безпеки та SBOM для продуктів з цифровими елементами, що продаються на ринку ЄС.

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

Формати SBOM: SPDX та CycloneDX

SPDX (Software Package Data Exchange) є стандартом ISO (ISO/IEC 5962:2021) для SBOM, розробленим спільнотою Linux Foundation. SPDX визначає схему для опису пакетів програмного забезпечення, їх залежностей та ліцензійної інформації. SPDX документи можуть бути виражені у кількох форматах: tag-value (текстовий формат, зручний для читання людиною), JSON, RDF та YAML. SPDX-ідентифікатори — стандартизовані рядки, такі як "SPDX-2.3" — використовуються для однозначного ідентифікації компонентів.

CycloneDX є стандартом OWASP для специфікацій BOM (Bill of Materials), розробленим з прямим фокусом на застосування безпеки. CycloneDX підтримує не лише SBOM, але й HBOM (апаратне забезпечення), MBOM (машинне навчання) та CBOM (криптографія) — що робить його особливо актуальним для оборонних систем, де апаратна та криптографічна прозорість є важливими. CycloneDX передбачає розширення VEX (Vulnerability Exploitability eXchange), що дозволяє постачальникам комунікувати, чи є конкретні відомі вразливості фактично використовуваними в їх продукті.

Генерація SBOM: Syft та cdxgen

Syft від Anchore є провідним інструментом для генерації SBOM з відкритим кодом. Він підтримує широкий спектр екосистем пакетів (Alpine, DEB, RPM, Maven, npm, PyPI, Go modules, NuGet та інші) та може аналізувати директорії файлової системи, контейнерні образи та артефакти OCI. Syft генерує SBOM у форматах SPDX та CycloneDX, що забезпечує гнучкість для задоволення різних вимог аудиторів та клієнтів.

Для CI/CD пайплайнів Syft може бути інтегрований як крок після збірки: після успішної збірки образу контейнера Syft генерує SBOM для цього образу, який потім підписується (за допомогою Cosign) та публікується поряд з образом у реєстрі контейнерів. Пов'язаний SBOM надає кожному образу в реєстрі машинно-зчитуваний інвентар компонентів.

cdxgen (CycloneDX Generator) є альтернативним генератором, оптимізованим для CycloneDX, з особливо сильною підтримкою Java/Kotlin (Maven/Gradle), JavaScript/TypeScript (npm/yarn) та Python (pip/poetry) проєктів. cdxgen аналізує файли маніфестів пакетів та lock-файли для визначення транзитивних залежностей — не лише прямих залежностей, що явно перераховані у package.json або pom.xml, але й залежностей їх залежностей на всій глибині дерева залежностей.

VEX: комунікація про використовуваність вразливостей

SBOM ідентифікує компоненти; SBOM у поєднанні з NVD або іншими базами даних вразливостей ідентифікує, які відомі CVE впливають на ці компоненти. Але присутність CVE в компоненті не означає автоматично, що розгорнуте програмне забезпечення є вразливим: вразливий шлях коду може бути недосяжним; конфігурація пом'якшення може зробити вразливість невикористовуваною; постачальник може вже інтегрувати виправлення без оновлення версії пакета.

VEX (Vulnerability Exploitability eXchange) вирішує цю проблему, надаючи постачальникам механізм для комунікації статусу використовуваності вразливостей у їх конкретних продуктах. VEX-документ може стверджувати, що конкретна CVE: "Не впливає" — вразлива функція не присутня чи не використовується; "Впливає" — вразливість справді вразлива з рекомендованими діями; "У процесі виправлення" — постачальник визнав вразливість і планує виправлення; "Виправлено" — вразливість виправлена з деталями конкретної версії.

Вимоги до SBOM при оборонних закупівлях

Для підрядників МО та ЗСУ що продають або планують продавати програмне забезпечення оборонним клієнтам ЄС та США, SBOM-відповідність стає контрактною вимогою. Практичні вимоги включають: наявність SBOM-документа у машинозчитуваному стандартному форматі (SPDX або CycloneDX), що охоплює всі залежності включно з транзитивними; SBOM повинен бути підписаний для верифікації цілісності; SBOM повинен оновлюватися з кожним релізом; вразливості повинні бути розкриті з відповідними VEX-твердженнями та таймлайнами усунення.

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

Інтеграція SBOM у систему управління вразливостями

SBOM найцінніший у поєднанні з постійним управлінням вразливостями. Автоматизований процес виглядає так: при публікації нового CVE SBOM автоматично запитується, щоб визначити, чи впливає вражений пакет на будь-який розгорнутий продукт; якщо так, інцидент управління вразливостями відкривається автоматично з доказами продукту, версії та розгортань, що впливають на нього; VEX-твердження оновлюються по мірі прогресу розслідування; записи про виправлення документуються по відношенню до CVE у фінальному стані VEX.