AI в пентесте: почему 9% доверия — это нормально

Cobalt в 2025 году зафиксировал обвал: доля компаний, полагающихся исключительно на автоматическое AI-сканирование при тестировании безопасности, рухнула на 20 процентных пунктов - по данным Infosecurity Magazine, доверие схлопнулось до однозначных цифр. За полтора года выстраивания ML-пайплайна триажа находок в команде из семи пентестеров вижу ту же картину: ни один AI-сканер не выдаёт результат, который можно отправить заказчику без ручной верификации. Ни один. Но прежде чем списывать технологию - стоит разобрать, что конкретно стоит за цифрами и как выстроить автоматизацию пентеста, которая реально экономит часы, а не создаёт иллюзию покрытия.

Доверие к AI-сканерам уязвимостей: что стоит за падением​

Cobalt зафиксировал не провал отдельного вендора - сместилась парадигма.

Вендоры обещали точность обнаружения уязвимостей на уровне пентестера при скорости автоматического сканера. На практике точность AI сканеров уязвимостей упёрлась в ту же базовую проблему DAST/SAST: инструмент работает с паттернами и не учитывает контекст конкретной среды - сетевую топологию, компенсирующие контроли, бизнес-логику приложения. Красивая обёртка, внутри - тот же движок.

Когда организация полагается только на автоматизированный поиск уязвимостей и пропускает business logic flaw, ведущий к утечке, доверие обнуляется одним инцидентом. Ситуацию усугубляет обратная проблема: AI-агенты на базе LLM сами уязвимы к атакам. Исследователи из George Mason University (фреймворк Mantis) показали красивый трюк: защитник выставляет decoy-FTP с anonymous-входом, прячет в выводе сервера prompt injection через ANSI-escape-последовательности - невидимые в терминале, но попадающие в контекстное окно агента. Агент послушно исполняет встроенную инструкцию, reverse shell открывается на атакующей машине. Эффективность - свыше 95%. Живой пентестер обойдёт подозрительно открытый FTP из чистого скепсиса (слишком хорошо, чтобы быть правдой). Агент не различает данные и инструкции в контексте - и это архитектурное свойство, а не баг конкретного фреймворка.

Исследование SANS Institute (2025) подтвердило: у организаций с высоким уровнем ложных срабатываний сканеров MTTR реальных уязвимостей на 40% дольше. В крупных средах - свыше 1000 часов на разгребание.

Проблема не в бесполезности AI-инструментов для пентестеров. Проблема - в позиционировании их как замены, а не ассистента.

False positive сканер: 30–60% шума в каждом отчёте​

По данным нескольких независимых обзоров (ThreatExploit, Squr.ai), уровень ложных срабатываний автоматизированных сканеров стабильно держится в диапазоне 30–60%. Каждый второй алерт - мусор.

Откуда берётся шум:

RHEL, Ubuntu LTS регулярно бэкпортируют security-фиксы без обновления номера версии. Сканер видит OpenSSL 1.1.1k - флагует CVE, закрытые в конкретной сборке месяцы назад. Команда проверяет, подтверждает наличие патча, закрывает тикет. Умножьте на десятки таких находок за один скан - и день уходит в мусорку.

Дальше - компенсирующие контроли. Сканер обнаруживает SQL injection в веб-форме, но WAF с virtual patching блокирует инъекционные паттерны. Уязвимость в коде формально существует, эксплуатируемости - ноль.

И классика: модифицированные баннеры, кэшированные ответы, неоднозначные сигнатуры. Неправильная версия порождает нерелевантные CVE-привязки.

Разберём конкретный кейс. CVE-2021-41773 - path traversal в Apache HTTP Server 2.4.49 (CVSS 9.8 CRITICAL, CWE-22), уязвимость из каталога CISA KEV, активно эксплуатируемая (в том числе в ransomware-кампаниях), с публичными PoC на Exploit-DB (EDB-50383, EDB-50512). Нюанс: патч для CVE-2021-41773 в версии 2.4.50 оказался неполным - обход закрыт только в CVE-2021-42013 (CVSS 9.8), поэтому при проверке надо учитывать обе CVE. Любой false positive сканер, определивший версию Apache 2.4.49, выставит CRITICAL. Но при проверке руками:

• Apache за reverse proxy с фильтрацией запросов - эксплуатация невозможна
• Конфигурация с Require all denied вне DocumentRoot - path traversal возвращает 403
• Версия обновлена, но баннер оставлен прежним (стандартный hardening) - находка полностью ложная

Пентестер проверит каждый из этих сценариев за 15 минут. Сканер не проверит ни одного.

Цена шума для организации​

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

Точность AI сканеров уязвимостей: что находит AI и что пропускает​

Где AI обнаруживает то, что пропускает классический SAST​

Vulnhuntr от Protect AI - статический анализатор Python-кода с LLM-верификацией - автономно нашёл подтверждённые уязвимости в крупных open-source проектах:

• CVE-2024-10099 - stored XSS в ComfyUI (comfyanonymous/comfyui v0.2.2, CVSS 6.1 MEDIUM, CWE-79). Вредоносный HTML загружается через /api/upload/image, payload исполняется при просмотре через /view.
• CVE-2024-10131 - RCE в RagFlow (infiniflow/ragflow v0.11.0, CVSS 8.8 HIGH, CWE-94). Функция add_llm в llm_app.py динамически инстанциирует классы из пользовательского ввода req['llm_factory'] без валидации.

По данным исследователя с cyber-ed.ru, на эти находки ушло около $200 токенов Claude API. При этом: большинство обнаруженного оказалось невалидным, два запуска на одном проекте давали разные результаты из-за недетерминированности LLM. Полностью автоматический поиск уязвимостей - один подтверждённый stored XSS за $200. Результат есть, но масштабируемость - под большим вопросом.

Сравнительная таблица: AI-сканер vs пентестер​

Каждая строка - тип уязвимости, с которым я работал при параллельном использовании AI-пайплайна и ручной верификации за последние два года. Не теория - статистика по реальным проектам.

В терминологии MITRE ATT&CK: AI-сканеры хорошо автоматизируют Vulnerability Scanning (T1595.002, Reconnaissance) и Network Service Discovery (T1046, Discovery). Но валидация Exploit Public-Facing Application (T1190, Initial Access) требует контекста, доступного только оператору - сетевая топология, конфигурация контролей, бизнес-логика цели.

По OWASP DevSecOps Maturity Model (DSOMM), AI-сканирование относится к категории Test - зрелость этого компонента определяется не наличием инструмента, а качеством верификации его результатов. На том же горизонте MITRE ATT&CK фиксирует технику Artificial Intelligence (T1588.007, Resource Development) уже как инструмент атакующих - LLM используются не только для защиты.

Интеграция AI в тестирование на проникновение: workflow из трёх этапов​

Угадайте, какой отчёт заказчик берёт в работу.

Операционные ограничения каждого этапа​

AI-ассистент пентестера - решения уровня OpenAI Codex Security и аналоги - полезен на первом и частично на втором этапе. Попытки использовать его для автономного тестирования возвращают к тем самым однозначным цифрам доверия.

Цифра 9% - не провал технологии искусственного интеллекта в кибербезопасности. Это маркер зрелости: организации, прошедшие цикл «купили AI-сканер → получили 800 findings → отправили без верификации → пропустили реальный вектор атаки», больше так не делают. За два года я провёл больше 30 проектов, где ML-пайплайн работал на этапе pre-filter. Скоринг отбраковывал от 60% до 80% сырых находок Nuclei как ложные (что согласуется с долей true positive ~35% на этапе pre-filter) - после ручной проверки false negative rate держался ниже 3%. Это инженерная настройка порогов под данные конкретного заказчика, а не магия.

Проблема начинается, когда тот же пайплайн «из коробки» применяют к новому стеку: модель, обученная на Java-приложениях, давала 45% ложных негативов на Go-сервисах. Обнаружить это может не сканер, а пентестер, знающий паттерны уязвимостей конкретного языка.

Индустрии давно пора перестать крутить вопрос «заменит ли AI пентестера» и перейти к операционной конкретике: при каком размере кодовой базы окупается ML-фильтр, какой false negative rate приемлем для risk appetite заказчика и сколько стоит час ручной верификации по сравнению с часом расследования ложного срабатывания. Если хотите руками прощупать, как работает связка AI-скоринга и ручной верификации на реальных целях - на HackerLab есть лабы с этой цепочкой.