П30. Исключения и принятие риска

Security gate завалил сборку на конкретном finding. Чинить нельзя/нечем прямо сейчас — нужно осознанно «жить с этим» ограниченное время. Эта практика — про то, как оформить принятие риска как запись с владельцем и сроком, а не как «голый mute» в интерфейсе сканера, и как связать карточку исключения с подавлением в gate одной датой.

Цель

Для одного блокирующего finding оформить связку «карточка в реестре + подавление в gate», где expiry карточки и ignoreUntil в конфиге сканера — одна и та же дата, а конфиг ссылается на ID карточки. Проверяемый результат: после добавления исключения число блокирующих findings у gate уменьшается ровно на одно, а в выводе сканера видно, что finding перенесён в «проигнорированные» с указанием причины.

Команда или действие

Берём воспроизводимый пример из модуля М14: lodash@4.17.19, CVE-2021-23337 (CVSS 7.2, command injection через _.template). Сначала фиксируем решение карточкой в реестре исключений (поля ниже), затем переносим ту же дату и ID в конфиг подавления OSV-Scanner.

Конфиг osv-scanner.toml рядом со сканируемым lockfile:

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

Запуск gate с конфигом (OSV-Scanner v2, scan-подкоманда):

# Базовый прогон — finding блокирует
osv-scanner scan -L package-lock.json

# Прогон с подавлением — конфиг ОБЯЗАТЕЛЬНО передаётся явно
osv-scanner scan -L package-lock.json --config ./osv-scanner.toml
echo "exit code: $?"

«Вечное» исключение — самая частая ошибка Подавление без ignoreUntil (или с датой, которую никто не отслеживает) живёт годами: фикс давно вышел, а risk acceptance всё ещё «активен». Поле срока обязательно. Истёкший ignoreUntil снова делает finding блокирующим — это и есть автоматический возврат на пересмотр, а не баг.

Что вы должны увидеть

Карточка в реестре исключений (минимальная единица учёта):

Поведение gate — ориентир по числу findings:

• Базовый прогон: CVE-2021-23337 присутствует в таблице уязвимостей, ненулевой exit code (сборка падает).
• Прогон с --config: то же finding уходит из блокирующих; OSV-Scanner отмечает его как отфильтрованное по конфигу, число блокирующих findings уменьшается на одно, exit code 0 (если это была единственная блокировка):

Filtered 1 vulnerability from output
No issues found
exit code: 0

Ключевая проверка: дата в ignoreUntil и Expiry карточки совпадают, а reason начинается с ID карточки — подавление трассируется до управленческого решения.

Если не получилось

Типичные ошибки - --config передали, но finding всё равно блокирует — конфиг не подхватился: либо забыли флаг (osv-scanner без --config ищет osv-scanner.toml только в сканируемой директории), либо неверный путь, либо id написан не в том регистре/формате (нужно ровно CVE-2021-23337). - ignoreUntil в прошлом — подавление не действует, finding остаётся блокирующим. Это правильное поведение для истёкшего исключения; для активного — проверьте, что дата в будущем. - Mute в UI сканера вместо карточки — finding скрыт, но решение нигде не записано: нет владельца, обоснования, срока. Через полгода никто не объяснит, почему он «ignored». Любое подавление должно ссылаться на ID карточки реестра. - unknown command "scan" / флаг не распознан — установлен OSV-Scanner v1, где форма иная (osv-scanner --config=osv-scanner.toml -L package-lock.json, без подкоманды scan). Сверьте osv-scanner --version.

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

Показать преподавателю: заполненную карточку исключения (с владельцем-ролью, обоснованием, компенсирующей мерой и expiry), конфиг osv-scanner.toml со ссылкой на ID карточки, и два прогона gate — до и с --config — где видно, что число блокирующих findings уменьшилось на одно. Совпадение дат ignoreUntil ↔ expiry обязательно.

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

• М14. Политики, исключения и принятие риска — родительский модуль.
• Смежные практики: П29 (вердикт готовности, который исключение помогает снять корректно), П07 (базовый прогон OSV-Scanner), П28 (откуда приходят непрошедшие приёмку компоненты).
• ISO/IEC 27001 — risk treatment: принятие риска как осознанный выбор с владельцем; NIST SSDF — PW.4/RV.1.
• Шаблоны: Реестр исключений · Порядок принятия риска · Политика приёмки сторонних компонентов.