Пиков / КАПО
Библиотека
Как читать авторский курс и нормативные материалы

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

П04. Генерация SBOM через cdxgen для C/C++

Цель

Сгенерировать SBOM для C/C++ проекта режимом cdxgen -t cpp и убедиться на конкретных компонентах, что сырой C/C++ SBOM неполон: версии часто пусты, идентификаторы вырождаются в pkg:generic/..., динамические .so и их привязка к системным DEB-пакетам не восстанавливаются. Дополнительно показать дельту «без Conan» против «с Conan»: декларация пакетного менеджера превращает часть generic-компонентов в нормальные координаты с версией. Проверяемый результат — cdxgen-bom.json, в котором видны и заполненные, и «слепые» компоненты.

Команда или действие

На вход — учебный C/C++ проект (CMake/make). Прогон делаем дважды: на «голом» дереве и после того, как зависимости объявлены через Conan.

cdxgen --version

# 1) без Conan: cdxgen видит только то, что нашёл в дереве сборки
cdxgen -t cpp -o cdxgen-noconan.json .

# 2) с Conan: объявляем зависимости, затем повторный прогон
conan install . --output-folder=build --build=missing
cdxgen -t cpp -o cdxgen-conan.json .

# сравнить число компонентов и долю пустых версий
jq '.components | length' cdxgen-noconan.json cdxgen-conan.json
jq '[.components[] | select(.version == null or .version == "")] | length' cdxgen-conan.json

cdxgen — публичный генератор CycloneDX (https://github.com/cdxgen/cdxgen). Сырой cdxgen-bom.json затем уходит на обогащение в генератор фактов (enrichment-утилита), который дотягивает динамические .so через анализ ELF и привязывает их к DEB-пакетам, — это уже следующий шаг конвейера, не покрытый данной практикой.

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

В cdxgen-noconan.json компонентов немного, и значительная часть из них без версии и с вырожденным PURL — это нормальное состояние C/C++ без дисциплины пакетного менеджера:

{
  "type": "library",
  "name": "zlib",
  "version": "",
  "purl": "pkg:generic/zlib"
}

После conan install часть таких записей в cdxgen-conan.json получает версию и осмысленный идентификатор:

{
  "type": "library",
  "name": "zlib",
  "version": "1.3.1",
  "purl": "pkg:conan/zlib@1.3.1"
}

Ориентир по числам: компонентов в обоих файлах единицы–десятки (а не сотни, как в npm-проекте из П03. Генерация SBOM через Syft); счётчик пустых версий в варианте без Conan заметно выше.

cdxgen для C/C++ даёт каркас, а не полный состав #include не несёт версии, а статически вшитая библиотека вообще исчезает из артефакта — поэтому pkg:generic/... без версии здесь не баг инструмента, а граница метода. Не принимайте такой SBOM за полный: его обязательно дообогащают данными ELF/DEB. Эта неполнота — причина, по которой в конвейере Организации существует отдельный генератор фактов.

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

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

Показать преподавателю: cdxgen-noconan.json и cdxgen-conan.json, два числа из jq и счётчик пустых версий. Указать пальцем хотя бы один компонент, который в варианте без Conan был pkg:generic/... без версии, а с Conan получил версию и нормальный PURL. Сформулировать, какие данные о компонентах в этом SBOM всё ещё отсутствуют и где они добираются.

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