Больше 500 исправлений в одном патч-цикле Microsoft уже плохо помещаются не только в change log, но и в управленческую логику. На этом фоне управление уязвимостями перестает быть историей про количество закрытых CVE и превращается в вопрос, который совет директоров формулирует куда жестче: стали ли риски ниже, чем квартал назад, и можно ли это доказать.
Именно эту мысль разбирает в спонсорском материале Horizon3 издание The Register. Логика простая и неприятная для многих ИБ-команд: традиционное управление уязвимостями, завязанное на поток CVE, оценки CVSS и KPI по патчам, все хуже отвечает на главный вопрос бизнеса. Руководству не нужен красивый отчет о том, сколько критических дыр команда отметила как fixed. Ему нужен понятный ответ, может ли злоумышленник пройти по реальной цепочке атаки и добраться до того, что действительно важно для компании.
Проблема в том, что сама механика работы с уязвимостями давно перегрета. Индустрия десятилетиями строила инструменты, которые умеют находить все больше слабых мест и генерировать все больше телеметрии. Но обнаружить еще не значит понять, чем именно это грозит конкретной инфраструктуре. В материале цитируется Drew Vanover, principal security strategist в Horizon3: по его словам, пройти вручную через сотни исправлений, оценить их, приоритизировать и безопасно раскатить в проде уже практически нереально. И это не фигура речи. Если один вендор за один цикл выкатывает более 500 фиксов, классическая схема patch it and forget it начинает ломаться не на теории, а на операционном уровне.
Есть и вторая проблема: привычные оценки серьезности все хуже помогают в приоритизации. CVSS удобно использовать как общий язык отрасли, но для реального бизнеса это слишком грубая линейка. Критичная уязвимость в изолированном сервисе и средняя уязвимость в компоненте, из которого можно собрать рабочую цепочку атаки до ценных данных, для компании имеют разный вес. В статье напоминают, что в мае 2026 года Минторг США в своем отчете раскритиковал текущее состояние NVD и даже предложил NIST отказаться от выставления CVSS-оценок как обязательного ориентира. Сама база уязвимостей у NIST уже несколько лет живет с бэклогом, а в апреле регулятор, по сути, публично признал, что старая модель захлебнулась под объемом входящих CVE.
На этом фоне неудивительно, что в центре обсуждения оказался CTEM, Continuous Threat Exposure Management. Gartner еще в 2023 году выделил его как один из ключевых трендов в кибербезопасности, но сейчас эта конструкция начинает выглядеть не как модный фреймворк для презентации, а как попытка вытащить ИБ из болота метрик ради метрик. Подход CTEM разбивает работу на пять этапов: определить действительно важные для бизнеса активы, понять, как именно они экспонированы, расставить приоритеты по реальному риску, проверить эксплуатируемость и только потом мобилизовать исправление через нормальный operational loop. В такой логике управление уязвимостями перестает быть каталогизацией CVE и становится проверкой того, какие пути атаки реально существуют здесь и сейчас.
Отдельный нерв текста связан с ИИ. The Register пишет, что frontier-модели ускоряют не только поиск багов, но и подготовку эксплуатационного кода. Для защитников это плохая новость в квадрате. Во-первых, объем новых уязвимостей будет расти еще быстрее. Во-вторых, окно между обнаружением проблемы и ее практической эксплуатацией сжимается. Cloud Security Alliance уже описывает это как асимметричный цикл уязвимостей: атакующие благодаря ИИ двигаются быстрее, а компании патчатся медленнее, иногда уже после того, как эксплойт успел появиться. В таком режиме побеждает не тот, кто закрывает больше тикетов, а тот, кто раньше находит действительно опасную траекторию атаки и ломает ее.
Horizon3 продает здесь вполне конкретный ответ: автоматизированное пен-тестирование через платформу NodeZero. Идея не в том, чтобы еще раз просканировать инфраструктуру и выдать длинный список находок, а в том, чтобы показать доказуемый маршрут злоумышленника. Платформа, как описано в статье, не просто находит слабости, но пытается использовать их, затем двигается дальше по среде и строит цепочку атаки так, как это делал бы реальный нападающий. Для ИБ-команды и разработчиков ценность в том, что на выходе остается не шум из сотен записей, а более короткий список реально эксплуатируемых проблем с понятным доказательством. После исправления система перепроверяет маршрут. Если пройти по нему уже нельзя, тикет закрывается не по формальному признаку, а по проверяемому факту. Для CFO это уже не технический жаргон, а риск-метрика, которую можно читать без переводчика с языка CVE на язык денег.
Любопытно, что самый спорный тезис материала касается прода. Многие безопасники по привычке предпочли бы гонять такие тесты на цифровом двойнике, чтобы не рисковать боевой средой. Vanover спорит именно с этим: по его версии, тестировать в production безопаснее, потому что цифровой двойник слишком быстро устаревает в среде, где команды постоянно выкатывают изменения, меняют доступы и собирают инфраструктуру на лету. Horizon3 делает ставку на жесткие guardrails: не шифровать систему полностью, чтобы доказать возможность ransomware, а остановиться на действиях, которые демонстрируют достижение цели без разрушения сервиса. В статье приводится цифра в более чем 320 тысяч тестов в production-средах клиентов, включая организации с особенно жесткими требованиями к контролю.
Для русскоязычной IT-аудитории из этого следует довольно практичный вывод. Разработчикам и платформенным командам придется жить в мире, где список уязвимостей сам по себе уже почти бесполезен без контекста эксплуатации. CISO и CTO придется объяснять бизнесу не скорость установки патчей, а снижение экспонирования по конкретным маршрутам атаки. А HR и фаундерам стартапов полезно заранее принять неприятный факт: спрос смещается от людей, которые умеют «вести Vuln Management», к тем, кто может увязать ИБ, инфраструктуру, приложение и бизнес-риски в одну проверяемую картину.
Главный вопрос теперь не в том, приживется ли CTEM как очередная аббревиатура, а в том, насколько быстро рынок согласится считать исправленной только ту проблему, по которой больше нельзя пройти на практике. Если это станет новым стандартом, привычное управление уязвимостями по количеству CVE и срокам патчинга придется серьезно пересобирать.