Что такое SBOM: зачем нужен список компонентов программного обеспечения

SBOM помогает понять, из чего именно состоит программа. По сути, это подробный список всех компонентов программного продукта с указанием их версий и связей. Если в одной из библиотек обнаруживается уязвимость, такой перечень позволяет быстрее определить, используется ли проблемный компонент в конкретном приложении и какие продукты требуют проверки или обновления.

Что такое SBOM и почему его сравнивают со списком ингредиентов

SBOM - это структурированный перечень компонентов, из которых состоит программное обеспечение. Аббревиатура расшифровывается как Software Bill of Materials - по смыслу это можно перевести как "ведомость компонентов программного обеспечения".

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

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

Что означает Software Bill of Materials

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

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

Допустим, веб-сервис использует фреймворк, библиотеку шифрования, драйвер базы данных и несколько десятков дополнительных пакетов. Каждый из этих компонентов может в свою очередь зависеть от других библиотек. В результате реальное количество элементов внутри проекта оказывается значительно больше, чем видно разработчику на первый взгляд.

SBOM помогает сделать эту структуру прозрачной.

Что обычно входит в SBOM

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

В перечне могут указываться:

• название библиотеки или пакета;
• версия компонента;
• разработчик или поставщик;
• уникальные идентификаторы пакета;
• лицензия;
• связи с другими зависимостями;
• информация о происхождении компонента.

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

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

Например, приложение использует библиотеку A, библиотека A зависит от библиотеки B, а библиотека B - от библиотеки C. Разработчик может никогда напрямую не добавлять C в проект, хотя фактически её код всё равно окажется частью программного продукта.

Чем SBOM отличается от обычного списка библиотек

На первый взгляд SBOM похож на файл зависимостей, который уже существует во многих проектах. В JavaScript это может быть package.json, в Python - requirements.txt, а в других экосистемах используются собственные форматы.

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

SBOM создаётся с другой целью. Это стандартизированное и машиночитаемое описание состава программного продукта, которое могут использовать системы кибербезопасности, инструменты контроля цепочки поставок и платформы анализа уязвимостей.

Кроме того, SBOM может описывать не только зависимости, которые разработчик добавил вручную, но и более глубокую структуру программного продукта. Благодаря этому он становится своеобразной картой состава приложения, которую можно автоматически анализировать при появлении новых угроз.

Зачем SBOM нужен для поиска уязвимостей

Одна из главных причин использовать SBOM - возможность быстро понять, затрагивает ли новая уязвимость конкретную программу. Без такого перечня разработчикам и специалистам по безопасности приходится вручную проверять зависимости каждого проекта, а в крупных системах это может означать анализ сотен компонентов.

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

Как уязвимость в одной библиотеке затрагивает множество программ

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

Представим, что разработчики используют библиотеку версии 3.4. Позже исследователи обнаруживают в ней серьёзную уязвимость, а исправление появляется в версии 3.4.1. Если компания точно знает состав своих приложений, она может быстро найти продукты, где установлена старая версия.

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

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

Похожая проблема возникает и с Уязвимостями нулевого дня: как работают Zero-Day атаки и защита особенно хорошо показывает, почему скорость обнаружения затронутых систем критична после публикации информации о новой угрозе.

Как SBOM ускоряет проверку после обнаружения новой уязвимости

Когда появляется информация о новой уязвимости, специалистам необходимо ответить на несколько вопросов: используется ли проблемный компонент, в каких продуктах он находится и какая версия установлена.

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

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

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

SBOM и поиск уязвимостей в зависимостях

SBOM становится особенно полезным вместе с базами известных уязвимостей и автоматическими сканерами безопасности.

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

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

Поэтому проверка зависимостей не заканчивается после сборки приложения. Состав программы практически не меняется, но информация о безопасности её компонентов постоянно обновляется.

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

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

Как SBOM работает на практике

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

Главная ценность такого подхода в том, что SBOM становится частью обычного жизненного цикла программы. Если состав приложения меняется, перечень можно обновлять вместе с новой сборкой.

Создание SBOM во время разработки и сборки программы

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

