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

Тридцать лет индустрия кибербезопасности жила по одному правилу: между выходом патча и появлением рабочего эксплойта проходят недели, а то и месяцы. Этого времени хватало, чтобы обновить системы и закрыть дыру раньше, чем ею воспользуются. Атака через n-day — то есть через уязвимость, для которой патч уже выпущен, но не везде установлен, — строилась на трудоёмкой ручной работе: исследователь брал diff между защищённой и незащищённой версией софта и вручную превращал разницу в рабочий код. На это уходили недели экспертного труда. Именно этот временной зазор десятилетиями считался страховкой для защитников.
Эта страховка перестала работать. Исследование Anthropic с использованием модели Claude Mythos Preview показало, что процесс, который раньше требовал недель, теперь занимает часы. Команда дала модели только публичный diff и два билда Firefox — ничего больше. Из 18 патчей модель автономно собрала 8 рабочих эксплойтов с исполнением произвольного кода. Первый готовый эксплойт появился меньше чем через час после того, как Mozilla выпустила патч. При этом официальный релиз Firefox с этим исправлением должен был выйти только через 18 дней — почти три недели форы, которой у защитников на самом деле не было.
С Windows-ядром задача была сложнее: никакого исходного кода, только урезанные бинарники и вывод декомпилятора. Модели дали 21 уязвимость (CVE) в ядре Windows. Для 18 из 21 она построила proof-of-concept — рабочее доказательство сбоя. Самый быстрый PoC появился за 31 минуту. Восемь цепочек довели атаку до полного доступа уровня SYSTEM, и обошлось это примерно в 2000 долларов за цепочку — сумма, которую может себе позволить практически любая группировка. Отдельно стоит отметить один случай: одна из SYSTEM-цепочек была построена для бага, которому Microsoft присвоила рейтинг «эксплуатация маловероятна» — рейтинг, изначально придуманный для калибровки работы человеческих исследователей. Как отмечают в отчёте, эта калибровка больше не работает. И важная деталь: даже публичные версии Claude со включёнными защитными механизмами смогли собрать часть эксплойтов — то есть проблема не ограничена одной закрытой лабораторной моделью.
В самой Anthropic это сформулировали коротко: «N-hour ближе к реальности, в которой мы теперь работаем». Исследователи придумали для этого явления термин «vulnpocalypse» — точку, после которой модель успевает вооружить раскрытую уязвимость быстрее, чем защитники успевают развернуть исправление. В этом и заключается ирония всей системы устранения уязвимостей: сам патч становится картой для атакующего. Выпуская исправление, компания одновременно публикует подробное описание того, что именно было сломано, — и вооружает этим описанием любого, кто ещё не обновился.
Отраслевая статистика подтверждает картину. По данным Verizon 2026 Data Breach Investigations Report, медианное время устранения уже известной, активно эксплуатируемой уязвимости составляет 43 дня — против 32 дней годом ранее, то есть разрыв не сокращается, а растёт. Полностью закрывается лишь 26% таких уязвимостей вообще. Даже лучшие команды закрывают в первую неделю только 30-40% известных эксплуатируемых дыр. А по данным Zero Day Clock, среднее время до появления эксплойта в 2026 году упало до менее чем 24 часов — против примерно 53 дней в 2024-м. При этом каждый день появляется около 135 новых CVE, и этот поток растёт на 40% год к году. Ни одна команда безопасности физически не успевает разобрать такой объём.
Отсюда вытекает смена самого вопроса, который задают себе службы безопасности. Старый вопрос — «что у нас уязвимо?» — больше не работает: когда в очереди из тысяч уязвимостей у половины оценка критичности 9,8 балла, приоритизация теряет смысл, потому что критично всё и одновременно ничего. Новый вопрос звучит иначе: какие конкретно уязвимости атакующий реально может использовать именно в нашей инфраструктуре, остановят ли эту попытку наши текущие защитные меры и можем ли мы это доказать. Ключевая мысль формулируется так: проверка эксплуатируемости не ускоряет патчинг — она делает саму скорость патчинга менее важной фактором.
Проверить реальную эксплуатируемость можно тремя способами, и они дополняют друг друга, а не заменяют.

[]Первый — запустить настоящий эксплойт в безопасной среде. Это самое сильное доказательство из возможных, именно это делает автономное пентестирование. Но у метода есть жёсткие границы: его нельзя применять на бизнес-критичных системах, в закрытых сегментах сети или на изолированных от интернета участках — то есть как раз там, где риски выше всего. Он также бесполезен, если публичного или безопасного эксплойта для конкретной CVE ещё не существует. В итоге таким способом безопасно проверяется лишь около 10-15% типичной инфраструктуры.
[]Второй — проверка против реальных средств защиты, для оставшихся 85-90% активов. Вместо запуска живого эксплойта воспроизводятся конкретные техники и поведение атакующего (TTP) на действующем стеке защиты, чтобы увидеть, что реально сработает, а что нет. Здесь уместна аналогия с испытанием уникальной пилотируемой ракеты: каждый узел проверяется на земле в условиях, максимально приближенных к боевым, а не в реальном полёте с риском для экипажа. CVE разбирается на цепочку техник, и каждое звено цепочки проверяется по отдельности против политик EDR, сегментации сети, allow-листов, правил межсетевого экрана. Если хотя бы одно обязательное звено обрывается — уязвимость доказанно не эксплуатируема в данной среде, и это подтверждено фактами, даже если актив недоступен для тестирования, а эксплойт ещё не существует.
[]Третий — непрерывная проверка того, держатся ли защитные меры со временем. Против живого стека защиты и обнаружения регулярно прогоняются самые свежие техники атакующих. Это позволяет увидеть, что действительно блокируется, что незаметно проскальзывает и где защита успела «сползти» с изначальных настроек — раньше, чем это обнаружит реальный злоумышленник.

Вместе эти три метода образуют один непрерывный цикл: проверить — принять решение — исправить — проверить снова. Это соответствует концепции Gartner под названием «Adversarial Exposure Validation». Практический результат такого подхода — критическая находка превращается не в догадку по оценке критичности, а в обоснованное решение из четырёх вариантов: патчить, снижать риск другими мерами, наблюдать или сознательно принять риск.
На этом принципе построена платформа Picus Security. Picus Autonomous Penetration Testing запускает реальные цепочки эксплойтов там, где активы доступны и безопасны для тестирования — это даёт самое надёжное доказательство. Picus Exposure Validation закрывает изолированные, бизнес-критичные системы и уязвимости без готового эксплойта — через TTP-цепочки без реального «подрыва», причём ответ можно получить уже в день раскрытия уязвимости. Picus Breach and Attack Simulation непрерывно испытывает действующий стек защиты новейшими техниками атакующих, а если какая-то защита не срабатывает — сразу выдаёт точную сигнатуру или правило, которое закроет пробел, и заново проверяет исправление.
Все три компонента работают на общей технологии Picus Swarm — команде ИИ-агентов, которая ведёт весь процесс на машинной скорости, но в рамках заданных пользователем ограничений и с прослеживаемой цепочкой действий, без непрозрачных баллов и выдуманных путей атаки. Вопрос, который сегодня задают на уровне совета директоров, изменился: раньше спрашивали «мы пропатчены?», теперь спрашивают «мы защищены прямо сейчас — и можете ли вы это доказать?».