Как читать авторский курс и нормативные материалы
Это учебные материалы, а не заключение о соответствии конкретного продукта. Организационные модели курса отделяйте от терминов стандарта: ППК в опубликованном проекте — машиночитаемый перечень, а живой реестр его версий является практикой сопровождения. Термин OSA в разных материалах имеет разный охват. Статус и обязательность нормативного документа проверяются отдельно; проект КАПО опубликован как проект первой редакции.
Порядок принятия риска
Назначение
Порядок описывает, как осознанно и формально принять остаточный риск, когда уязвимость или лицензионную проблему компонента нельзя устранить в срок SLA, а блокировать релиз нецелесообразно. Цель — заменить «молчаливое игнорирование» решением с владельцем, обоснованием и сроком пересмотра.
Когда применяется
- Истекает SLA по политике уязвимостей, а исправления нет (нет патча, обновление ломает совместимость).
- Лицензионное отклонение допускается временно (через Порядок исключения лицензии).
- Эксплуатируемость низка в продуктовой конфигурации, но статус
not_affectedстрого не доказуем по требованиям VEX/evidence.
Шаги
- Описать риск. Завести/обновить Паспорт риска компонента: компонент, версия, CVE/БДУ, CVSS, severity, сценарий эксплуатации.
- Оценить применимость. Зафиксировать VEX-обоснование, issuer и evidence, почему риск в продукте ниже базового CVSS (или подтвердить, что выше). Если доказательств для
not_affectedнет, оформляется не VEX-подавление, а принятие остаточного риска. - Описать компенсирующие меры. WAF/сегментация/отключение функции/мониторинг — то, что снижает вероятность или ущерб до пересмотра.
- Определить уровень одобрения. Чем выше severity, тем выше уровень принимающего (см. матрицу ниже).
- Назначить владельца и срок. Владелец риска (роль) + дата обязательного пересмотра.
- Согласовать и зафиксировать. Подпись/отметка одобрения; запись в Реестр исключений со ссылкой на паспорт риска.
- Поставить на контроль. На дату пересмотра — повторная оценка: устранить, продлить с новым обоснованием или эскалировать.
Матрица полномочий на принятие риска
| Severity | Кто принимает | Макс. срок принятия |
|---|---|---|
| Critical | Владелец продукта + комитет по риску | 30 дней |
| High | Владелец продукта | 90 дней |
| Medium | Руководитель направления безопасной разработки | 180 дней |
| Low | Дежурный аналитик SCA (роль) | до следующего релиза |
Принятие риска не закрывает уязвимость Статус остаётся открытым (
affected+risk_accepted), а неfixed. По истечении срока риск автоматически возвращается в triage. Бессрочное принятие риска запрещено.VEX не равен принятию риска
not_affectedозначает, что уязвимость не влияет на конкретную версию продукта в проверенном контексте. Принятие риска означает обратное: влияние возможно или подтверждено, но Организация временно принимает остаточный риск. Подробно: VEX в процессе РБПО.Компенсирующая мера без проверки — не мера Если заявлен компенсирующий контроль (например, сегментация сети), он должен быть подтверждён evidence, иначе принятие риска необоснованно.
Минимальная карточка решения
| Поле | Значение |
|---|---|
| Объект риска (компонент@версия) | |
| CVE/БДУ или лицензионное отклонение | |
| Severity / CVSS | |
| VEX-статус / issuer / evidence | |
| Обоснование (почему не устраняем сейчас) | |
| Компенсирующие меры + evidence | |
| Принимающий (роль) | |
| Дата принятия / срок пересмотра | |
| Ссылка на паспорт риска |
Связь с курсом
- Модуль: М14. Политики, исключения и принятие риска
- Справка: VEX в процессе РБПО
- Практики: П30. Исключения и принятие риска · П35. VEX triage · П29. Readiness dashboard
- Нормативка: ISO IEC 27001 (управление риском) · NIST SP 800-161 Rev.1
- Связанные шаблоны: Паспорт риска компонента · Реестр исключений · Политика управления уязвимостями компонентов