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

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

Конспект: много исполнителей и корпоративная модель продукта

Зачем модуль

Когда продукт делает одна команда, состав ПО можно получить «у себя»: запустил cdxgen/Syft на своём дереве и получил SBOM. Корпоративное изделие Организации устроено иначе. Это сборка из подсистем 5–10 соисполнителей поверх многолетнего legacy, и значительную часть состава ты физически не собираешь — её приносят извне. Источником факта о составе становится не твой пайплайн, а ZIP-архив от внешней команды, у которой свой стек, своя дисциплина версионирования и свой (часто никакой) опыт SCA. Модуль про то, как принять эти данные, оценить их пригодность и не потерять ответственность за состав целого продукта.

Ключевые идеи

Контракт поставки — это не про формат, а про обязательства. Недостаточно записать «присылайте CycloneDX». Контракт фиксирует: что входит в ZIP (bom.json, build logs, список unresolved-компонентов, license evidence), к какому commit/tag это относится, кто на стороне соисполнителя владелец, и какой минимум качества данных считается приёмлемым. Без последнего пункта SBOM приходит «технически валидным», но бесполезным: компоненты без PURL/CPE, лицензии как сырая строка, граф зависимостей плоский.

ZIP — это поставка, а не SBOM. Один файл bom.json не доказывает ничего. Для C/C++ legacy (см. М09) состав не выводится из манифеста — нужен build evidence: что реально слинковалось. Поэтому в ZIP должны лежать логи сборки и перечень того, что инструмент не смог распознать.

Обмен идёт через артефакт-репозиторий, а не через почту. Соисполнитель кладёт ZIP в общий артефакт-репозиторий с иммутабельными координатами (имя:версия), CI Организации забирает оттуда, прогоняет через генератор фактов (enrichment-утилиту) и передаёт обогащённый bom.json в сервис аудита/вердиктов. Это даёт provenance: видно, кто, когда и какую версию поставил.

Качество данных от внешних команд нужно измерять, а не предполагать. Метрики приёмки: доля компонентов с PURL, доля с распознанной лицензией, число unresolved, глубина графа. Низкие значения — не повод для отказа, а повод вернуть worklist соисполнителю.

Главная ловушка много-исполнительской модели «SBOM прислали» ≠ «состав известен». Технически валидный CycloneDX с компонентами без идентификаторов даёт сканеру почти ноль CVE — и создаёт ложное ощущение чистоты. Меряйте coverage, а не наличие файла.

Как выглядит на практике

Генератор фактов получает сырой SBOM соисполнителя и достраивает его: тянет метаданные из PyPI/npm/Conan/apt, а для C/C++ делает бинарный анализ ELF (через LIEF), определяет слинкованные динамические библиотеки и маппит их на системные DEB-пакеты. На выходе — обогащённый bom.json:

# генератор фактов (enrichment-утилита), команда обогащения
enrich-sbom contractor-A/bom.json enriched/A-bom.json --component-path subsystem-A

Приёмка партии из 7 соисполнителей в едином сводном виде:

Соисполнитель	Компонентов	PURL coverage	unresolved	Лицензии	Вердикт приёмки
A	142	96%	3	OK	принято
B	88	61%	27	сырые строки	worklist
N	210	89%	11	OK	принято с замечаниями

Строка B — типичная: формально SBOM есть, но 27 unresolved и лицензии не нормализованы, поэтому состав не считается известным до доразметки.

Слепые зоны именно этой темы

«Чужой» unresolved оседает у тебя. Если соисполнитель не доразметил библиотеку, нераспознанный компонент в итоговом изделии становится твоей зоной риска.
Внутренний форк под видом open source. Соисполнитель прислал «обычную» библиотеку, а это патченный форк с другим риском и без апстрим-CVE.
Версия ZIP ≠ версия SBOM. ZIP пересобрали, а bom.json внутри старый — provenance ломается молча.
Размытая ответственность. Все принимают, никто не владеет составом конкретной подсистемы.

Связь с нормативкой

ГОСТ Р 56939-2024 требует управляемости работ и документации разработчика — контракт поставки её обеспечивает. Проект ГОСТ КАПО задаёт регулярность КАПО, в т.ч. по сторонним поставкам. ISO/IEC 27001 (supplier relationships) и NIST SP 800-161 закрывают управление поставщиками и provenance.

Что уносим в работу

Завести контракт поставки и соглашение о качестве данных до старта приёмки.
Принимать только через артефакт-репозиторий с иммутабельными координатами и чек-листом ZIP.
Мерить coverage поставки и возвращать worklist, а не молча принимать — отработка в П28.
Сводить состав всех соисполнителей в единый readiness-отчёт по продукту — П29.
Закрепить владельца состава каждой подсистемы в RACI.