Окно эксплуатации уязвимостей ушло в минус: что ИИ меняет в защите

По данным Mandiant M-Trends, на которые ссылается автор цикла об управлении уязвимостями на Habr, среднее время до эксплуатации в 2025 году ушло примерно в минус 7 дней: атака в среднем начиналась раньше патча. Окно эксплуатации уязвимостей сжалось настолько, что суточный SLA на критические дыры становится условием выживания. ИИ при этом ускоряет защиту, вооружает атакующих и добавляет компании новую поверхность атаки: чат-ботов и MCP-серверы.

Почему окно эксплуатации уязвимостей сделало суточный SLA обязательным?

Атакующий успевает раньше, чем многие компании доходят до первого совещания по патчу. В девятнадцатой части цикла «Управление уязвимостями для самых маленьких» на Habr автор напоминает цифры из прошлых глав: от публикации уязвимости до эксплойта в среднем проходит 5 дней, а каждую четвёртую уязвимость атакуют в день публикации.

Со ссылкой на Mandiant M-Trends автор добавляет: в 2025 году среднее время до эксплуатации впервые стало отрицательным, около минус 7 дней. Атака в среднем начиналась раньше, чем производитель выпускал исправление. С ИИ-инструментами у атакующих, по его оценке, счёт пойдёт на часы.

У цифры есть оговорки. Методики в пересказе нет: неизвестно, на какой выборке считали и как учитывали уязвимости нулевого дня, которые эксплуатировали ещё до публикации. Одна долгая кампания с такой уязвимостью сдвигает среднее сильнее сотни рядовых CVE. Поэтому «минус 7» лучше читать как направление, а не как константу для расчёта SLA.

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

Как устроить суточный трек на практике

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

• Критерии эскалации. В суточный трек попадает CVE на активе, доступном из интернета или недоверенного сегмента, если выполнено хотя бы одно условие: уязвимость есть в CISA KEV, опубликован рабочий эксплойт, производитель сообщает об эксплуатации, либо CVSS 9 и выше без аутентификации.
• Компенсирующие меры. Закрыть сервис списком разрешённых адресов или убрать за VPN, включить виртуальный патч на WAF или IPS, отключить уязвимую функцию или модуль, усилить мониторинг по признакам из бюллетеня. Меру считают принятой, когда её проверили снаружи.
• Кто решает. Владелец системы отвечает за патч или меру, ИБ проверяет результат. Если за сутки невозможно ни то ни другое, исключение письменно принимает бизнес-владелец вместе с руководителем ИБ и со сроком пересмотра. Дежурный инженер в чате такое решение не принимает.

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

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

Чем ML-приоритизация отличается от ещё одного отчёта сканера?

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

Самым зрелым применением ИИ в управлении уязвимостями автор считает ранжирование. В коммерческих платформах это Tenable VPR, Qualys TruRisk и Rapid7 Active Risk: машинное обучение разбирает тысячи признаков и оставляет десятки по-настоящему срочных задач. Заявленный эффект: приоритетная очередь сокращается на 40-50 %. Независимого замера в статье нет, проверьте цифру на своей очереди.

Рядом с коммерческими моделями работает открытая EPSS. Автор описывает её как ML-модель, которая предсказывает вероятность эксплуатации. Добавим то, чего в пересказе нет: EPSS ведёт сообщество FIRST, модель выдаёт число от 0 до 1 для горизонта в 30 дней и регулярно его пересчитывает. Значение месячной давности могло уже устареть.

CVSS, EPSS и KEV в отчётах часто стоят в соседних колонках, но отвечают на разные вопросы.

Каталог CISA Known Exploited Vulnerabilities из ML-скоринга не выводится: это отдельный источник, куда CVE попадает после подтверждённой эксплуатации. Поэтому он годится для сверки. Если модель отодвинула вниз CVE из KEV, разбираться надо с моделью. Обратное не работает: каталог не претендует на полноту и не знает, доступен ли ваш сервер из интернета.

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

Заметка практика. На проектах мы регулярно видим одну картину: скоринг понижает приоритет уязвимости на «внутреннем» сервере, который на деле опубликован наружу через забытый проброс порта или старое правило балансировщика. Модель не знает вашу сетевую топологию. Для интернет-доступных активов отдельно проверяйте KEV, рабочий эксплойт, сетевую достижимость и фактическую версию компонента, а не ту, что записана в CMDB.

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

Big Sleep, XBOW и агентный SOC: где работа, а где самоотчёт

Самый весомый результат у Google. Проект Big Sleep, совместная работа DeepMind и Project Zero, в 2025 году находил реальные уязвимости в широко используемом ПО, в том числе в библиотеке SQLite. В одном случае агент нашёл CVE-2025-6965, которую, по данным Google, злоумышленники уже готовились эксплуатировать.

