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

В сфере искусственного интеллекта произошло заметное событие. ersilh0x 27 минут назад Как я решил приоритизацию самых критических уязвимостей и создал Vulnaware 4 мин 431 Информационная безопасность * Кейс У уязвимостей нет инцидента, нет простоя, нет тикета с горящим 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 — управляемое изменение системы.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.