Среднее время прорыва eCrime в 2025 году сократилось до 29 минут, тогда как даже строгие корпоративные процессы часто дают на устранение критической уязвимости недели, а иногда и 30 дней. На этом фоне окно экспозиции перестает быть узким термином из словаря ИБ и становится главным показателем того, успеет ли компания закрыть дыру раньше, чем по ней кто-то зайдет.
Именно к такому выводу подводит свежая колонка о последствиях релиза Mythos от Anthropic 7 апреля 2026 года, о чем сообщает The Hacker News. После анонса рынок обсуждал в основном привычные вещи: сколько новых CVE добавит ИИ в и без того переполненный конвейер, как быстро команды захлебнутся в приоритизации и через сколько злоумышленники начнут масштабно использовать найденные проблемы. Но автор материала предлагает сдвинуть оптику: важнее не сам поток находок, а длина промежутка между моментом, когда уязвимость уже можно эксплуатировать, и моментом, когда компания действительно ее закрыла. Это и есть окно экспозиции, и именно оно все чаще определяет реальный риск для бизнеса.
Логика здесь неприятно простая. Если атакующий может закрепиться в инфраструктуре за 29 минут, а внутренний процесс исправления уязвимости движется в темпе согласований, change window и пересылки тикетов между командами, то формально зрелая программа защиты может проигрывать еще до первого созвона. ИИ-инструменты вроде Mythos не создали эту проблему с нуля, но сделали ее заметнее и, вероятно, болезненнее. До них модель управления уязвимостями уже трещала по швам: по данным из материала, в 2025 году было раскрыто 48 185 CVE, что на 22% больше, чем в 2024-м, а в 2026 году ожидается уже 66 000 новых записей. Для большинства крупных организаций это означает не рост нагрузки на 10-20%, а окончательный переход в режим бесконечного хвоста, где очередь на исправление больше не сокращается.
На бумаге индустрия давно знает, как должна выглядеть зрелая работа с риском. В статье напоминают про CTEM-подход Gartner, где цепочка состоит из пяти этапов: scoping, discovery, prioritization, validation и mobilization. Первые три стадии все активнее автоматизируются и работают почти на машинной скорости. Проверка того, что защита действительно блокирует реальную атаку, тоже стала быстрее благодаря платформам для тестирования путей атаки. А вот mobilization, то есть реальное доведение проблемы до исправления, по-прежнему упирается не в технологии, а в оргструктуру. И здесь обычно начинается знакомый корпоративный театр: безопасность что-то нашла, эксплуатация занята релизом, владельца актива надо уточнить, у продакшн-системы окно изменений только через две недели, а legacy-сегмент лучше вообще не трогать, потому что он работает и слава богу.
Автор статьи называет это мягким подбрюшьем большинства программ CTEM, и спорить трудно. Разрыв между фразами «мы знаем, что это опасно» и «мы это устранили» часто измеряется не часами, а месяцами. В тексте приводится еще одна показательная цифра: high- и critical-уязвимости в приложениях в среднем исправляют за 55 дней, а почти половина корпоративных уязвимостей остается без патча даже через год. Если вспомнить про 29-минутное breakout time, становится понятно, почему красивые отчеты с квартальным уровнем patch coverage в 90% выглядят не как победа, а как бухгалтерия после инцидента. Для атакующего неважно, что вы закрыли девять проблем из десяти к концу квартала. Ему достаточно одной, которая вела к важному активу и оставалась открытой в нужный день.
Отдельно интересно, что даже регуляторы начинают смещать акцент. В статье упоминается директива CISA BOD 26-04, которая переводит федеральные агентства США от механического CVSS-first-подхода к учету эксплуатируемости и контекста актива. По сути, это движение в ту же сторону, куда давно толкает CTEM: исправлять не все подряд по тяжести на бумаге, а то, что реально может быть использовано и затрагивает значимые системы. Но и здесь есть неприятная оговорка. Такой подход помогает решить, что чинить сначала, но не отвечает на другой вопрос: как именно заставить организацию чинить это достаточно быстро. Если команда безопасности уже умеет отличать шум от риска, а процесс ремедиации все равно буксует, окно экспозиции остается открытым.
Для разработчиков, платформенных команд и ИТ-руководителей из этого следует довольно приземленный вывод. Разделение на «реактивную» и «проактивную» безопасность устаревает быстрее, чем хотелось бы. SOC давно живет в метриках скорости: dwell time, MTTD, MTTR, containment speed. А команды vulnerability management, cloud security и network security традиционно отчитывались другими числами: доля закрытых патчей, процент покрытия, сроки исправления misconfiguration по SLA. Проблема в том, что ИИ-ускорение поиска уязвимостей ставит всех на один секундомер. Если путь от disclosure до weaponization сжимается до часов, а проникновение в среду измеряется минутами, проактивные команды больше не могут жить по календарю релизного комитета. Им тоже нужны speed-based metrics, иначе они просто будут считать аккуратно оформленное отставание.
Еще одна важная мысль из материала касается не только скорости, но и масштаба последствий. Полностью закрыть окно экспозиции, похоже, не получится ни у кого. Поэтому вопрос меняется: не «можем ли мы устранить все», а «насколько далеко злоумышленник пройдет, пока щель еще открыта». Здесь на первый план выходит blast radius, то есть множество критичных активов, до которых можно добраться через конкретную уязвимость или конфигурационную ошибку. Автор ссылается на Verizon DBIR 2026 и делает ставку на анализ путей атаки: не каждая экспозиция ведет к действительно опасному сценарию, часть упирается в тупики. Если это видно заранее, backlog перестает быть бесконечной свалкой и превращается в конечный набор маршрутов, которые нужно разорвать в первую очередь. Для бизнеса это намного полезнее, чем еще один дашборд с количеством открытых тикетов.
Для русскоязычного рынка у этого сюжета есть понятное прикладное измерение. Крупные компании в регионе так же зависят от длинных цепочек согласований, гетерогенной инфраструктуры, унаследованных систем и нехватки людей, которые могут быстро брать ownership за исправление. Поэтому окно экспозиции здесь не абстракция из западной колонки, а довольно точное описание того, почему многие ИБ-программы выглядят зрелыми до первого реально быстрого противника. На этом фоне главный вопрос для отрасли звучит уже не как «сколько уязвимостей найдет ИИ в следующем квартале», а как «какую часть критичных путей компания умеет закрывать быстрее, чем атакующий успеет ими воспользоваться». Именно на этом разрыве в скорости теперь и будет проверяться реальная, а не отчетная зрелость безопасности.