Как читать авторский курс и нормативные материалы

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

Практическая работа: от порога политики до карточки исключения

Цель

Получить отчёт SCA, применить к нему пороги политики приёмки, развести findings на «gate / fix / исключение» и оформить два управленческих решения (исключение и принятие риска) с трассируемостью до версии компонента и сроком пересмотра.

Входные данные

Берётся тестовый проект (например, демо-репозиторий с известными уязвимыми зависимостями) и зафиксированный отчёт сканера. Все запуски — только на согласованном фрагменте, без отправки кода во внешний облачный сервис без отдельного решения.

Порядок выполнения

Сгенерируйте отчёт. Запустите сканер по проекту и выгрузите машинный результат с CVSS и лицензиями. Пример с OSV-Scanner: bash osv-scanner --format json --output scan.json ./project Зафиксируйте: версию инструмента (osv-scanner --version), commit/tag проекта, дату.
Примените пороги политики. По Политика приемки сторонних компонентов разметьте каждый finding: - CVSS base ≥ 7.0 при наличии фикса → кандидат на блок; - копилефт-лицензия (GPL-2.0-only / AGPL-3.0) в проприетарном дистрибутиве → блок; - malware-сигнал → instant fail; - всё ниже порога → допущено.
Разведите решения. Для каждого findings выберите ровно одну ветку: fix/replace · not affected (VEX) · accepted risk (исключение). Минимум один finding должен закрыться через VEX not_affected, а не через исключение.
Оформите две карточки исключения по Реестр исключений и Порядок принятия риска. Обязательные поля: ID, компонент (PURL с версией), finding, обоснование, компенсирующая мера, автор (роль), дата открытия, expiry, статус.
Свяжите gate и реестр. Внесите подавление в конфиг gate так, чтобы дата совпадала с expiry, а в reason стоял ID карточки: toml [[02 Справочник/Глоссарий/IgnoredVulns|IgnoredVulns]] id = "CVE-XXXX-XXXXX" ignoreUntil = 2026-09-17T00:00:00Z reason = "EXC-2026-0NN: <краткое обоснование>"
Заведите запись в реестр и проверьте: нет ни одного «голого» mute без ссылки на карточку; у каждого исключения есть автор и срок.

Ожидаемый результат

scan.json + зафиксированные версия инструмента, commit/tag, дата;
таблица разметки findings по веткам решения;
две заполненные карточки исключения в реестре;
фрагмент конфига gate, синхронизированный по дате и ID с реестром;
один finding, закрытый через VEX not_affected (без открытия исключения).

Если не получилось - Сканер выдал мало findings — проверьте, что в SBOM есть PURL/версии (иначе нечему сопоставляться, см. М04/М06). - Все findings ушли в «исключения» — порог политики не задан или слишком мягкий; вернитесь к шагу 2. - В карточке нет компенсирующей меры — это не принятие риска, а его игнорирование; добавьте меру и условие ретеста. - ignoreUntil без даты — gate замолчит навсегда; expiry обязателен.

Критерий зачёта

Показать преподавателю: (1) две корректные карточки исключения с автором, обоснованием, мерой и expiry; (2) конфиг gate, где дата подавления = expiry и стоит ID карточки; (3) один finding, закрытый через VEX, а не исключением. Объяснить по любому finding, почему он попал в свою ветку.

Нормативная и шаблонная связка

П30. Исключения и принятие риска · ISO IEC 27001 (risk treatment) · NIST SP 800-218 SSDF (PW.4/RV.1) · ГОСТ Р 56939-2024 · Требования к CI security gate.