Как читать авторский курс и нормативные материалы

Это учебные материалы, а не заключение о соответствии конкретного продукта. Организационные модели курса отделяйте от терминов стандарта: ППК в опубликованном проекте — машиночитаемый перечень, а живой реестр его версий является практикой сопровождения. Термин OSA в разных материалах имеет разный охват. Статус и обязательность нормативного документа проверяются отдельно; проект КАПО опубликован как проект первой редакции.

CycloneDX

Для чего

CycloneDX — формат спецификации состава ПО, изначально заточенный под безопасность цепочки поставки. Помимо перечня компонентов он несёт граф зависимостей (dependencies), сведения о происхождении (pedigree), вложенный VEX и описания сервисов. Стандартизован как ECMA-424; под BSI TR-03183-2 v2.1.0 SBOM принимается в CycloneDX версии ≥ 1.6 (JSON или XML).

Как применяют

Минимальный валидный документ в JSON несёт bomFormat, specVersion и перечень компонентов с идентификаторами:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "version": 1,
  "metadata": { "component": { "type": "application", "name": "my-app" } },
  "components": [
    {
      "type": "library",
      "name": "openssl",
      "version": "3.0.13",
      "purl": "pkg:conan/openssl@3.0.13",
      "cpe": "cpe:2.3:a:openssl:openssl:3.0.13:*:*:*:*:*:*:*"
    }
  ]
}

Компонент несёт сразу Package URL и CPE — purl для сопоставления с OSV, cpe для NVD. Граф dependencies отделяет прямые зависимости от транзитивных. Чтение и разбор такого документа отрабатывается в П02. Чтение CycloneDX JSON руками.

Сильные стороны

VEX можно встроить прямо в BOM (vulnerabilities[].analysis) — факт состава и решение по уязвимости в одном файле; для аудита всё равно нужно явно хранить issuer, версию продукта и evidence.
Богатая модель: dependencies, pedigree, services, поддержка ML-BOM/SaaS-BOM.
Широкая поддержка генераторами (Syft, cdxgen, Trivy) и сканерами.

Ограничения

Поле licenses слабее структурировано, чем в SPDX, — для строгого юридического workflow часто берут SPDX.
Версии 1.4 → 1.6 различаются полями; старый потребитель может не понять документ новой версии.
Свобода модели порождает неполные BOM «технически валидные, но бедные» — отсюда нужен quality gate (П34. SBOM quality gate).
Встроенный VEX не должен превращать SBOM в «сам себе вердикт»: порядок выпуска VEX и evidence фиксируется отдельно в VEX в процессе РБПО.

Offline / on-premise

Генерация и валидация полностью локальны: схема (JSON Schema / XSD) распространяется вместе со спецификацией, проверка структуры идёт без сети. Обогащение уязвимостями и подпись — отдельные шаги, которые тоже работают в закрытом контуре при локальных зеркалах источников.

Связанные темы

М03 Форматы SBOM · М02 SBOM как факт · М06 Поиск уязвимостей Справка: VEX в процессе РБПО Практики: П02. Чтение CycloneDX JSON руками · П09. VDR и VEX различие факта и решения · П34. SBOM quality gate Смежные карточки: SPDX · SWID · Package URL · CPE · OpenVEX · cdxgen