Google подняла максимальную выплату в своей программе поиска уязвимостей для облака до $250 тыс. — за Root-in-Cloud уязвимости, позволяющие получить полный административный контроль над чужими организациями или проектами Google Cloud. Для команд, использующих публичное облако, новость важна не размером чека: компания отдельно выделила ошибки, которые ломают границы между арендаторами и сервисами.
Новая категория появилась в Cloud Vulnerability Reward Program в ноябре. Как сообщает BleepingComputer, премия предназначена для исследователей, способных доказать захват прав уровня roles/owner либо полный контроль IAM над произвольным проектом или организацией без исходного доступа и специальной подготовки целевой среды.
Под определение Root-in-Cloud уязвимости попадают, в частности, обходы изоляции между арендаторами и сложные логические ошибки на стыке облачных сервисов. Речь не о типичной проблеме в одном веб-приложении и не о случайно опубликованном ключе доступа. Исследователь должен показать, что недостаток архитектуры Google Cloud позволяет перейти от отсутствия прав к полномочиям, с которыми можно управлять ресурсами клиента, политиками доступа и конфигурацией проекта.
Порог намеренно высокий. Крис Бетц, CISO Google Cloud, пояснил, что для максимальной выплаты нужно продемонстрировать административный контроль над произвольными организациями или проектами. Эксплойт не должен опираться на уже скомпрометированные учётные данные, предварительный доступ к проекту жертвы, социальную инженерию, действия пользователя или нестандартную подготовку конкретного проекта. Иными словами, Google ищет неудачную настройку клиента, а воспроизводимый дефект в собственной платформе.
Отдельно в правилах оговорён путь через производственную инфраструктуру Google. Если исследователь получил удалённое выполнение кода в Borg — внутренней системе оркестрации, на которой работает производственная инфраструктура компании, — либо достиг состояния root-in-prod, его отчёт автоматически рассмотрит комиссия Cloud VRP на соответствие новому уровню награды. Но здесь действует жёсткое ограничение: после получения исполнения нельзя развивать атаку, добывать производственные учётные данные или перемещаться по инфраструктуре. Такие действия приведут к дисквалификации.
Доказать захват, не трогая клиентов
Главная практическая деталь программы — механизм безопасного доказательства. Google не предлагает исследователям проверять находку на реальных клиентских проектах, что при таком классе ошибок было бы слишком похоже на несанкционированный доступ. Вместо этого компания подготовила выделенный сервисный аккаунт: исследователь должен криптографически подтвердить, что получил к нему неразрешённый доступ. По словам руководителя Cloud VRP Майкла Коте, этот сценарий делает проверку результата детерминированной и убирает необходимость экспериментировать с чужими данными.
Для bug bounty это важная смена акцента. Уязвимость в облаке редко укладывается в схему «отправил один запрос — получил секрет». Часто она возникает в цепочке из разрешений, API, сервисных идентичностей, сетевых политик и неочевидной логики передачи полномочий. Чем глубже проблема затрагивает общую инфраструктуру, тем сложнее исследователю доказать её воздействие и тем выше риск задеть других пользователей платформы. Google пытается купить именно такие исследования, одновременно задав довольно узкий коридор допустимых действий.
Для разработчиков и DevOps-инженеров это не повод срочно менять настройки Google Cloud: объявление не описывает конкретную уязвимость и не содержит индикаторов компрометации. Зато оно хорошо показывает, какие сценарии облачный провайдер считает наиболее опасными. Организациям по-прежнему стоит исходить из того, что ошибки в IAM и чрезмерные права сервисных аккаунтов остаются собственной зоной ответственности клиента. Программа вознаграждает дефекты платформы, но не отменяет принцип минимальных привилегий, ревизию ролей и разделение сред.
Для CISO и руководителей разработки сигнал ещё прозаичнее: модель безопасности облака не заканчивается на настройке VPN и включённом MFA. Современный облачный ландшафт держится на доверии к механизмам изоляции и авторизации провайдера. Если в них находится архитектурный сбой, последствия могут выходить далеко за пределы одного аккаунта. Поэтому публичная готовность платить $250 тыс. за такие находки — одновременно стимул для независимых исследователей и признание того, что классы межсервисных ошибок требуют отдельного внимания.
Награды растут, а поток отчётов приходится фильтровать
Расширение Cloud VRP происходит на фоне неоднозначной ситуации с программами Google по поиску багов. В октябре компания приостановила приём отчётов в Open Source Software Vulnerability Rewards Program после наплыва заявок, сгенерированных ИИ. Проблема не в самом использовании моделей для анализа кода, а в потоке слабых, непроверенных сообщений, которые занимают время триаж-команд. Новая облачная награда устроена противоположным образом: требования к эффекту, воспроизводимости и безопасному доказательству максимально конкретны.
Google развивает программы вознаграждений с 2010 года. За это время компания выплатила исследователям по всему миру свыше $81,6 млн. В 2025 году выплаты достигли рекордных $17,1 млн и достались более чем 700 специалистам; это на 40% больше, чем $12 млн годом ранее. На этом фоне отдельный потолок в $250 тыс. выглядит не маркетинговым жестом, а попыткой привлечь специалистов, способных месяцами разбирать пограничные случаи в сложной облачной архитектуре.
Следующий вопрос — станет ли безопасный механизм доказательства отраслевым шаблоном. Чем больше критических систем работают в общих облаках, тем менее приемлема старая логика «покажите эксплуатацию на реальной цели». Если крупные провайдеры научатся давать исследователям проверяемый способ доказать захват без доступа к данным клиентов, рынок bug bounty сможет охотнее платить за самые опасные классы ошибок — и реже превращать их проверку в инцидент.
