После Mythos: почему bug bounty теперь нужны более жесткие доказательства

Несколько недель назад я писал об Anthropic Mythos и Project Glasswing. Тогда речь шла прежде всего о большой линии: если модели действительно становятся лучше в поиске старых уязвимостей, комбинировании exploit-путей и понимании целых codebase, то vulnerability research меняется.

Новая статья Sophos о bug bounty в эпоху Mythos показывает теперь операционную сторону этого изменения.

Вопрос уже не только в том, находит ли ИИ более хорошие уязвимости. Вопрос в том, способны ли bug bounty программы, security-команды и engineering-организации достаточно быстро отличать мусор, правдоподобные утверждения и реальные проблемы безопасности.

Настоящая проблема не только в AI slop

Когда речь заходит об ИИ и bug bounty, многие сразу думают о slop: автоматически созданных отчетах, наполовину понятых ошибках, выдуманных exploit-цепочках, невоспроизводимых утверждениях и большом количестве текста с малым содержанием.

Это реально. И для maintainer’ов, product security команд и людей на triage это ужасно раздражает.

Но это только одна сторона.

Другая сторона опаснее: хорошие исследователи могут использовать те же модели, чтобы быстрее находить реальные уязвимости, проверять гипотезы на больших codebase и системно проходить варианты одного паттерна. То, что раньше занимало дни или недели ручной работы, в будущем может попадать в очередь за часы.

Так проблема смещается. Раньше вопрос часто звучал так: получаем ли мы достаточно хороших внешних findings? Сегодня вопрос скорее такой: можем ли мы достаточно быстро распознавать, валидировать, приоритизировать и превращать реальные findings в fixes, пока шум одновременно растет?

Почему Sophos здесь интересный источник

Статья Sophos не является общим комментарием про ИИ. Sophos смотрит на собственную bug bounty программу и приводит конкретные цифры.

По данным Sophos, публичная программа работает на Bugcrowd с декабря 2017 года. Sophos пишет, что к моменту публикации статьи было оплачено 1 343 уязвимости при 7 091 submission всего и общей сумме выплат 599 695 долларов США.

Для 2025 года Sophos, среди прочего, называет:

• 59 400 долларов США выплат за более чем 52 отчета
• около 420 участвующих исследователей
• до 80 000 долларов США за Intercept X Endpoint при определенных условиях
• до 50 000 долларов США за Sophos Central
• до 50 000 долларов США за Sophos Firewall
• 13 действительных Sophos Firewall bugs в 2025 году с общей выплатой 21 500 долларов США
• 13 действительных Sophos Central bugs в 2025 году с общей выплатой 11 650 долларов США

Это не астрономические цифры, но именно поэтому они интересны. Они показывают, сколько сортировочной работы стоит за относительно зрелой программой. Тысячи submissions не означают автоматически тысячи релевантных проблем безопасности. И ИИ, вероятно, не сделает это соотношение легче.

Он сделает его жестче.

Воспроизводимость становится входным билетом

Самое важное следствие, на мой взгляд, банально, но неудобно: security report без чистой воспроизводимости станет менее ценным.

Не потому, что triage-команды ленивы. А потому, что их время становится дефицитнее.

Если отчет утверждает, что показывает remote code execution, auth bypass или критическую утечку данных, он должен четко доказать:

• какая версия затронута
• какая конфигурация нужна
• какие права нужны атакующему
• какие шаги воспроизводимо приводят к результату
• какие logs, requests, traces или screenshots поддерживают утверждение
• какой impact действительно доказан
• где граница между предположением и доказательством

Это звучит строго. Так и есть. Но это станет необходимым, если security-команды не должны тонуть в правдоподобно звучащих текстах.

Отчет, созданный ИИ, может выглядеть очень убедительно по языку. Он может цитировать код, формулировать как CVE и имитировать аккуратную структуру. Это не делает его правдой. И наоборот, короткий сухой отчет с хорошим proof of concept может быть чрезвычайно ценным.

Новая валюта не формулировка. Новая валюта - доказательство.

ИИ делает authorization bugs особенно неприятными

Один пункт в статье Sophos кажется мне особенно практичным: ИИ может помочь масштабировать найденный authorization bypass на более широкие области scope.

Это совпадает с тем, что и так видно в реальных SaaS-средах. Authorization редко является одним переключателем. Она живет в ролях, tenants, object ID, subdomains, API versions, admin surfaces, mobile endpoints, legacy routes и наполовину мигрированных features.

Если исследователь находит паттерн, ИИ может помочь системно проверить его варианты:

• Работает ли bypass только для одного endpoint или для целого семейства endpoints?
• Работает ли он только в одном tenant или между tenants?
• Есть ли та же логика в старых и новых API?
• Действительно ли admin и user роли везде чисто разделены?
• Можно ли загрузить объект напрямую по ID, хотя UI его не показал бы?

Именно там ИИ становится опасно полезным. Не как магический hacker, а как ускоритель скучной, широкой, системной проверки.

И это плохо для организаций, безопасность которых сильно зависит от того, что ни у кого нет достаточно времени проверить все скучные варианты.

Bug bounty - не PR-почтовый ящик

Многие компании до сих пор относятся к bug bounty почти как к теме имиджа: у нас есть программа, значит мы открытые, современные и security-minded.

Этого больше недостаточно.

