SBOM в production: CycloneDX, SPDX и контроль поставки

⚙️ Теория

📦 Что такое SBOM

SBOM (Software Bill of Materials) описывает состав ПО: пакеты, версии, зависимости и их связи. Это база для:

оценки уязвимостей;
комплаенса лицензий;
расследования инцидентов в цепочке поставки.

🧩 CycloneDX и SPDX

CycloneDX ориентирован на security use-cases и практичную интеграцию в AppSec.
SPDX широко используется для лицензирования и стандартизирован как ISO/IEC 5962.

Оба формата применимы; выбор зависит от задач и tooling.

⚠️ Частая ловушка

"Генерируем SBOM для галочки" без дальнейшего использования в policy и triage.

❓ Что нужно уметь объяснить

Почему SBOM не заменяет сканирование?

SBOM это инвентаризация состава. Она нужна сканерам и аналитике, но сама по себе не устраняет уязвимости.

Что дает максимальный эффект?

Привязка SBOM к конкретному артефакту и автоматические policy checks при деплое.

Когда SBOM устаревает?

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

🧪 Практика

1. Минимальный pipeline шаг

build артефакта;
генерация SBOM (CycloneDX/SPDX);
подпись артефакта и SBOM;
проверка policy до deploy.

2. Пример policy-правила

блокировать релиз при наличии критичных CVE без approved exception;
блокировать релиз при отсутствии SBOM/подписи.

3. Guardrails

хранить SBOM рядом с release-артефактом;
делать traceability по artifact digest;
регулярно проверять качество SBOM (покрытие зависимостей, формат, валидность).

🧾 Вывод

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