Большинство программ исправления уязвимостей закрывают тикеты, но не проверяют исчезновение риска

Команды ИБ сегодня видят свои инфраструктуры лучше, чем когда-либо, но часто всё ещё не знают главного — сработало ли исправление по факту. Уязвимость закрыли, патч поставили, правило переписали, настройку поменяли, тикет перевели в статус «решено». Атакующий путь может остаться открытым, а риск просто исчезает из отчёта без реального исчезновения из системы.

Новая реальность делает проблему острее. Отчёт Mandiant M-Trends 2026 оценивает среднее время до эксплуатации уязвимости как минус 7 дней. Атаки начинаются ещё до более полного осознания проблемы организацией. В отчёте Verizon 2025 DBIR медианное время исправления уязвимостей на пограничных устройствах составляет 32 дня.

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

Главный вопрос звучит проще и жёстче. Как компания понимает, что исправление реально убрало риск?

Обсуждение ИИ в кибербезопасности часто сводится к скорости. Инструменты вроде Mythos показывают возможности продвинутых моделей в построении цепочек эксплуатации. Раньше временное решение, частичный патч или настройка «на всякий случай» жили месяцами. Сейчас злоумышленник с ИИ быстро проверяет места с дырявой защитой.

Проблема не в отсутствии исправлений у компаний. Слишком часто исправление считается завершённым по формальному признаку:

• вендор выпустил патч и опубликовал бюллетень;
• администратор применил настройку на устройстве;
• DevOps внёс изменение в конфигурацию;
• инженер закрыл задачу в трекере;
• тикет ушёл в отчёт как remediated.

На бумаге всё красиво. На практике патч мог быть обходным, примениться не на всех системах или закрыть только один путь атаки.

Не всякий риск решается патчем. Слабое правило межсетевого экрана может оставлять доступ туда, где его быть не должно. То же касается привилегий, политик EDR, настроек SIEM, сетевых ACL, IAM-ролей, cloud security group и параметров доступа к хранилищам.

Самая болезненная зона лежит между обнаружением и исправлением. Команда ИБ находит риск, но не владеет системой для его закрытия. Исправление уходит к разным командам:

• инфраструктурным специалистам;
• разработчикам конкретных приложений;
• DevOps-инженерам и SRE;
• владельцам бизнес-сервисов;
• внешним подрядчикам и интеграторам.

У каждого свои сроки, окна изменений, спринты и приоритеты. Даже точная находка может неделями лежать между командами.

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

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

Скорость прохождения тикетов не равна снижению риска. За минуты можно назначить владельца, напомнить о сроке и закрыть задачу в SLA. Риск при этом останется. Исправление могло охватить 3 системы из 4, а временное правило могло сломаться после следующего изменения конфигурации.

Многие компании измеряют свою ИБ-программу количеством закрытых тикетов, а не реальным исчезновением рисков из инфраструктуры.

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

Повторная валидация решает несколько задач сразу:

• показывает реальное состояние после исправления;
• выявляет частичные и обходные патчи;
• проверяет устойчивость workaround’а к новым изменениям;
• подтверждает закрытие всех путей атаки;
• меняет культуру измерения работы ИБ.

Особенно это значимо для пограничных устройств, облачных ресурсов и внешнего периметра. VPN-шлюзы, почтовые сервисы, firewalls, web gateway, балансировщики и API становятся первыми целями. Без повторной проверки на узлах организация делают ставку на удачу.

Старый процесс строился вокруг логики «найти — назначить — исправить — закрыть». Новый процесс должен выглядеть иначе. После исправления проводится повторная проверка с подтверждением исчезновения базового риска.

ИИ-ускорение атак делает ложную уверенность дорогой. Модели быстро подбирают варианты эксплуатации и обходят слабые workaround’ы. Формальное закрытие задач превращается в слабое место самой программы защиты.

Многие метрики ИБ заточены под объём работы, а не под снижение риска. Подобные показатели полезны, но не отвечают на главный вопрос о реально исчезнувших из инфраструктуры рисках.

В облачных средах повторная валидация должна учитывать скорость изменений. Конфигурация сегодня закрыта, завтра новый deployment снова открыл доступ. IAM-роль поправили вручную, потом Terraform вернул старое состояние. Без автоматической или регулярной проверки откаты конфигурации трудно увидеть вовремя.

В классической инфраструктуре ситуация не легче. Возможны типичные провалы исправлений:

• патч применился, но агент не перезапустился
• правило firewall добавили без проверки порядка правил
• EDR-политика назначена группе, но устройства её не получили
• SIEM начал собирать события без нужного источника
• сегментацию сети применили частично

Программы исправления должны соединять workflow и техническую проверку. Подтверждённая находка превращается в задачу, задача уходит нужной команде, исправление контролируется, а затем система проверяет недостижимость атакующего результата.

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

Время до закрытия задачи остаётся значимым, но рядом должна появиться метрика времени до подтверждённого устранения риска. Подобный показатель честнее. Он учитывает не только действие команды, но и реальное состояние инфраструктуры после действия.

Отдельно стоит смотреть на исключения и временные меры. При невозможности патча и постановке workaround повторная валидация ещё нужнее. Временные ограничения, компенсационные меры или ручные фильтры должны проверяться после внедрения и после значимых изменений среды.

Эксперты редакции CISOCLUB отмечают, что проблема remediation сегодня не сводится только к скорости установки патчей. По мнению редакции, главная слабость многих программ кроется в отсутствии подтверждения реального устранения риска. В эпоху ИИ-ускоренных атак закрытый тикет нельзя считать финалом. Финалом должна быть повторная проверка с подтверждением закрытого атакующего пути и исчезнувшей базовой проблемы. Без подобной дисциплины красивые проценты закрытых уязвимостей превращаются в декорацию, а атакующий получает фору в днях, неделях и месяцах работы внутри слабо проверенной инфраструктуры.