Bug bounty программа - это производственная система. Ей нужны ясные правила, хороший triage, техническая воспроизводимость, близость к продукту, engineering-ответственность и связь с incident response. Иначе она становится просто публичным почтовым ящиком, где внешние исследователи, AI slop и реальные атакующие используют один и тот же вход.

Sophos соединяет в статье два неудобных пункта:

Первое: хорошие исследователи помогают. Внешний взгляд, другие модели мышления и постоянное давление ценны.

Второе: система с деньгами и доверием может быть использована злоупотребительно. Sophos ссылается на опыт вокруг Pacific Rim, Asnarök и Personal Panda, где временная близость между активной эксплуатацией и последующими bug bounty reports как минимум вызывала вопросы. Sophos прямо не говорит, что каждый такой report был злонамеренным. Но операционный вывод остается: bug bounty программу нельзя строить на наивности.

Практически это означает:

• Reports нужно коррелировать с telemetry.
• Новый finding должен также уметь запускать ретроспективные threat hunts.
• Triage должен знать, были ли уже видны похожие exploit-попытки.
• Репутация исследователя помогает, но не заменяет техническую проверку.
• Safe harbor важен, но не заменяет обнаружение злоупотреблений.

Такова трезвая реальность: bug bounty - часть Secure by Design, а не его замена.

Более жесткие доказательства означают и более жесткую ответственность

Здесь есть напряжение, которое не стоит сглаживать.

Исторически исследователям часто говорят: остановитесь достаточно рано. Покажите bug, но не уходите слишком глубоко. Не трогайте customer data. Никакого lateral movement. Никаких разрушительных действий.

Это правильно.

Одновременно burden of proof будет расти. Если ИИ массово создает правдоподобные, но ложные reports, программы будут требовать больше evidence. Тогда появляется трудный вопрос: как исследователь может сильнее доказать impact, не соскальзывая в опасное поведение?

Ответ не может быть: “просто делайте больше.” Ответ должен стать более контролируемым:

• более ясные Rules of Engagement
• выделенные test environments
• безопасные пути reproduction
• согласованные границы для proof of impact
• лучшие sandbox и lab systems
• автоматизированные replays для proof of concept

Для крупных производителей это почти обязательно. Кто серьезно платит высокие bounties, должен иметь и инфраструктуру, чтобы быстро и чисто валидировать reports.

Для меньших проектов это горьче. Они получают ту же волну slop, но не те же ресурсы. Именно поэтому некоторые проекты сократят финансовые bug bounties или полностью их отключат. Не потому, что они не воспринимают безопасность серьезно, а потому, что эксплуатация самой программы становится нагрузкой.

Чему могут научиться админы и MSP

Можно сказать: это касается только производителей и Bugcrowd-программ.

Я так не думаю.

Тот же механизм затрагивает MSP, внутренние IT-команды и ответственных за security. Везде, где нужно оценивать внешние или внутренние findings, давление растет:

• Scanners дают больше findings.
• AI assistants объясняют findings убедительнее.
• Developers приносят AI-generated security notes.
• Customers спрашивают о CVE до того, как понимают контекст.
• Management хочет знать, реальный ли риск или просто громкий.

Практический ответ - не игнорировать все. Ответ - более жесткий процесс validation.

На мой взгляд, туда входят как минимум эти вопросы:

1. Воспроизводима ли проблема?
2. Ясен ли затронутый scope?
3. Есть ли реалистичный attacker path?
4. Impact технически доказан или только заявлен?
5. Есть ли logs или telemetry, которые могут показать exploitation?
6. Fix - это patch, configuration, workaround или просто пластырь?
7. Нужно ли ретроспективно искать, не было ли это уже использовано?

Это звучит как больше работы. Так и есть. Но это лучшая работа, чем нервно реагировать на каждый хорошо написанный report.

Почему это хорошо подходит к Mythos

Ключевой пункт Mythos для меня никогда не был только: “вау, модель находит bugs.”

Пункт был в другом: если такие способности становятся реальнее, уменьшается время между finding, understanding, reproduction и exploitation. Именно там это бьет по bug bounty программам. Они находятся на пересечении research, attack potential, engineering и responsibility.

Sophos формулирует это в своей статье похоже: вопрос не в том, как остановить AI submissions. Вопрос в том, как сохранить trust и signal, когда хорошее исследование и шум могут производиться со скоростью машины.

Для меня это самое чистое резюме проблемы.

Не каждой организации нужна большая собственная bug bounty программа. Но каждой организации нужны лучшие механизмы проверки технических утверждений. Потому что поток security-информации не станет меньше. Он станет быстрее, громче и лучше написанным.

Моя оценка

Я считаю статью Sophos полезным follow-up к Mythos, потому что она переносит дискуссию из комнаты моделей в операционную комнату.

Mythos - это зрелищный сигнал. Bug bounty triage - это рабочий стол, на котором видно, успевают ли security-процессы.

Мой тезис простой:

• Кто только собирает больше reports, проиграет.
• Кто требует воспроизводимое evidence, лучше приоритизирует.
• Кто связывает bug bounty, telemetry, engineering и incident response, быстрее реагирует.
• Кто понимает ИИ только как text generator, недооценивает его ценность для системной security-работы.
• Кто не фильтрует AI slop, сжигает время людей, которые должны решать реальные проблемы.

Это звучит менее гламурно, чем frontier model, который находит zero-days. Но именно там решается, дойдет ли security gain до defenders или все просто утонут в еще большем шуме.

До следующего раза,
Joe