AI-генерируемые отчёты об уязвимостях: взгляд триажера

За последние восемь месяцев через мою triage-очередь прошло больше 300 входящих отчётов. Треть из них - AI slop: несуществующие функции, вымышленные commit-хэши, impact-блоки, которые ChatGPT штампует с одинаковой убедительностью и для реальной RCE, и для выдуманного self-XSS. Мой pipeline проверки прост до безобразия: grep по кодовой базе на упомянутые функции, валидация CVE через NVD API, воспроизведение PoC в Burp Suite - и за пять минут вердикт готов. Даниэль Стенберг, создатель curl, в июле 2025 года назвал происходящее «Death by a Thousand Slops». С тех пор, по оценке инженеров HeroDevs, стало ощутимо хуже.

AI slop в кибербезопасности: масштаб проблемы​

AI slop в bug bounty - это LLM-сгенерированные отчёты об уязвимостях, которые выглядят профессионально, содержат правильную структуру и терминологию, но описывают несуществующие баги. Термин пришёл из медиасреды, где slop - синоним низкокачественного AI-контента. В security research это мусорные баг-репорты, которые льются через HackerOne, Bugcrowd и вендорские программы ради быстрого заработка. Подробнее - в нашем подробном разборе безопасность llm атаки.

Экономика атаки элементарна: генерация отчёта - 30 секунд, проверка - час работы специалиста. Socket.dev формулирует точно: асимметрия, при которой создание отчёта стоит тридцать секунд, а разбор - час, нежизнеспособна.

Масштаб по данным платформ:


Крупные вендоры с собственными security research программами - от Apple Security Research до Google VRP - работают по сходной модели приёма отчётов. TechCrunch запросил комментарии у Google, Meta и Microsoft: Microsoft и Meta отказались, Google промолчал. Проблема касается любой программы, принимающей отчёты от внешних исследователей.

Явление напрямую связано с OWASP LLM Top 10 (2025), категория LLM09: Misinformation - способность LLM генерировать ложную или вводящую в заблуждение информацию. Галлюцинированные уязвимости - частный случай этого риска, спроецированный на bug bounty.

Анатомия мусорного баг-репорта: маркеры ИИ-генерации​

Триаж AI slop - навык, который нарабатывается после разбора сотни кейсов. Вот конкретные маркеры, по которым опытный триажер выносит вердикт в первые 30 секунд.