Например, разработчик добавляет новую библиотеку в проект. При следующей сборке система автоматически обнаруживает этот компонент, определяет его версию и добавляет в новый SBOM.

Такой подход особенно удобен в автоматизированной разработке. Генерацию SBOM можно встроить в CI/CD-процесс вместе с тестированием, сборкой приложения и проверками безопасности.

В этом случае Автоматизация процессов разработки: как ускорить релизы и повысить стабильность IT-продукта может включать не только автоматические тесты и развёртывание, но и постоянный контроль состава программного продукта.

Для каждого релиза можно сохранять отдельный SBOM. Это позволяет точно определить, какие компоненты находились внутри конкретной версии программы даже спустя несколько месяцев после её выпуска.

Проверка компонентов и их версий

После создания SBOM его можно передать системе анализа уязвимостей. Она извлекает названия компонентов, номера версий и другие идентификаторы, а затем сравнивает их с информацией из баз известных уязвимостей.

Допустим, внутри приложения обнаружена библиотека версии 2.7.4. Если для неё зарегистрирована известная проблема безопасности, система может автоматически отметить компонент как потенциально уязвимый.

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

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

Что происходит при обнаружении уязвимой зависимости

Если система находит потенциально опасный компонент, первым шагом становится определение масштаба проблемы. Команда проверяет, какие приложения и версии продукта содержат эту зависимость.

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

Если исправленная версия компонента уже существует, зависимость обычно обновляют, после чего приложение заново собирают и тестируют. Новый SBOM должен отражать уже обновлённый состав.

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

Таким образом, SBOM помогает не только обнаружить проблему, но и быстро определить, где именно необходимо выполнить обновление.

Почему SBOM нужно постоянно обновлять

SBOM полезен только тогда, когда соответствует реальному состоянию программы. Если перечень был создан год назад, а после этого разработчики несколько раз меняли зависимости, использовать его для анализа безопасности уже опасно.

Поэтому правильнее рассматривать SBOM не как документ, который создаётся один раз, а как часть каждой версии программного продукта.

Новый релиз получил новую библиотеку - меняется SBOM. Обновилась версия существующего пакета - меняется SBOM. Компонент удалили - он должен исчезнуть и из перечня.

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

Форматы SBOM: CycloneDX и SPDX

Сам SBOM - это не один конкретный формат файла. Чтобы разные инструменты могли создавать, передавать и анализировать такие перечни компонентов, используются стандартизированные форматы. Два самых известных варианта - CycloneDX и SPDX.

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

CycloneDX

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

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

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

CycloneDX поддерживается множеством инструментов для анализа зависимостей, контейнеров и программных проектов. Поэтому его часто можно встретить в процессах DevSecOps и автоматического контроля безопасности.

SPDX

SPDX расшифровывается как Software Package Data Exchange. Этот формат изначально получил широкое применение для описания программных пакетов, лицензий и происхождения компонентов.

В SPDX можно указывать сведения о пакетах, отдельных файлах, версиях, авторах, лицензиях и отношениях между элементами программного продукта. Благодаря этому формат подходит не только для анализа безопасности, но и для контроля использования стороннего кода.

Это важно для крупных проектов с большим количеством open source-компонентов. Некоторые библиотеки распространяются на условиях, которые требуют определённого способа использования или распространения исходного кода. Структурированный перечень помогает компаниям понимать, какие лицензии присутствуют внутри продукта.

При этом SPDX также может использоваться как полноценный формат SBOM и передавать информацию, необходимую для автоматизированного анализа компонентов.

Нужно ли разработчику выбирать формат вручную

Во многих проектах разработчику не приходится самостоятельно решать, каким должен быть SBOM. Формат часто определяется используемыми инструментами, требованиями компании, заказчика или инфраструктуры безопасности.

Один сканер может по умолчанию экспортировать CycloneDX, другой - SPDX, а некоторые системы поддерживают сразу несколько вариантов.

Поэтому важнее не столько выбрать "лучший" стандарт, сколько убедиться, что созданный SBOM действительно содержит полный и актуальный состав приложения.

Если инструмент пропустил часть транзитивных зависимостей или неправильно определил версии компонентов, даже идеально оформленный файл не даст надёжной картины безопасности.

