Как читать авторский курс и нормативные материалы
Это учебные материалы, а не заключение о соответствии конкретного продукта. Организационные модели курса отделяйте от терминов стандарта: ППК в опубликованном проекте — машиночитаемый перечень, а живой реестр его версий является практикой сопровождения. Термин OSA в разных материалах имеет разный охват. Статус и обязательность нормативного документа проверяются отдельно; проект КАПО опубликован как проект первой редакции.
Политика управления уязвимостями компонентов
Назначение
Политика устанавливает единые пороги severity, сроки устранения (SLA) и правила приоритизации уязвимостей в open source и сторонних компонентах продуктов Организации. Она отвечает на вопрос «нашли уязвимость в зависимости — что и в какой срок обязаны сделать».
Когда применяется
- При появлении новых findings после прогона сервиса аудита/вердиктов поверх SBOM/VDR.
- При плановом пересмотре открытых уязвимостей (еженедельный triage).
- При публикации значимой уязвимости во внешних источниках (NVD, БДУ ФСТЭК) для компонента, входящего в портфель продуктов.
Область действия и роли
| Параметр | Значение |
|---|---|
| На что распространяется | Все релизные сборки, контейнерные образы и поставки соисполнителей |
| Владелец политики | Руководитель направления безопасной разработки (роль, без ФИО) |
| Исполнитель triage | Дежурный аналитик SCA (роль) |
| Эскалация | Владелец продукта + комитет по риску |
Классификация и пороги severity
Базовая метрика — CVSS v3.1/v4.0 базовый вектор, скорректированный по применимости (VEX) и по эксплуатируемости (EPSS, наличие в CISA KEV / актуальность по БДУ ФСТЭК).
| Severity | CVSS | Усиливающие факторы | SLA на устранение/митигацию |
|---|---|---|---|
| Critical | 9.0–10.0 | в KEV или EPSS ≥ 0.5, сетевой вектор без аутентификации | 7 календарных дней |
| High | 7.0–8.9 | достижима из недоверенной зоны | 30 дней |
| Medium | 4.0–6.9 | требует локального доступа/предусловий | 90 дней |
| Low | 0.1–3.9 | не достижима в продуктовой конфигурации | планово, следующий релиз |
| None / not affected | — | подтверждено VEX-статусом not_affected от ответственного issuer |
фиксация обоснования и evidence, без работ |
Жёсткое правило gate Релиз с открытой Critical-уязвимостью без действующего исключения (см. Реестр исключений) не выпускается. CI security gate блокирует сборку.
Порядок реакции (обязательный минимум)
- Findings из сервиса аудита/вердиктов выгружаются как VDR и привязываются к версии компонента (PURL).
- Каждая уязвимость получает VEX-статус:
affected/not_affected/under_investigation/fixed; указывается issuer решения и evidence по продуктовой версии (VEX в процессе РБПО). - Для
affectedзаводится Паспорт риска компонента и назначается владелец с дедлайном по SLA. - Устранение: обновление версии, патч, замена компонента или компенсирующий контроль.
- После исправления — обязательный ретест; статус закрывается только по evidence.
- Если SLA не выдерживается — оформляется принятие риска с ограниченным сроком.
Что считается evidence закрытия
- VDR/VEX с новым статусом и ссылкой на сервис аудита/вердиктов.
- Diff версии компонента в SBOM (было/стало).
- Evidence для VEX: SBOM/ППК, build log, reachability/call graph, triage issue, upstream advisory/VEX как вспомогательный источник.
- Протокол ретеста с нулём подтверждённых эксплуатируемых findings по этой CVE/БДУ.
Связь с курсом
- Модуль: М06. Поиск уязвимостей и управление VDR/VEX
- Справка: VEX в процессе РБПО
- Практики: П06. Grype поверх готового SBOM · П09. VDR и VEX различие факта и решения · П35. VEX triage
- Нормативка: БДУ ФСТЭК · NIST SP 800-218 SSDF (RV.1–RV.3) · CISA KEV · EPSS
- Связанные шаблоны: Паспорт риска компонента · Регламент ретеста после исправления · Требования к CI security gate