cKEV Index: приоритизация уязвимостей в условиях ускоренных атак

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

Обнаружение ускорилось, устранение — нет. Растёт список открытых проблем. За каждым обновлением стоят люди и время. Возникает вопрос: что исправлять первым?

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

Один человек — множество атак

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

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

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

В cybersecurity мы видим дешевление разработки эксплойтов для известных уязвимостей — так называемых 1-day. На массовый продукт такие атаки особенно эффективны: описание проблемы и выпущенное исправление дают готовую отправную точку для эксплуатации.

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

Спрос опережает предложение

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

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

Даже крупные компании чувствуют это. В августе команда Microsoft объяснила задержку первого накопительного обновления Exchange Server тем, что использование ИИ увеличило объём находок. Каждую нужно подтвердить, воспроизвести, исправить, проверить на регрессии. Ежемесячные обновления безопасности выходили, но для большого обновления команда ждала более спокойного месяца — выпуск обновления и сразу следующее означал бы удвоить работу администраторов.

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

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

Когда порядок имеет значение

Если каждую неделю приходит 30 задач, а команда выполняет 20, очередь растёт на 10. Сортировка определит, какие 20 сделать первыми. Остальные ждут, а в конце недели ещё 30.

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

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

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

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

UPS учитывает эту динамику при выборе следующего шага.

Основа методики

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

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

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

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

Как это использовать

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

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

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

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

От записи к задаче

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

1. Проверьте, затронуты ли ваши системы. Сопоставьте запись с инвентаризацией и результатами проверки внешнего периметра. Уточните версию, конфигурацию, включённые функции, доступ. Совпадения названия продукта недостаточно.
2. Определите последствия и ближайшее действие. Что получит атакующий? Можно ли установить обновление сейчас? Если нет, выберите временную меру: ограничение доступа, отключение функции, изменение конфигурации. Проверьте, что она закрывает уязвимый путь.
3. Назначьте ответственного и срок. Укажите сервис, изменение и способ проверки. Один пакет может закрыть несколько CVE. Одна CVE потребует изменений в нескольких системах.
4. Следите за новыми событиями. Эксплойт, атаки или обход исправления требуют пересмотра срока. Должен быть понятный порядок ускоренного согласования.
5. Проверьте результат. Убедитесь, что обновлена рабочая копия, конфигурация вступила в силу, уязвимость устранена. При признаках эксплуатации разберитесь с инцидентом.

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

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

Ранние стадии UPS дают команде время на подготовку.

Баланс нагрузки

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

Мы проверили этот компромисс в модели очереди с ограниченной пропускной способностью. На выборке 245 уязвимостей, добавленных в CISA KEV в 2025 году, при разных ограничениях 35–53% задач удавалось завершить к моменту включения в каталог за счёт ранних сигналов.

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

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

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

Две стороны

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

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

У заказчика очередь — из изменений в инфраструктуре. Информация об уязвимости объясняет срочность. Ответственный за сервис планирует обновление с учётом последствий для бизнеса.

Доступ

Открытая версия cKEV Index доступна на сайте. В ней показаны уязвимости на стадиях Urgent Patch и Emergency/IR с краткой историей событий, повлиявших на приоритет.

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

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

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