Конспект: Политики, исключения и принятие риска

Зачем модуль

SCA/OSA-инструмент выдаёт findings, но не имеет полномочий ни блокировать релиз, ни разрешить «жить с уязвимостью». Без явной политики команда скатывается в одну из двух крайностей: либо блокирует merge на любом Medium и разработка встаёт, либо массово «мьютит» всё в интерфейсе сканера — и через полгода никто не знает, почему 140 findings помечены как «ignored» и истёк ли их срок. Модуль закрывает эту дыру: политика приёмки задаёт измеримые пороги, а всё, что не проходит порог, либо чинится, либо оформляется как исключение с владельцем и сроком пересмотра. Решение перестаёт жить в голове дежурного и становится записью в реестре.

Ключевые идеи

Политика — это пороги, а не лозунги. «Не пускаем уязвимые компоненты» неисполнимо; исполнимо — конкретные условия. Например: блокировать сборку при CVSS v3.1 base ≥ 7.0 с известным фиксом; блокировать любую копилефт-лицензию (GPL-2.0-only, AGPL-3.0) в проприетарном дистрибутиве; немедленно ронять pipeline при срабатывании malware-сигнала (тайпсквоттинг, вредоносный postinstall). Порог должен ссылаться на машинный факт: CVSS-вектор, SPDX-идентификатор лицензии, флаг malicious из фида.

Severity и эксплуатируемость — разные оси. Порог по CVSS отсекает по тяжести, но не по достижимости. Поэтому политика работает в паре с VEX: компонент с Critical может быть not_affected, если уязвимый код не вызывается. Это переводит часть findings из «блокер» в «обоснованно допущено» без оформления риска.

Security gate ≠ управленческое решение. Gate — автоматическое правило в CI: детерминированное, без подписи, без срока. Оно отвечает «проходит / не проходит». Принятие риска — это решение человека жить с тем, что gate завалил: оно требует автора (владельца риска по роли), обоснования, компенсирующих мер и expiry. Gate без процедуры исключения превращается в стену; процедура без gate — в благие намерения.

Слепая зона: «вечное» исключение Самая частая ошибка — исключение без expiry или с датой, которую никто не отслеживает. Через год компонент остаётся в дистрибутиве, фикс давно вышел, а risk acceptance всё ещё «активен». Срок пересмотра — обязательное поле; истёкшее исключение автоматически возвращает finding в статус «блокирует».

Как выглядит на практике

Карточка исключения — минимальная единица учёта. Пример записи в реестре:

Тот же случай в gate (пример OSV-Scanner с конфигом подавления osv-scanner.toml):

[[02 Справочник/Глоссарий/IgnoredVulns|IgnoredVulns]]
id = "CVE-2021-23337"
ignoreUntil = 2026-09-17T00:00:00Z   # дата = expiry карточки EXC-2026-014
reason = "EXC-2026-014: _.template не вызывается; ретест после апгрейда"

Ключевая дисциплина: ignoreUntil в конфиге gate и expiry в реестре — одна и та же дата; конфиг ссылается на ID карточки, а не живёт сам по себе.

Связь с нормативкой

• ISO IEC 27001 — risk treatment: принятие риска как осознанный выбор с владельцем.
• NIST SP 800-218 SSDF — PW.4/RV.1: обработка third-party компонентов и реакция на уязвимости.
• ГОСТ Р 56939-2024 и Проект ГОСТ Р КАПО — управляемость работ и регулярность применения КАПО.
• Шаблоны: Политика приемки сторонних компонентов · Реестр исключений · Порядок принятия риска.

Что уносим в работу

1. Переписать политику как таблицу порогов CVSS / лицензии / malware с привязкой к машинному факту.
2. Любое подавление в сканере должно ссылаться на ID карточки исключения — «голых» mute быть не должно.
3. Поле expiry обязательно; истёкшее исключение возвращает finding в блокирующий статус.
4. Развести в регламенте, что решает gate, а что — владелец риска.
5. Отработать оформление на П30.