Модуль JVN-Findings - реестр находок
Зачем он нужен

Раньше у нас было так: сканеры выдают кучу отчётов, кто-то вручную сводит их в таблицы, потом переносит в тикеты, потом отдельно считает просрочки - и это всё каждый раз заново. JVN-Findings это вытаскивает из разных мест и собирает в одном реестре. Все результаты - в одном списке, без ручной перегонки данных.

Что видно по каждой находке

По каждой записи можно сразу понять:
откуда пришла проблема;
на какой объект или путь она указывает;
насколько она критична;
в каком состоянии находится;
есть ли CVE;
входит ли в CISA KEV;
какой срок устранения установлен;
нарушен ли этот срок;
как менялся статус;
кто и что решил.

Главная мысль: ИБ-команда видит актуальную картину по всем рискам в одном месте, а не по частям в разных системах.

Как живёт находка

У каждой находки есть свой жизненный цикл:
обнаружено → открыто → триаж → работа над исправлением → проверка → закрыто.

Если риск не исправляется, его можно официально принять - с указанием причины и срока, на который это решение действует. То есть само наличие находки ещё не делает её подтверждённой угрозой: окончательное решение всегда за человеком.

Приоритеты
Уровни критичности:
🔴 Критический
🟠 Высокий
🟡 Средний
🔵 Низкий
⚪ Информационный
И отдельно система выделяет уязвимости из CISA KEV - чтобы их не затеряли среди сотен других записей. Это позволяет команде не разбирать всё подряд с одинаковым вниманием, а сосредоточиться на самом опасном.

Сроки и просрочки

Для каждого уровня критичности задаётся свой SLA. Пример:

Критичность SLA
Критическая 7 дней
Высокая 30 дней
Средняя 90 дней
Низкая 180 дней
Информационная 365 дней
Система сама отслеживает, где срок вышел, и показывает это прямо в реестре. Например: «Критические - 6 открытых, все 6 просрочены». Больше не нужно вручную сверять даты в Excel.

Фильтры и работа с дублями

Реестр позволяет отфильтровать находки по критичности, статусу, типу анализа, CVE, KEV, факту просрочки, объекту, пути. Есть и сворачивание дублей - особенно актуально, когда сканеры запускаются повторно. Вместо бесконечного потока одинаковых записей инженер видит одну логическую находку и работает с ней.

История изменений

Все ключевые решения по находке попадают в лог. В любой момент можно восстановить:
что нашли → когда нашли → какой статус поставили → какое решение приняли → кто принял → на каком основании → до какого срока.

Для аудита - как внутреннего, так и внешнего - это практически обязательная вещь.

Что в итоге получает ИБ-команда

Было:

сканеры → куча отчётов → CSV → Excel → ручной триаж → тикеты → ручной контроль SLA

Стало:

анализаторы → единый реестр → приоритеты → SLA → назначенный ответственный → устранение или принятие риска → аудит-логи

То есть модуль становится связующим звеном между тем, что нашли сканеры, и тем, что с этим делают дальше.


P.s - при написании текста была использована ИИ.