Что такое SBOM и зачем он нужен компании

SBOM (Software Bill of Materials, «спецификация программного обеспечения») — это перечень компонентов, из которых собрано приложение: библиотеки, их версии, поставщики, лицензии и зависимости. CISA сравнивает его со списком ингредиентов. Компании нужен SBOM, чтобы за минуты отвечать на вопрос «затронуты ли мы новой уязвимостью» и требовать прозрачности от поставщиков ПО.

Почему о SBOM заговорили все

Современное приложение почти всегда включает множество open-source компонентов, причём большинство из них попадает в сборку не напрямую, а как транзитивные зависимости. Когда в популярной библиотеке находят критическую уязвимость, первый вопрос — «а у нас она есть и где?». Без SBOM ответ ищут вручную днями; со SBOM — выполняют поиск по инвентарю.

Показательный пример — Log4Shell (CVE-2021-44228): библиотека Log4j используется в продуктах самых разных вендоров, и организациям пришлось срочно выяснять, где именно она есть. Об этом риске подробнее — в материале атаки на цепочку поставок ПО.

После атак на цепочки поставок требования к SBOM стали появляться в регулировании. Указ президента США 14028 «Improving the Nation's Cybersecurity», подписанный 12 мая 2021 года, выделил безопасность цепочки поставок ПО в отдельный раздел и поставил задачу определить минимальные элементы SBOM; в июле 2021 года NTIA опубликовало отчёт «The Minimum Elements For a Software Bill of Materials». Нормативные требования США напрямую не действуют в странах Центральной Азии, но SBOM всё чаще запрашивают международные вендоры, крупные заказчики и банки.

Что входит в SBOM

• Название и версия каждого компонента
• Поставщик или автор
• Уникальные идентификаторы (purl, CPE) и хеши
• Связи зависимостей — включая транзитивные
• Лицензии

Чем полнее данные, тем точнее сопоставление с базами уязвимостей. SBOM без версий и идентификаторов бесполезен для автоматического анализа.

Форматы: CycloneDX и SPDX

Два основных открытых стандарта — CycloneDX и SPDX.

• CycloneDX: разрабатывается OWASP Foundation и Ecma International; зафиксирован как стандарт ECMA-424 (опубликован 10 декабря 2025 года). Помимо SBOM описывает SaaSBOM и HBOM, форматы — JSON, XML и Protobuf. Исторически ориентирован на безопасность.
• SPDX: проект Linux Foundation, международный стандарт ISO/IEC 5962:2021. Описывает происхождение, лицензии и данные о безопасности; традиционно силён в лицензионном комплаенсе.

Большинство инструментов умеют работать с обоими форматами, поэтому выбирайте тот, который запрашивают ваши заказчики, а в идеале — умейте отдавать оба.

Как формировать SBOM

Вручную — не вариант: зависимости меняются с каждой сборкой. SBOM генерируется автоматически в CI/CD инструментами класса SCA. Например, Sonatype Lifecycle и SBOM Manager формируют SBOM при каждой сборке, сопоставляют компоненты с базой уязвимостей и политиками компании и позволяют хранить SBOM для всех версий продукта. Обзор альтернатив для выбора — в статье сравнение SCA-решений.

Практические правила генерации:

• Формируйте SBOM на этапе сборки, а не «задним числом» по репозиторию — так в него попадают реальные версии артефактов.
• Храните SBOM для каждого релиза: уязвимость могут найти в версии, которая давно в проде.
• Сверяйте SBOM с базой уязвимостей не один раз, а непрерывно: новые CVE появляются уже после релиза.

Как использовать SBOM для безопасности

1. Реакция на новые CVE: мгновенный поиск затронутых приложений.
2. Политики: запрет компонентов с критическими уязвимостями или запрещёнными лицензиями.
3. Приёмка ПО: требуйте SBOM от подрядчиков и вендоров.
4. Аудит и комплаенс: доказательство контроля цепочки поставок.

CISA отмечает, что SBOM работает в паре с VEX — заявлением о том, затрагивает ли конкретный продукт известную уязвимость. Это помогает отсеять уязвимости компонентов, которые в вашем продукте недостижимы, и не тратить время на пустые тикеты. С SBOM удобно сочетать и другие классы AppSec-инструментов: SCA отвечает за состав, SAST и DAST — за собственный код и поведение приложения.

