Окно эксплуатации Zero-Day сократилось до 24 часов

Каждый, кто хоть раз сидел на утреннем колле по триажу в понедельник, знает негласное правило: у вас есть примерно квартал, чтобы закрыть неудобные уязвимости до того, как кто-то их вооружит. Это правило только что похоронили. Новый метрический проект под названием Zero-Day Clock утверждает: среднее время от публичного раскрытия до эксплуатации в реальных условиях сократилось с почти года в 2021-м до чуть более двадцати четырёх часов в 2026-м. Окна патчей, рассчитанные на человека-атакующего, сносит инструментарий, который не спит.

Что произошло

Zero-Day Clock — это измерительный проект, запущенный Сергеем Эппом из Sysdig при поддержке большинства крупных технологических и кибербезопасных вендоров. Его единственная задача — дать конкретные числа тому, на что отрасль намекала последние два года: AI-ассистированная генерация эксплоитов сжимает окно реакции защитника практически до нуля.

Как сообщал Tom's Hardware, средний интервал между обнаружением уязвимости и её эксплуатацией упал с примерно года в 2021-м до чуть более суток в этом году. Прогноз ZDC ещё более мрачный: один час к 2027-му, и в конечном счёте — одна минута.

Изменился и состав угроз. Пять лет назад 31% эксплоитов были zero-day, то есть атакующие уже использовали их до раскрытия. Сегодня эта цифра составляет 73,2%. Обратная сторона — то, что в данных называется неэксплуатируемыми уязвимостями: баги, которые сообщаются и тихо умирают, так никем и не вооружённые. В 2021-м эта категория составляла около 60–70%, а сейчас опустилась до 25% на момент раскрытия. Если смотреть на горизонт шести недель, ноль уязвимостей остаётся неиспользованными — против примерно 24% для прошлогодней когорты.

Исследователи честно говорят о границах своих данных: «Мы отслеживаем только публично видимые эксплоиты. Приватные или государственные эксплоиты могут появляться раньше». Поэтому воспринимайте эти цифры как нижнюю границу, а не потолок. Реальная кривая круче.

Техническая анатомия

Почему часы идут так быстро? Сходятся две структурные причины.

Первая: сырая основа современного программного обеспечения по-прежнему небезопасна. ZDC связывает 70% уязвимостей с ошибками безопасности памяти. Это всё та же семья проблем — переполнение буфера, use-after-free — которую мы не можем исправить с 1990-х. AI-инструментарий не изобрёл эти классы ошибок. Он просто промышленно автоматизировал процесс их поиска. Модель, способная прочитать diff, найти небезопасную арифметику указателей и выдать работающий proof-of-concept, превращает то, что раньше занимало неделю у старшего реверс-инженера, в запуск скрипта.

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

Рекомендуемые ZDC технические контрмеры напрямую отвечают на оба этих давления. На уровне основы: переходите с C и C++ на Rust или другой язык с безопасной работой с памятью, поставляйте продукты со всеми включёнными по умолчанию функциями безопасности, внедряйте архитектуру zero-trust и проектируйте системы одноразовыми, чтобы скомпрометированный хост можно было уничтожить и пересобрать за минуты. На уровне инструментария: делайте AI-защитные инструменты open-source, чтобы защитники имели паритет с атакующими, у которых уже есть доступ к тем же моделям.

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

Кто пострадает

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

iGaming-платформы особенно уязвимы. Live-беттинг-инфраструктура работает на пределе, платёжные интеграции разрослись, а регуляторные ограничения нередко тормозят экстренное применение патчей — каждое изменение требует подтверждения соответствия сразу в нескольких юрисдикциях. 24-часовое окно эксплуатации против стека, которому требуется 72 часа для проведения регулируемого конфигурационного изменения, — это структурное несоответствие. Производственные инциденты в этом сегменте, которые я наблюдал, как правило, восходят к стороннему SDK или интеграции с фидом коэффициентов, которую никто в основной команде не поддерживает. Теперь эти вендоры должны работать в том же темпе.

Fintech находится в похожем затруднении. PCI-периметр, театр change advisory board и партнёры по корневому банкингу, которые деплоят по собственному ледниковому расписанию, означают, что реальная задержка патчинга определяется самым слабым звеном. Неудобный вывод: если ваш KYC-вендор патчится ежемесячно, ваше реальное окно экспозиции — ежемесячное, независимо от скорости вашего собственного пайплайна.

Криптовалютные и DeFi-команды сталкиваются с противоположной проблемой. Они патчатся быстро, но иммутабельные контракты вообще не поддаются патчингу. Когда окно эксплуатации сокращается до часа, вся защитная позиция должна переориентироваться на circuit breakers, приостанавливаемые контракты и агрессивный мониторинг мемпула. Код, который нельзя изменить, нуждается в изменяемой инфраструктуре вокруг себя.

Вендоры корпоративной инфраструктуры сталкиваются с вопросом ответственности напрямую. Высказывание Брюса Шнайера в отчёте ZDC прямолинейно: «Ни одна отрасль за последние 150 лет не улучшила безопасность без принуждения со стороны государства». Он также указывает, что небезопасные продукты, первыми выходящие на рынок, каждый раз обыгрывают более качественно построенных конкурентов. Если законодательство об ответственности будет принято, экономические стимулы наконец перевернутся. Если нет — гонка ко дну продолжится.

План действий для команд безопасности

Конкретные действия на ближайшие две недели, упорядоченные по значимости:

Проведите аудит реальной задержки патчинга, а не декларируемой. Возьмите последние десять CVE, затронувших ваш стек. Измерьте реальное время от публикации CVE до деплоя в продакшн. Если медиана превышает 48 часов, числа ZDC говорят, что вы уже проигрываете. Определите узкое место: задержка вендора, процесс CAB, регрессионное тестирование или окна развёртывания.

Проведите инвентаризацию зависимостей от C и C++. То, что 70% уязвимостей — ошибки безопасности памяти, является вводной для планирования, а не занимательным фактом. Определите, какие сервисы в вашем критическом пути всё ещё используют небезопасные языки. Переписывать их в этом квартале вы не будете, но вы должны знать, какие из них являются приоритетными кандидатами на миграцию в Rust в течение следующего года.

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

Настройте алертинг на основе KEV. Подпишитесь на фиды MITRE CVE и обновления CISA KEV напрямую в вашу дежурную ротацию — не просто в Slack-канал, который никто не читает в 2 ночи. Когда окно эксплуатации составляет сутки, асинхронного уведомления недостаточно.

Давите на вендоров письменно. Добавляйте пункты о SLA патчинга в договоры при продлении. Обязательство закрыть критическую уязвимость менее чем за 72 часа должно быть базовым требованием. Если вендор не может на это согласиться, он — потенциальный источник переноса ответственности на вас.

Ключевые выводы

• Среднее время от раскрытия до эксплуатации упало с ~1 года (2021) до ~1 дня (2026), с прогнозом 1 час в 2027-м. 90-дневное окно раскрытия — пережиток прошлого.
• Доля zero-day среди эксплоитов выросла с 31% до 73,2% за пять лет. Защитники прибывают после атакующего, а не до него.
• 70% уязвимостей — ошибки безопасности памяти. Миграция критических сервисов на Rust — стратегический приоритет, а не опциональное улучшение.
• ZDC считает только публичные эксплоиты. Приватная и государственная активность по определению за пределами графика, поэтому реальная кривая хуже.
• Одноразовая инфраструктура, SLA патчинга у вендоров и пейджинг на основе KEV дают больше, чем любой одиночный защитный инструмент, для сокращения разрыва.