На практике компании также могут преобразовывать один формат в другой или хранить несколько вариантов одного и того же SBOM, если этого требуют разные системы.

Главное преимущество стандартных форматов состоит в совместимости. Разработчик может создать SBOM одним инструментом, передать его другой системе и автоматически проверить компоненты без ручного переноса данных.

Почему одного SBOM недостаточно для безопасности программы

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

Его основная задача - дать точную информацию о компонентах. Дальше эту информацию необходимо использовать: сопоставлять с базами уязвимостей, оценивать риски, обновлять зависимости и контролировать новые версии продукта.

SBOM показывает состав, но не исправляет уязвимости

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

После этого начинается обычная работа команды безопасности и разработчиков. Необходимо понять серьёзность уязвимости, проверить наличие исправленной версии, оценить совместимость обновления и выпустить новую сборку программы.

Поэтому SBOM правильнее сравнивать не с антивирусом, а с подробной картой. Карта показывает, где находится проблема, но устранять её всё равно приходится другими средствами.

Кроме того, не каждая уязвимость одинаково опасна для конкретного приложения. Если проблемный участок библиотеки никогда не вызывается программой, реальный риск может быть ниже. В других случаях достаточно самого присутствия компонента или определённой конфигурации, чтобы система оказалась под угрозой.

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

Проблемы устаревших и неполных SBOM

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

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

Обратная ситуация возникает после обновлений. Компания может заменить проблемный пакет безопасной версией, но продолжить использовать старый SBOM. Система анализа будет считать приложение уязвимым, хотя реальный состав уже изменился.

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

Есть и более сложная проблема: не все компоненты одинаково легко идентифицировать. Внутри коммерческого ПО могут находиться изменённые версии библиотек, внутренние пакеты компании или компоненты без стандартных идентификаторов. Это усложняет автоматическое сопоставление с внешними базами данных.

SBOM как часть безопасности цепочки поставок ПО

Современная программа зависит не только от собственного исходного кода. В её создании участвуют менеджеры пакетов, сторонние библиотеки, контейнеры, системы сборки, репозитории и различные инструменты разработки.

Все эти элементы образуют программную цепочку поставок. Если один из компонентов оказывается скомпрометирован, проблема может попасть во множество продуктов одновременно.

Поэтому Кибербезопасность 2026: новые угрозы, тренды и лучшие технологии защиты включает не только защиту серверов и аккаунтов, но и постоянный контроль сторонних компонентов, от которых зависит работа программ.

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

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

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

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

FAQ

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

   SBOM - это структурированный список компонентов, из которых состоит программа. В нём указываются библиотеки, пакеты, их версии и связи между зависимостями. Такой перечень помогает понять реальный состав приложения и быстрее найти потенциально уязвимые компоненты.

2. Зачем SBOM нужен обычной программе?

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

3. Может ли SBOM автоматически найти уязвимость?

   Сам SBOM уязвимости не ищет. Он предоставляет данные о составе программы.
   Для поиска проблем его используют вместе со специальными сканерами и базами известных уязвимостей. Система сравнивает компоненты и их версии из SBOM с опубликованными сведениями об угрозах и отмечает потенциально опасные совпадения.
   После этого разработчики должны оценить реальный риск и при необходимости обновить зависимость или принять другие меры защиты.

4. Чем CycloneDX отличается от SPDX?

   CycloneDX и SPDX - два распространённых стандарта описания SBOM.
   CycloneDX активно используется в задачах безопасности программной цепочки поставок и хорошо подходит для описания компонентов и зависимостей между ними. SPDX также позволяет создавать SBOM, но исторически большое внимание в нём уделялось информации о программных пакетах, происхождении компонентов и лицензиях.
   Для большинства проектов важнее не название формата, а полнота и актуальность данных внутри SBOM.

Заключение

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

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

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

Чтобы такой подход действительно работал, SBOM необходимо создавать для каждой актуальной версии продукта и обновлять вместе с изменениями зависимостей. В сочетании со сканированием компонентов и регулярными обновлениями это значительно упрощает контроль программной цепочки поставок.