Как читать авторский курс и нормативные материалы
Это учебные материалы, а не заключение о соответствии конкретного продукта. Организационные модели курса отделяйте от терминов стандарта: ППК в опубликованном проекте — машиночитаемый перечень, а живой реестр его версий является практикой сопровождения. Термин OSA в разных материалах имеет разный охват. Статус и обязательность нормативного документа проверяются отдельно; проект КАПО опубликован как проект первой редакции.
Контрольные вопросы
Уровень 1 — понимание архитектуры 1. Какие два сервиса образуют конвейер Организации и какова единственная зона ответственности каждого? 2. Что подаётся на вход генератору фактов и что является его выходным артефактом? 3. Почему генератор фактов не должен выносить лицензионные вердикты и искать уязвимости? 4. Где в конвейере находится Dependency-Track и что такое VDR в этом потоке?
Уровень 2 — механика обогащения 5. Как генератор фактов восстанавливает фактически слинкованные библиотеки C/C++-компонента, которых нет в сыром cdxgen-SBOM? (назовите цепочку: ELF → ... → DEB) 6. Из каких внешних источников добиваются метаданные компонентов и в каких случаях каждый из них применим? 7. Почему обогащение требует Astra/Debian-окружения и к чему приведёт запуск на другой ОС? 8. Что означает «факт обратим и воспроизводим» применительно к команде
enrich-sbom?Уровень 3 — граница и слепые зоны 9. Как на аудите за минуту определить, по какую сторону границы «факты/решения» лежит конкретная строка отчёта? 10. Почему удаление Excel-отчёта в версии 2.0.0 генератора фактов — это риск для потребителей, и как его закрыть? 11. При каких условиях «зелёный» readiness является ложным, и как это распознать до релиза? 12. Чем число компонентов в обогащённом SBOM должно соотноситься с составом в сервисе вердиктов и почему расхождение — дефект процесса?
Кейс-задачи
Кейс A — подмена факта решением Инженер предлагает «оптимизацию»: пусть генератор фактов сразу отбрасывает компоненты с GPL-лицензией, чтобы сервис вердиктов не тратил время. Объясните, какую гарантию конвейера это ломает и что произойдёт при повторном аудите того же входа.
Кейс B — пустой VDR Сервис вердиктов показал readiness «готов к поставке»: 0 уязвимостей. При проверке выяснилось, что Dependency-Track сутки назад потерял связь с фидом БДУ/OSV. Опишите, как отличить «нет уязвимостей» от «нет данных» и какой пункт регламента это предотвращает.
Кейс C — занижённый состав Соисполнитель прислал артефакт; после обогащения покрытие
purlпочти не выросло, DEB-компоненты не появились. Перечислите три гипотезы причины (вход, окружение, бинарники) и проверочное действие для каждой.