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

...

Что не так со SBOM и как действительно защитить цепочку поставок ПО

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

1. Введение
2. Что именно даёт SBOM
3. Почему SBOM не гарантирует безопасность ПО
4. Что это означает для российских компаний
5. Выводы

Введение

Современное программное обеспечение редко пишется с нуля. В его основе десятки, а иногда и сотни внешних компонентов: open-source библиотек, коммерческих SDK, фреймворков и зависимостей. Каждый новый компонент добавляет ещё одно звено в цепочку поставок ПО. Если такой компонент окажется уязвимым или скомпрометированным, проблема может затронуть продукты, в которых этот компонент используется.

Риски растут вместе с числом внешних зависимостей. По данным аналитиков, за первые восемь месяцев 2025 года количество атак на цепочки поставок выросло на 110% по сравнению с аналогичным периодом 2024 года. Чаще всего они затрагивают промышленность (41%), ретейл (32%), энергетику (15%) и высокотехнологичные компании (12%).

При таком количестве зависимостей компании нужно как минимум понимать, из чего состоит используемое ПО. Для этого применяют SBOM (Software Bill of Materials) — машиночитаемый перечень компонентов продукта. Он позволяет сопоставить состав ПО с базами уязвимостей и быстрее определить, какие версии компонентов требуют внимания.

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

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

Что именно даёт SBOM

SBOM — это машиночитаемый список компонентов, из которых состоит программный продукт. В зависимости от формата он также содержит сведения о версиях, поставщиках, зависимостях и других характеристиках компонентов.

Обычно в SBOM входят:

название и версия компонента;
поставщик;
идентификаторы Package URL (purl) и CPE;
зависимости между компонентами;
хеш-суммы и сведения о лицензиях.

Главная ценность SBOM — прозрачность состава ПО. Его можно загрузить в SCA-систему (Software Composition Analysis, анализ состава ПО), сопоставить с базами уязвимостей и быстро определить, какие продукты используют уязвимый компонент.

Чаще всего используют два формата: SPDX (Software Package Data Exchange) и CycloneDX.

SPDX (проект Linux Foundation) стал международным стандартом ISO/IEC 5962:2021 и широко применяется для описания компонентов и лицензий. CycloneDX (проект OWASP) создавался с упором на безопасность цепочки поставок. Формат описывает компоненты, зависимости, хеши и другие сведения, которые можно использовать при анализе состава ПО и управлении уязвимостями.

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

Рисунок 1. Области применения SBOM (источник: OX Security)

Почему SBOM не гарантирует безопасность ПО

Разберём основные ограничения.

1. SBOM показывает состав, но не безопасность компонентов

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

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

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

Для этого используют VEX (Vulnerability Exploitability eXchange) — машиночитаемую информацию о том, затрагивает ли конкретная уязвимость определённый продукт и нужны ли меры по её устранению. Например, в VEX можно указать статус not_affected, если уязвимость есть в используемой версии библиотеки, но в конкретном продукте нет условий для её эксплуатации.

Эти инструменты решают разные, но связанные задачи:

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

Вместе они формируют основу для принятия решения о том, есть ли реальный риск и что с ним делать.

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

Что делать

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

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

2. SBOM может быть неполным и устаревшим

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

Полнота зависит от способа формирования SBOM. CISA выделяет шесть типов:

SBOM проектирования (Design SBOM) создаётся на этапе проектирования и описывает компоненты и зависимости, которые планируется использовать в продукте, в том числе ещё не реализованные.
SBOM исходного кода (Source SBOM) создаётся по исходному коду и зависимостям проекта. Он показывает состав ПО на этапе разработки, но может не учитывать компоненты, которые появляются при сборке или во время работы приложения.
SBOM сборки (Build SBOM) формируется во время сборки и связывает компоненты с конкретным артефактом. При этом часть косвенных или динамически загружаемых зависимостей может остаться за пределами анализа.
SBOM анализа (Analyzed SBOM или Binary SBOM) создаётся при анализе готового артефакта: пакета, исполняемого файла или контейнера. Такой подход позволяет анализировать ПО без доступа к исходному коду и сборочной среде. Полнота зависит от возможностей инструмента.
SBOM развёрнутого ПО (Deployed SBOM) описывает состав ПО, установленного в системе. Это статический снимок развёрнутого артефакта.
SBOM среды выполнения (Runtime SBOM) формируется во время работы приложения и помогает определить, какие компоненты присутствуют в работающей системе, в том числе динамически загружаемые.

Проблема особенно заметна при работе с транзитивными зависимостями — компонентами, которые добавляются в проект через другие зависимости. Например, приложение напрямую использует библиотеку A, которая требует библиотеку B. Если генератор SBOM зафиксировал только библиотеку A и не указал зависимость от B, состав ПО будет неполным. В результате уязвимость в библиотеке B может остаться незамеченной.

В исследовании 2026 года проанализировали 78 612 публичных SBOM-файлов из набора Wild SBOMs. Из них удалось разобрать 77 092 документа. Результаты показали:

в 52,9% документов вообще не было связей между компонентами;
8,8% имели блок зависимостей, но при этом большинство компонентов оставались изолированными;
38,3% содержали связанные графы зависимостей.

Авторы отдельно отмечают, что отсутствие связи нельзя считать доказательством отсутствия зависимости.

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

Национальный центр кибербезопасности Великобритании (National Cyber Security Centre) рекомендует создавать новый SBOM при каждой сборке и предупреждает, что неточный SBOM может создать неверное представление о составе ПО.

Что делать

При разработке ПО автоматически создавайте SBOM в CI/CD при каждой сборке или выпуске артефакта и проверяйте его качество: наличие версий, идентификаторов purl и CPE, а также связей между компонентами. Связывайте SBOM с конкретной версией и хешем артефакта.

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

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

