Запуск программы bug bounty в эпоху ИИ
Дейкстра однажды пошутил, сказав следующее:
Каждая функция, которую выпускает команда, содержит несколько ошибок, и единственный вопрос, который действительно имеет значение, — кто найдет их первым.
Мы проводим программы bug bounty уже несколько лет. В рамках наших программ HackerOne и раскрытия уязвимостей количество заявок выросло с 28 во втором квартале 2025 года до 75 во втором квартале 2026 года, то есть примерно в два с половиной раза. Большая часть того, что выявляет программа, соответствует классическому сценарию веб-безопасности: внешняя сторона отправляет контролируемые данные в интернет-сервис, эти данные передаются другим внутренним службам, и где-то по пути предположение, которое перестало быть верным, превращается в уязвимость. За каждой уязвимостью в наших сервисах стоит одна и та же забота: защита данных клиентов, проходящих через наш конвейер, и доверие, которое оказывают нам клиенты. Именно ради этой защиты существует наша программа bug bounty (наряду с регулярными проверками безопасности с доверенными внешними партнерами), и именно это подтолкнуло нас к тому, чтобы находить эти ошибки самостоятельно, прежде чем это сделает кто-то за пределами нашей организации.
Логистика проведения программы bug bounty с технической стороны редко обсуждается с точки зрения защитника в эпоху ИИ. Из тех 75 отчетов, поданных во втором квартале 2026 года, 31 был помечен как дубликат по состоянию на ноябрь 2026 года. Годом ранее дубликатами были 3 из 28 отчетов. Мы также видим отчеты, созданные ИИ, и лишь некоторые из них являются валидными. Мы выплачиваем вознаграждение, когда отчет реален, и берем на себя сортировку, когда это не так. Но сортировка — это лишь видимая часть расходов. То, что действительно имеет значение, — это риск: пока отчет не поступит, реальная ошибка остается в работающем сервисе, через который проходят данные клиентов, и время работает против того, кто найдет ее первым. Рано или поздно возникает вопрос: можем ли мы сами найти эти ошибки, прежде чем они попадут в очередь.
Валидные отчеты VDP в HackerOne без дубликатов, апрель 2025 г. – сентябрь 2026 г., всего 162
Мы уже ведем карту нашего периметра, нашей поверхности атаки, доступной из интернета, с точки зрения злоумышленника. Мы хотели превратить этот инвентарь в исследование безопасности на уровне исходного кода, используя тщательно подготовленный мультиагентный конвейер: выяснить, что делает конечная точка, отследить данные через сервисы, с которыми она взаимодействует, и проверить предположения на каждом этапе. Вместо того чтобы останавливаться на правдоподобной ошибке, система работает над поиском, подкрепленным доказательствами, с воспроизведением там, где это возможно, и достаточным контекстом для инженера, чтобы принять меры. Так родился Project Artemis.
Что такое Artemis?
Artemis — это наша red team с поддержкой ИИ. Она состоит из специализированных агентов, которые самоорганизуются при исследовании потенциальных уязвимостей безопасности в наших сервисах.
«Разведчик» собирает данные, «Аналитик» изучает их и готовит планы тестирования, а «Оператор» проверяет выбранные гипотезы в ограниченной среде. Независимый «Арбитр» проверяет доказательства, воспроизводит их, где это возможно, и помечает решения, требующие участия человека.
Роли агентов Artemis и обратная связь
Для первой кампании два инженера по безопасности запустили Artemis на своих ноутбуках, используя Hermes и Claude Code. Кампания принесла 112 находок. С тех пор мы заменили Claude Code на OpenCode, поскольку его базовая подсказка использует меньше токенов и более настраиваема. Hermes остается частью системы.
Artemis дает каждому агенту конкретную задачу, набор инструментов и навыков, а также общие правила взаимодействия. Средства контроля адаптированы к роли, с изоляцией и ограниченным исходящим трафиком для канала исполнения. Цель состоит в том, чтобы дать агентам достаточно возможностей для проверки гипотезы, не рассматривая эту возможность как разрешение тестировать все, до чего они могут дотянуться.
Поверхность атаки как проблема данных
Проект начался с инвентаризации интернет-ориентированных конечных точек в нескольких сервисах, экспортированных в формате JSON, который могли читать агенты. Многие маршруты включали указатель на обработчик; для остальных конвейеру приходилось находить реализацию. Эти конечные точки стали отправными точками для отслеживания контролируемых злоумышленником данных в системе. Инвентаризация включала наши собственные сервисы и сторонние компоненты, размещенные на наших мощностях; и то, и другое считается поверхностью атаки. Затем мы расставили приоритеты маршрутов по степени подверженности риску и потенциальному воздействию, давая каждой кампании управляемый объем работы, а не пытаясь исследовать все сразу.
Точность важнее ложных срабатываний
Создание конвейера было самым важным шагом. Механически это цепочка этапов, каждый из которых является отдельным процессом, считывающим выходные данные предыдущего этапа и записывающим следующие. Это дает нам то, что промежуточные результаты сохраняются на диске, где мы можем их прочитать, и если агент завершает работу, он может продолжить с того места, на котором остановился. Если этап оказывается безрезультатным или у агента заканчиваются токены, мы можем переписать этот этап, не затрагивая остальное. Эта простота сэкономила нам время, поскольку необходимость повторного запуска этапа возникала не раз.
Один из этих агентов — «Верификатор», который создан для того, чтобы подвергать все сомнению. Кандидат на ошибку не продвигается дальше только потому, что звучит правдоподобно. Другие агенты проверяют его под разными углами: действительно ли код ошибочен, может ли злоумышленник получить к нему доступ и создает ли это поведение значимое воздействие? Прохождение этих проверок — это этап квалификации, а не доказательство само по себе. Мы также проводим независимые исследования параллельно, чтобы сократить затраченное время, сохраняя при этом доказательства отдельно. Цель проста: меньше спекулятивных отчетов и более веские находки, на основе которых могут действовать продуктовые команды.
Конвейер Artemis: от поступления данных до поданного отчета
От нуля до результата: первая кампания Artemis
Достигнув этой точки, мы позволили конвейеру работать около недели. Результаты начали поступать рано, и мы вышли на поразительную цифру: 112 находок, из которых 93 были валидными, а остальные были отложены как дубликаты или недействительные. Для одной кампании, полностью прочитанной из исходного кода и подтвержденной на локальной копии стека, это было намного больше, чем мы ожидали, и это была только первая кампания. Artemis полностью эксплуатировала 80 из 93 валидных находок самостоятельно. Оставшиеся 13 были либо невозможны для прямой эксплуатации, либо требовали участия человека.
Двенадцать записей были дубликатами уже отслеживаемых находок, а семь были опровергнуты. Каждый отчет включал больше, чем просто автоматическое оповещение. Он объяснял механизм, предоставлял подтверждающие доказательства и указывал пределы того, что было продемонстрировано. Это была целевая кампания, а не эталонное тестирование против человеческой red team или заявление о полном покрытии. Это дало нам конкретную причину продолжать инвестировать в этот подход.
Что сделала сортировка со 112 находками: кампания Artemis 1
Если посмотреть на серьезность, результаты еще более поразительны: по оценке CVSS, Artemis нашла 4 критические, 23 высокие, 25 средних и 15 низких уязвимостей. И уязвимости сгруппировались именно там, где мы предсказывали: сначала авторизация, затем внедрение команд и IDOR.
Находки Artemis по уровню серьезности CVSS среди всех 93 валидных находок
Занимая место в очереди
Прохождение проверки верификатором — это еще не значит, что находка стоит потраченного времени инженера. Сначала должны произойти еще две вещи:
- Проверка того, известно ли нам уже об этой проблеме. Кандидаты сравниваются в режиме «только чтение» с существующими тикетами и предыдущими отчетами, чтобы отличить новые находки от дубликатов, связанных уязвимостей и регрессий. Дубликат не должен приводить к созданию нового тикета или требовать повторной работы по воспроизведению. Однако связанная находка или регрессия все же могут потребовать расследования. Такое разграничение позволяет поддерживать очередь в актуальном состоянии, не отбрасывая при этом новые доказательства.
- Проверка того, применима ли находка к развернутой системе. Мы повторно выводим расположение кода из символов, просматриваем всю цепочку промежуточного ПО и проверяем соответствующие доказательства развертывания и конфигурации. Уязвимость в исходном коде не всегда достижима в работающем сервисе, а локальное воспроизведение не является автоматическим доказательством влияния на продакшн. Каждый отчет должен четко отражать эти различия, включая любые оставшиеся предварительные условия или неопределенности.
Тикет составляется так, чтобы инженер мог начать работу с самой находки, а не повторять расследование. Он содержит трассировку потока данных, выполненные проверки, доказательства воспроизведения (если они есть) и простое описание того, что было продемонстрировано, а что — нет. Первопричина дает четкую цель для исправления, а ссылки на связанные проблемы обеспечивают контекст. Цель состоит в том, чтобы сократить путь от находки в безопасности до инженерного изменения.
От чтения к запуску
Агенты исследуют не все классы ошибок одинаково. Мы отдаем приоритет границам безопасности, которые важны для мультиарендной платформы: изоляция арендаторов, аутентификация, авторизация, подделка запросов на стороне сервера (SSRF), инъекции и непреднамеренное раскрытие секретов. Авторизации уделяется особое внимание, поскольку разделение действий и данных одного арендатора от другого является фундаментальным требованием нашего продукта.
Artemis разделяет чтение кода и тестирование потенциальной уязвимости. Сначала агенты анализируют исходный код и формируют гипотезу. Для выбранных гипотез они затем проверяют, можно ли воспроизвести поведение в авторизованной среде. Этот второй шаг называется динамическим тестированием. Он требует правильной области действия, фикстур и элементов управления.
Одна из вещей, которыми мы гордимся больше всего, — это воспроизводимая локальная среда, охватывающая основные части платформы RudderStack. Определенная как код, она дает нам контролируемое место для проверки уязвимого поведения с тестовыми данными и сбора доказательств воспроизведения. Мы можем протестировать находку, отправив входные данные в локальную копию, наблюдая, срабатывает ли ошибка, и фиксируя доказательство. Это позволяет избежать взаимодействия с «живой» системой или данными другого арендатора. Это превращает динамическое подтверждение из риска, который мы постоянно откладывали, в безопасное действие для каждой серьезной находки, и оно быстро становится мостом между тем, что читает Artemis, и тем, что мы можем доказать.
Модели и стоимость
Вопрос, который висит над любой подобной инициативой, — это стоимость, как денег, так и времени, и обычно предполагается, что она должна быть огромной. Это было то, к чему мы готовились больше всего, и это оказалось самым большим сюрпризом всей кампании.
Для первой кампании каждый инженер использовал аккаунт Anthropic Claude, аккредитованный в рамках программы Cyber Verification Program (CVP). В общей сложности кампания заняла не более одной недели использования двух подписок Claude Max. В денежном выражении это план за 200 долларов в месяц, распределенный на четыре недели, на двух человек, на одну неделю: (200 / 4) × 2, или около 100 долларов. Для первой кампании мы использовали Claude Opus 5 с разным уровнем усилий при аудите, проверке, валидации, работе над доказательством концепции и составлении отчетов. Позже мы использовали Opus 4.8, когда запросы к Anthropic стали деградировать после выпуска Opus 5.5.
С тех пор Artemis изменился. Теперь он использует Sol 6.1 для своих задач, за исключением работы над доказательством концепции, где используется DeepSeek V4.1 Flash.
Сто долларов и неделя практически автономных вычислений на 112 находок. Общая стоимость оказалась значительно ниже, чем мы ожидали, и она меркнет по сравнению с ценностью, которую приносит инициатива Artemis.
Пределы автоматизированного охотника
Если одно решение и сделало эту работу успешной, так это то, что мы сделали верификатор враждебным. Агент, который с радостью соглашается, что ошибка реальна, не избавляет вас от триажа. Он скрывает его, перекладывая принятие решения с человека, смотрящего в очередь, на модель, которую теперь вам приходится перепроверять. Единственная причина, по которой результат стоит времени инженера по безопасности, а не является еще одним потоком мусора, заключается в том, что каждая находка в нем выжила после атак агентов, созданных для ее уничтожения.
Обнадеживающая и разочаровывающая части — это один и тот же факт. Чтение кода через границы сервисов, как это было с находками по авторизации, выявляет вещи, которые пропускают инструменты, основанные на сигнатурах. Это также работает громче всего там, где это наиболее полезно. Все, что касается авторизации, создает больше всего шума, и в черновом запуске рецензент-человек нашел реальные ошибки, которые агенты прочитали и пропустили. Поэтому мы относимся к этому как к инструменту для генерации потенциальных проблем, а не как к чему-то, что дает окончательное заключение по сервису.
Что чаще всего сбивало нас с толку, так это не ложные срабатывания, а устаревший код. Экспорт поверхности привязывает каждый репозиторий к коммиту, и некоторые из этих коммитов были значительно старше того, что реально развернуто, а в эпоху ИИ, с CI/CD, код движется быстрее, чем когда-либо. Находка, указывающая на строку, которая с тех пор переместилась, выглядит в точности как галлюцинация, потому что кода, который она описывает, больше нет, хотя на самом деле ошибка существует, а указатель старый. Повторный вывод привязок из символов вместо номеров строк исправил больше неверных ответов, чем любое изменение промпта.
Нам также пришлось перестать доверять собственной системе оценки. Некоторое время мы оценивали конвейер по тому, может ли он повторно найти ошибки, которые мы взяли из истории, и он нашел их все, что было приятно, но ничего не доказывало; тест, который нельзя провалить, ничего не измеряет. Число, которое оказалось важным, было противоположным. Запустите конвейер против коммита, который исправил каждую известную ошибку, где правильным поведением является тишина, и посчитайте, как часто он все равно «поднимает руку». Это и есть уровень ложных срабатываний, и именно за ним мы теперь следим.
Наш первый подход к динамическому тестированию не сработал так, как планировалось. Мы намеревались подтвердить худшие находки в «живой» промежуточной среде (staging), но тестирование общей среды несло риски. В ранней попытке почти все находки не прошли проверку по экологическим причинам. Большинство из них были нацелены на код, который существовал только в открытых пулл-реквестах и не был развернут в staging. И когда мы наконец проверили наши собственные промпты на реальном потоке данных, мы обнаружили, что агенты все еще запрашивают поля, которых в потоке нет, и ни один из них не считывает сигнал о том, что код изменился. Модели работали нормально. Мы просто неправильно их подключили.
На данный момент честный вывод заключается в том, что Artemis находит реальные эксплуатируемые ошибки, иногда те, которые пропустили другие наши инструменты.
Что дальше
Artemis уже работает в изолированной среде и может подключаться к авторизованной среде — копии рабочей — для проведения учений red team. Мы хотим расширить охват, чтобы больше кандидатов могли перейти от анализа на уровне исходного кода к автоматизированному воспроизведению. Мы также стремимся к более четкой передаче доказательств командам, отвечающим за код, наряду с автоматизированным повторным тестированием результатов после того, как исправления попадают в новый релиз.
В долгосрочной перспективе мы хотим, чтобы Artemis исследовала новые изменения вскоре после их выпуска, а не дожидалась следующей кампании. Мы также планируем перезапускать проверки, когда новые модели привносят улучшения, связанные с безопасностью.
У нас есть база истинно положительных и ложноположительных результатов, привязанная к конкретным коммитам исходного кода, что позволяет нам быстро оценивать новые модели перед началом кампании.
