Software Bill of Materials (SBOM) перейшов від опціонального артефакту до контрактного зобов'язання швидше, ніж очікувала більшість оборонних підрядників. У 2021 році це була рекомендація, похована всередині Executive Order 14028. До 2026 року це гейтова умова — кожен бінарний файл, що постачається замовнику США або NATO, повинен мати поточний, підписаний, machine-readable SBOM, і конвеєр, що його створив, має бути здатний довести під час аудиту, що SBOM було згенеровано з тих самих джерел у тій самій збірці, що породила артефакт. Ця стаття пройде інженерні рішення, які визначають, чи переживе ваш CI/CD конвеєр цей аудит.

1. Чому SBOM став обов'язковим для оборони

Чотири регуляторні нитки зійшлися. Executive Order 14028 (травень 2021) вимагав від федеральних постачальників ПЗ надавати SBOM і заклав фундамент для «мінімальних елементів» NTIA. NDAA Section 1655 (FY2023, уточнений через поправки FY2026) розширив вимоги SBOM на оборонні закупівлі, зобов'язавши прайм-підрядників DoD та субпідрядників надавати SBOM для будь-якого ПЗ, що постачається Департаменту, зі специфічними положеннями щодо компонентів китайського походження та постачальників із ворожих країн. NIS2 застосував паралельний тиск через оборонну базу ЄС, вимагаючи задокументованого керування ризиками ланцюга постачання для essential та important entities. NIST SP 800-218 — Secure Software Development Framework (SSDF) — кодифікував генерацію SBOM як очікувану практику для будь-якого вендора, що самозасвідчується за OMB M-22-18 та M-23-16.

Практичний ефект — оборонний вендор ПЗ без інструментарію SBOM у 2026 році не є конкурентним вендором. RFP включають положення про SBOM. Аудити включають перевірки SBOM. І відсутній SBOM трактується так само, як відсутній test report — як свідчення того, що інженерний процес постачальника неповний. Хороша новина для інженерних команд: генерація SBOM, належно інструментована, дешева в підтримці. Погана новина — «належно інструментована» ховає довгий список архітектурних рішень, більшість з яких приймаються неправильно з першого разу.

2. CycloneDX проти SPDX

Два формати SBOM мають значення: CycloneDX (виник в OWASP, нині стандарт Ecma) і SPDX (виник у Linux Foundation, ISO/IEC 5962:2021). Вони покривають ту саму концептуальну ділянку — компоненти, версії, ліцензії, хеші, зв'язки — але діалекти розходяться у способах, що мають значення для інструментарію.

CycloneDX оптимізований для безпекових випадків використання: нативна підтримка VEX, поля вразливостей першого класу, легкий JSON, тісна інтеграція з екосистемою OWASP (Dependency-Track, dependency-check). Це формат, що його за замовчуванням виробляє більшість безпекових команд. SPDX оптимізований для ліцензій та provenance: багатша мова виразів ліцензій, довший родовід в open-source compliance аудитах, ISO-штамп, якого юридичні та закупівельні команди просять у регульованих галузях.

Оборонні замовники просять обидва. NDAA-узгоджені контракти все частіше специфікують «SPDX 2.3 або новіше, або CycloneDX 1.5 або новіше», лишаючи вибір формату постачальнику — поки що downstream-інструментарій замовника не змусить один або інший. Прагматичний патерн — dual-emit: генерувати CycloneDX SBOM у збірці для внутрішнього інструментарію вразливостей, потім перетворювати на SPDX під час доставки за допомогою конвертера (open-source cyclonedx-py, cdx2spdx або SPDX tools chain). Ставтеся до одного як до джерела істини, до іншого — як до похідного артефакту; тримайте обидва версіонованими разом із бінарним файлом.

3. Генерація SBOM під час збірки чи після збірки

Найбільший визначник довіри до SBOM — це коли в конвеєрі SBOM створюється. Існують два табори. Post-build сканери (Trivy, Snyk, GitHub native dependency graph у режимі сканування) приймають готовий контейнерний образ або бінарний файл і реверс-інжинірять його компоненти. Build-time генератори (Syft, підключений до збірки, cdxgen, мовно-специфічний інструментарій на кшталт cargo cyclonedx, mvn cyclonedx, npm sbom) спостерігають фактичний процес збірки і випромінюють SBOM з вирішеного графа залежностей, який збірка використала.

