Перейти к содержанию

Ручная перепроверка

Security Hub поддерживает два связанных механизма, закрывающих цикл «нашли уязвимость → исправили → находка автоматически закрылась»:

  1. Periodic verify_fixes — при каждом плановом ре-сканировании DomainScope и IaC-сканер сообщают Hub, что текущая загрузка является повторным проходом по тому же scope. Hub автоматически закрывает находки, которых сканер больше не видит.
  2. Manual rescan trigger — кнопки в UI Hub'а «Перепроверить» (на уровне проекта или конкретной находки), которые принудительно дёргают сканер прямо сейчас.

Когда что использовать

Сценарий Механизм
Стандартный day-to-day Periodic verify_fixes (включается one-time, дальше работает само)
После hot-fix'a — хочу убедиться сейчас, что находка закрылась Кнопка «Перепроверить» на карточке находки
После большого пакета изменений по периметру Кнопка «Перепроверить scope» на странице проекта
Подтвердить ручной триаж конкретной находки через LLM Кнопка «LLM-анализ» на карточке находки (через sandbox-проверку)

Автоматическое закрытие при плановом сканировании

По умолчанию выключено

Возможность не работает, пока её не включат явно. Это сознательное решение: при неполном сканировании слепое закрытие отсутствующих находок приводит к массовому ложному закрытию.

Сканеры помечают периодическую загрузку как повторный проход по тому же периметру. Hub сравнивает свежий отчёт с тем, что уже открыто на этом продукте по тому же сканеру, и закрывает находки, которых в новом отчёте нет.

Три условия, все обязательны:

  1. FEATURE_AUTO_VERIFY_FIXES=true — на всей установке;
  2. признак auto_verify_fixes_enabled — в настройках проекта;
  3. verify_fixes=true при загрузке — DomainScope и сканер конфигураций выставляют его сами при плановом повторном проходе.

Если хотя бы одно не выполнено, не закрывается ничего.

Плюс кворум. Даже при всех трёх условиях находка не закрывается с первого раза:

  • внутри одной проверки отсутствие подтверждается несколькими попытками (AUTO_VERIFY_PROBE_RETRIES, по умолчанию 3) — любой ответ «на месте» или «неопределённо» немедленно оставляет находку открытой;
  • закрытие происходит после AUTO_VERIFY_ABSENT_THRESHOLD последовательных проверок с результатом «отсутствует» (по умолчанию 3). Любое обнаружение сбрасывает счётчик.

Текущее значение счётчика хранится у каждой находки в поле auto_verify_absent_streak.

Что Hub пишет в Jira при автозакрытии

Если у закрываемой находки есть связанная задача в Jira, Hub:

  • добавляет к задаче комментарий (по умолчанию):

Находка автоматически закрыта по результатам повторного сканирования: при свежем сканировании того же scope сканер больше не обнаружил эту уязвимость. Если уверены, что проблема остаётся актуальной — переоткройте задачу вручную.

  • при заданном auto_verify_close_transition переводит задачу в указанный статус. Настраивается в jira_config проекта:
auto_verify_close_comment: "Свой текст комментария..."
auto_verify_close_transition: "Resolved"   # имя транзишена

Если оставить auto_verify_close_transition пустым — будет только комментарий, задача остаётся в текущем статусе и закрывается уже вручную ответственным.

Manual rescan trigger

После включения функции в UI появляются две кнопки.

«Перепроверить scope» — на странице проекта

Запускает все подключённые к проекту сканеры по полному перечисленному scope. Полезно после большого обновления инфраструктуры, miration ивента, или когда нужно быстро убедиться, что приоритетные находки закрыты.

Кнопка видна пользователям с правом write на проект.

«Перепроверить через сканер» — на карточке находки

Доступна только для сетевых находок (есть host/ip). Триггерит точечный re-scan конкретного host:port. Если уязвимости больше нет — следующий тик сервиса auto-verify закроет находку как fixed.

Кнопка видна пользователям с правом write на продукт.

«LLM-анализ» — на карточке находки

