Как читать авторский курс и нормативные материалы
Это учебные материалы, а не заключение о соответствии конкретного продукта. Организационные модели курса отделяйте от терминов стандарта: ППК в опубликованном проекте — машиночитаемый перечень, а живой реестр его версий является практикой сопровождения. Термин OSA в разных материалах имеет разный охват. Статус и обязательность нормативного документа проверяются отдельно; проект КАПО опубликован как проект первой редакции.
Билет 01
Теоретический вопрос
Разведите три понятия: SCA (анализ состава ПО), OSA (управление открытым кодом как процесс закупки и контроля) и OSS-риск. На примере одной угрозы цепочки поставки (уязвимый транзитивный компонент, опасная лицензия, заброшенный upstream, typosquatting) покажите, какую часть угрозы закрывает SCA как факт о составе, а какую — OSA как организационный контроль. Где проходит граница ответственности и почему её нельзя стереть?
Практический вопрос
Мини-кейс В защищаемое ПО Организации попал компонент, о котором известно только имя
libfastjsonи приблизительная версия «2.x из системного пакета». Сформулируйте, что из этого относится к зоне SCA (восстановление факта о составе), а что — к зоне OSA (допуск компонента, источник загрузки, политика). Постройте цепочку «угроза → факт → решение» и укажите, на каком шаге ответ перестаёт быть техническим и становится управленческим.
Что должен показать ответ
- Источник факта: машинный SBOM/ППК как декларация состава, а не словесное описание «примерно 2.x».
- Инструмент: SCA-сканер для извлечения состава; OSA — controlled repository / proxy как точка контроля источника.
- Владелец решения: специалист композиционного анализа отвечает за полноту факта; допуск компонента — сервис аудита/вердиктов по политике, не инженер «на месте».
- Нормативная опора: ГОСТ Р 56939-2024, NIST SP 800-161 Rev.1 (цепочка поставки), OWASP SCVS.
- Evidence: запись в SBOM с координатами и происхождением; журнал допуска компонента в OSA-контуре.