Лише build-time генерація заслуговує на довіру при аудиті. Причина проста: post-build сканер ідентифікує те, що бачить, — він не може відрізнити бібліотеку, що статично залінкована в бінарний файл, від бібліотеки, що була підтягнута для build-time інструменту, але ніколи не була поставлена. Він не бачить приватних реєстрів, до яких у сканера немає облікових даних. Він не бачить генерацію коду під час компіляції. Рецензент, що питає «звідки ви знаєте, що цей SBOM повний?», отримує дієву відповідь лише тоді, коли SBOM було створено самою збіркою, з provenance назад до lockfiles. Post-build сканування — корисна друга думка. Воно не є первинним артефактом.

На практиці команди сходяться на стеку з Syft для OS і контейнерних шарів, мовно-нативних генераторів (cargo, npm, pip, mvn, go-licenses з CycloneDX-виводом) для компонентів коду, cdxgen коли поліглотні репозиторії потребують одного проходу, і Trivy або нативний SBOM-експорт GitHub як post-build перехресну перевірку. Конвеєр збірки зливає мовно-нативні виходи в один CycloneDX-документ, підписує його та прикріплює до випущеного артефакту.

4. Підпис SBOM та атестація

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

Домінуючі примітиви — sigstore/cosign для keyless-підпису (OIDC-прив'язані сертифікати, transparency log у Rekor) і in-toto атестації для формату заяви. Атестація in-toto має три частини: subject (хеш атестованого артефакту), тип предиката (наприклад, https://cyclonedx.org/bom або тип SLSA provenance) і тіло предиката (сам SBOM або build provenance). Cosign підписує атестацію, прикріплює її як OCI-артефакт поруч з контейнерним образом і виштовхує підпис у Rekor transparency log.

SLSA-фреймворк (Supply-chain Levels for Software Artifacts) — це модель зрілості, на яку оборонні замовники посилаються, коли хочуть єдине число, що прив'язує їхні вимоги. SLSA 1 означає, що provenance існує. SLSA 2 означає, що воно підписане і служба збірки хостована. SLSA 3 означає, що збірка ізольована і provenance не може бути підробленим самим проєктом. SLSA 4 означає двосторонню рецензію та герметичні, відтворювані збірки. Більшість оборонних контрактів у 2026 році просять SLSA 3 як підлогу для ПЗ, що постачається в operational environments; SLSA 2 прийнятний для нерозгорнутого інструментарію. SLSA 4 лишається рідкісним поза найвищою класифікацією навантажень.

5. Шар кореляції вразливостей

SBOM — це список компонентів; сам по собі він не є звітом про вразливості. Шар кореляції з'єднує SBOM з базами даних вразливостей (NVD, OSV, GitHub Advisory Database), щоб виробити список вразливостей на артефакт. Тут більшість команд виявляє, що 80% повідомлених вразливостей у їхньому SBOM не експлуатуються в їхньому контексті — вразлива функція ніколи не викликається, постраждала конфігурація ніколи не вмикається, або шлях недосяжний з будь-якої зовнішньої поверхні.

Стандартизований спосіб це повідомити — VEX (Vulnerability Exploitability eXchange). Заява VEX оголошує, для конкретної CVE проти конкретної версії продукту, один з чотирьох статусів: not_affected, affected, fixed або under_investigation, з обґрунтуванням (наприклад, vulnerable_code_not_in_execute_path). CycloneDX підтримує VEX нативно; SPDX підтримує його через супровідний формат CSAF (Common Security Advisory Framework). Оборонний замовник, що переглядає ваш SBOM, очікує побачити заяви VEX, що пояснюють відкриті CVE, — а не мовчанку.

Операційний workflow виглядає так: SBOM згенерований у збірці → сканування вразливостей проти OSV/NVD → тріаж в інструменті на кшталт Dependency-Track → інженер подає заяву VEX з обґрунтуванням → VEX прикріплюється як підписана in-toto атестація поруч з SBOM. Аудитор замовника бачить когерентну історію для кожної CVE.

Ключовий висновок: Оборонний конвеєр, що відвантажує SBOM без заяв VEX, топить замовника в шумі. За шість місяців замовник перестає читати SBOM, бо не може відрізнити сигнал від фону. Постачальник, що відвантажує SBOM + VEX, отримує акредитацію; постачальник, що відвантажує лише SBOM, отримує запит на ремедіацію для кожної «high» CVE у транзитивному Go-модулі. Тріажте свої власні вразливості — ваша DevSecOps та zero-trust позиція оцінюється за тим, наскільки добре ви корелюєте, а не скільки CVE підіймаєте.

6. Логіка гейта CI

SBOM і заяви VEX забезпечують гігієну ланцюга постачання лише тоді, коли конвеєр на них блокує. Гейт сидить між «збірка успішна» і «релізний артефакт просунутий». Сучасні команди пишуть гейт як політику в Rego (Open Policy Agent) або Kyverno, що оцінюється проти SBOM та VEX як входів.

Робочоздатна політика забезпечує чотири правила. Одне: ніяких критичних CVE без обґрунтування VEX. Два: ніяких компонентів зі списку заборонених ліцензійних родин (AGPL у проприєтарних поставках, будь-що з пунктом про походження під експортним контролем США). Три: ніяких компонентів з реєстрів санкціонованих держав (тут живе NDAA 1655 — пакети китайського походження автоматично позначаються). Чотири: SBOM має бути підписаний, build provenance має заявляти SLSA 3 або вище, і запис у Rekor transparency log має існувати.

Винятки (waivers) — це місце, де більшість політик провалюється на практиці. Загальне перевизначення «ігнорувати цю CVE назавжди» — патерн провалу аудиту. Патерн, що виживає під аудитом, — це waiver з обґрунтуванням і терміном дії: файл waiver живе в репозиторії, рецензується у pull request, називає CVE і артефакт, містить письмове обґрунтування (ті ж поля обґрунтування VEX) і має дату закінчення. Конвеєр приймає waiver лише поки він не прострочений. Аудитори обожнюють цей патерн, бо він продукує письмовий слід рішень про ризик; інженери толерують його, бо це обмежена робота.

7. Постачання замовнику

SBOM — не лише артефакт збірки, а контрактна поставка. Оборонні контракти у 2026 році рутинно включають положення про формат SBOM, підпис, механізм доставки та частоту оновлень. Перемови щодо формату зазвичай відбуваються при складанні контракту: постачальник пропонує CycloneDX 1.5 JSON, замовник контрпропонує SPDX 2.3, бо цього вимагає його downstream-інструмент, і постачальник зобов'язується до dual-emit. Доставка зазвичай через контрольований замовником реєстр або портал — ніколи через email-вкладення, які забороняє політика інформаційної безпеки замовника.

Зобов'язання періодичного оновлення — положення, яке більшість постачальників недооцінює. NDAA-узгоджені контракти зазвичай вимагають оновленого SBOM з кожним патч-релізом, кожним квартальним maintenance drop і протягом 72 годин після розкриття будь-якого in-scope CVE. Якщо ваш процес релізу займає тиждень, ви не можете дотриматися 72-годинного дедлайну. Виправлення — зробити випромінювання SBOM автоматичним на кожен реліз, включаючи патч-релізи, щоб SBOM завжди був поточним з бінарним файлом, який запускає замовник. Постачальники, що намагаються регенерувати SBOM вручну після релізу, опиняються в позиції пояснення прогалин рецензентам акредитації — див. також як обмеження допуску і персоналу впливають на те, що ваша команда може відвантажувати.

8. Виживання при аудиті

Рецензент акредитації приходить. Він ставить три питання. Покажіть мені SBOM для версії 2.4.1, яка у нас працює у продакшні. Ваш реєстр повертає підписаний документ CycloneDX з in-toto атестацією, що вказує на хеш бінарного файлу, встановленого замовником. Покажіть мені заяви VEX для кожної «high» CVE у цьому SBOM. Ваш реєстр повертає VEX-бандл з обґрунтуваннями та датами. Покажіть мені, як ви дізналися б сьогодні, якщо нову CVE розкрили проти будь-якого компонента у цьому SBOM. Ви показуєте безперервне сканування, що працює проти корпусу SBOM, і SLA сповіщення замовника.

Конвеєр, що чисто відповідає на ці три питання, — це конвеєр, що виживає. Конвеєр, що не може, — бо SBOM було згенеровано пост-фактум, або заяви VEX живуть у таблиці, або ніхто не відстежує розкриття CVE проти випущених SBOM, — це конвеєр, що втрачає контракт при оновленні. Інвестиція скінченна; наслідок невкладеня — ні. Для ширшого фреймування ланцюга постачання див. наш огляд SBOM в оборонному ПЗ, повний гайд з оборонної кібербезпеки та глибокий розбір DevSecOps + zero trust, що сидить на один шар вище за цю конвеєрну роботу.