cKEV Index: успеть до полуночи

ИИ помогает быстрее искать уязвимости, разбирать исправления и готовить эксплойты. Окно технологических работ от этого длиннее не становится. У команды по-прежнему есть проверка совместимости, согласования и системы, которые должны работать. Атакующему достаточно выбрать одну подходящую ошибку.

Чем больше находок, тем острее вопрос: что исправлять первым? За каждым обновлением стоят люди и время. Если обнаружение ускоряется, а устранение остаётся на прежнем уровне, растёт очередь открытых проблем.

Поэтому мы открываем cKEV Index — каталог приоритетных уязвимостей СайберОК на основе методики Urgent Patch Score (UPS). В нём собраны проблемы, требующие срочного внимания, и события, которые объясняют их приоритет: появление эксплойта, подтверждение атак и другие свидетельства. В открытой версии представлены стадии Urgent Patch и Emergency / IR с сокращённой историей событий.

Один дома

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

В сентябрьском отчёте Anthropic описаны два показательных случая. В кампании GTG-50014 злоумышленники использовали ИИ на разных этапах — от разведки до эксплуатации и обработки похищенных данных. Один из них организовал массовый разбор Android-приложений для поиска ключей и учётных данных. В случае GTG-50029 одиночный атакующий применял агентов для разведки, анализа кода и проверки находок. Claude помог ему разработать и отладить эксплойт, сработавший, как минимум, на четырёх сайтах.

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

В СайберОК мы видим рост возможностей поиска не только ещё неизвестных уязвимостей, но и удешевление разработки эксплойтов к уже раскрытым недостаткам — 1-day. Для атак на массовый продукт второй путь особенно привлекателен: описание проблемы и выпущенное исправление дают готовую отправную точку.

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

Горшочек не вари

Исследователи и разработчики используют те же возможности. Наш пример — открытый фреймворк rust-in-peace, который эксперты СайберОК развивают для анализа безопасности программ с помощью ИИ-агентов. Он объединяет несколько способов поиска, проверку гипотез, воспроизведение ошибок и проверку исправлений.

Публичный реестр проекта содержит около сотни находок, направленных разработчикам проектов с открытым исходным кодом, включая ядро Linux.

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

Даже у крупных разработчиков эта работа уже влияет на график выпуска обновлений.

Так, в августовской публикации Where is Exchange SE CU1 anyway? команда Microsoft объяснила задержку первого накопительного обновления Exchange Server Subscription Edition тем, что использование ИИ увеличило объём находок. Каждую из них необходимо подтвердить, воспроизвести, исправить и проверить на регрессии. При этом, ежемесячные обновления безопасности продолжали выходить. Но для выпуска CU1 команда ждала более спокойного месяца: выпускать большое обновление и сразу заставлять администраторов устанавливать следующее, означало бы, удвоить их работу.

Другой пример — Oracle в июльском Critical Patch Update сообщила об исправлении 1434 различных CVE. На тот момент это был крупнейший выпуск обновлений безопасности компании. Среди причин Oracle назвала расширение охвата продуктов, применение ИИ для обнаружения проблем и ускорение разработки исправлений. Да, это квартальное обновление, и не все уязвимости нашёл ИИ. Но тенденция понятна. По нашей оценке, до насыщения ещё далеко.

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

Игры разума или как совладать со следующей волной

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

Что приходит на ум, когда стоит задача приоритизации угроз?

CVSS Base описывает техническую тяжесть уязвимости; дополнительные метрики CVSS учитывают угрозы и особенности среды. EPSS оценивает вероятность эксплуатации CVE в реальных атаках в ближайшие 30 дней (документация CVSS, EPSS FAQ).

Однако выбрать стратегию исправлений по одному EPSS не получается. В работе Prediction Meets Patch Queues: Empirical Limits of EPSS-Only Prioritization Using CISA KEV Additions in 2025 мы проверили распространённый подход: исправлять всё, у чего прогнозируемая вероятность выше выбранного порога.

Высокий порог оставляет за бортом часть уязвимостей, которые уже используются в атаках. Низкий резко увеличивает объём проверок и исправлений. В модели с ограниченными ресурсами команда получает растущую очередь, а часть важных задач всё равно опаздывает. При этом задержка может возникнуть ещё до постановки задачи: нужной оценки пока нет, или она пересекает порог слишком поздно. Дополнительные сотрудники исправят больше задач из очереди, но пропущенную таким отбором уязвимость они в ней не увидят.

В реальной инфраструктуре к этому добавляются вопросы: установлен ли уязвимый продукт, доступна ли нужная функция, какие права требуются атакующему, что он сможет сделать? Сколько времени займёт обновление и можно ли до него ограничить доступ к опасной функции?

Обстановка тоже меняется. В понедельник опубликовано описание дефекта, в среду появились подробности его воспроизведения — PoC, а в пятницу — готовый модуль эксплуатации. Позже разработчик подтвердил использование уязвимости в атаках. Техническая тяжесть осталась прежней, а срочность выросла.

UPS учитывает эту историю при выборе следующего действия.

Время, вперёд!

Методика описана в исследовании СайберОК UPS Meets Patch Queues: Evidence-timeline prioritization under limited capacity, cadence, and compliance gravity.

UPS собирает проверяемые сигналы: публикации, появление инструментов эксплуатации, сведения об атаках. У каждого события есть дата и источник. По мере поступления сведений уязвимость переходит в следующую фазу работы. Сильный сигнал может сразу поднять её приоритет: проходить все ступени по порядку необязательно.

