Просте пояснення
SBOM — це перелік усіх компонентів усередині програмного продукту: кожної бібліотеки з відкритим кодом, кожного внутрішнього пакета, кожної залежності залежності — разом із версією та джерелом походження. Уявіть це як список інгредієнтів на упаковці харчового продукту: не опис того, що робить продукт, а точний перелік того, з чого він складається, аж до частин, які ви не додавали самостійно.
Сучасні застосунки не пишуться з нуля, а збираються — типовий продакшн-застосунок легко може мати сотні опенсорсних залежностей, підтягнутих транзитивно, більшість з яких ніхто в команді не обирав свідомо і навіть не впізнає за назвою. SBOM — це артефакт, який робить цей невидимий ланцюг поставок видимим і придатним для аналізу.
Чому це стало нагальним питанням, а не академічним
Раніше SBOM був радше пунктом комплаєнсу, актуальним переважно для державних підрядників. Це змінили дві речі. По-перше, серія серйозних інцидентів у ланцюгу поставок — уразливості, заховані на три-чотири рівні залежностей углиб, або відверто шкідливий код, підкладений у популярний опенсорсний пакет — зробили відповідь «ми насправді не знаємо, що всередині нашого власного софту» неприйнятною для служб безпеки. По-друге, підтягнулося регулювання: державні закупівлі у США та європейський Cyber Resilience Act поступово вимагають SBOM для софту, що продається на цих ринках, а великі корпоративні клієнти дедалі частіше просять постачальників надати SBOM під час закупівлі — незалежно від того, чи вимагає цього регулятор.
Коли критична вразливість у популярній бібліотеці потрапляє в заголовки новин, перше, що запитує будь-яка служба безпеки: «Чи стосується це нас, і де саме?» Без SBOM відповідь на це питання означає ручний пошук по дереву залежностей під тиском часу. З SBOM це запит, який займає кілька хвилин.
Що насправді входить до SBOM
- Інвентар компонентів — кожна бібліотека та пакет, прямі й транзитивні, з точними номерами версій.
- Походження (provenance) — звідки взявся кожен компонент і, в ідеалі, як саме він був зібраний.
- Інформація про ліцензії — дедалі частіше окреме питання для відділів закупівель і юристів, не пов'язане напряму з безпекою.
- Відомі вразливості — коли перелік звіряється з базою даних вразливостей, статичний інвентар перетворюється на інструмент, придатний до дії.
На практиці мають значення два формати: SPDX (виник для потреб ліцензійного комплаєнсу, тепер використовується широко) і CycloneDX (створений насамперед для безпеки, з екосистеми OWASP). Більшість інструментів підтримують обидва; який саме формат потрібен конкретному клієнту чи регулятору, зазвичай вам просто повідомляють, а не залишають на вибір.
Чи потрібен він вам насправді? Короткий чекліст
- Ви продаєте софт державним установам або корпоративним клієнтам із формальним процесом перевірки безпеки? — Дуже ймовірно, що так, зараз або незабаром.
- Ваш продукт обробляє чутливі дані або перебуває там, де компрометація матиме серйозні наслідки (охорона здоров'я, фінанси, інфраструктура)? — Варто мати SBOM незалежно від того, чи вже хтось про нього запитував.
- Чи запитувала коли-небудь служба закупівель або безпеки клієнта: «Що входить до вашого ланцюга поставок ПЗ?» — Якщо це вже сталося одного разу, станеться знову.
- Чи здатна ваша команда швидко відповісти на запитання «чи стосується це нас?», коли в новинах з'являється чергова серйозна опенсорсна вразливість? — Уже саме по собі це достатня причина.
Якщо жоден із цих пунктів поки що не стосується вас — наприклад, невеликий внутрішній інструмент без зовнішніх клієнтів, — SBOM є нижчим за пріоритетом, хоча його генерування сьогодні настільки дешеве, що рідко є вагома причина повністю відмовлятися від нього, щойно ви починаєте постачати щось клієнтам.
Згенерувати SBOM — не найскладніша частина, складніше — підтримувати його
Інструменти для генерування SBOM зі збірки вже зрілі й здебільшого автоматизовані — реальна робота не тут. Реальна робота полягає в тому, щоб тримати SBOM актуальним, поки залежності постійно оновлюються, вбудувати його в CI, щоб він перегенеровувався з кожною збіркою, а не застарівав, і — це та частина, яка й дає реальну цінність — під'єднати його до фіда вразливостей, щоб нова CVE в бібліотеці, яку ви використовуєте, з'являлася як сповіщення, а не ставала для вас новиною від клієнта.
Потрібен процес роботи з SBOM, який не застаріває?
Ми вбудовуємо генерування SBOM і моніторинг залежностей просто в пайплайн, а не робимо це одноразовим документом для комплаєнсу.
Поширені запитання
Чи є SBOM тим самим, що й аудит безпеки?
Ні. SBOM — це інвентар: він показує, що входить до складу вашого софту. Аудит безпеки оцінює, чи є цей софт справді безпечним. SBOM — одне з джерел даних для якісного аудиту, а не заміна для нього.
Як часто потрібно перегенеровувати SBOM?
В ідеалі — з кожною збіркою, вбудовано в CI, а не вручну за розкладом: залежності змінюються достатньо часто, щоб SBOM, згенерований раз на квартал, уже застарів на момент, коли хтось його відкриє.
Чи потрібен SBOM опенсорсному софту?
Опенсорсні проєкти дедалі частіше публікують власні SBOM саме для того, щоб компанії, які їх використовують, могли будувати на їхній основі точні SBOM для себе — увесь сенс у тому, що ця інформація має поширюватися вниз по ланцюгу залежностей, а не зупинятися на першому рівні.
SPDX чи CycloneDX — який формат обрати?
Якщо конкретний клієнт або регулятор уже повідомив, який формат потрібен, використовуйте саме його. Якщо вибір вільний — CycloneDX наразі має сильнішу екосистему інструментів для безпеки, а SPDX — ширше поширення для потреб ліцензійного комплаєнсу. Хороші інструменти зазвичай можуть згенерувати обидва формати з тих самих вихідних даних.