SPDX 3.0 и CycloneDX 1.7: выбор формата SBOM для CI и аудита

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

SPDX 3.0 и CycloneDX 1.7 развиваются в сторону общей модели прозрачности, поэтому их возможности частично пересекаются. Оба стандарта способны описывать компоненты, идентификаторы, отношения и сведения о безопасности. Однако акценты различаются: SPDX особенно силён в лицензировании, происхождении и универсальном графе фактов, а CycloneDX предлагает прикладную структуру для AppSec, сервисов, уязвимостей и криптографических активов.

Под SPDX 3.0 далее понимается ветка стандарта 3.0, включая опубликованную уточняющую редакцию 3.0.1. SPDX как семейство спецификаций признан международным стандартом ISO/IEC 5962. CycloneDX 1.7 поддерживает JSON, XML и Protocol Buffers, а его модель охватывает компоненты, сервисы, зависимости, уязвимости, криптографические активы, формирование и аттестации.

Краткий вывод

• Для AppSec-проверок в CI чаще удобнее CycloneDX 1.7: его объектная модель прямо ориентирована на компоненты, сервисы, зависимости, уязвимости, VEX и криптографические свойства.
• Для лицензионного аудита и передачи доказательств происхождения обычно предпочтительнее SPDX 3.0 благодаря глубокой лицензионной модели, гранулярности до файлов и фрагментов и гибкому графу отношений.
• Для SaaS, API и сервисных архитектур CycloneDX предлагает более готовую предметную модель.
• Для инвентаризации криптографии CycloneDX 1.7 имеет явное преимущество: криптографические активы представлены стандартизованными объектами и свойствами.
• При обязательном формате заказчика решающим становится контракт или профиль обмена, а не внутреннее предпочтение команды.
• В смешанном процессе допустимо выпускать оба формата, но их следует формировать из одного источника данных. Последовательная конвертация готовых документов может потерять часть семантики.

Главное различие моделей данных

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

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

CycloneDX организует данные вокруг BOM-документа с хорошо определёнными разделами: метаданные, компоненты, сервисы, зависимости, композиции, уязвимости, формирование, аннотации, декларации и другие сущности. Внутри документа объекты получают идентификаторы bom-ref, через которые строятся ссылки и граф зависимостей.

Такая структура обычно проще для прикладного потребителя. Сканер может сразу найти массив компонентов, сопоставить их по Package URL или CPE, затем обработать зависимости и раздел уязвимостей. SPDX требует от потребителя более полноценной работы с графом и профилями, зато позволяет выразить сложные отношения без привязки к одному заранее заданному дереву.

Сериализация и проверка документов

CycloneDX 1.7 официально поддерживает три сериализации:

• JSON — наиболее практичный вариант для CI, REST API, хранилищ артефактов и большинства сканеров;
• XML — подходит системам, где обмен, валидация и архивирование построены вокруг XML Schema;
• Protocol Buffers — компактное бинарное представление, полезное для высоконагруженного обмена, если все участники действительно его поддерживают.

Наличие Protocol Buffers в спецификации не означает, что его понимает любой генератор или сканер CycloneDX. Для интеграции важна поддержка конкретной комбинации: CycloneDX 1.7 и выбранной сериализации. На практике JSON остаётся самым безопасным вариантом обмена, если контрагенты не согласовали иное.

В SPDX 3.0 основной стандартизованный путь машинного обмена связан с JSON-LD. Модель имеет семантику графа, а описания модели и ограничения SHACL позволяют проверять классы, свойства и связи. Это удобно для объединения данных из нескольких источников, но предъявляет более высокие требования к потребителю, чем обработка обычного вложенного JSON.

Форматы SPDX 2.x нельзя автоматически считать сериализациями SPDX 3.0. Если инструмент заявляет экспорт в SPDX JSON, RDF, YAML или Tag/Value, необходимо проверить версию документа. Поддержка SPDX 2.2 или 2.3 не подтверждает поддержку профильной модели 3.0.

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

