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

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

Практическая работа: полнота SBOM и разделение слоёв

Цель

На реальном CycloneDX JSON оценить присутствие минимальных элементов (NTIA/CISA), посчитать «слепые» компоненты и развести найденные проблемы по слоям: дефект факта (SBOM), интерпретация, решение. Проверяемый результат — заполненная таблица дефектов и вывод о готовности артефакта.

Входные данные (зафиксировать до начала)

Запишите: репозиторий, commit/tag, инструмент и его версию, дату генерации SBOM, путь к файлу (bom.json). Без этих координат результат не воспроизводим.

Шаги

Метаданные артефакта. Проверьте, кто и чем сгенерировал SBOM: bash jq '.metadata | {timestamp, tools: .tools, authors: .authors, component: .component.name}' bom.json
Общий объём. Сколько всего компонентов: bash jq '.components | length' bom.json
Компоненты без идентификатора (не сопоставятся с CVE автоматически): bash jq '[.components[] | select(.purl == null and .cpe == null)] | length' bom.json jq '.components[] | select(.purl == null) | .name' bom.json
Компоненты без версии: bash jq '.components[] | select(.version == null or .version == "" or .version == "unknown") | {name, version}' bom.json
Граф зависимостей. Есть ли связи (или только плоский список): bash jq '.dependencies | length' bom.json
Классификация. Для каждой находки определите слой: дефект факта (поле SBOM), интерпретация (нужно сопоставление с базой) или решение (вердикт человека). Отметьте, что из этого — дефект инструмента, а что — дефект процесса поставки (например, соисполнитель прислал SBOM без supplier).

Что вы должны увидеть

Число вида «из 214 компонентов 37 без purl» — это и есть метрика полноты, а не «файл есть».
В metadata либо валидные tools/authors/timestamp, либо явный пробел, который вы отмечаете как дефект.
Заполненную таблицу:

Находка	Поле	Слой (факт/интерпретация/решение)	Источник (инструмент/процесс)
37 компонентов без `purl`	`components[].purl`	факт	процесс (генерация на этапе after-build)
версия `unknown` у внутр. форка	`components[].version`	факт	процесс
«нет CVE → значит безопасно»	—	ошибка интерпретации	—

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

jq: error ... Cannot index ... — у вас не CycloneDX, а SPDX или иной формат: проверьте jq '.bomFormat, .specVersion' bom.json.
Команда возвращает null на .metadata.tools — инструмент пишет метаданные в другом месте (.metadata.tools.components в новых спецификациях); посмотрите структуру jq '.metadata | keys' bom.json.
«Слишком мало CVE» по итогам — почти всегда не удача, а следствие низкого покрытия purl; вернитесь к шагу 3.

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

Показать преподавателю: (1) число компонентов без purl/версии; (2) состояние metadata; (3) таблицу с минимум пятью находками, каждая отнесена к слою и к источнику; (4) одно предложение — какой gate можно безопасно включить в CI и какой порог полноты в нём задать.

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

NTIA Minimum Elements for SBOM и CISA Minimum Elements for SBOM (состав полей), BSI TR-03183-2 v2.1.0 (качество), ГОСТ Р 56939-2024 (управляемость). Закрепление: Минимальный набор полей ППК, Чек-лист качества CycloneDX, Соглашение о качестве данных SBOM.

Основа практики: П02. Чтение CycloneDX JSON руками.