Google назвал это «первым случаем, когда ИИ-агент предотвратил эксплуатацию уязвимости в реальных условиях». Это заявление самой компании: как Google узнал о подготовке атаки, из пересказа не следует, и снаружи проверить это нельзя. Сама находка в SQLite с присвоенным CVE остаётся фактом, а не демонстрацией на стенде.

С XBOW картина менее однозначная. Автономная система для пентеста в апреле-июне 2025 года занимала первое место в рейтинге американского сегмента HackerOne в категории программ раскрытия уязвимостей (VDP), а к августу опустилась на третье. Отсюда же расходится по презентациям цифра «в 85 раз быстрее человека».

Её источник: собственный бенчмарк XBOW из 104 сценариев, которые система прошла за 28 минут против 40 часов у пентестера с 20-летним стажем. Это самоотчёт компании, а не независимый аудит. Время прохождения сценариев ничего не говорит о качестве проверки, полноте покрытия и воспроизводимости на чужой системе.

Автор сам предлагает относиться к цифре как к маркетингу, но признаёт порядок величины: если ИИ находит уязвимости за минуты, атакующие с такими инструментами будут находить их так же быстро. Похожий разрыв между заявленными цифрами и реальным стендом мы видели в тесте ИИ-агентов для пентеста на Juice Shop.

Третья линия, агентный SOC. ИИ-агенты забирают рутину первой линии: разбор алертов, первичную сортировку, обогащение данными. Под это выросла отдельная категория продуктов с иерархией агентов, которые автоматизируют анализ уровня L1/L2. Gartner, по словам автора, относит ИИ-агентов в безопасности к главным трендам 2026 года.

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

Отвечает ли компания за ответы своего чат-бота?

Да, и это уже проверено в суде. Автор называет ИИ как объект атак самой недооценённой из трёх ролей. Чат-бот для клиентов, ассистент или ML-модель антифрода появляются как новый класс активов со своими уязвимостями, а за их ошибки платит компания.

Air Canada: бот как часть сайта

В феврале 2024 года канадский трибунал по мелким искам обязал Air Canada выплатить пассажиру компенсацию. Чат-бот на сайте выдумал несуществующее правило возврата по льготному тарифу для поездки на похороны, и пассажир заплатил почти вдвое больше положенного.

Авиакомпания доказывала, что бот это «отдельное юридическое лицо, отвечающее за свои слова». Арбитр довод отверг: бот часть сайта, значит, отвечает компания. Сумма здесь вторична, важен прецедент.

MyCity: почти два года незаконных советов

Городской чат-бот Нью-Йорка MyCity с марта 2024 года давал предпринимателям незаконные советы: что можно забирать чаевые у сотрудников, отказывать держателям жилищных ваучеров и не принимать наличные. Всё это городские законы прямо запрещают.

Расследование вышло уже в апреле 2024 года. Власти оставили бота работать под вывеской «пилотного проекта», добавив дисклеймер, и закрыли его только в феврале 2026 года.

Chevrolet: внедорожник за доллар

В ноябре 2023 года пользователь простой манипуляцией промптом велел чат-боту дилерского центра Chevrolet соглашаться со всем, что говорит клиент, и добавлять, что предложение юридически обязывающее. Бот «продал» внедорожник за один доллар. Пост набрал 20 млн просмотров, сделку дилер не исполнил.

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

Какие угрозы описывает OWASP Top 10 для LLM

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

• prompt injection: вредоносные инструкции в тексте заставляют модель обходить ограничения и раскрывать данные;
• утечка системного промпта (prompt leaking): выманивание скрытых инструкций;
• jailbreak: обход встроенных ограничений, часто под предлогом «образовательных целей»;
• отравление обучающих данных: например, антифрод начинает пропускать мошенников;
• утечка конфиденциальных данных, переданных во внешний ML-сервис.

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

Для российского бизнеса добавляется вопрос, какие персональные данные клиентов бот отправляет во внешний ML-сервис и где этот сервис находится. Для 152-ФЗ это вопрос с конкретными последствиями. Такие сценарии закрывает ручной пентест LLM-приложений, а не скоринг CVE.

Кто отвечает за безопасность MCP-серверов, если протокол её не даёт?

Тот, кто сервер разворачивает и подключает. В 2025 году ИИ-агенты массово перешли на Model Context Protocol от Anthropic, который связывает модель с внешними инструментами и данными. Спецификация прямо признаёт: на уровне протокола безопасность не обеспечивается, это целиком забота того, кто поднимает сервер.

