Как выявить неизвестные компоненты в программном обеспечении с помощью анализа SBOM

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

Главный принцип работы такой: SBOM (Software Bill of Materials, перечень компонентов программного обеспечения) не просто показывает, какие пакеты входят в приложение, а позволяет сопоставить фактический состав программы с ожидаемым. Если компонент отсутствует в описании, имеет неясное происхождение или обнаруживается только на этапе анализа собранного артефакта, это сигнал для дополнительной проверки. При этом сам SBOM не является гарантией полной видимости: качество результата зависит от способа его формирования и глубины проверки. citeturn0search25turn0academia26

Что именно считается неизвестным компонентом

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

К неизвестным компонентам могут относиться:

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

В зрелом процессе работы с SBOM важно различать две ситуации: компонент действительно отсутствует в программе или он есть, но не был корректно идентифицирован. Ошибка идентификации может привести к тому, что система не найдёт известные риски, даже если нужная библиотека фактически присутствует. citeturn0search27

Почему обычного списка зависимостей часто недостаточно

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

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

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

Как выявлять неизвестные компоненты через анализ SBOM

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

1. Создать SBOM для фактического программного артефакта

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

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

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

2. Сравнить SBOM с известными источниками компонентов

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

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

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

3. Найти расхождения между SBOM разных этапов

Один из практичных способов обнаружения неизвестных компонентов — сравнение нескольких SBOM:

1. создать SBOM исходного проекта;
2. создать SBOM готового результата сборки;
3. сравнить списки компонентов;
4. исследовать элементы, которые появились только на финальном этапе.

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

4. Проверить неизвестные элементы вручную

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

Полезно выяснить:

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

Какие признаки указывают на неизвестные компоненты

При анализе SBOM стоит обращать внимание не только на отсутствующие записи, но и на признаки неполноты данных.

Признак	Что это может означать	Что проверить
Компонент есть в файлах приложения, но отсутствует в SBOM	SBOM создан с недостаточной глубиной анализа	Повторить генерацию для готового артефакта
Нет версии или производителя	Компонент невозможно надёжно сопоставить с базами данных	Определить происхождение и идентификатор
В SBOM указаны неизвестные зависимости	Цепочка поставки описана неполностью	Получить дополнительные данные от поставщика или выполнить анализ самостоятельно
Одинаковый код определяется как разные компоненты	Проблема идентификации или вариаций компонентов	Проверить метаданные и происхождение кода

Отдельная сложность связана с тем, что разные инструменты могут по-разному определять границы компонента. Поэтому отсутствие записи в одном SBOM не всегда означает отсутствие программного элемента в продукте. citeturn0academia24

Какие инструменты используют для анализа SBOM

Для поиска неизвестных компонентов применяются инструменты двух типов: генераторы SBOM и системы анализа состава программного обеспечения (SCA).

Генераторы SBOM создают перечень компонентов. SCA-системы дополнительно помогают сопоставлять компоненты с базами уязвимостей, лицензиями и внутренними правилами безопасности. Некоторые платформы также позволяют хранить SBOM нескольких версий приложений и отслеживать изменения состава. citeturn0search1turn0search7

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

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

Почему SBOM может не показать все компоненты

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

• Неполная генерация. Инструмент мог анализировать только часть системы.
• Недостаточные метаданные. Компонент найден, но его невозможно правильно идентифицировать.
• Изменённый сторонний код. Модифицированная библиотека может не совпасть с оригинальной версией.
• Закрытые зависимости. Поставщик может не предоставить полную информацию.
• Разница между проектом и поставляемым продуктом. Итоговый артефакт может содержать элементы, которых не было в исходном описании.

Если зависимость неизвестна, это не всегда означает ошибку команды разработки. Иногда информация отсутствует на уровне поставщика. В таких случаях рекомендуется фиксировать неполноту данных и по возможности получать дополнительные сведения из цепочки поставки. citeturn0search25

Типичные ошибки при анализе SBOM

Проверять только прямые зависимости

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

Считать наличие SBOM доказательством полной прозрачности

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

Игнорировать качество идентификации

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

Не анализировать изменения между версиями

Компоненты меняются вместе с релизами. Сравнение SBOM разных версий помогает быстрее заметить появление новых зависимостей.

Практический порядок действий для проверки программного продукта

Если задача — найти неизвестные компоненты в конкретном приложении, удобно действовать по следующей схеме:

1. Определите объект проверки: исходный код, сборку, контейнер или готовый пакет.
2. Создайте SBOM максимально близко к реальному объекту эксплуатации.
3. Проверьте, что у каждого компонента есть понятный идентификатор и версия.
4. Найдите компоненты без происхождения или с неполными данными.
5. Сравните полученный список с ожидаемым составом продукта.
6. Разберите причины появления неизвестных элементов.
7. Добавьте найденные зависимости в процесс контроля изменений.

Когда особенно важно искать неизвестные компоненты

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

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

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

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

Практическая последовательность:

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

Главный принцип работы с неизвестными компонентами

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

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