Несуществующие функции и методы. LLM уверенно ссылается на код, которого нет в проекте. В инциденте с curl (отчёт H1 #3125832) фигурировали вымышленные функции и несуществующие commit-хэши. Гарри Синтонен, разобравший кейс публично, описал паттерн: отчёт «refers to functions and methods that do not exist», а при конфронтации автор ссылался на «old or new versions of components, using non-existent commit hashes». Проверка: grep -r "function_name" ./src/ - занимает секунды.

Фальшивый сценарий эксплуатации при реальной кодовой базе. В случае с Hibernate (документирует HeroDevs) разные аккаунты слали отчёты с идентичным сценарием: атакующий модифицирует persistence.xml. Это серверный конфигурационный файл, недоступный извне - он не парсится из недоверенного ввода в runtime. Чтобы его модифицировать, нужен уже скомпрометированный сервер. Разные submitters, один сценарий, одинаковая уверенность, ноль working proof - один промпт, несколько аккаунтов.

Шаблонный impact без привязки к контексту. LLM генерирует impact по шаблону: «This vulnerability allows an attacker to execute arbitrary code, leading to complete compromise of confidentiality, integrity, and availability.» Этот текст одинаково лепится к stored XSS в admin-панели с тремя пользователями и к RCE с сетевым доступом без аутентификации. Модель не различает реальный масштаб последствий - ей всё равно.

Невоспроизводимые шаги. Сет Ларсон, Security Developer-in-Residence в Python Software Foundation, приводит характерный пример: urllib3 получил отчёт, потому что сканер обнаружил упоминание SSLv2. Проект использует эту ссылку исключительно для явного отключения протокола. Сканер нашёл паттерн, LLM оформил находку в отчёт, submitter не потратил ни секунды на проверку.

Зацикленная аргументация при отклонении. Бенджамин Пиуфль из Open Collective описывает цикл: вы объясняете, почему сценарий невозможен - ИИ генерирует новый ответ, столь же убедительный и столь же фейковый. Каждый ответ «slightly different from the previous one, each requiring the same explanation you just gave». Единственный выход - закрыть отчёт. Через несколько дней другой аккаунт открывает аналогичный.

Практическая предфильтрация​

На практике первый уровень фильтрации автоматизируется. Pipeline скоринга входящих отчётов:

• Поиск упомянутых функций/методов: grep -r "function_name" ./src/
• Валидация CVE через NVD API - несуществующие идентификаторы это мгновенный red flag
• Проверка commit-хэшей: git log --oneline | grep <hash>
• Batch-анализ: идентичная структура impact/remediation от разных аккаунтов

Второй уровень - верификация заявленных уязвимостей. Если отчёт утверждает XSS в конкретном эндпоинте, запуск semgrep --config=auto по указанному файлу покажет, есть ли sink без санитизации. Влад Ионеску из RunSybil (ex-Meta red team) в комментарии TechCrunch сформулировал это хорошо: «People are receiving reports that sound reasonable, they look technically correct. And then you end up digging into them, trying to figure out, 'oh no, where is this vulnerability?' It turns out it was just a hallucination all along.»

Фейковые уязвимости от ИИ: разбор реальных кейсов​

curl: несуществующий код, реальные выплаты​

Проект curl получил отчёт H1 #3125832, который Синтонен публично препарировал. На первый взгляд - правдоподобно: описание уязвимости при работе с HTTP/3, технический язык, ссылки на реальный исходный код. При экспертном разборе рассыпался: выдуманные патчи для несуществующего кода, фейковые описания функциональности, вымышленные commit-хэши.

Аккаунт, связанный с отчётом, применял ту же тактику к другим организациям - и в некоторых случаях получал выплаты. «The attacker miscalculated badly. Curl can smell AI slop from miles away,» - написал Синтонен. Ключевое различие: curl - проект с глубокой экспертизой автора, без давления «заплатить, чтобы не тратить время». Корпоративные программы, где триажеры не знают кодовую базу на уровне мейнтейнера, значительно уязвимее.

Node.js: волонтёры на линии огня​

Security triage в Node.js ведут волонтёры в свободное время. Каждый час на ложные отчёты уязвимостей - час, не потраченный на реальный CVE и security release для миллионов разработчиков. Проект поднял планку на HackerOne, потребовав минимальный reputation score. Не хватило.

Команда исследует LLM-assisted triage: rule-based классификатор убирает очевидный шум, затем LLM оценивает, что заслуживает человеческого внимания. По оценке HeroDevs, это «поражение»: каждый добавленный фильтр несёт риск отсечения легитимного отчёта. «That researcher moves on and the vulnerability stays open.»

Hibernate: один промпт - десять аккаунтов​

HeroDevs, поддерживающая End-of-Life библиотеки, получила аномальный объём отчётов о Hibernate с одним и тем же сценарием: модификация persistence.xml. «Different submitters, same scenario, same fabricated exploit chain, same confident tone. Same complete absence of working proof.» Инженер HeroDevs описывает процесс разбора как «Dante circle of hell, a descent through plausible-sounding nonsense» - каждый ответ на отклонение порождает новый AI-generated аргумент, столь же уверенный и столь же фальшивый.

Борьба с AI bug bounty спамом: ответ платформ​

HackerOne: Hai Triage​

HackerOne запустил Hai Triage - систему, где AI-агенты работают в связке с человеческими аналитиками. Агенты отсекают шум, помечают дубликаты и приоритизируют реальные угрозы. Аналитики валидируют и эскалируют. Отчёты с «hallucinated vulnerabilities, vague technical content, or other forms of low-effort noise» обрабатываются как спам.

Репутационная система ограничивает submitters с низким рейтингом: меньше доступных программ, лимит на количество отчётов. Но механизм дырявый: в кейсе с curl reporter сам закрыл отчёт со статусом «Not Applicable», что не влияет на репутацию. Джо Купер на Mastodon написал точно: «The long-term credibility of researchers on the platform is the only value HackerOne brings to the table.»

Bugcrowd: playbooks + ML​

Кейси Эллис утверждает, что AI «widely used in most submissions», но пока не вызвал «significant spike in low-quality 'slop' reports». Команда Bugcrowd использует ручной разбор по playbooks плюс ML для ассистирования. Прогноз Эллиса: «This'll probably escalate in the future, but it's not here yet.»

Корпоративные программы: слабое звено​

Socket.dev точно формулирует проблему модерации bug bounty программ без глубокой экспертизы: «The real exploit here is that the attacker exploits the fact that the victims don't have the capacity to perform thorough analysis and rather just pay up. It's cheaper to pay the bug bounty than hire an expert to perform true analysis.» Вот и вся бизнес-логика атаки: AI slop эксплуатирует не код, а triage-процесс.

LLM-сгенерированные отчёты под микроскопом​

Исследование из arxiv проанализировало 9 942 публично раскрытых отчёта с HackerOne: 8 542 валидных и 1 400 невалидных. Три вывода, которые стоит запомнить:

LLM склонны к over-accept. GPT-5, DeepSeek и fine-tuned RoBERTa показали высокую общую точность классификации, но систематически плохо детектировали невалидные отчёты. Модели «тянутся» к принятию - архитектура оптимизирована под helpfulness, а не под критический анализ. Для triage-задачи вывод однозначный: LLM как единственный фильтр ненадёжен.

RAG с таксономией отклонений работает. Исследователи построили таксономию причин отклонения для Information Disclosure уязвимостей и встроили её в RAG-фреймворк. Consistency классификации выросла, bias снизился. Практический вывод: структурированное знание о паттернах невалидных отчётов бьёт zero-shot промпт к LLM.

Репутация влияет на решения. Анализ семантически похожих отчётов с разным статусом показал: reporters с высокой репутацией получают более благоприятные решения в пограничных случаях. Perceived expertise влияет на review judgments. Для исследователя - прямой стимул инвестировать в качество отчётов и строить профиль, а не гнать объём.

ИИ-генерация PoC: грань между спамом и реальным research​

Злоупотребление ИИ в security research не отменяет легитимных находок. AI-инструменты находят реальные уязвимости - разница в верификации.

Vulnhuntr от Protect AI обнаружил stored XSS в ComfyUI (CVE-2024-10099, CVSS 6.1 MEDIUM, CWE-79: Improper Neutralization of Input During Web Page Generation). Вектор: AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N - атакующий загружает HTML-файл с XSS-payload через /api/upload/image, выполнение при просмотре через /view. По данным CISA: SSVC Track* (PoC существует, не автоматизируется, partial impact). EPSS 0.0035 - ниже медианы.

Тот же инструмент нашёл RCE в RagFlow (CVE-2024-10131, CVSS 8.8 HIGH, CWE-94: Code Injection). Функция add_llm в llm_app.py использует пользовательский ввод req['llm_factory'] для динамической инстанциации классов без валидации. CISA SSVC: Track* (PoC существует, total impact). EPSS 0.0114 - выше медианы.

Разница между этими находками и AI slop: Vulnhuntr генерирует PoC с конкретным trace потока данных и оценкой уверенности (шкала 1-10, выше 7 - вероятная уязвимость). Мусорный отчёт - красиво звучащий текст без единого доказательства.

Сами AI-инструменты при этом создают собственную поверхность атаки. CVE-2025-59536 - code injection в Claude Code до версии 1.0.111 (CVSS 8.7 HIGH по CVSS:4.0, CWE-94). Инструмент можно было заставить выполнить код из проекта до подтверждения пользователем trust-диалога при запуске в untrusted-директории. EPSS 0.2636 - top 5% по вероятности эксплуатации, публичный PoC на GitHub.

Качество отчётов о безопасности: чек-лист для исследователя​

Проблема AI slop в bug bounty - не технологическая. Это проблема стимулов. Пока генерация отчёта стоит ноль, а его проверка - час работы эксперта, поток не остановить фильтрами. HackerOne запускает Hai Triage, Node.js строит LLM-классификаторы, Bugcrowd добавляет ML-ассистентов - всё это реактивные меры. Они масштабируют защиту, но не меняют экономику.

Два вектора способны реально сдвинуть ситуацию. Первый - повышение стоимости входа: обязательный working PoC в sandbox-среде до принятия на триаж, proof-of-work для отчётов, жёсткий бан аккаунтов за AI-мусор без возможности обнулить репутацию через самозакрытие в статусе «Not Applicable». Второй - явное вознаграждение качества вместо объёма: бонусы за exceptional reports, публичный рейтинг по проценту подтверждённых находок.

Через год-два дешёвые LLM-отчёты убьют bug bounty для легитимных исследователей. Не потому что ИИ найдёт все баги - а потому что triage-команды утонут в шуме и перестанут читать. Синтонен предупреждает: «Genuine researchers quit in frustration as they don't get proper reward for their hard work, and see AI slop scoop the money.» Я уже вижу это в реальных проектах: исследователи уходят из программ, где их отчёты стоят в очереди за сотней AI-галлюцинаций. Платформы, которые не поменяют правила в ближайшие месяцы, потеряют инфраструктуру crowdsourced security, строившуюся десятилетие. И никакой AI-фильтр не заменит того, что реально работает - живого эксперта, который знает свой продукт на уровне исходного кода. Если хочешь отработать разбор таких отчётов на практике - на HackerLab есть лабы с реальными и фейковыми баг-репортами.