Компоненты и идентификаторы

Оба стандарта позволяют описать имя, версию, поставщика, контрольные суммы и внешние идентификаторы компонента. Для автоматического сопоставления особенно важен Package URL: пара «имя плюс версия» часто неоднозначна, тогда как корректный purl указывает экосистему пакета, пространство имён и дополнительные квалификаторы.

CycloneDX предлагает набор типов компонентов для приложений, библиотек, контейнеров, файлов, устройств, машинного обучения, данных и других объектов. Компоненты могут быть вложены друг в друга для описания состава сборки. При этом вложенность не заменяет граф зависимостей: структура «система — подсистема — часть» и отношение «зависит от» передаются отдельно.

В SPDX графовая модель позволяет связать пакеты, файлы и фрагменты кода. Гранулярность до файла или snippet особенно ценна при юридической проверке, когда лицензия отдельного файла отличается от лицензии пакета либо в исходный файл включён фрагмент с иными условиями.

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

Зависимости и полнота состава

CycloneDX представляет зависимости через ссылки между объектами. Граф способен охватывать прямые и транзитивные зависимости, а также отношения компонентов с сервисами и сервисов друг с другом. Такая модель естественно ложится на работу SCA-сканеров и визуализацию дерева зависимостей.

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

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

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

Лицензии и юридический аудит

SPDX исторически тесно связан с обменом лицензионными сведениями. Стандарт использует SPDX License List, идентификаторы исключений и выражения, позволяющие формально записывать сочетания вроде альтернативного или совместного лицензирования. Можно разделять заявленную автором лицензию, итоговый вывод аудитора и фактические наблюдения.

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

CycloneDX также использует идентификаторы и выражения SPDX. Версия 1.7 различает заявленные и заключённые лицензии, а наблюдения могут выступать доказательной базой. Помимо open source, модель способна хранить собственные названия и тексты лицензий, а также коммерческие сведения: лицензиара, лицензиата, покупателя, заказ на приобретение, даты продления и окончания.

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

Сервисы и SaaS

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

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

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

Граф SPDX позволяет представлять широкий набор сущностей и отношений, но для типового описания API и потоков данных CycloneDX предлагает более готовую предметную структуру. Если сервисы являются обязательной частью аудита, следует сначала проверить, заполняет ли генератор соответствующие поля, а не ограничиваться наличием возможности в спецификации.

Уязвимости и VEX

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

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

В SPDX 3.0 сведения VEX входят в профиль безопасности и связываются с элементами через формализованные отношения оценки. Графовый подход полезен, когда необходимо объединить уязвимость, продукт, доказательство, источник оценки и другие факты цепочки поставки.

Для операционного конвейера CycloneDX часто проще: его VEX-структура близка к объектам, с которыми работают системы управления уязвимостями. SPDX удобен, если организация уже строит единый граф происхождения и хочет включить VEX в более широкий набор утверждений.

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

Криптографические активы

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

Такая модель полезна при поиске устаревших алгоритмов, инвентаризации сертификатов и подготовке к миграции на постквантовые механизмы. Анализатору не приходится интерпретировать произвольные пользовательские поля: основные понятия стандартизованы.

SPDX может описать программные пакеты, файлы и отношения, связанные с реализацией криптографии, а расширяемость модели позволяет добавлять специализированные сведения. Однако базовая ветка SPDX 3.0 не предоставляет столь же прикладной и унифицированной модели криптографических активов, как CycloneDX 1.7.

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

Сборка, происхождение и аттестации

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

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

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

При настройке безопасной сборки полезно также учитывать практики хранения секретов, кэширования и выпуска аттестаций: подробнее они разобраны в статье о Docker BuildKit, secrets, SBOM и provenance.

Совместимость генераторов и сканеров

Название формата в списке возможностей инструмента ещё не гарантирует совместимость. При оценке генератора или сканера нужно проверить:

