Что такое SBOM: как описывают состав программного обеспечения

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

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

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

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

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

Важно понимать границы понятия. SBOM — это не документация, не архитектурная схема и не отчёт о безопасности. Это именно перечень состава в формализованном виде, который могут читать и люди, и автоматизированные инструменты. Сам по себе SBOM ничего не защищает — его ценность в том, что другие процессы (поиск уязвимостей, аудит лицензий, оценка поставщиков) становятся возможными и быстрыми.

Какие данные содержит SBOM и как он устроен

В 2025 году CISA опубликовало обновлённые Minimum Elements for an SBOM, развивая предыдущую работу NTIA. Требования нужно сверять с действующей версией документа и конкретным контрактом или регулятором, а не с одним неизменным перечнем.

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

Граф зависимостей показывает заявленные связи и пути включения компонента. Он помогает анализу, но сам по себе не доказывает, что конкретный уязвимый код попал в исполняемый артефакт или может быть вызван.

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

Форматы 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 в обоих. Выбор обычно определяется тем, какой формат требует заказчик или регулятор, и какими инструментами уже пользуется команда.

Зачем 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 уменьшает количество ложных тревог и помогает приоритизировать обновления.