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

Сучасні застосунки часто містять значну частку сторонніх бібліотек і транзитивних залежностей, але універсальної частки 70–90% для «типового» продукту немає. Коли в компоненті знаходять уразливість, актуальний інвентар допомагає швидко перевірити, де він використовується. Для цього й застосовують SBOM.

SBOM (Software Bill of Materials) — це структурований перелік усіх компонентів, із яких складається програмний продукт: бібліотек, фреймворків, модулів, їхніх версій, ліцензій і зв’язків між ними. Якщо проводити аналогію, це подібно до списку інгредієнтів на упаковці продукту харчування: ви можете не знати рецепт, але точно бачите, що всередині. У статті розберемо, як SBOM працює на практиці, які дані він містить, які формати вважаються стандартними і як почати використовувати його в реальному проєкті.

Що таке SBOM простими словами

Термін «Bill of Materials» прийшов із виробництва: там специфікація матеріалів описує, з яких деталей складається верстат, автомобіль чи телефон. Якщо виробник виявляє браковану партію підшипників, він за специфікацією швидко визначає, у які моделі вони потрапили. SBOM переносить ту саму логіку у світ програмного забезпечення.

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

Важливо розуміти межі поняття. SBOM — це не документація, не архітектурна схема і не звіт про безпеку. Це саме перелік складу у формалізованому вигляді, який можуть читати й люди, й автоматизовані інструменти. Сам по собі SBOM нічого не захищає — його цінність у тому, що інші процеси (пошук вразливостей, аудит ліцензій, оцінка постачальників) стають можливими й швидкими. Ця логіка перегукується з принципами моделі безпеки Zero Trust, де кожен доступ перевіряють окремо.

Які дані містить SBOM і як він влаштований

У 2025 році CISA опублікувала оновлені Minimum Elements for an SBOM, розвиваючи попередню роботу NTIA. Вимоги слід звіряти з чинною версією документа та конкретним контрактом або регулятором, а не з одним незмінним переліком.

• Назва компонента та постачальника (хто створив бібліотеку).
• Версія — з точністю, достатньою для ідентифікації конкретного релізу.
• Унікальні ідентифікатори: хеші, координати пакета (наприклад, PURL — Package URL).
• Залежності та зв’язки: який компонент від якого залежить.
• Ліцензія, за якою поширюється компонент.
• Автор SBOM-документа і час його створення.

Граф залежностей показує заявлені зв’язки й шляхи включення компонента. Він допомагає аналізу, але сам по собі не доводить, що конкретний уразливий код потрапив у виконуваний артефакт або може бути викликаний.

На практиці SBOM може охоплювати різні рівні: окремий контейнерний образ, мікросервіс, мобільний застосунок, прошивку пристрою або цілу систему. Формально стандарт не вимагає одного «правильного» охоплення — воно залежить від того, хто і для чого запитує документ. Схожі підходи до автентифікації без паролів описує матеріал про безпарольну авторизацію passkeys.

Формати SPDX і CycloneDX: у чому різниця

Найпоширеніші відкриті формати — SPDX, стандартизований як ISO/IEC 5962, і CycloneDX від OWASP. Придатність формату визначають версія, профіль, потрібні поля та вимоги одержувача; загальне «офіційне визнання» не замінює цієї перевірки.

SPDX (Software Package Data Exchange) розвивається Linux Foundation і стандартизований як ISO/IEC 5962. Історично він виріс із задачі обліку ліцензій у відкритому коді, тому дуже сильний саме у правовому вимірі: детально описує ліцензії, авторські права, походження файлів. SPDX часто обирають там, де важливий юридичний аудит open source.

CycloneDX створений спільнотою OWASP і спочатку орієнтований на безпеку. Він зручний для опису компонентів із прив’язкою до вразливостей, сервісів і контексту виконання, легко інтегрується в процеси DevSecOps. Для команд, яким SBOM потрібен насамперед для реагування на CVE, CycloneDX часто виявляється практичнішим.

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

Варто враховувати й ширший контекст: тренди кібербезпеки 2026 за версією Gartner дедалі частіше пов’язують прозорість складу ПЗ із вимогами регуляторів.

Навіщо SBOM потрібен для кібербезпеки

Log4Shell показав складність пошуку транзитивних компонентів у великій кількості систем. Актуальний і достатньо повний SBOM може прискорити інвентаризацію, але твердження про гарантовану відповідь «за години» потребує вимірювань конкретної організації.

