Що таке SBOM і навіщо знати всі залежності проєкту

Зачіпка

SBOM - це інвентар того, з чого насправді складається твій застосунок. Не тільки власний код, а й бібліотеки, transitive dependencies, версії, ліцензії і компоненти, які команда часто не бачить щодня.

Коли з’являється нова CVE, перше практичне питання не “це страшно?”, а “чи є цей компонент у нас?”. SBOM потрібен саме для швидкої відповіді.

Проблема / Контекст

Сучасний проєкт рідко пишеться з нуля. Навіть невеликий вебзастосунок може тягнути сотні пакетів через npm, pnpm, pip, Maven, Go modules, Docker image або системні пакети. Частину залежностей команда додала сама. Частина приїхала через інші бібліотеки.

Поки все працює, цей шар майже невидимий. Потім виходить гучна CVE в популярній бібліотеці, security team питає про вплив, клієнт просить доказ, а команда починає шукати відповідь у lockfile, container image, CI logs і старих release notes. Якщо інвентарю немає, реакція стає повільною і нервовою.

SBOM переводить цю ситуацію з режиму “здається, у нас цього немає” у режим “ось список компонентів і версій”. Він не виправляє вразливості сам. Але він дає карту, без якої dependency audit перетворюється на здогадки.

Чому це важливо

SBOM важливий не тому, що це модний compliance-документ. Його цінність у дуже земних задачах.

По-перше, він прискорює CVE-triage. Якщо вразливість знайдена у конкретній версії бібліотеки, команда швидко перевіряє, чи є ця версія у production artifact. Це краще, ніж вручну перебирати package.json, lockfile і docker layers під тиском.

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

По-третє, SBOM допомагає говорити з клієнтами, аудиторами і внутрішньою security-командою без театру. Замість “ми перевіримо” можна показати процес: SBOM генерується на release, SCA сканує компоненти, критичні знахідки потрапляють у backlog або incident flow.

І ще один плюс: інвентар залежностей дисциплінує release. Якщо команда не може пояснити, що саме вона відправляє в production, це вже сигнал, що supply chain прозорість слабка.

Схема в голові

Уяви SBOM як список деталей для зібраного велосипеда. Рама, колеса, гальма, ланцюг, виробник, модель і версія. Якщо потім виявиться, що певна партія гальм має дефект, ти не розбираєш велосипед навмання. Ти дивишся в інвентар.

Для software це виглядає так:

• є application code;
• є direct dependencies, які команда додала явно;
• є transitive dependencies, які прийшли через них;
• є package manager і lockfile;
• є build artifact або container image;
• є SBOM у форматі CycloneDX або SPDX;
• є SCA-перевірка, яка порівнює компоненти з відомими вразливостями.

Важливий момент: SBOM має описувати не мрію про проєкт, а реальний artifact. Якщо production збирається в Docker image, корисніше мати SBOM для image або release artifact, а не тільки для source tree.

Як це зробити

1. Визнач джерело правди

Спочатку виріши, з чого генерується SBOM. Для Node.js це може бути lockfile. Для container-based deploy - image. Для monorepo - окремі SBOM для сервісів або один агрегований звіт.

Поганий варіант - вручну підтримувати список залежностей у README. Він швидко застаріває. Кращий варіант - генерувати SBOM автоматично з package manager, lockfile або artifact.

Практичні питання:

• що саме потрапляє у production;
• де фіксуються точні версії;
• які build steps додають компоненти;
• чи є системні пакети всередині container image;
• чи треба окремо описувати frontend, backend і infra modules.

2. Обери формат

Найчастіше зустрічаються CycloneDX і SPDX. Для більшості команд головне не сперечатися про формат тижнями, а вибрати той, який підтримують їхні інструменти, клієнти і CI/CD.

CycloneDX часто зручний для application security і supply chain перевірок. SPDX широко використовується для software materials, ліцензій і provenance. У реальному житті іноді потрібні обидва, але стартувати можна з одного формату, якщо він закриває поточну задачу.

3. Генеруй SBOM у CI/CD

SBOM має бути частиною release workflow, а не ручною командою “коли згадаємо”. Мінімальна схема:

1. встановити залежності з lockfile;
2. зібрати application або image;
3. згенерувати SBOM;
4. запустити SCA або vulnerability scan;
5. зберегти SBOM як release artifact;
6. заблокувати release лише для справді критичних правил, які команда готова підтримувати.

Для локального старту команда може використати інструменти на кшталт Syft, Trivy, CycloneDX generators або вбудовані можливості платформи. Назва інструмента менш важлива, ніж повторюваність процесу.

4. Перевір direct і transitive dependencies

Після першої генерації не вір файлу сліпо. Перевір кілька речей:

• чи є у звіті основні direct dependencies;
• чи видно transitive dependencies;
• чи збігаються версії з lockfile;
• чи потрапили системні пакети з image;
• чи немає dev-only пакетів у production SBOM, якщо вони не входять у release;
• чи зрозуміло, який commit або release відповідає цьому SBOM.

Якщо SBOM не можна прив’язати до конкретного release, користь різко падає. Через місяць ніхто не згадає, який саме файл описував яку збірку.

5. Поєднай SBOM із SCA

SBOM сам по собі - це інвентар. SCA - це перевірка інвентарю на відомі проблеми. Разом вони дають практичну картину.

Корисний workflow:

• SBOM каже, що компонент є у release;
• SCA знаходить CVE для цього компонента;
• команда перевіряє, чи використовується вразлива частина;
• якщо потрібен контекст, додається VEX;
• ticket отримує пріоритет за реальним ризиком, а не тільки за гучністю заголовка.

Це важливо, бо не кожна CVE однаково небезпечна для кожного продукту. Але без SBOM складно навіть почати нормальну розмову.

Типові помилки

• генерувати SBOM один раз і забути про нього;
• описувати source tree, коли production складається з іншого image;
• не включати transitive dependencies;
• зберігати SBOM без прив’язки до commit, tag або release;
• плутати SBOM із SCA-звітом;
• блокувати всі non-critical findings і ламати delivery;
• ігнорувати ліцензії, бо “це тільки security”;
• не перевіряти, чи інструмент бачить dev dependencies окремо від production dependencies;
• тримати SBOM тільки локально на ноутбуці розробника.

Висновок / План дій

SBOM не робить проєкт безпечним автоматично. Він робить його видимим. А видимість - це перший крок до нормальної реакції на CVE, ліцензійні питання і supply chain інциденти.

Почни з малого:

1. визнач, який artifact реально йде в production;
2. згенеруй SBOM з lockfile або image;
3. обери CycloneDX або SPDX;
4. додай генерацію у CI/CD;
5. збережи SBOM поруч із release;
6. підключи SCA-перевірку;
7. домовся, які знахідки блокують release;
8. перевір процес на одній відомій CVE.

Якщо завтра в новинах з’явиться критична вразливість у популярній бібліотеці, команда з SBOM відповідає спокійніше: “перевірили, ось версія, ось вплив, ось дія”. Саме заради цього інвентар і потрібен.

Офіційні джерела:

• https://www.cisa.gov/sbom
• https://www.ntia.gov/page/software-bill-materials
• https://cyclonedx.org/
• https://spdx.dev/
• https://owasp.org/www-community/Component_Analysis