Рисунок 2. Как меняется состав ПО на этапах разработки, сборки и поставки (источник: NTIA)

3. Идентификация компонентов

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

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

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

Для точного сопоставления используют устойчивые идентификаторы. Например, purl (Package URL) описывает тип пакета, его источник, имя и версию. CPE (Common Platform Enumeration) — стандарт идентификации программных и аппаратных продуктов, который используют при сопоставлении компонентов с данными об уязвимостях.

Для российских систем нужно учитывать идентификаторы и правила сопоставления, используемые БДУ ФСТЭК России.

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

Что делать

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

При анализе ПО с помощью SCA проверяйте результаты автоматического сопоставления для новых и критичных компонентов, особенно если инструмент не смог однозначно их идентифицировать. При выборе SCA-инструмента учитывайте поддержку нужных источников данных об уязвимостях, включая БДУ ФСТЭК России, и проверяйте актуальность загружаемых данных.

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

4. SBOM не описывает происхождение артефакта и не защищает CI/CD

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

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

Однако provenance не защищает саму среду сборки. Если злоумышленник получил возможность изменить процесс в CI/CD, система может создать артефакт с вредоносным содержимым и зафиксировать этот процесс в provenance.

Это показала атака Mini Shai-Hulud в мае 2026 года. Злоумышленники скомпрометировали 84 npm-артефакта в 42 пакетах TanStack. Атака использовала ошибку в настройке GitHub Actions, отравление кеша и кражу OIDC-токена, что позволило опубликовать вредоносные пакеты через легитимный CI/CD-процесс.

При этом атака не доказывает несостоятельность SLSA Build Level 3. Скомпрометированная платформа не соответствовала требованиям изоляции, предусмотренным этим уровнем. Платформа, соответствующая SLSA Build Level 3, должна была предотвратить использованный в атаке способ компрометации — отравление кеша.

Рисунок 3. Векторы компрометации цепочки поставок ПО (источник: Google)

В SLSA 1.2 Build Track предусмотрены три уровня защиты.

Уровень 1 (L1) — сборочная система формирует provenance с информацией о создании артефакта: кто собирал, какой процесс использовался, какие были входные данные. Уровень фиксирует факт сборки для последующего анализа, но не защищает от подмены.

Уровень 2 (L2) — сборка выполняется на управляемой сборочной платформе (hosted build platform), которая сама генерирует и криптографически подписывает provenance. Пользователь может проверить, что данные о происхождении действительно созданы доверенной платформой и не были изменены после сборки.

Уровень 3 (L3) — сборочная платформа дополнительно защищает сам процесс сборки от вмешательства. Одна сборка не должна влиять на другую, а шаги пользовательской сборки не должны получать доступ к секретам платформы, например к ключу, который используется для подписи provenance. Это снижает риск того, что скомпрометированная сборка изменит результат другой сборки или получит возможность создавать поддельный provenance.

Не обязательно сразу внедрять самый высокий уровень. Можно начать с L1, чтобы получать сведения о процессе сборки, а затем перейти к подписанному provenance на L2 и усилить защиту среды сборки на L3.

Что делать

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

Если вы управляете средой сборки, применяйте практики SLSA для повышения её защищённости, ограничивайте права CI/CD-систем и защищайте секреты. При необходимости разделяйте сборочные среды с учётом критичности продукта. Контролируйте изменения в репозиториях, сценариях автоматизации и конфигурации сборки, чтобы вовремя обнаруживать несанкционированные изменения.

Рисунок 4. Модель данных SLSA Provenance (источник: SLSA)

5. SBOM нужно проверять на подлинность и целостность

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

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

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

Что делать

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

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

Если поставщик не предоставляет данных, необходимых для такой проверки, учитывайте это при оценке рисков.

6. SBOM не показывает, что происходит с ПО во время работы

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

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

Для критичных систем полезно сравнивать SBOM с составом ПО в production-среде. Runtime SBOM и другие инструменты анализа работающего ПО помогают находить расхождения между составом артефакта и тем, что фактически запущено. При этом можно учитывать внешние зависимости и используемые API.

Что делать

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

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

7. Сам SBOM тоже нужно защищать

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

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

Что делать

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

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

Что это означает для российских компаний

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

ГОСТ Р 56939-2024 описывает процессы безопасной разработки ПО, включая управление конфигурацией и составом программных компонентов. Для государственных информационных систем, информационных систем госорганов, государственных унитарных предприятий и учреждений действуют требования приказа ФСТЭК России № 117. В случаях, когда оператор самостоятельно разрабатывает ПО для таких систем, управление составом ПО становится обязательным.

При работе с уязвимостями российским организациям также нужно учитывать БДУ ФСТЭК России наряду с другими источниками, когда это применимо. Уязвимости в БДУ получают собственные идентификаторы, которые могут использоваться наряду с международными идентификаторами CVE. Поэтому SCA-инструмент должен уметь сопоставлять компоненты из SBOM с записями об уязвимостях в БДУ и других базах.

Выводы

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

Для оценки рисков SBOM используют вместе с другими механизмами. SCA сопоставляет компоненты с базами уязвимостей, VEX помогает определить применимость найденной уязвимости к конкретному продукту, provenance связывает артефакт с исходным кодом и процессом сборки, а SLSA задаёт требования к защите сборочной среды. Дополнительно нужно контролировать поставщиков и проверять состояние ПО после его развёртывания.

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

Полезные ссылки:

У клиентов LastPass украли личные данные через подрядчика

Атаки на цепочки поставок ПО: как они работают и как защититься

Как в 2025 доверие обернулось угрозой: анализ атак на цепочки поставок