Цифра, которая требует объяснения
В июне 2026 года компания Cobalt, предоставляющая услуги пентеста как сервиса, опубликовала отчёт с примечательным числом: доля организаций, готовых полностью полагаться на AI-powered penetration testing, упала с 29% до 9% всего за год. При этом 47% компаний теперь предпочитают гибридную модель — человек плюс автоматизация. Рынок не отказался от ИИ, он переосмыслил его роль.
Прежде чем делать выводы, стоит зафиксировать ограничение: эти данные — из отчёта одного вендора с очевидным коммерческим интересом в том, чтобы продавать именно гибридный подход. Выборка не репрезентирует весь рынок кибербезопасности. Тем не менее направление движения согласуется с тем, что практики наблюдают на рабочих местах — и именно поэтому цифры заслуживают разбора.
Почему охлаждение произошло именно сейчас
CISOs последние два года испытывали давление сверху: руководство и советы директоров требовали внедрять ИИ. Автономный пентест идеально вписывался в эту риторику — обещал масштабирование, скорость и снижение затрат. Многие организации запустили пилоты.
Год реальной эксплуатации обнажил расхождение между демонстрацией и рабочим процессом. Три проблемы оказались особенно болезненными.
Слепые пятна в критических уязвимостях. Семьдесят восемь процентов компаний зафиксировали, что автоматизированные системы пропустили значимые уязвимости. В пентесте это называется false negative — пропущенная уязвимость. Если инструмент молчит, это не значит, что всё чисто; это может означать, что он просто не добрался до нужного слоя атаки.
Лавина находок без контекста. Параллельно AI-системы генерируют огромный объём данных и срабатываний. Число публично раскрытых уязвимостей растёт на 46% быстрее, чем прогнозировалось год назад. Microsoft в рамках июньского Patch Tuesday 2026 года закрыла рекордные 206 уникальных CVE — во многом благодаря AI-обнаружению. Звучит как успех. Но каждую из этих находок кто-то должен проверить, подтвердить и расставить приоритеты.
Непредсказуемые затраты. AI-сервисы склонны к непредсказуемому потреблению вычислительных ресурсов. После того как другие бизнес-процессы неожиданно «разогнали» AI-бюджеты, безопасники стали осторожнее в финансовых оценках.
Почему поток находок превращается в проблему валидации
Вот ловушка, в которую легко попасть: больше автоматизации → больше находок → казалось бы, лучше защита. Но цепочка устроена иначе.
flowchart TD A[Больше автоматизации] --> B[Больше находок] B --> C[Рост объёма данных и шума] C --> D[Перегрузка экспертов валидацией] D --> E[Падение доверия к полной автономии] E --> F[Сдвиг к гибридной модели]
Аналитики FIRST сформулировали это прямо: «В эпоху, когда ИИ может находить значительно больше уязвимостей, чем люди, узкое место — уже не обнаружение, а человеческая способность верифицировать, координировать и патчить». Добавим к этому ещё один уровень: даже верификация — это полдела. Нужно ещё понять, что уязвимость значит в конкретном бизнес-контексте, насколько реалистична её эксплуатация и что исправлять в первую очередь.
HackerOne столкнулась с этим настолько остро, что была вынуждена приостановить программу Internet Bug Bounty — поток заявок, требующих валидации, превысил возможности обработки. Проблема false positive (ложные срабатывания) здесь не менее серьёзна, чем false negative: каждый ложный сигнал — это потраченное время эксперта, который мог бы разбирать настоящую угрозу.
Где ИИ реально помогает, а где начинает ломаться
Это не вопрос «хороший или плохой инструмент». Это вопрос соответствия задачи и инструмента. Разные этапы security-тестирования требуют разного уровня автономности.
| Этап пентеста | Что делает ИИ | Роль человека | Уровень доверия к автономии |
|---|---|---|---|
| Разведка (Recon) | Сбор данных об инфраструктуре, перечисление сервисов | Задаёт границы и цели | Высокий |
| Первичный поиск уязвимостей | Автоматическое сканирование, сопоставление с базами CVE | Проверка покрытия | Средний |
| Триаж и приоритизация | Ранжирование по CVSS и паттернам | Контекстная оценка реального риска | Низкий — нужен эксперт |
| Подтверждение эксплойта | Проверка воспроизводимости атаки | Полная ответственность за вывод | Очень низкий |
| Оценка бизнес-риска | Вспомогательный анализ | Финальное решение | Минимальный |
| Рекомендации по исправлению | Шаблонные советы | Адаптация к архитектуре | Зависит от контекста |
Паттерн очевиден: чем ближе к результату, который влияет на реальное решение — «закрыть порт», «остановить релиз», «уведомить регулятора» — тем меньше места для полной автономии.
«Находит больше» ≠ «лучше защищает»
Это разграничение принципиально. Инструмент, генерирующий сотни потенциальных уязвимостей за час, выглядит впечатляюще в демонстрации. Но если 60% из них — false positives, а критические уязвимости спрятаны в оставшихся 40% вперемешку с незначительными замечаниями, команда безопасности получает не ускорение, а новую работу: разбирать шум.
Дерек Раш из Bishop Fox описывает это точно: системы генерируют огромный объём данных, и только опытный специалист может придать контексту LLM правильную форму. «Нужен эксперт, чтобы решить, стоит ли разрабатывать находку дальше, и если да — как выглядит полная, подтверждённая цепочка атаки».
Это не недостаток конкретного продукта. Это структурное свойство текущего поколения инструментов: они хорошо масштабируют ширину покрытия, но глубина и суждение остаются за человеком.
Как отличить рабочую систему от рекламного обещания
Когда вендор говорит об «автономном пентесте», полезно задать несколько конкретных вопросов.
Что именно автономно? Разведка и сканирование — рутина, которую давно автоматизируют. Подтверждение эксплойта и оценка риска — совсем другая история. Если граница не обозначена, скорее всего, её нет.
Как измеряется качество? Показатель «найдено X уязвимостей» ничего не говорит без данных о false positive rate и о том, сколько критических находок было пропущено (false negative). Спросите про оба числа.
Кто несёт ответственность за вывод? В настоящем пентесте есть конкретный человек, который подписывается под финальным отчётом. Если система «автономна», но ответственность размыта — это красный флаг.
Какова реальная стоимость валидации? Если инструмент находит 500 проблем в день, а команда может разбирать 50 — экономии не получится. Нужно считать не только лицензию, но и нагрузку на экспертов.
Гибридная модель — не компромисс, а архитектура
Формулировка «человек в петле» (human-in-the-loop) иногда воспринимается как временное решение до момента, когда ИИ «дозреет». Это неверная интерпретация. В кибербезопасности человек в петле — это не костыль, а часть архитектуры ответственности.
Чем больше автоматизации в разработке, тем быстрее растёт поверхность атаки. AI-ассистированный код создаётся быстрее и в больших объёмах — а значит, больше точек входа требуют проверки. Автоматизация порождает автоматизацию: это не плохо, но требует осознанного масштабирования контроля качества, а не его замены.
Сандип Сингх из HackerOne описывает дуальную модель точно: «Агент делает непрерывную работу в ширину — первый проход; человек делает работу в глубину и с суждением — периодически». Это не временный компромисс. Это рациональное разделение труда, при котором каждая сторона делает то, в чём действительно сильна.
Что в итоге
Падение с 29% до 9% за один год — это не приговор технологии. Это рынок, который прошёл через типичный цикл: завышенные ожидания, реальные эксперименты, коррекция. Те, кто год назад верил в полную замену пентестера, теперь точнее понимают, за что именно платят.
ИИ в security-тестировании хорошо делает одно: масштабирует первый проход — разведку, перечисление, сопоставление с известными паттернами. Это реальная ценность, особенно при росте объёмов кода и частоты релизов. Но качество защиты по-прежнему определяется тем, что происходит после — верификацией, приоритизацией и принятием решения. А это пока остаётся за человеком — не потому что ИИ «недостаточно умный», а потому что именно здесь сосредоточена ответственность за последствия.
Выводы статьи основаны прежде всего на отчёте одного вендора; это полезный сигнал, но не окончательный срез всего рынка. Показатели автономного пентеста сильно зависят от сценария и зрелости процесса. Статья описывает технологические ограничения и не является рекомендацией по выбору конкретного поставщика услуг безопасности.