Каждую фазу можно связать с действиями команды. Конкретные сроки и ответственных задаёт сама организация.

На стадии Emergency команда проверяет, затронуты ли её системы, и ищет следы возможной атаки. Решение о начале расследования принимает по результатам этой проверки.

В таксономии UPS отдельно учитываются публикация PoC, появление готового средства эксплуатации и подтверждение атак. Для сильных сигналов установлена максимальная срочность. Повторные пересказы одного сообщения отсеиваются, чтобы популярность новости не умножала её вес.

Важен и момент, когда сведения стали доступны. Если об атаке узнали в пятницу, то оценивать принятое в понедельник решение нужно по тем данным, которые были у команды в понедельник. История сигналов сохраняет эти основания и помогает разобраться, когда именно возникла необходимость действовать быстрее.

 Показания приборов

В открытой версии cKEV показаны две наиболее срочные стадии UPS — Urgent Patch и Emergency / IR. В карточке есть балл cKEV, фаза и сокращённая история событий. Дополнительные поля содержат описание, CVSS, EPSS, сведения об эксплуатации, ссылки и рекомендации — по мере наличия данных.

Начинать стоит с основания срочности. Уязвимость уже используют в атаках? Появился готовый эксплойт? Что известно о необходимых правах и конфигурации? Пустое поле означает, что сведения ещё предстоит уточнить.

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

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

Дело техники

 Чтобы запись из каталога стала задачей для ИТ, её нужно связать с конкретной системой, ответственным и способом устранения.

1. Проверьте, затронуты ли ваши системы. Сопоставьте запись с инвентаризацией и результатами проверки внешнего периметра. Уточните версию, конфигурацию, включённые функции и доступ к ним. Одного совпадения названия продукта для этого мало.

2. Определите последствия и ближайшее действие. Что получит атакующий при успешной эксплуатации? Можно ли установить обновление сейчас? Если потребуется время, выберите временную меру из рекомендаций разработчика: ограничение доступа, отключение функции или изменение конфигурации. Проверьте, что она действительно закрывает опасный путь.

3. Назначьте ответственного и срок. В задаче должны быть указаны сервис, необходимое изменение и способ проверки результата. Один пакет обновлений может закрыть несколько CVE. Одна CVE может потребовать отдельных изменений в нескольких системах.

4. Следите за новыми событиями. Готовый эксплойт, подтверждённые атаки или обход исправления могут потребовать пересмотра срока. У задачи должен быть понятный порядок ускоренного согласования.

5. Проверьте результат. Убедитесь, что обновлена работающая копия приложения, нужная конфигурация вступила в силу и уязвимость устранена. Если обнаружены признаки эксплуатации, разберитесь с возможным инцидентом.

Рассмотрим условную ситуацию. Для внешнего сервиса вышел бюллетень безопасности. Обновление назначено на следующее окно, команда нашла затронутые экземпляры и подготовила тестовую среду. Затем появился готовый модуль эксплуатации, и уязвимость перешла в Urgent Patch.

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

В этом и польза ранних стадий UPS: команда получает время на подготовку.

День сурка

Сколько задач начинать заранее? Глубокий разбор каждого слабого сигнала быстро займёт всё время. Ожидание подтверждённых атак оставит команду с подготовкой и установкой обновления в последний момент.

В исследовании UPS мы проверили этот компромисс в модели очереди с ограниченной пропускной способностью. В выборке было 245 уязвимостей, добавленных в CISA KEV в 2025 году. При разных ограничениях пропускной способности 35–53% задач удавалось завершить к дате включения уязвимости в KEV за счёт более ранних сигналов. Контрольной точкой служила дата включения в каталог, к которой эксплуатация уже была подтверждена (исследование и материалы).

Для своей команды стоит посчитать затраты на первичный разбор, поиск затронутых систем, испытания, согласование, устранение и повторную проверку. Тогда станет видно, сколько задач можно готовить заранее и где скапливается работа.

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

Если очередь всё равно растёт, придётся менять условия: закрывать лишние внешние интерфейсы, автоматизировать испытания, объединять изменения или добавлять людей. Часть рисков организация может принять на определённый срок. У такого решения должны быть ответственный, основание и дата пересмотра.

Две очереди

У разработчика средств защиты своя очередь, так новый дефект нужно исследовать, подготовить способ обнаружения, проверить его точность и безопасность. Появление эксплойта может потребовать срочно вернуться к известной уязвимости и доработать проверку.

UPS помогает нам выбирать, какие из этих работ ускорить. Например, появление готового модуля эксплуатации повышает приоритет разработки проверки на соответствующую уязвимость. Подтверждение атак требует проверить, способны ли мы обнаружить проблему у заказчиков и какие рекомендации можем им дать.

У заказчика очередь состоит из изменений в его инфраструктуре. СКИПА и PentOps помогают найти доступные системы и проверить их защищённость. Сведения об уязвимости объясняют срочность. Ответственный за сервис планирует обновление с учётом его последствий для бизнеса.

Доступ открыт

Ограниченная версия cKEV Index доступна публично: открыть каталог. В ней представлены стадии Urgent Patch и Emergency / IR с сокращённой историей событий.

Полная версия и API доступны пользователям CyberOK СКИПА, PentOps и Vulnum. Через API данные можно включить в собственный процесс управления уязвимостями.

Методика, таксономия сигналов и исследовательские материалы также опубликованы.

Для начала выберите несколько записей по продуктам, которые используются у вас. Найдите затронутые системы, разберите причину срочности и проверьте, назначены ли ответственный и срок устранения.