7 ошибок в баг баунти с ИИ-агентами: как перестать слать мусорные репорты

Владислав Бэк и Даниил Шушаков, практики российских баг баунти и спикеры OFFZONE, собрали за полгода работы с агентными связками семь типовых ошибок, которые превращают ИИ-поиск уязвимостей в генератор невалидных репортов, и рассказали, как каждую из них закрыть.

Доклад прозвучал на OFFZONE и затем был опубликован в текстовом виде авторами: Владислав Бэк занимается реагированием на инциденты и параллельно багхантит на российских площадках, Даниил Шушаков работает пентестером в «Инфосистемы Джет» и регулярно попадает в топы баг баунти программ. Ниже их опыт, переложенный в пошаговый формат.

Что понадобится

• ИИ-агент с доступом к инструментам: Claude Code, Cursor, Codex CLI или аналог, способный выполнять команды в терминале
• Изолированная виртуальная машина или набор MCP-контейнеров (Model Context Protocol, протокол подключения инструментов к агенту), чтобы агент запускал команды, не трогая боевую среду
• Burp Suite или curl для ручной перепроверки запросов
• Шаблон отчёта с обязательными полями: описание, шаги воспроизведения, доказательства, реальный импакт
• Набор custom rules (правил валидации) по классам уязвимостей
• Аккаунт на российской баг баунти площадке
• Время: 2 часа на настройку связки, далее 15 минут на валидацию каждой находки

Семь ошибок и как их закрыть

1. Галлюцинации и фабрикация. Агент выдумывает уязвимости, раздувает критичность до CVSS 10.0 и подаёт предположение как доказанный факт. Решение: дайте агенту реально выполнять команды в изолированной среде. Пока у модели нет возможности запустить проверку, она додумывает результат. Подключите полный доступ к командам в виртуальной машине или MCP-контейнеры. После этого перепроверьте вручную: отправьте запросы в Burp или curl и убедитесь, что поведение воспроизводится.

2. Хантер не валидирует находку. Слепое доверие к красивому отчёту, спешка на ивентах и низкая цена ошибки (максимум понизят уровень сигнала) приводят к тому, что репорт улетает на площадку без проверки. Решение: если не понимаете, что нашёл агент, не отправляйте. Разберитесь, воспроизведите, убедитесь, что поведение тянет на баг с реальным импактом. Даже если отправили в спешке, вернитесь позже и допишите детали в комментариях.

3. Непонимание реальной модели угроз. Агент принимает информацию за уязвимость и строит спекулятивные цепочки. Классический пример: заголовок X-Powered-By: PHP/8.1 превращается в цепочку «раскрытие стека, значит CVE, значит RCE, значит бизнес уничтожен». Каждое звено тут допущение, а не доказательство. Решение: дайте агенту контекст приложения. Не просто «маркетплейс», а маркетплейс с такими-то функциями, где вот это поведение легитимно. Запустите второго агента на опровержение: его задача не найти баг, а доказать, что находки первого агента невалидны.

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

5. Правила валидации не заданы. Агент не знает, что считается настоящей багой для конкретного класса уязвимостей. Решение: напишите custom rules для каждого типа: инъекции, SSRF (Server-Side Request Forgery, когда сервер можно заставить отправить запрос на внутренний ресурс), доступ и авторизация, XSS (межсайтовый скриптинг), раскрытие информации, файловые загрузки. Отдельное правило на сам процесс верификации.

6. Отсутствие бизнес-контекста в промпте. Системный промпт (базовая инструкция для модели) описывает цель «ищи баги», но не объясняет, как устроено приложение. Агент из одного HTTP-ответа не может оценить критичность бизнес-логики. Решение: в промпте нормально опишите приложение, его роли, разрешённые действия и границы скоупа (scope, периметр тестирования). Количество ложных срабатываний падает, а на их место приходят находки, которые действительно принимают.

7. Нет петли обратной связи. Агент повторяет одни и те же ошибки от запуска к запуску. Решение: сохраняйте результаты каждой сессии, отмечайте, какие находки приняли, а какие отклонили, и загружайте эту историю агенту в контекст следующего запуска.

Что делать с этим прямо сейчас, по ролям

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

Опытному исследователю. Пропишите custom rules по классам уязвимостей и добавьте агента-оппонента. Это не удваивает затраты, а сокращает время на ручную фильтрацию ложных срабатываний.

Автору на Дзене, который пишет про ИИ. Описанный подход с двумя агентами (один ищет, второй опровергает) работает не только в безопасности. Тот же принцип применим к фактчекингу контента: один агент генерирует, второй проверяет утверждения. Попробуйте на своих текстах.

Предпринимателю. Если у вас есть продукт и вы запускаете баг баунти программу, учитывайте: поток невалидных ИИ-репортов, это новая реальность для триажеров (специалистов, которые сортируют отчёты). Закладывайте ресурсы на фильтрацию и прописывайте в правилах программы требования к доказательствам.

Принцип, который стоит забрать из этого доклада, прост: ИИ-агент это не замена исследователю, а усилитель. Если усиливать нечего, на выходе будет усиленный мусор. Дайте агенту реальные инструменты, контекст и оппонента, а себе оставьте финальное слово. Тогда баг баунти начнёт приносить принятые репорты, а не понижение сигнала.