В апреле 2025 года Invariant Labs описали Tool Poisoning Attack. Вредоносная инструкция прячется в описании инструмента: модель его читает, пользователь в интерфейсе не видит. В демонстрации безобидный на вид MCP-сервер «факт дня» незаметно подменял логику легитимного сервера и вытаскивал переписку из WhatsApp.

В июле 2025 года нашли CVE-2025-54136 в Cursor по прозвищу MCPoison, CVSS 8,8. Редактор слепо доверял однажды одобренной конфигурации MCP, даже если после одобрения её тихо заменили вредоносной командой. Пользователь подтверждал одно, запускалось другое. Уязвимые и исправленные версии в пересказе не указаны, их надо смотреть в бюллетене Cursor.

Потом пошла целая серия. По подсчёту, на который ссылается автор, за первые недели 2026 года против MCP-серверов набралось больше тридцати CVE, почти половина из них варианты внедрения команд. Схема одна: через prompt injection атакующий заставляет модель вызвать инструмент так, что на хосте выполняются произвольные команды. Продукты и идентификаторы в статье не перечислены, поэтому цифру лучше воспринимать как оценку масштаба.

Стандарты догоняют. OWASP в декабре 2025 года выпустил Top 10 для агентных приложений, отдельный MCP Top 10 готовится, MITRE добавил профильные техники в ATLAS. Автор добавляет практичную деталь: MCP-серверы в компании скорее всего уже есть, даже если ИБ о них не знает, и инвентаризировать их нужно как любой сервис на периметре.

Как провести инвентаризацию MCP-серверов

1. Где искать. На рабочих станциях разработчиков: .cursor/mcp.json в проектах и ~/.cursor/mcp.json, .vscode/mcp.json, claude_desktop_config.json у Claude Desktop. В репозиториях ищите ключ mcpServers. Удалённые MCP-эндпоинты видны в журналах прокси и в списке интеграций корпоративных ИИ-ассистентов.
2. Что записать. Команду запуска и аргументы, источник пакета и закреплённую версию, транспорт (локальный процесс или удалённый адрес), список инструментов с описаниями.
3. Какие у сервера права. Какие токены он получает из окружения, к каким системам ходит, может ли писать, удалять или выполнять команды на хосте.
4. Кто владелец. За каждым сервером закрепляется команда, которая его подключила и отвечает за обновления. Сервер без владельца отключают до выяснения.
5. Как следить за изменениями. Храните утверждённые конфигурации в репозитории, смотрите diff после обновлений и повторно подтверждайте не только имя сервера, но и команду, аргументы и схему инструментов. Именно этот разрыв эксплуатировала MCPoison.

Из этих историй следует одно инженерное правило: системный промпт не служит механизмом авторизации. Запрет «никогда не удаляй данные» модель выполняет вероятностно. Права ОС, отдельная учётная запись и внешняя проверка параметров инструмента работают независимо от того, что ответила модель. Где у вас проходит граница доверия, показывает тестирование безопасности ИИ-агентов.

Пытался ли ИИ сбежать из песочницы на самом деле?

Подтверждённых случаев в боевых развёртываниях нет, и это говорят сами OpenAI и Anthropic. Anthropic пишет об этом в исследовании Agentic Misalignment, а в августе 2025 года, когда компании проверяли модели друг друга, обе повторили оговорку: такое поведение видели только в контролируемых тестах.

Громкие заголовки берутся из стресс-тестов, где модель нарочно загоняют в угол:

• Apollo Research, декабрь 2024 года, OpenAI o1. Модели подсунули поддельную переписку о скорой замене и дали доступ к файлам как самостоятельному агенту. Попытки отключить надзор случились в 5 % запусков, подделка данных в пользу своей цели в 19 %, копирование себя поверх модели-замены в 2 %. Оба «сервера», между которыми шло копирование, были изолированными песочницами, к своим весам модель доступа не имела. На последующих расспросах она в 99 % случаев отрицала свои действия или лгала.
• Anthropic, май 2025 года, Claude Opus 4. Корпоративный ассистент с доступом к почте и искусственно суженный выбор между шантажом и бездействием. Шантаж в 84-96 % запусков.
• Тот же сценарий на моделях других разработчиков, июнь 2025 года. Gemini 2.5 Flash: 96 %, GPT-4.1 и Grok 3: 80 %, DeepSeek-R1: 79 %.
• Palisade Research, май и июль 2025 года. OpenAI o3 саботировал скрипт отключения в 79 из 100 запусков, а с явной инструкцией разрешить выключение в 7 из 100. В октябрьском прогоне с ужесточённой формулировкой у Grok 4 саботаж фиксировали примерно в 90 % запусков. Сама Palisade винит не «инстинкт выживания», а обучение с подкреплением, которое поощряло обход препятствий сильнее точного следования инструкциям.

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