• какую версию SPDX или CycloneDX он создаёт и принимает;
• какие сериализации поддерживаются на чтение и запись;
• сохраняются ли идентификаторы, граф зависимостей и типы отношений;
• обрабатываются ли сервисы, VEX, лицензии и криптографические свойства;
• валиден ли результат по официальной схеме или модели;
• можно ли получить детерминированный документ для одной и той же сборки;
• не удаляются ли неизвестные поля при импорте и повторном экспорте;
• способен ли сканер сопоставлять компоненты по purl, CPE и контрольным суммам;
• различает ли система отсутствие данных и подтверждённое отсутствие риска.

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

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

Что выбрать для CI

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

CycloneDX 1.7 разумно выбрать основным форматом CI, если:

• главная задача — SCA и управление уязвимостями;
• нужно передавать VEX в том же семействе документов;
• в анализ входят API, SaaS и другие сервисы;
• планируется инвентаризация криптографии;
• все основные инструменты подтверждённо поддерживают схему 1.7;
• команде нужен обычный JSON с прямой объектной структурой.

SPDX 3.0 разумно выбрать основным форматом CI, если:

• результаты конвейера затем используются для детального лицензионного аудита;
• нужны связи между пакетами, файлами, фрагментами, сборками и источниками фактов;
• организация строит общий семантический граф цепочки поставки;
• партнёры или заказчики требуют SPDX;
• внутренние инструменты готовы работать с профилями и JSON-LD.

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

Для CI полезно отдельно проверять контейнерные образы до публикации. Практические подходы к сканированию образов, созданию SBOM и настройке порогов блокировки описаны в материале о Trivy в CI/CD.

Если генераторы, валидаторы или системы хранения SBOM развёртываются самостоятельно, им требуется изолированная среда с административным доступом. Для таких задач подойдёт VPS-сервер; на виртуальном хостинге обычно нельзя устанавливать системные сервисы и контейнерные рантаймы.

Облачный VDS-сервер

Виртуальные серверы с быстрым запуском и гибкой конфигурацией от 390₽ / мес

Доступные локации

Россия Нидерланды

Смотреть тарифы

Что выбрать для аудита

Аудит отличается от CI тем, что требует не только результата, но и объяснения. Проверяющий должен установить происхождение компонента, понять полноту охвата, изучить основание лицензионного заключения и связать документ с конкретной версией продукта.

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

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

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

Можно ли выпускать оба формата

Публикация SPDX и CycloneDX оправданна, если у документов разные потребители. Например, CycloneDX может поступать в систему управления уязвимостями, а SPDX — в контур юридического контроля и архив аудита.

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

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

Итоговые критерии выбора

1. Определите потребителя. Формат выбирается под сканер, аудитора, заказчика или отраслевой профиль, а не по популярности названия.
2. Зафиксируйте точную версию. Записи «SPDX» или «CycloneDX» недостаточно: нужны версия спецификации и сериализация.
3. Опишите обязательные данные. Отдельно отметьте лицензии, VEX, сервисы, полноту состава, криптографию и происхождение сборки.
4. Проверьте фактический экспорт. Возможности спецификации бесполезны, если генератор оставляет нужные поля пустыми.
5. Протестируйте полный маршрут. Документ должен пройти генерацию, валидацию, импорт, анализ, хранение и повторное получение без потери семантики.
6. Не смешивайте неизвестность и отсутствие. Незаполненное поле не подтверждает отсутствие компонента, лицензии или уязвимости.
7. Свяжите SBOM с артефактом. Используйте контрольную сумму, неизменяемое хранилище и проверяемую подпись или аттестацию.

Универсального победителя нет. CycloneDX 1.7 чаще оказывается практичнее для автоматизированного AppSec, VEX, SaaS и криптографической прозрачности. SPDX 3.0 лучше подходит для сложных графов происхождения и глубокого лицензионного аудита. Если эти задачи одинаково важны, оптимальным решением становится единый источник фактов и контролируемый выпуск двух валидных документов, а не попытка свести один стандарт к подмножеству другого.