SBOM не гарантирует безопасность ПО: как реально защитить цепочку поставок
SBOM показывает состав, но не безопасность компонентов
SBOM предоставляет перечень компонентов программного обеспечения и их версий. Это позволяет сопоставить состав ПО с базами данных известных уязвимостей. Однако сам по себе SBOM не оценивает реальную опасность уязвимости для конкретной системы. Для определения риска необходимо выяснить, используется ли уязвимый код, доступен ли он извне и задействован ли в рабочих сценариях. Наличие уязвимости в компоненте не означает автоматическую уязвимость всего продукта.
Проблема касается и устаревших зависимостей. По данным Sonatype, 80% зависимостей остаются необновлёнными более года. SBOM помогает выявить такие компоненты, но решение об их обновлении и сроках принимает команда разработки. Для уточнения, затрагивает ли уязвимость конкретный продукт, используют VEX (Vulnerability Exploitability eXchange). VEX предоставляет машиночитаемую информацию о том, влияет ли уязвимость на продукт, и требуются ли меры по её устранению. Например, статус not_affected указывает, что уязвимость не эксплуатируется в данном продукте.
SBOM не обнаруживает неизвестные уязвимости или вредоносное поведение компонентов. Если угроза ещё не зарегистрирована в базе данных уязвимостей или компонент скомпрометирован, SBOM не выявит такую угрозу.
Обновиться до актуальной версии или поставить плагин безопасности
При выпуске программного обеспечения необходимо формировать SBOM для каждой версии. Компоненты следует проверять с помощью SCA-систем (Software Composition Analysis) и отслеживать появление новых уязвимостей. Для критических проблем нужно проверять фактическое использование уязвимого кода и условия для его эксплуатации. Результаты проверки необходимо фиксировать в VEX. Приоритет исправления уязвимостей определяется с учётом CVSS, возможности эксплуатации, фактического использования компонента и критичности системы.
SBOM может быть неполным и устаревшим
SBOM описывает состав программного обеспечения на определённом этапе его жизненного цикла. Если при создании не удалось определить часть зависимостей или состав продукта изменился после формирования SBOM, документ перестаёт точно отражать реальное положение дел. Полнота SBOM зависит от способа его формирования. Существуют различные типы SBOM: проектирования, исходного кода, сборки, анализа, развёрнутого ПО и среды выполнения. Каждый тип имеет свои ограничения.
Проблема особенно актуальна для транзитивных зависимостей — компонентов, которые добавляются в проект через другие зависимости. Если генератор SBOM не учитывает такие цепочки, состав ПО будет неполным. Уязвимость в таком компоненте может остаться незамеченной. Исследование 2026 года показало, что в 52,9% проанализированных SBOM-файлов отсутствовали связи между компонентами.
Актуальность SBOM также важна. После выпуска ПО разработчики могут обновлять библиотеки или изменять версии контейнерных образов. Если SBOM не обновляется, он будет описывать предыдущий состав продукта. Национальный центр кибербезопасности Великобритании рекомендует создавать новый SBOM при каждой сборке.
При разработке ПО добавляйте в SBOM идентификаторы purl и CPE
После формирования SBOM, SCA-инструмент сопоставляет компоненты с данными об уязвимостях, анализируя их названия, версии и другие характеристики. Сложности возникают из-за различий в наименованиях компонентов, форматах версий и сведениях о поставщиках в разных источниках. Один и тот же компонент может иметь разные обозначения в проекте, SBOM и базе уязвимостей.
Для точного сопоставления используют устойчивые идентификаторы, такие как purl (Package URL) и CPE (Common Platform Enumeration). Purl описывает тип пакета, его источник, имя и версию. CPE — стандарт идентификации программных и аппаратных продуктов, используемый для сопоставления компонентов с данными об уязвимостях. Для российских систем необходимо учитывать идентификаторы и правила сопоставления, используемые БДУ ФСТЭК России.
Если компонент не удалось однозначно идентифицировать, SCA может связать его с уязвимостью другого компонента или версии, что приводит к ложным срабатываниям или пропуску информации об уязвимости.
При разработке ПО автоматически создавайте SBOM в CI/CD
При разработке программного обеспечения следует добавлять в SBOM идентификаторы purl и CPE, когда это применимо, и проверять корректность этих идентификаторов. SBOM необходимо связывать с конкретным программным артефактом и его хешем для последующей проверки соответствия. При анализе ПО с помощью SCA следует проверять результаты автоматического сопоставления для новых и критичных компонентов, особенно если инструмент не смог их однозначно идентифицировать. При выборе SCA-инструмента важно учитывать поддержку нужных источников данных об уязвимостях, включая БДУ ФСТЭК России, и проверять актуальность загружаемых данных. Для собственных и малоизвестных компонентов рекомендуется вести внутренний реестр с названиями, версиями, идентификаторами и источниками.
SBOM не описывает происхождение артефакта и не защищает CI/CD
SBOM демонстрирует состав программного артефакта, включая отдельные сведения о сборке, такие как инструменты, время создания и хеши. Однако он не всегда описывает полное происхождение артефакта: из какого исходного кода и в каком процессе он был создан. Для полного понимания происхождения артефактов применяют концепцию provenance, которая включает информацию о процессе сборки, используемых инструментах и исходных данных. Это позволяет оценить доверие к процессу сборки и самому артефакту. Без такой информации невозможно полностью оценить безопасность цепочки поставок ПО.
Источник: Anti-Malware