SBOM: как бизнесу увидеть, из чего состоит его софт, и сделать его безопаснее

Почему прозрачность в программном обеспечении становится новой нормой безопасности — и как «список ингредиентов» для кода помогает компаниям избежать проблем.

Цифровой бизнес строится на чужом коде — и это риск

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

Но есть обратная сторона: вместе с удобством приходит зависимость от чужого кода, а значит, и уязвимости, которые могут стать угрозой для бизнеса. Когда в 2021 году в популярной библиотеке Log4j нашли критическую уязвимость, тысячи компаний по всему миру спешно проверяли: «А мы-то используем её или нет?» Во многих случаях ответить на этот вопрос было невозможно: у компаний просто не было списка компонентов, из которых состоит их продукт.

Как компании сейчас решают проблему — практика SCA

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

Так появился подход SCA (Software Composition Analysis) — анализ состава программного обеспечения. SCA-инструменты автоматически исследуют проект и формируют полную картину его зависимостей. Они позволяют:

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

SCA стал ключевым элементом современной практики DevSecOps, когда контроль безопасности встроен прямо в процесс разработки. Неотъемлемой частью практики SCA является формат SBOM.

Что такое SBOM

SBOM (Software Bill of Materials) — это файл в формате JSON или XML (структурированное описание и перечисление объектов), который включает в себя инвентаризационный список всех компонентов (пакетов, библиотек), используемых в разрабатываемом приложении или необходимых для его работы. Простыми словами, это «список ингредиентов» программного обеспечения.

Он показывает:

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

Фактически SBOM — это файл, который говорит:

«Наш продукт использует библиотеку X версии 2.3, библиотеку Y версии 1.4, и они зависят от библиотеки Z версии 0.9».

Поиск зависимостей в проекте является непростой задачей: разные экосистемы пакетов указывают использование тех или иных сторонних зависимостей по-разному, и к каждой нужен собственный подход для их определения. Например, в Java используется экосистема пакетов Maven и зависимости указываются в файле манифеста pom.xml. В Python применяется пакетный менеджер pip, а зависимости могут указываться по-разному — в файле requirements.txt или в Pipfile (если используется инструмент Pipenv).

Два наиболее популярных стандарта (формата) файла SBOM — CycloneDX и SPDX. Существует множество различных инструментов для автоматического поиска зависимостей и сборки SBOM, в их числе — Trivy, Syft, cdxgen. Они используют разные подходы к определению зависимостей проекта, но в среднем все справляются с этой задачей и выдают подробный и структурированный SBOM.

Какие задачи SBOM решает в сфере ИБ?

SBOM позволяет решить две связанные задачи:

1. Инвентаризировать все используемые в продукте (исходном коде, артефакте, операционной системе) компоненты;
2. Автоматизировать анализ их безопасности с помощью инструментов SCA. Политики безопасности могут включать в себя проверку компонентов на уязвимости и лицензионную чистоту, а также на дату публикации, имя автора и другие элементы.

Решение обеих задач позволит снизить риск атаки на цепочку поставок ПО.

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

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

Стоит отметить, что наличие уязвимой библиотеки в составе ПО ещё не говорит о присутствии уязвимости, которую могли бы эксплуатировать злоумышленники. Для этого уязвимая функция должна быть достижима из кода, и при этом данные, которые в неё поступают, не должны быть защищены дополнительными мерами безопасности. Большинство инструментов SCA не отвечают на вопрос о возможности эксплуатации найденной уязвимости — для этого требуется ревью AppSec-инженера или разработчика. Однако сейчас некоторые решения уже начинают анализировать совместно и код, и набор библиотек, что помогает снизить количество ложноположительных (False Positive) срабатываний и объём ручной работы по их нахождению.

Зачем бизнесу знать состав своего кода

Понимание состава ПО — это не техническая прихоть, а вопрос управления рисками и ответственности.

Определение состава ПО позволяет:

1. Быстрее реагировать на угрозы. Когда появляется новая уязвимость (например, CVE-2025-xxxx), компания может мгновенно понять, затронута ли она, если есть SBOM. Без него на поиск ответа могут уйти дни или недели.
2. Минимизировать репутационные и финансовые потери. Утечка данных или сбой из-за «чужой» уязвимости — это не только техническая проблема. Это потеря доверия, уход клиентов, штрафы и возможные иски.
3. Контролировать цепочку поставок ПО. Если вы закупаете программное обеспечение или заказываете его у подрядчика, SBOM помогает убедиться, что внутри нет «сюрпризов» — старых библиотек, вредоносных модулей или компонентов без лицензии.
4. Упростить аудит и обеспечить соответствие отраслевым и регуляторным требованиям. Во многих странах SBOM становится обязательным элементом при поставках ПО государственным или критическим структурам. Например, в США после президентского указа о кибербезопасности (Executive Order 14028) поставщики федеральных систем должны предоставлять SBOM вместе с продуктом. Похожие инициативы появляются также в Европе и Азии.

Если говорить о практике регулирования и требований к SBOM в Российской Федерации, то можно отметить следующее:

• По требованию ФСТЭК России (информационное письмо № 240/24/4436 от 26.09.2024) изготовители средств защиты информации (далее — СЗИ), испытательные лаборатории и органы по сертификации при проведении сертификации СЗИ, включающих в свой состав заимствованные программные компоненты с открытым исходным кодом, должны проводить сертификационные испытания СЗИ и осуществлять их поддержку безопасности с учётом заимствованных компонент.
• ГОСТ Р 56939-2024, который описывает процессы разработки безопасного ПО, устанавливает, что процесс композиционного анализа должен включать в числе прочего процесс по формированию перечня заимствованного ПО, а также его постоянную актуализацию и контроль на предмет наличия известных уязвимостей.

Вывод

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

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

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

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