Практическая работа: один компонент в CycloneDX и SPDX

Цель

Взять один и тот же компонент, найти его описание в SBOM формата CycloneDX 1.6 и SPDX 3.0.1, сверить наличие обязательных полей компонента по BSI TR-03183-2, раздел 5.2.2, и зафиксировать, какие поля теряются при сравнении двух форматов.

Что понадобится

• Стенд из П01. Стенд WSL2 Docker и базовая гигиена с jq.
• Два SBOM одного артефакта: bom.cdx.json (CycloneDX ≥ 1.6) и bom.spdx.json (SPDX ≥ 3.0.1). Сгенерировать можно по П03. Генерация SBOM через Syft (syft <образ> -o cyclonedx-json и -o spdx-json).

Обязательные поля компонента (BSI 5.2.2) — чек-лист

1. Component creator (email или URL)
2. Component name
3. Component version
4. Filename of the component
5. Dependencies on other components (+ признак полноты)
6. Distribution licences
7. Hash value of the deployable component (SHA-512)
8. Executable property
9. Archive property
10. Structured property

Где искать в форматах В CycloneDX поля 8–10 нет нативно — они кодируются свойствами bsi:component:executable / :archive / :structured (BSI property taxonomy). В SPDX 3.0.1 для них используют software_additionalPurpose и comment. Если этих свойств нет — поле считается отсутствующим, даже если файл валиден по схеме формата.

Порядок выполнения

1. Зафиксируйте вход: артефакт (образ/архив), инструмент и его версия, дата генерации, версии форматов: bash jq -r '.specVersion' bom.cdx.json # ожидаем 1.6 или выше jq -r '."@graph"[]? | select(.type=="CreationInfo") | .specVersion' bom.spdx.json
2. Выберите один компонент (например zlib) и вытащите его из CycloneDX: bash jq '.components[] | select(.name=="zlib") | {name, version, purl, swid, licenses, hashes, bsi: (.properties // [] | map(select(.name|startswith("bsi:")))) }' bom.cdx.json
3. Найдите тот же компонент в SPDX (пакет + идентификаторы): bash jq '."@graph"[]? | select(.name=="zlib")' bom.spdx.json
4. Заполните таблицу сверки по 10 полям: для каждого формата отметьте «есть / нет / частично» и впишите фактическое значение или причину отсутствия.
5. Отметьте расхождения: где значение в CycloneDX и SPDX отличается (особенно версия, лицензия declared/concluded, наличие hash), и какое поле есть в одном формате, но отсутствует в другом.

Ожидаемый результат

Заполненная таблица вида:

Плюс вывод 3–5 строк: какой формат полнее по выбранному компоненту, какие поля BSI отсутствуют в обоих и почему (ограничение инструмента генерации или формата).

Если не получилось

• specVersion = 1.4/1.5 или SPDX 2.x — SBOM не проходит BSI v2.1.0; перегенерируйте инструментом поновее.
• Компонент не находится по имени — проверьте group/namespace и регистр; в SPDX имя может быть в software_Package, а файл — в software_File.
• Нет полей bsi:component:* — это норма для большинства генераторов; зафиксируйте как пробел качества, а не как ошибку выполнения.
• Нет hash SHA-512 — частая потеря; проверьте, что генератор имел доступ к бинарю (Analysed/Build SBOM), а не только к lockfile.

Критерий зачёта

Показать преподавателю: (1) обе версии форматов соответствуют BSI; (2) заполненную таблицу сверки по 10 полям с фактическими значениями; (3) минимум одно реальное расхождение между форматами и одно поле BSI, отсутствующее в обоих, с объяснением причины.

Нормативная и практическая связка

BSI TR-03183-2 v2.1.0 (раздел 5.2.2, маппинг 8.2) · П02. Чтение CycloneDX JSON руками · П34. SBOM quality gate · Чек-лист качества CycloneDX · Чек-лист качества SPDX · Соглашение о качестве данных SBOM.