Після появи CVE SBOM дає змогу зіставити ідентифікатори та версії з інвентарем продуктів. Це не завжди миттєва відповідь: потрібні якісні ідентифікатори, актуальний документ, аналіз застосовності та перевірка виконуваного коду.

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

У США Executive Order 14028 запустив розроблення федеральних вимог і мінімальних елементів SBOM; конкретний обов’язок постачальника залежить від правил закупівлі та контракту. У ЄС Cyber Resilience Act передбачає машиночитаний SBOM у технічній документації виробника, а основні вимоги застосовуватимуться з 11 грудня 2027 року.

Як SBOM створюється та оновлюється

SBOM майже ніколи не пишуть вручну — для будь-якого реального проєкту це було б марнотратством і джерелом помилок. Документ генерується автоматично інструментами аналізу складу, які сканують маніфести пакетних менеджерів (package.json, pom.xml, requirements.txt, go.mod), lock-файли, контейнерні образи та бінарні артефакти.

Поширені підходи до генерації:

• На етапі збірки: плагіни для систем збірки (Maven, Gradle, npm) створюють SBOM під час кожного білду, тому документ завжди відповідає конкретній версії продукту.
• Аналіз репозиторію: сканери читають маніфести залежностей у вихідному коді.
• Аналіз готових артефактів: інструменти на кшталт Syft розбирають контейнерні образи чи архіви й відновлюють склад компонентів навіть без доступу до вихідного коду.

SBOM потрібно прив’язувати до конкретної версії або артефакту й оновлювати разом зі зміною складу. Частота генерації залежить від моделі випуску й ризику; генерація в CI/CD для кожної збірки покращує простежуваність, але не є універсальною формальною вимогою.

Після генерації SBOM зазвичай проходить через сканер вразливостей (наприклад, Grype або OSV-Scanner), який звіряє компоненти з базами CVE. Такий тандем «SBOM плюс сканер» дає команді постійно оновлювану картину ризиків без повторного ручного аудиту.

Типові помилки та обмеження SBOM

Перша й найпоширеніша помилка — сприймати SBOM як разовий документ для «галочки» у тендері. Застарілий SBOM не просто марний: він створює хибне відчуття контролю. Якщо команда перевіряє склад продукту за минулорічним файлом, вона аналізує продукт, якого більше немає.

Ігнорування транзитивних залежностей створює прогалини, але жоден інструмент не гарантує повний граф для всіх мов, бінарних артефактів і вручну вбудованого коду. Повноту потрібно вимірювати й документувати.

Є й принципові обмеження, про які варто знати, щоб не чекати від SBOM неможливого:

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

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

Як почати використовувати SBOM у своєму проєкті

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

1. Оберіть формат. Якщо немає зовнішніх вимог, для більшості розробницьких команд практичний вибір — CycloneDX через фокус на безпеці та широку підтримку інструментів.
2. Згенеруйте перший SBOM наявними безкоштовними засобами: Syft для контейнерів і артефактів, cdxgen або плагіни пакетних менеджерів — для вихідного коду.
3. Вбудуйте генерацію в CI/CD, щоб кожна збірка автоматично отримувала свіжий SBOM.
4. Підключіть сканер вразливостей, який читає SBOM, і налаштуйте сповіщення про нові CVE для наявних компонентів.
5. Визначте, кому і в яких випадках ви надаєте SBOM: замовникам, аудиторам, регуляторам.

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

Поширені запитання про SBOM

Чи відрізняється SBOM від SCA-сканування?

SCA — клас процесів та інструментів для виявлення й аналізу сторонніх компонентів, ліцензій і вразливостей. SBOM — стандартизований опис складу, який може бути створений SCA-сканером, системою збірки, постачальником або іншим процесом; це не завжди «результат SCA».

Чи потрібен SBOM малому проєкту чи стартапу?

SBOM може бути корисним і малому проєкту, але вартість впровадження залежить від стеку, артефактів, вимог до якості та підтримки. Формальні обов’язки виникають із конкретного контракту, галузевого правила або законодавства, а не просто з появи корпоративного замовника.

Чи безпечно публікувати SBOM? Це ж карта для атакуючого?

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

Що таке VEX і навіщо він потрібен разом із SBOM?

VEX (Vulnerability Exploitability eXchange) — це додатковий документ, у якому постачальник пояснює, чи конкретна вразливість у компоненті зі SBOM реально зачіпає продукт. Наприклад, бібліотека вразлива, але вразлива функція в продукті не викликається. VEX зменшує кількість хибних тривог і допомагає пріоритезувати оновлення.