SBOM (Software Bill of Materials)

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

Что такое SBOM

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

Существует несколько форматов SBOM, самыми распространенными среди которых являются Software Package Data eXchange (SPDX), CycloneDX, SWID по стандарту ISO/IEC 19770-2:2015. Чтобы сгенерировать спецификацию в выбранном формате, необходимо воспользоваться специальными плагинами и платформами, например, ActiveState, Maven или Gradle.

Как выглядит SBOM? Это файл XML или JSON, включающий следующие блоки:

• Метаданные файла: метка времени создания, спецификации, индивидуальный номер.
• Перечень и описание компонентов.
• Источник файла SBOM.
• Описание зависимостей между компонентами.

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

Цели и задачи Software Bill of Materials в контексте информационной безопасности

SBOM помогает команде разработки безопасно использовать Open source-компоненты, делать выводы о целесообразности их внедрения, прогнозировать риски, связанные с уязвимостями в сторонних библиотеках. Благодаря Software Bill of Materials разработчики могут предусмотреть потенциальные векторы атак на Supply Chain — цепочку поставок, под которой понимают все этапы пути ПО с момента создания до попадания к конечному потребителю. Такие атаки происходят достаточно часто, поэтому необходимо заранее определить уязвимые звенья цепи и продумать меры реагирования.

Частные задачи SBOM, позволяющие минимизировать риски Supply Chain-атак:

• Инвентаризация всех компонентов, использованных при создании программного продукта.
• Автоматизация контроля безопасности составляющих ПО с помощью инструментов Software Composition Analysis (SCA) — анализа состава программного обеспечения, который позволяет проверять заимствованные компоненты на уязвимости и лицензионную чистоту. Также применяется анализ Supply Chain Security (SCS) для оценки рисков атак на цепочку поставок.

Также с помощью SBOM контролируется целостность ПО и всех его компонентов.

Для кого важен SBOM

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

Проблемы внедрения SBOM

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

• Для поддержания точных SBOM нужны инвестиции в технологии и инструменты.
• Потребуется интеграция инструментов управления спецификацией с конвейерами CI/CD.
• Возникнет необходимость тщательного отслеживания всех компонентов ПО для поддержания полноты SBOM.

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

Анализ SBOM с помощью анализатора Solar appScreener

SBOM анализируется с помощью таких технологий, как Software Composition Analysis (SCA) и Supply Chain Security (SCS), которые в автоматическом анализаторе Solar appScreener объединены в общий модуль — OSA. В него также входит анализ лицензионных рисков, который можно выполнить, зная Software Bill of Materials.

Коротко расскажем, в чем суть перечисленных технологий:

• SCA — детальный анализ состава программного обеспечения. С его помощью можно обнаружить все заимствованные компоненты, проверить безопасность сторонних библиотек и выявить проблемы с лицензированием Open source-фрагментов.
• SCS — технология, позволяющая прогнозировать риски, связанные с тем или иным звеном цепочки поставок. Solar appScreener выставляет каждому проверяемому компоненту оценку доверия на основе определенных метрик.
• Анализ лицензионных рисков — оценка возможных проблем с лицензированием сторонних компонентов (например, устаревшие лицензии или несовместимые для разных компонентов).

Применение этих технологий и использование SBOM-файла позволит всесторонне проанализировать безопасность Open source-компонентов и эффективно управлять рисками ИБ. Но следует понимать, что обнаруженные уязвимости в сторонних библиотеках и открытых компонентах не говорят о том, что в готовом ПО обязательно будут слабые места, которые смогут проэксплуатировать злоумышленники. Чтобы атака состоялась, уязвимые функции должны быть достижимы именно из программного кода. Обнаружить такие бреши безопасности можно с помощью статического анализа — Static Application Security Testing (SAST). Платформа Solar appScreener предоставляет все необходимые инструменты для его проведения. Также с помощью анализатора можно внедрить динамическое тестирование — Dynamic Application Security Testing (DAST). Оно позволяет проверить, как приложение будет вести себя в эксплуатации и обнаружить уязвимости, которые нельзя выявить до запуска ПО.

Как Solar appScreener проводит SCA-анализ

Если есть готовый SBOM-файл, необходимо загрузить его в анализатор, после чего модуль SCA проверит предоставленные данные по базам сторонних компонентов и уязвимостей. Также анализатор использует собственные базы, разработанные экспертами ГК «Солар», благодаря чему возрастает эффективность анализа.

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