SBOM (Software Bill of Materials) — это «список ингредиентов» вашего ПО: полная опись пакетов, библиотек, версий и зависимостей, которые содержит образ. Как этикетка с составом, он точно говорит, что внутри.
Его ценность становится очевидной в день критической уязвимости: вместо ручного перебора десятков образов вы обращаетесь к SBOM и за секунды узнаёте, какие образы содержат затронутый компонент и в какой версии.
Почему это важно для ваших образов
- Быстрая реакция на CVE: вы мгновенно понимаете, касается ли вас новая уязвимость.
- Безопасность цепочки поставок: вы знаете, откуда взялся каждый компонент.
- Соответствие: всё больше стандартов и клиентов требуют его как свидетельство.
- Прозрачность: если вы публикуете образы, SBOM вызывает доверие у тех, кто ими пользуется.
Стандартные форматы
| Формат | Происхождение | Примечания |
|---|---|---|
| SPDX | Linux Foundation / ISO | Стандарт ISO, широко используется в соответствии |
| CycloneDX | OWASP | Ориентирован на безопасность, богат для анализа уязвимостей |
Два доминирующих формата SBOM; многие инструменты экспортируют в оба.
Как сформировать SBOM образа шаг за шагом
- Выберите инструмент: Syft от Anchore — фактический стандарт для формирования SBOM образов и файловых систем; есть и облачные варианты.
- Формируйте в конвейере: во время сборки AMI просканируйте файловую систему и выпустите SBOM, например в CycloneDX и SPDX.
- Анализируйте уязвимости: пропустите SBOM через Grype или Trivy, чтобы сопоставить его с базами CVE.
- Подпишите и заархивируйте: подпишите SBOM — например, через cosign — и сохраните как артефакт, привязанный к версии образа.
- Обращайтесь при необходимости: при новой CVE проверьте архивные SBOM, чтобы понять охват.
Регуляторный контекст 2026 года
SBOM годами набирает вес как хорошая практика безопасности цепочки поставок. Регуляторная картина, впрочем, неоднозначна: в США администрация пересмотрела в 2026 году унаследованные требования к аттестации ПО в сторону более риск-ориентированного подхода, тогда как в Европейском союзе такие нормы, как Cyber Resilience Act, продвигают прозрачность ПО и опись компонентов. Практический вывод: независимо от нормативных качелей наличие SBOM — защитное и коммерческое преимущество, которое стоит взять на вооружение.
Хорошие практики
- Формируйте SBOM автоматически при каждой сборке, а не вручную.
- Храните его версионированным рядом с соответствующим образом.
- Сочетайте со сканированием уязвимостей, чтобы он был действенным.
- Подписывайте его, чтобы гарантировать целостность и происхождение.
Часто задаваемые вопросы
SBOM — это то же, что сканирование уязвимостей?
Нет. SBOM — это опись компонентов; сканирование сопоставляет эту опись с базами CVE, чтобы найти уязвимости. Они дополняют друг друга: сначала вы знаете, что у вас есть, потом — уязвимо ли это.
SPDX или CycloneDX?
SPDX — стандарт ISO, широко применяемый в вопросах соответствия; CycloneDX больше ориентирован на безопасность. Многие инструменты экспортируют в оба, так что выбирать что-то одно не обязательно.
Нужен ли SBOM, если я только использую чужие образы?
Да. Запросить или сформировать SBOM используемых образов позволяет оценить их риск и быстро реагировать на уязвимости, даже если собирали их не вы.
В imaxe.cloud мы делаем ставку на прослеживаемость: описывать и документировать ПО наших образов — часть того, чтобы собирать их хорошо.
