Окно между публикацией новой дыры и ее массовой эксплуатацией в интернете теперь измеряется часами, а не днями. Для команд, у которых управление уязвимостями завязано на тестовые стенды, change-окна и согласования с бизнесом, это неприятная новость: атакующие уже работают в темпе, который обычный цикл патчинга не догоняет.
Об этом пишет The Hacker News, разбирая, как ИИ меняет привычную механику атаки и защиты. Главный тезис простой: индустрия много лет повторяла мантру «патчите быстрее», но в 2026 году этого уже недостаточно. Патч по-прежнему нужен, но сам по себе он перестал быть ответом на проблему, когда эксплуатация уязвимости начинается через считаные часы после раскрытия.
Повод для разговора дал майский апдейт Project Glasswing от Anthropic. Компания заявила, что вместе примерно с 50 партнерами использовала Claude Mythos Preview и за один месяц выявила более 10 тысяч уязвимостей высокой и критической степени опасности в системно значимом ПО. Сам по себе этот результат еще не означает катастрофу, но хорошо показывает масштаб сдвига: поиск, воспроизведение и проверка уязвимостей автоматизируются. И если защитники получили ускоритель, то у нападающих он тоже уже в руках.
На практике это означает неприятный разрыв между скоростью атаки и скоростью исправления. В материале приводятся данные Verizon 2026 DBIR: медианное время на закрытие критической уязвимости выросло за год с 32 до 43 дней. То есть атакующие живут в горизонте нескольких часов, а защитники, особенно в крупном энтерпрайзе, все еще живут неделями. И дело не в лени команд безопасности. Патч в промышленной среде редко ставится кнопкой: нужно проверить совместимость, не уронить прод, уложиться в регламент изменений, пройти внутренние approvals и не сломать зависимые сервисы.
Именно поэтому старая рекомендация «просто ускорьте патчинг» звучит все более оторванно от реальности. Авторы материала довольно точно формулируют проблему: для многих компаний это совет уровня «просто станьте выше ростом». Полезно на словах, но не очень применимо на практике. Отдельное давление добавляют регуляторы. В статье упоминается недавнее руководство индийского CERT-In, которое для некоторых критических уязвимостей фактически подталкивает компании к исправлению в пределах суток. Намерение понятно, но инженерная реальность от этого не меняется: часть уязвимостей начнут атаковать раньше, чем организация успеет безопасно выкатить фикс.
Отсюда и сдвиг в самом подходе к управлению уязвимостями. Если раньше схема была довольно прямолинейной, найти CVE, оценить severity, отправить в работу и дождаться патча, то теперь нужен более быстрый и агрессивный цикл. Сначала предугадывать, какие уязвимости с высокой вероятностью пойдут «в поле». Потом быстро валидировать, задевает ли проблема конкретную инфраструктуру: используется ли уязвимый компонент, доступен ли он извне, подтверждается ли эксплуатация именно в вашей среде. И только после этого решать, что надо немедленно изолировать, что можно прикрыть временными мерами, а что действительно может дождаться штатного окна обновлений.
Это важный нюанс для разработчиков, платформенных команд и ИТ-руководителей. Severity давно перестал быть единственным критерием. Критическая уязвимость в редко используемом внутреннем сервисе и менее громкая, но воспроизводимая дыра в интернет-доступном компоненте создают разный риск для бизнеса. В условиях, когда ИИ ускоряет эксплуатацию, фильтрация в первые часы после disclosure становится не nice to have, а базовой функцией. Командам нужен не просто список CVE, а ответ на несколько приземленных вопросов: где это стоит, кто владелец системы, можно ли достучаться до компонента извне, есть ли подтвержденный путь эксплуатации, и что мы можем перекрыть до выхода патча.
Следующий уровень зрелости, о котором говорит материал, это временные меры защиты как полноценная часть процесса, а не аварийная самодеятельность. Если уязвимость подтверждена, но патч нельзя сразу поставить без риска для продакшена, нужно покупать время. Речь о вполне земных вещах: ограничение доступа, отключение уязвимой функции, правила для WAF или API-шлюза, обновление IDS/IPS, сегментация, изоляция, изменение конфигурации, отдельный мониторинг подозрительных паттернов. Причем эффективность такой защиты зависит от того, понимает ли команда реальный путь эксплуатации. Универсальная заглушка по описанию CVE почти всегда слабее, чем мера, собранная из конкретного payload, условий атаки и наблюдаемого вредоносного поведения.
В конце The Hacker News, ожидаемо для спонсорского материала, подводит читателя к платформе watchTowr как к инструменту, который объединяет threat intelligence, управление внешней поверхностью атаки и автоматизированные меры снижения риска. Но даже если вынести маркетинг за скобки, базовый вывод выглядит трезво: управление уязвимостями больше не может строиться только вокруг скорости установки патчей. Следующий вопрос для отрасли уже не в том, как еще сильнее ускорить традиционный процесс, а в том, сколько компаний успеют перестроить его вокруг быстрой валидации эксплуатируемости и временного сдерживания атак, пока ИИ не превратил недельный цикл защиты в исторический артефакт.