Команда запускает LLM для проверки веб-приложения и получает убедительный отчёт: модель описывает возможную цепочку атаки, предполагаемый обход проверки и пример риска для данных. На первый взгляд это похоже на экономию времени пентестера. Проблема начинается там, где красивое объяснение принимают за доказанную уязвимость.
LLM хорошо строит гипотезы, но не всегда понимает реальные границы среды. Она может перепутать тестовый ответ с рабочим поведением, переоценить влияние ошибки, не заметить ограничение роли или придумать шаг, который не воспроизводится. Поэтому модель должна быть источником гипотез, а не финальным валидатором.
Практическая задача AppSec — встроить AI в пентест так, чтобы каждая находка проходила независимую проверку. Нужны тестовая среда, повторяемый сценарий, доказательство доступа, оценка влияния и решение человека. Если этого нет, отчёт модели остаётся черновиком.
Такой подход особенно важен для команд, которые уже получают много AI-сгенерированных отчётов от внутренних разработчиков, внешних исследователей и автоматических инструментов.
Где модель ошибается
Главная ошибка — путать правдоподобный путь с рабочей эксплуатацией. Модель может увидеть похожий шаблон в коде, но не проверить состояние сессии, роль пользователя, привязку ресурса к владельцу или серверную проверку. В итоге отчёт выглядит уверенно, а воспроизведение ломается на первом реальном запросе.
Вторая ошибка — завышение критичности. Если модель не видит бизнес-контекста, она может назначить высокий риск там, где нет доступа к данным, или наоборот недооценить тихую ошибку авторизации.
- не принимать текст без воспроизведения;
- проверять роль пользователя;
- проверять владельца объекта;
- сравнивать тестовую и рабочую конфигурацию;
- фиксировать запрос и ответ;
- отделять гипотезу от доказательства;
- назначать риск только после проверки влияния.
Независимый контур проверки
Проверка должна быть независимой от инструмента, который создал гипотезу. Если та же модель пишет отчёт и сама подтверждает его, команда получает круговое доверие. Лучше использовать разные уровни: статический анализ, динамический тест, ручной запрос, журнал приложения и решение владельца сервиса.
Для критичных зон нужен запрет на автоматическое принятие результата. Модель может предложить сценарий, но человек должен подтвердить, что действие действительно возможно, безопасно воспроизводится и относится к нужной системе.
- разделить генерацию и валидацию;
- использовать отдельный тестовый стенд;
- прикладывать минимальный запрос;
- прикладывать журнал приложения;
- сравнивать с политикой доступа;
- проверять влияние на данные;
- утверждать критичность человеком.
Шаблон карточки находки
Карточка AI-находки должна быть строже обычной заметки. В ней отдельно указываются предположение модели, реальные шаги проверки, результат воспроизведения, затронутый актив и нерешённые вопросы. Если хотя бы один элемент отсутствует, находка не должна попадать в очередь исправления как подтверждённая.
Такой шаблон снижает шум и помогает разработчикам. Они видят не только красивое описание, но и конкретный тест, который можно повторить после исправления.
- краткая гипотеза;
- источник сигнала;
- условия воспроизведения;
- роль пользователя;
- затронутые данные;
- доказательство доступа;
- оценка влияния;
- критерий закрытия.
Контрольные журналы
Любой AI-помощник в процессе проверки должен оставлять следы. Команде нужны не только итоговые выводы, но и исходная гипотеза, источник данных, шаг проверки, решение человека и причина отклонения. Без этого нельзя понять, помогла модель или просто убедительно описала ошибку.
Журналы лучше сразу приводить к единой схеме. Тогда события из репозитория, тестовой среды, почты, облака и SIEM можно связать в одну временную линию.
- идентификатор задачи;
- источник гипотезы;
- данные, переданные модели;
- ссылка на ручную проверку;
- решение политики;
- результат теста;
- владелец исправления;
- срок повторной проверки.
Практический порядок внедрения
Начинать нужно с режима наблюдения. Команда выбирает один процесс, собирает реальные события, считает шум и только затем включает обязательные проверки для критичных случаев. Это снижает риск, что новая AI-функция создаст красивые отчёты, но не улучшит безопасность.
Для каждого правила назначается владелец. Он отвечает за качество сигнала, исключения, срок действия правила и связь с рабочим процессом.
- описать процесс до внедрения AI;
- выбрать один ограниченный сценарий;
- собрать события за две недели;
- проверить ложные срабатывания;
- назначить владельца правила;
- описать исключения;
- включить обязательную проверку только для критичных зон.
Метрики результата
Успех измеряется не количеством сгенерированных отчётов. Важно видеть, сократилось ли время проверки, уменьшилось ли число пропущенных дефектов, стали ли доказательства полнее и не выросла ли нагрузка на аналитиков.
Если метрика не улучшается, контроль нужно сузить. Узкое правило, которое стабильно ловит один риск, ценнее широкой модели, создающей поток неподтверждённых замечаний.
- время до подтверждённой гипотезы;
- доля воспроизводимых находок;
- число ложных отчётов;
- доля задач с доказательствами;
- время назначения владельца;
- число повторных дефектов;
- доля ручных исключений.
Разбор инцидента после срабатывания
Когда правило сработало, команда не должна ограничиваться отметкой «подтверждено» или «ложно». Нужна короткая послесобытийная карточка: что увидели первым, какой сигнал оказался решающим, какие данные были недоступны и какое действие действительно остановило риск. Такая карточка превращает один случай в материал для улучшения процесса.
Особенно важно фиксировать пропущенные события. Если модель предложила полезную гипотезу, но журнал не позволил её проверить, проблема находится не в модели, а в наблюдаемости. Если журнал был полным, но правило не сработало, нужно менять логику корреляции.
- первый замеченный сигнал;
- решающий артефакт;
- недостающий журнал;
- решение аналитика;
- действие владельца системы;
- срок исправления;
- обновление правила обнаружения.
Как снизить шум без потери риска
AI-подходы часто создают много похожих выводов. Если отправлять их напрямую разработчикам или аналитикам, доверие быстро исчезает. Нужно группировать сигналы по причине, активу и владельцу, а не показывать каждую формулировку как отдельный инцидент.
Хороший фильтр не скрывает риск, а объединяет повторяющиеся симптомы. Например, десять похожих предупреждений о доступе к чужим объектам должны стать одной задачей по проверке авторизации, а не десятью независимыми карточками. Для SOC похожие письма объединяются в кампанию, а не в десятки несвязанных жалоб.
- объединять события по корневой причине;
- сохранять первичные доказательства;
- назначать одного владельца;
- показывать частоту повторов;
- оставлять возможность раскрыть детали;
- разделять риск и шум;
- проверять качество правила раз в месяц.
