Как я решил приоритизацию самых критических уязвимостей и создал Vulnaware

У уязвимостей нет инцидента, нет простоя, нет тикета с горящим SLA. У неё нет ничего, что обычно заставляет IT сервис решать проблему быстрее. Именно поэтому она проигрывает конкуренцию за внимание ровно до того дня, когда становится инцидентом.

Verizon DBIR 2026 зафиксировал перелом: эксплуатация уязвимостей впервые за 19-летнюю историю отчёта обошла кражу учётных данных и стала вектором номер один это 31% взломов против 20% годом ранее.

Как должен выглядеть цикл управления уязвимостями

Стандарт NIST SP 800-40 Rev. 4 описывает цикл пятью стадиями: discovery -> identification -> prioritization -> remediation -> verification. Часто в компаниях трудности возникают между стадией обнаружения уязвимости и стадией когда «почему-то до сих пор не устранили», то есть ровно на приоритизации.

В реальности уязвимости эксплуатируются меньше 10% всех когда-либо опубликованных CVE. Отсюда самый разумный вывод будет: не бежать «закрыть все уязвимости», а «найти те самые», раньше, чем это сделает атакующий.

SLA которые никто не измеряет

Регуляторы требуют сроков устранения. Долгое время федеральный стандарт США BOD 22-01 был предельно прост: 15 дней на интернет доступные активы, а 25 на остальные, независимо от контекста. В июне 2026 CISA этот подход отменила директивой BOD 26-04, плоский дедлайн заменён матрицей из четырёх признаков, дающей срок 3, 14 или 60 дней:

• публичная доступность актива;

• присутствие в KEV;

• автоматизация эксплуатации;

• тяжесть технического воздействия.

В России требования по срокам устранения тоже есть. Но много ли компаний реально знают, за сколько дней у них закрывается критическая уязвимость, например на периметре сети? Задайте себе вопрос прямо: вы видели хотя бы в одной Российской VM-платформе честный график MTTR, ещё и по тем уязвимостям, что реально важны? Чаще всего этой цифры просто нет, потому что нет продуманной автоматизации и универсальных интеграций между сканером и системой, где выполняется работа IT сервиса. Либо у заказчиков нет такого запроса к вендорам, а значит отсутствует замер эффективности устранения уязвимостей в самих компаниях. Получается правило — молчание удобнее признания.

Оперативное исправление уязвимости начинается с ITSM

Существуют разные способы взаимодействия команд ИБ и ИТ, это могут быть отчеты об уязвимостях, а может быть и платформа ITSM, в которой можно создавать заявки(тикеты) на сервисное обслуживание. И да здесь речь идет про оперативное устранение, единичных случаев, а не тысячи запросов в неделю =)

Пока уязвимость не превратилась в тикет, её не существует для инженера, который
её будет устранять. Стандарт ITIL4 чётко описывает понятия:

• incident — незапланированное прерывание сервиса;

• service request — предсказуемая, заранее одобренная заявка;

• change — управляемое изменение системы.

Я считаю, что уязвимость, которую необходимо устранить, это не обязательно инцидент. Это change или service request с понятным исполнителем, сроком и очередью. Без этого «приоритизация» останется красивым списком, который никто не обязан выполнять. Но есть и мнение, считать уязвимость инцидентом и тут могут возникнуть спорные моменты между ИТ сервисом и ИБ. Можно прочертить линию посередине и задать более высокий приоритет для запроса, если уязвимость критическая и договориться по критериям оценки такой уязвимости и SLA. Это понимание должно быть у обеих сторон.

Сейчас Российские VM имеют реальный пробел: практически ни одно VM-решение в РФ, не интегрируется out of the box с большинством ITSM систем, ни с open-source, ни с коммерческими. Каждая такая интеграция возможно пишется заново, силами интегратора, под конкретный проект.

Vulnaware это приоритизация как отдельный слой

В итоге я решил построить свой инструмент, движок приоритизации уязвимостей, с внешней, независимой от VM вендора экспертизой, что в свою очередь дополнило осведомленность и полноту процесса приоритизации.

Здесь важна оговорка: Vulnaware это не VM-платформа. Vulnaware помогает решить один конкретный вопрос: что из найденного нужно устранять в первую очередь и как об этом оперативно узнает нужный человек. Это недостающий слой между сканером и ITSM.

В качестве источников я взял три сканера:

• Maxpatrol VM(пока что beta доработка);

• Nessus Pro;

• Greenbone/OpenVAS.

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

• группы активов в MaxPatrol VM;

• имя папки с задачами сканирования в Nessus;

• тег на хостах в Greenbone/OpenVAS.

Скоринг приоритизации уязвимостей я решил реализовать по следующим признакам:

• наличие эксплойта (KEV) в community фидах от компании Vulncheck;

• уязвимость — трендовая(если источник Maxpatrol);

• вхождения в CISA KEV каталог.

По сути приоритизировать только те уязвимости, которые имеют хотя бы эксплойт.

Как выглядит приоритизация и польза для SOC

Приоритизацию можно использовать как в автоматическом, так и в ручном режиме. В ручном режиме не будет автоматических оповещений и заведения тикетов в ITSM.

В приоритизацию включено две задачи:

• оперативно оповестить команду;

• завести тикет в ITSM системе.

Оперативное оповещение реализовано через Telegram бота для канала/группы, с возможностью(по желанию) сокрытия информации об активе(хост/IP), что бы не раскрывать внутреннюю информацию на мессенджере, если это критично. Так же реализовал оповещение по электронной почте. Шаблон сообщений реализован на Jinja.

Заведение тикета я реализовал в следующих платформах ITSM:

• Jira Service Management;

• GLPI;

• Znuny;

• osTicket.

С лидирующими Российскими ITSM вообще проблема, по сути нет свободного, открытого API с возможностью поиграться с их системами.

Так же я реализовал небольшое веб-приложение с таблицей учета уязвимостей и возможностью вручную пушить их по нужному каналу.

Что это даёт на практике

В итоге получился оперативный механизм приоритизации с дополнительной экспертизой и оповещением SOC 24/7. Из тысяч строк сканера приоритизируется только те, что реально представляют опасность. Реализация тикета, где тикет попадает туда, где уже работает инженер, в тот service desk, который уже внедрен в компании, а не в новый интерфейс, который никто не знает.

Ссылка на open-source репозиторий Vulnaware: github.com/ErSilh0x/VULNaware.