SBOM для frontend

Отдельная слепая зона — клиентский JavaScript, который подгружается в браузере со сторонних CDN. Классический SBOM, собранный на сборке, его не видит: скрипт подключается уже в рантайме. Для этого существует Frontend SBOM, который формирует, например, DPA FAST Analyzer.

Типичные ошибки при работе с SBOM

• SBOM «для галочки». Файл сформировали один раз для аудита и забыли. Устаревший SBOM опаснее его отсутствия: он создаёт ложное чувство контроля.
• Только прямые зависимости. Большинство проблем приходит через транзитивные компоненты, поэтому SBOM без связей зависимостей малоинформативен.
• Нет процесса реакции. Инвентарь сам по себе не закрывает уязвимости: нужны владельцы приложений, сроки исправления и приоритизация по реальной достижимости уязвимого кода.
• Разные форматы у разных команд. Если каждая команда формирует SBOM по-своему, свести данные в единую картину невозможно. Договоритесь о формате и месте хранения.
• Игнорирование контейнеров и образов. Компоненты операционной системы и базовых образов тоже входят в состав поставляемого продукта.

С чего начать внедрение SBOM

Не нужно сразу охватывать все приложения. Практичный порядок действий:

1. Выберите несколько критичных приложений и включите автоматическую генерацию SBOM в их сборке.
2. Согласуйте формат (CycloneDX, SPDX или оба) и место хранения, доступное службе ИБ.
3. Подключите сопоставление с базой уязвимостей и настройте уведомления о новых находках.
4. Определите политики: какие уязвимости и лицензии недопустимы и кто принимает решение об исключениях.
5. Добавьте требование SBOM в договоры и процесс приёмки ПО от подрядчиков.
6. Постепенно расширяйте охват на остальные приложения и образы контейнеров.

Такой подход позволяет получить первые результаты быстро и не перегрузить команды. Он хорошо ложится в общий план внедрения безопасной разработки, а решения по инструментам удобно проверять на небольшом пилоте.

SBOM и цепочка поставок

SBOM отвечает на вопрос «что внутри», но не гарантирует, что внутри нет вредоносного кода. Поэтому его дополняют контролем того, что вообще попадает в сборку: репозиторием артефактов с проверкой компонентов, блокировкой подозрительных пакетов и политиками допуска. Вместе эти меры формируют контроль цепочки поставок: вы знаете состав продукта и не пускаете в него заведомо опасное. Для организаций, которые сами поставляют ПО заказчикам, SBOM становится ещё и элементом доверия: он показывает, что состав продукта известен и управляем.

Кто должен владеть SBOM

Формально SBOM генерируется автоматически, но у него должен быть владелец. Обычно это служба ИБ или команда платформы разработки: они определяют формат, хранилище и политики, а команды продуктов отвечают за исправление находок в своих приложениях. Чёткое разделение ответственности важно: без него SBOM копится в хранилище, но никто не реагирует на уведомления. Полезно также заранее решить, кому и в каком виде SBOM передаётся вовне — заказчикам, регуляторам, партнёрам, — и какие данные в нём допустимо раскрывать.

Практический пример: что делать, когда появилась новая CVE

Представьте, что в популярной библиотеке объявлена критическая уязвимость. Без SBOM команда рассылает вопросы в чаты разработки, ждёт ответов и по ходу выясняет, что часть приложений собирается по старым инструкциям. Со SBOM порядок другой:

1. Служба ИБ ищет уязвимый компонент и версию по всем сохранённым SBOM и получает список затронутых приложений и релизов.
2. Список ранжируется по критичности: интернет-сервисы и системы с чувствительными данными идут первыми.
3. Для каждого приложения определяется, достижим ли уязвимый код; здесь помогает VEX-статус «затронут / не затронут».
4. Владельцы получают задачи с версией, на которую нужно перейти, и сроком исправления.
5. Новая сборка проверяется политикой: компонент с уязвимой версией больше не проходит в релиз.

Разница между «искали несколько дней» и «получили список за несколько минут» часто и определяет, успеете ли вы закрыть уязвимость раньше атакующих.

Частые вопросы

Источники

• CISA: Software Bill of Materials (SBOM)
• CycloneDX: Specification Overview
• SPDX: About the specification
• CISA: Apache Log4j Vulnerability Guidance