Пиков / КАПО
Библиотека
Как читать авторский курс и нормативные материалы

Это учебные материалы, а не заключение о соответствии конкретного продукта. Организационные модели курса отделяйте от терминов стандарта: ППК в опубликованном проекте — машиночитаемый перечень, а живой реестр его версий является практикой сопровождения. Термин OSA в разных материалах имеет разный охват. Статус и обязательность нормативного документа проверяются отдельно; проект КАПО опубликован как проект первой редакции.

Регламент композиционного анализа ПО

Назначение Сквозной порядок композиционного анализа (SCA) и анализа открытого ПО (OSA) в Организации: от приёмки сборки до релизного решения и мониторинга в продуктиве. Это материнский документ группы — из его пронумерованных шагов выводятся строки RACI, а контроли каждого шага дают evidence для матрицы evidence.

Когда применяется

Запускается на каждый релиз-кандидат продукта, на каждую поставку от соисполнителя и при плановом периодическом пересканировании компонентов в продуктиве. Триггеры: подготовка релиза, приёмка ZIP/контейнера от внешнего исполнителя, публикация новой уязвимости в используемом компоненте.

Границы и термины

Порядок (шаги процесса)

  1. Приёмка и фиксация входа. Принять сборку/поставку, зафиксировать версию, источник, дату, исполнителя. Для поставки соисполнителя — проверить комплектность по Контракт поставки SBOM от соисполнителя и Чек-лист ZIP поставки.
  2. Генерация/получение SBOM. Сгенерировать SBOM из исходников и сборки либо принять входной SBOM/ППК. Для C/C++ legacy — обязательно сохранить build evidence (логи сборки, граф линковки), без него SBOM не считается достаточным.
  3. Контроль качества SBOM. Проверить покрытие PURL/CPE, наличие dependency graph, корректность лицензионных полей. Прогнать Чек-лист качества CycloneDX / Чек-лист качества SPDX; несоответствия — в Соглашение о качестве данных SBOM.
  4. Идентификация компонентов. Сопоставить компоненты с PURL/CPE; неопознанные — в Реестр unresolved libraries и Порядок работы с неопознанной библиотекой. Невозможность распознать не скрывается, а превращается в worklist.
  5. Обогащение фактами. Прогнать «генератор фактов»: уязвимости (NVD, OSV, БДУ ФСТЭК), лицензии, malware/protestware, reachability там, где доступно.
  6. Анализ уязвимостей. Сформировать VDR, отделить факт от решения через VEX (см. Порядок загрузки VDR из Dependency-Track). Триаж по Политика управления уязвимостями компонентов.
  7. Анализ лицензий. Классифицировать лицензии, выявить несовместимости и неизвестные лицензии (см. Политика лицензионной чистоты, Порядок работы с неизвестной лицензией).
  8. Триаж и решения. По каждому риску — решение: разрешено / блокировано / требуется доработка / риск принят. Исключения оформить через Реестр исключений и Порядок принятия риска (обоснование, владелец, срок пересмотра обязательны).
  9. Релизный gate. Прогнать релиз-кандидат через Требования к CI security gate. Решение «сервиса аудита/вердиктов» фиксируется как вердикт с evidence.
  10. Журналирование. Все действия и вердикты записать в audit trail по Журналирование и audit trail.
  11. Мониторинг в продуктиве. Поставить компоненты на периодический пересмотр; при новой уязвимости вернуться к шагу 5. Ретест исправлений — по Регламент ретеста после исправления.

Минимальные правила

Связь с курсом