Уже существующая кнопка. Перезапускает LLM-классификатор с учётом текущего состояния находки и (опционально) sandbox-проверку. Не вызывает сканер, не меняет инфраструктурно ничего. Полезно когда:

  • Изначальный вердикт LLM был «uncertain» и появилось дополнительное мнение.
  • Изменился контекст находки (новые теги, обновлённое описание).
  • Хотим повторно проверить найденный потенциальный false-positive перед закрытием.

Включение функции (Hub-сторона)

Установите три блока env-переменных Hub:

# Мастер-переключатель (без него endpoints возвращают 404)
FEATURE_MANUAL_RESCAN=true

# Auto-verify-fixes должен быть включён, чтобы цикл работал
FEATURE_AUTO_VERIFY_FIXES=true

# Адреса и API-ключи сканеров (см. ниже DomainScope/IaC-сторону)
DOMAINSCOPE_RESCAN_URL=http://<domainscope-service>:8087
DOMAINSCOPE_RESCAN_API_KEY=<любая случайная строка ≥ 32 символов>
IAC_SCANNER_RESCAN_URL=http://<iac-scanner-service>:8086
IAC_SCANNER_RESCAN_API_KEY=<любая случайная строка ≥ 32 символов>

# SSRF-защита: allowlist host'ов (comma-separated, без scheme/port), на которые
# Hub'у разрешено слать rescan-webhook. ОБЯЗАТЕЛЕН, если задан хотя бы один из
# *_RESCAN_URL выше — иначе Hub может быть направлен на произвольный destination
# при operator-misconfig. Перечислите host'ы из *_RESCAN_URL.
RESCAN_HOST_ALLOWLIST=<domainscope-service>,<iac-scanner-service>

# (optional) сетевой таймаут на вызов сканер-webhook'а
RESCAN_TIMEOUT_SECONDS=10

После выставления — перезапуск Hub backend (docker compose up -d backend или kubectl rollout restart deploy/hub-backend).

После перезапуска включите в UI каждого проекта, для которого хотите автозакрытие, флаг «Auto-verify fixes» в панели проекта.

Включение функции (сканер-сторона)

И DomainScope, и IaC-сканер запускают встроенный HTTP-сервер, принимающий webhook'и Hub'а. Без RESCAN_API_KEY в окружении сервер не стартует — это сознательная защита (никаких неаутентифицированных endpoints).

DomainScope:

RESCAN_API_KEY=<тот же ключ, что в DOMAINSCOPE_RESCAN_API_KEY у Hub>
RESCAN_LISTEN_ADDR=:8087                  # default :8087
# (optional) accept только для конкретного project_id Hub'а:
RESCAN_EXPECTED_PROJECT_ID=<uuid проекта в Hub>

В Compose/Helm не забыть expose-нуть порт 8087 внутри сети cluster'а так, чтобы Hub backend смог достучаться.

IaC-сканер:

RESCAN_API_KEY=<тот же ключ, что в IAC_SCANNER_RESCAN_API_KEY у Hub>
RESCAN_LISTEN_ADDR=:8086                  # default :8086

IaC-сканеру требуется service-аккаунт Hub'а со scope list_products — уже должен быть настроен (используется текущим scheduler'ом).

Что увидит оператор

  • В аудит-логе Hub'а появятся записи rescan_dispatched_project / rescan_dispatched_finding с указанием инициатора и job_id сканера.
  • В аудит-логе закрытий — auto_verify_fixed с указанием engine'а сканера и причины.
  • В связанной задаче Jira — комментарий с объяснением, что находка закрыта автоматически, и что делать, если вы с этим не согласны.

Отключение / отмена

  • Глобальный kill-switch для manual rescan: FEATURE_MANUAL_RESCAN=false + рестарт Hub. Кнопки исчезнут, endpoint'ы вернут 404.
  • Глобальный kill-switch для auto-close: FEATURE_AUTO_VERIFY_FIXES=false + рестарт. Сканеры продолжат отсылать verify_fixes=true, но Hub не будет ничего закрывать.
  • Per-project: снять флаг «Auto-verify fixes» в панели проекта. Действует немедленно.

Связанные разделы