Что проверять на проекте

Чек-лист аудитора для продукта, который собирают несколько соисполнителей. Проверяем не «есть ли SBOM», а управляем ли процесс поставки состава и однозначна ли ответственность.

Контракт и качество данных

• [ ] Для каждого соисполнителя действует контракт поставки SBOM: что в ZIP, к какому commit/tag, владелец на стороне соисполнителя.
• [ ] Есть соглашение о качестве данных с числовыми порогами (PURL coverage, доля распознанных лицензий, лимит unresolved) — а не «по возможности».
• [ ] Пороги качества реально применяются при приёмке (есть отказы/возвраты в истории, а не только зелёные приёмки).

Поставка и обмен

• [ ] Обмен идёт через артефакт-репозиторий с иммутабельными координатами (имя:версия), а не через почту/мессенджер.
• [ ] ZIP-поставка комплектна по чек-листу ZIP: bom.json + логи сборки + список unresolved + license evidence.
• [ ] Версия внутри bom.json совпадает с координатами ZIP в репозитории (нет молчаливого рассинхрона).
• [ ] Для подсистем C/C++ в поставке есть build evidence (логи/ELF), без которого состав не считается доказанным.

Provenance и ответственность

• [ ] По любому компоненту итогового изделия восстанавливается источник: соисполнитель, версия поставки, дата, commit/tag.
• [ ] В RACI явно назван владелец состава каждой подсистемы; чужой unresolved-компонент имеет ответственного на стороне Организации.
• [ ] Приёмку каждой поставки кто-то подписывает (роль, дата, версия инструмента) — есть приёмочный артефакт.

Сводный состав и обработка

• [ ] Составы соисполнителей сводятся в единый состав изделия без потери источника каждого компонента.
• [ ] Worklist на доразметку (unresolved, сырые лицензии, форки) ведётся и закрывается, а не накапливается молча.
• [ ] Принятые поставки уходят в обработку дальше по контуру (генератор фактов → сервис аудита/вердиктов), и это прослеживается до readiness-отчёта по продукту.

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

ГОСТ Р 56939-2024 · проект ГОСТ КАПО · ISO/IEC 27001 (supplier relationships) · NIST SP 800-161.