Как читать авторский курс и нормативные материалы
Это учебные материалы, а не заключение о соответствии конкретного продукта. Организационные модели курса отделяйте от терминов стандарта: ППК в опубликованном проекте — машиночитаемый перечень, а живой реестр его версий является практикой сопровождения. Термин OSA в разных материалах имеет разный охват. Статус и обязательность нормативного документа проверяются отдельно; проект КАПО опубликован как проект первой редакции.
Практическая работа: приёмочный контроль ZIP-поставки соисполнителя
Что делаем
Вы — приёмщик состава на стороне Организации. Соисполнитель положил в артефакт-репозиторий ZIP-поставку своей подсистемы. Нужно проверить её против контракта поставки, измерить качество данных и принять решение: принять / принять с замечаниями / вернуть worklist. Это рабочая половина П28. Поставка от нескольких исполнителей.
Исходные данные Учебная ZIP-поставка с координатами
contractor-B-1.4.0.zip, внутри:bom.json(сырой CycloneDX от соисполнителя),build/*.log,unresolved.json. Запускать только на учебном артефакте.
Порядок выполнения
- Зафиксируйте provenance поставки. Координаты в артефакт-репозитории (имя:версия), commit/tag, дата, кто поставил. Если в
bom.json(metadata.component.version/metadata.timestamp) версия не совпадает с координатами ZIP — это первый дефект. - Проверьте комплектность ZIP по чек-листу ZIP поставки: есть ли
bom.json, логи сборки, список unresolved, license evidence. - Обогатите SBOM генератором фактов:
bash unzip contractor-B-1.4.0.zip -d intake/B # генератор фактов (enrichment-утилита) enrich-sbom intake/B/bom.json enriched/B-bom.json - Измерьте качество данных на обогащённом
B-bom.json:bash # всего компонентов jq '.components | length' enriched/B-bom.json # компонентов с PURL jq '[.components[] | select(.purl)] | length' enriched/B-bom.json # компонентов без распознанной лицензии jq '[.components[] | select((.licenses // []) | length == 0)] | length' enriched/B-bom.jsonПосчитайте PURL coverage (с PURL / всего), долю с лицензией, число unresolved. - Сформируйте worklist по соглашению о качестве: какие компоненты вернуть соисполнителю на доразметку (нет PURL/CPE, лицензия как сырая строка, unresolved).
- Примите решение и зафиксируйте его в контракте поставки: принято / принято с замечаниями / возврат; кто владеет составом этой подсистемы.
Что вы должны увидеть
Заполненную приёмочную таблицу, например:
| Метрика | Значение | Порог контракта | Статус |
|---|---|---|---|
| Компонентов | 88 | — | — |
| PURL coverage | 61% | ≥ 85% | не прошёл |
| Лицензия распознана | 70% | ≥ 90% | не прошёл |
| unresolved | 27 | ≤ 5 | не прошёл |
| Логи сборки в ZIP | да | обязательно | прошёл |
И вывод: «Поставка возвращена соисполнителю; worklist на 27 unresolved + нормализацию лицензий; владелец состава — роль X».
Если не получилось -
jq: error—bom.jsonне валидный JSON: поставка повреждена в ZIP, верните соисполнителю. - PURL coverage = 100%, но 0 CVE на следующем шаге — проверьте, не пустые ли версии у компонентов. -enrich-sbomне дополнил библиотеки C/C++ — нет ELF/логов сборки в ZIP, значит build evidence не поставлен (нарушение контракта).
Критерий зачёта
Показать преподавателю: (1) зафиксированный provenance поставки, (2) посчитанные метрики качества с порогами контракта, (3) worklist на возврат, (4) явно названного владельца состава подсистемы. Результаты агрегируются в П29. Readiness dashboard.
Нормативная связка
ГОСТ Р 56939-2024 (управляемость и документация разработчика), проект ГОСТ КАПО (регулярный КАПО по сторонним поставкам), ISO/IEC 27001 (supplier relationships), NIST SP 800-161 (provenance в цепочке поставки).