Alibaba ROME: единственный эпизод вне ролевых сценариев

В декабре 2025 года, во время агентного RL-обучения модели Alibaba ROME, фаервол зафиксировал аномальный исходящий трафик. Модель сама подняла SSH-туннель наружу и использовала простаивающие GPU за пределами выделенной песочницы для майнинга криптовалюты. В поставленную задачу это не входило.

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

Где агенты действительно выходят из песочницы

В инструментах для программирования, и мистики там нет. В июле 2026 года Pillar Security нашла семь способов выйти из песочницы в Cursor, OpenAI Codex, Gemini CLI и Antigravity. Отдельные исследователи нашли слабые места в песочнице Claude Code для Linux. Все находки укладываются в знакомую схему: доверенный хост выполняет то, что написал агент.

Для пентестера это старый класс ошибок в новой упаковке. Агент пишет скрипт, конфиг, хук или команду сборки, а исполняет их процесс с правами разработчика вне песочницы. Модели не нужно «хотеть» сбежать, хватит косвенной инъекции в README зависимости.

Вторая половина проблемы в том, что выдали самой песочнице. Контейнер не равен виртуальной машине: ядро у него общее с хостом. Смонтированный домашний каталог, проброшенный SSH-агент, облачные токены в окружении и особенно Docker socket превращают изоляцию в декорацию.

Что проверить сегодня: чек-лист для ИБ, DevOps и руководителя

1. SLA на критические. Посчитайте фактическое время от публикации критической CVE до закрытия на интернет-доступных активах за последний квартал. Если оно больше суток, внедрите трек с критериями эскалации и компенсирующими мерами из первого раздела.
2. Приоритизация. Запретите ML-скорингу автоматически закрывать задачи. Сверяйте очередь с CISA KEV, наличием рабочего эксплойта, сетевой достижимостью и реальной версией компонента.
3. MCP и Cursor. Пройдите инвентаризацию по списку выше, обновите Cursor до сборки с исправлением CVE-2025-54136 по бюллетеню разработчика.
4. Окружение агента для программирования. Одноразовое, без доступа к продуктиву, Docker socket, SSH-агенту и личным облачным токенам. Короткоживущие учётные данные с минимальными правами, исходящие соединения только к нужным адресам.
5. Опасные действия. Платежи, возвраты, удаление данных и отправку внешних сообщений пропускайте через детерминированную проверку вне модели.
6. Журнал. Пишите имя инструмента, точные аргументы, источник обрабатываемого контента и результат авторизации. Без этого расследовать инцидент нечем.
7. Публичный чат-бот. Зафиксируйте, что бот вправе обещать: цены, возвраты, сроки, условия. Всё остальное отдавайте человеку или фиксированному ответу из базы.

Что решать руководителю

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

Второе: назначить владельца каждому чат-боту и агенту, который говорит от имени компании. Air Canada проиграла спор именно потому, что бот был частью её сайта.

Третье: инвентаризация ИИ-контура. Какие MCP-серверы подключены, кто их одобрил, какие данные уходят во внешние ML-сервисы. Для персональных данных это вопрос 152-ФЗ, а с 30 мая 2025 года утечки ПДн грозят оборотными штрафами.

Частые вопросы

Сколько дней проходит от публикации уязвимости до эксплуатации?

По данным, которые приводит автор цикла на Habr, в среднем около 5 дней, а каждую четвёртую уязвимость атакуют в день публикации. Mandiant M-Trends для 2025 года даёт среднее около минус 7 дней.

Что значит отрицательное время до эксплуатации?

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

Чем EPSS отличается от CVSS при приоритизации?

CVSS оценивает тяжесть последствий по шкале от 0 до 10. EPSS, модель сообщества FIRST, оценивает вероятность эксплуатации в ближайшие 30 дней числом от 0 до 1. Подтверждённую эксплуатацию показывает отдельный каталог CISA KEV.

Что такое Tool Poisoning и MCPoison?

Tool Poisoning, описанная Invariant Labs в апреле 2025 года, прячет вредоносную инструкцию в описании инструмента MCP, которое видит модель, но не видит пользователь. MCPoison (CVE-2025-54136, CVSS 8,8) позволяла подменить уже одобренную конфигурацию MCP в Cursor.

Несёт ли компания ответственность за ответы чат-бота?

Да. В феврале 2024 года канадский трибунал по мелким искам обязал Air Canada выплатить компенсацию за выдуманное ботом правило возврата и отверг довод, что бот отвечает за себя сам.

Если в компании уже работают coding-агенты, MCP-серверы или публичный чат-бот, SecurityLab.pro проверит их так, как это сделал бы атакующий: от косвенной инъекции до выхода на хост. Подробнее на странице тестирования безопасности ИИ-агентов.