Как читать авторский курс и нормативные материалы
Это учебные материалы, а не заключение о соответствии конкретного продукта. Организационные модели курса отделяйте от терминов стандарта: ППК в опубликованном проекте — машиночитаемый перечень, а живой реестр его версий является практикой сопровождения. Термин OSA в разных материалах имеет разный охват. Статус и обязательность нормативного документа проверяются отдельно; проект КАПО опубликован как проект первой редакции.
Контрольные вопросы
Базовый уровень 1. Чем источник факта о составе в много-исполнительской модели отличается от модели одной команды? 2. Что, кроме
bom.json, обязательно входит в ZIP-поставку соисполнителя и зачем нужен каждый элемент? 3. Почему обмен SBOM ведут через артефакт-репозиторий, а не пересылкой файла? Что это даёт для provenance? 4. Что фиксирует контракт поставки SBOM сверх требования «присылайте CycloneDX»?Применение 5. Какие метрики качества поставки вы измеряете при приёмке и какие пороги разумно записать в соглашение о качестве данных? 6. Соисполнитель прислал валидный CycloneDX, но сканер нашёл почти ноль CVE. Какие три причины проверите в первую очередь? 7. Для подсистемы на C/C++ соисполнитель прислал только
bom.jsonбез логов сборки. Почему это нарушение контракта и что вернуть в worklist? 8. Как версия ZIP-поставки и версия внутриbom.jsonмогут разойтись и почему это ломает provenance молча? 9. Чем «возврат worklist соисполнителю» лучше «отказа в приёмке» при низком coverage?Продвинутый уровень 10. Как в RACI развести ответственность за состав между соисполнителем, приёмщиком Организации и владельцем продукта? Кто несёт риск чужого unresolved-компонента? 11. Соисполнитель под видом обычной open source библиотеки поставил внутренний патченный форк. Как это обнаружить и почему это меняет профиль риска? 12. Как свести составы 7 соисполнителей в единый readiness-отчёт по продукту, не потеряв, чей компонент откуда пришёл?
Кейс-задачи
Кейс 1. «Зелёный, но пустой» Поставка соисполнителя: 88 компонентов, PURL coverage 61%, лицензии у 70%, 27 unresolved, логи сборки есть. Контрактные пороги: PURL ≥ 85%, лицензия ≥ 90%, unresolved ≤ 5. Сформулируйте решение приёмки, перечень для worklist и одно предложение, что закрепить в соглашении о качестве, чтобы такая поставка не повторялась.
Кейс 2. «Чей это компонент» В сводном составе изделия после merge всплыла уязвимая библиотека без указания соисполнителя-источника. Релиз через 3 дня. Опишите, какие поля provenance должны были присутствовать, чтобы за минуты найти владельца, и как организовать приём через артефакт-репозиторий, чтобы источник никогда не терялся. Свяжите с П28.
Кейс 3. «Форк-невидимка» Две подсистемы декларируют одну и ту же библиотеку одной версии, но в одной это апстрим, а в другой — патченный внутренний форк с собственной CVE. Как приёмочный контроль и контракт поставки помогут различить их по идентичности компонента (PURL-квалификаторы, evidence), и почему «одинаковое имя:версия» здесь обманчиво?