Что такое SBOM (спецификация программного обеспечения) и зачем он нужен

SBOM (Software Bill of Materials, спецификация программного обеспечения) — это структурированный список компонентов, библиотек и зависимостей, входящих в состав программного продукта.

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

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

Сегодня SBOM является одним из ключевых элементов безопасности цепочки поставки программного обеспечения (Software Supply Chain Security).

Почему SBOM стал критически важен

Современные приложения состоят из большого количества сторонних компонентов. В enterprise-разработке доля open source-зависимостей может превышать 80–90%.

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

Наиболее известные инциденты последних лет:

• Log4Shell;
• SolarWinds;
• XZ Utils;
• атаки через заражённые npm- и PyPI-пакеты.

В таких условиях организациям необходимо:

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

Именно эту задачу решает SBOM.

Какие данные содержит SBOM

Современный SBOM обычно включает:

• название компонента;
• версию библиотеки;
• производителя;
• лицензию;
• зависимости;
• криптографические хэши;
• URL источника;
• идентификаторы PURL;
• идентификаторы CPE;
• сведения о сборке.

Пример данных SBOM:

Copy{
  "name": "log4j-core",
  "version": "2.17.2",
  "supplier": "Apache Software Foundation",
  "license": "Apache-2.0",
  "purl": "pkg:maven/org.apache.logging.log4j/log4j-core@2.17.2"
}

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

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

В эту систему также входят:

• SCA (Software Composition Analysis);
• анализ уязвимостей;
• проверка происхождения артефактов;
• цифровая подпись контейнеров;
• контроль CI/CD;
• аттестация сборок;
• доверенные реестры контейнеров.

SBOM помогает:

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

Форматы SBOM

Существует несколько основных форматов SBOM.

SPDX

SPDX (Software Package Data Exchange) — один из наиболее распространённых открытых стандартов описания программных компонентов.

Формат развивается организацией Linux Foundation и часто используется для:

• лицензирования;
• compliance-аудита;
• обмена данными между организациями.

SPDX хорошо подходит для юридического и лицензионного анализа.

CycloneDX

CycloneDX — современный формат SBOM, ориентированный прежде всего на безопасность.

Он активно используется в:

• DevSecOps;
• CI/CD;
• контейнерной инфраструктуре;
• Kubernetes;
• cloud-native средах.

CycloneDX поддерживает:

• уязвимости;
• криптографические данные;
• зависимости;
• сервисы;
• контейнерные артефакты.

Сегодня CycloneDX считается одним из наиболее перспективных форматов для secure software supply chain.

SWID

SWID (Software Identification Tags) применяется для инвентаризации программного обеспечения и управления IT-активами.

Чаще используется в enterprise-инфраструктуре и системах управления конфигурациями.

Чем CycloneDX отличается от SPDX

Хотя оба формата решают схожие задачи, между ними есть существенные различия.

SPDX чаще используется для:

• лицензионного compliance;
• юридического аудита;
• обмена информацией о пакетах.

CycloneDX чаще применяется для:

• DevSecOps;
• анализа уязвимостей;
• контейнерной безопасности;
• CI/CD;
• cloud-native инфраструктуры.

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

Что такое VEX и как он связан с SBOM

VEX (Vulnerability Exploitability eXchange) — это формат описания эксплуатационной применимости уязвимостей.

SBOM показывает:

какие компоненты входят в продукт.

VEX показывает:

действительно ли конкретная уязвимость опасна для данного продукта.

Например:

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

В этом случае VEX позволяет избежать ложных срабатываний и снизить объём ручного анализа.

Сегодня SBOM и VEX всё чаще используются совместно.

Как SBOM помогает управлять уязвимостями

SBOM значительно ускоряет реакцию на новые угрозы.

Когда публикуется новая CVE:

1. система анализирует SBOM;
2. определяется наличие уязвимого компонента;
3. оценивается влияние;
4. запускается обновление зависимостей.

Без SBOM подобная проверка часто выполняется вручную и занимает много времени.

SBOM в DevSecOps и CI/CD

Современные DevSecOps-процессы всё чаще автоматически генерируют SBOM на этапе сборки приложения.

Обычно SBOM создаётся:

• при Maven-сборке;
• во время Gradle pipeline;
• в GitLab CI;
• в GitHub Actions;
• в Jenkins.

После этого документ:

• подписывается;
• публикуется вместе с артефактом;
• передаётся в системы анализа безопасности.

SBOM для Java-приложений

Для Java-экосистемы SBOM особенно важен, поскольку приложения часто содержат большое количество сторонних библиотек.

Типичные источники зависимостей:

• Maven Central;
• Gradle dependencies;
• Spring Boot starters;
• Jakarta EE библиотеки.

Генерация SBOM позволяет:

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

SBOM для контейнеров и Kubernetes

В cloud-native средах SBOM используется не только для приложений, но и для контейнерных образов.

Container SBOM позволяет:

• анализировать состав Docker-образов;
• проверять базовые образы;
• отслеживать системные пакеты;
• контролировать уязвимости ОС и runtime.

Это особенно важно для:

• Kubernetes;
• OpenShift;
• Docker;
• OCI-совместимых платформ.

Сегодня многие организации внедряют:

• trusted images;
• image signing;
• provenance verification;
• проверку цепочки поставки контейнеров.

Инструменты генерации и анализа SBOM

Наиболее популярные инструменты:

Syft

Генерация SBOM для приложений и контейнеров.

Trivy

Сканирование контейнеров и анализ уязвимостей.

Grype

Анализ CVE и проверка компонентов.

Dependency-Track

Платформа мониторинга компонентов и supply chain risk.

CycloneDX Maven Plugin

Генерация SBOM для Maven-проектов.

SPDX Tools

Работа с SPDX-документами.

Пример генерации SBOM для Maven

Пример генерации CycloneDX SBOM:

mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom

После выполнения команды создаётся файл:

bom.xml

или

bom.json

Регуляторные требования и стандарты

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

Сегодня SBOM поддерживается:

• CISA;
• NIST;
• OpenSSF;
• Linux Foundation;
• OWASP Foundation.

SBOM также связан с:

• NIST SSDF;
• SLSA;
• Cyber Resilience Act (CRA);
• NIS2.

Во многих отраслях наличие SBOM постепенно становится обязательным требованием.

SBOM и доверенная поставка ПО

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

Для этого используются:

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

SBOM становится фундаментом этой системы.

Что в итоге?

SBOM уже перестал быть просто списком библиотек.

Сегодня это важнейший элемент:

• DevSecOps;
• безопасности цепочки поставки ПО;
• управления уязвимостями;
• compliance;
• container security;
• enterprise-разработки.

Использование SBOM позволяет организациям:

• быстрее реагировать на угрозы;
• контролировать зависимости;
• повышать прозрачность поставки ПО;
• снижать supply chain risk;
• соответствовать требованиям регуляторов.

По мере развития cloud-native инфраструктуры и DevSecOps значение SBOM будет только расти.