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

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

CycloneDX ECMA-424

О документе

Что это ECMA-424 — стандарт Ecma International, закрепляющий спецификацию CycloneDX как формат Bill of Materials. Издан техническим комитетом TC54; развитие самого формата ведёт проект OWASP CycloneDX. Это не методичка по управлению уязвимостями, а схема данных: как машинно описать состав продукта и связанные с ним факты безопасности.

CycloneDX покрывает не только классический SBOM (компоненты), но и связанные типы BOM: VEX (статус эксплуатируемости уязвимости), VDR (раскрытие найденных уязвимостей), CBOM (криптография), а также блоки compositions (полнота описания) и evidence (откуда инструмент узнал о компоненте). Сериализация — JSON, XML или Protocol Buffers; в курсе рабочий вариант — JSON.

Ключевые требования

Идентификация документа. Корень содержит bomFormat: "CycloneDX", specVersion, serialNumber (URN-uuid) и version (ревизия самого BOM) — без них документ не самоописателен.
Идентификация компонентов через purl. Каждый component несёт type, name, version; для матчинга на уязвимости — purl в формате pkg:type/namespace/name@version, при наличии — cpe.
Прослеживаемость до субъекта поставки. Секция metadata фиксирует timestamp, tools (чем сгенерирован BOM) и metadata.component (что именно описывается).
Честность охвата. Блок compositions с aggregate (complete / incomplete / unknown) обязателен, когда состав описан не полностью — иначе SBOM молча выдаёт частичную картину за полную.
Разделение факта и решения. Уязвимость как факт живёт в vulnerabilities; решение «эксплуатируема ли она в продукте» — это VEX-analysis.state (exploitable, not_affected, in_triage…), а не свойство компонента.
Доказуемость происхождения данных. Блок evidence (identity, occurrences, call-stack) показывает, на каком основании инструмент приписал компонент продукту.

Что считать evidence

Артефакты соответствия - Валидный CycloneDX JSON с заполненными metadata.timestamp, metadata.tools, serialNumber, version — основной ППК продукта. - Отчёт проверки против официальной JSON-схемы CycloneDX соответствующей specVersion (gate в CI). - Заполненный compositions.aggregate для C/C++-сборок, где статическая линковка делает охват incomplete. - VEX-документ CycloneDX с analysis.state/justification по каждой значимой уязвимости. - Метрика качества: доля компонентов с валидным purl и непустой version.

Маппинг на практики и шаблоны

Чтение и ручной разбор структуры: П02. Чтение CycloneDX JSON руками.
Генерация для C/C++, где формат проявляет слепые зоны: П04. Генерация SBOM через cdxgen для C C++.
Разделение VDR/VEX как разных типов BOM: П09. VDR и VEX различие факта и решения, триаж — П35. VEX triage.
Контроль качества документа: Чек-лист качества CycloneDX; минимальный набор полей ППК — Минимальный набор полей ППК.
Контекст модуля: М03. Форматы SBOM: CycloneDX, SPDX, SWID.

Ограничение

Это учебная карточка Карточка пересказывает структуру формата под задачи курса и не воспроизводит официальный текст ECMA-424. Конкретные имена полей и допустимые значения для аудита сверять с актуальной спецификацией CycloneDX выбранной specVersion и с регламентами Организации.