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

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

Что проверять на проекте (чек-лист аудитора по C/C++)

Чек-лист дополняет общий аудит SBOM конкретикой C/C++. Каждый пункт — это вопрос «есть ли доказательство», а не «декларировано ли».

Управление зависимостями

[ ] Есть ли пакетный менеджер. Используется ли Conan/vcpkg или зависимости подключены вручную (-l, системный apt, third_party/)? Если менеджера нет — состав восстанавливается только из сборки и бинаря.
[ ] Как линкуются зависимости. Видна ли строка линковки (make VERBOSE=1, verbose CMake)? Какие компоненты подключены динамически, какие статически?
[ ] Видны ли динамические зависимости. Снят ли readelf -d/ldd, и сопоставлены ли DT_NEEDED с DEB-пакетами через dpkg -S/apt (есть ли версия и PURL у каждой .so)?

Слепые зоны

[ ] Видны ли статические библиотеки (.a). Есть ли в проекте статическая линковка, и учтены ли эти компоненты отдельно — ведь в DT_NEEDED их нет? Есть ли список того, что вшито.
[ ] Stripped binaries. Поставляются ли бинарники без символов/debug-info? Если да — зафиксировано ли, что бинарный анализ по ним неполон и требуется build-scan?
[ ] Vendored / third_party/. Есть ли скопированные исходники OSS без версии и истории? Установлены ли их версия, апстрим и лицензия?
[ ] Внутренние форки. Отличены ли форки от апстрима (свои патчи → другой профиль риска)? Заведён ли паспорт компонента на форк?

Полнота и процесс

[ ] Build-scan. Восстанавливается ли состав на этапе сборки (перехват вызовов компилятора/линкера), а не только поздним сканом готового бинаря?
[ ] Unresolved libraries. Есть ли реестр .so/символов, не смапленных ни на один пакет, с ответственным и сроком доразметки? См. Реестр unresolved libraries.
[ ] Ручная разметка. Есть ли процедура ручного дозаполнения PURL/CPE/версии для того, что инструмент не распознал (с автором, датой, обоснованием)? См. Порядок работы с неопознанной библиотекой.
[ ] Обогащение фактов. Проходит ли сырой cdxgen SBOM через обогащение (бинарный анализ ELF + маппинг на DEB + метаданные из Conan/apt) перед тем, как попасть в сервис аудита/вердиктов?
[ ] Трассируемость. Зафиксированы ли для C/C++ артефакта: способ сборки, версии инструментов (gcc, cdxgen, readelf), дистрибутив, commit/tag, дата, соисполнитель?

Красный флаг SBOM C/C++ компонента содержит подозрительно мало записей и при этом нет ни одного DT_NEEDED-маппинга, ни списка статически вшитого, ни реестра unresolved. Это не «чистый» компонент, а непроверенная слепая зона — состав не доказан.

Нормативная опора

ГОСТ Р 56939-2024 · NIST SP 800-218 SSDF (PS.3.2, PW.4, RV.1) · BSI TR-03183-2 v2.1.0 · CERT C C++ · MISRA C C++