Google Cloud Build является одной из ведущих серверлес-платформ для непрерывной интеграции и непрерывного развертывания (CI/CD), обеспечивая автоматизированные процессы сборки и тестирования программного обеспечения. Интеграция с GitHub — ключевая часть экосистемы Cloud Build, позволяющая запускать сборки на основе событий в репозиториях, таких как создание или обновление pull request (PR). Однако в июле 2025 года была обнаружена и задокументирована критическая уязвимость, связанная с контролем запуска сборок через комментарии к pull request, вознаграждённая Google в размере $30,000. Этот инцидент открыл важные вопросы безопасности в области взаимодействия CI/CD-систем с системами управления исходным кодом и подчеркнул необходимость глубокого понимания архитектуры этих интеграций для предотвращения злоупотреблений. Для начала стоит понимать, что Google Cloud Build предназначен для автоматизации процессов сборки и развертывания, тесно взаимодействуя с репозиториями исходного кода.
Пользователи могут настроить триггеры, которые запускают сборку на основе определённых событий — например, создание или обновление pull request. Однако, поскольку сборки могут иметь доступ к привилегиям, секретам и ресурсам, контроль за тем, кто и как может инициировать запуск сборок, крайне важен для предотвращения атак, связанных с повышением привилегий или внедрением вредоносного кода. Для уменьшения рисков был введён механизм «контроля комментариев». Суть его заключается в том, что если автор pull request не обладает правами записи в основной репозиторий, запуск сборки может быть инициирован только после того, как владелец или другой участник с правами записи оставит специальный комментарий, например, /gcbrun. Такая мера необходима для того, чтобы поддерживать контроль над тем, какие изменения оказываются в CI/CD пайплайне, и предотвратить так называемые атаки «отравленной сборки», когда злоумышленник пытается внедрить вредоносный код именно на этапе выполнения сборки.
Однако исследователь безопасности Аднан Хан обнаружил, что в реализации этого контроля существует то, что в области информационной безопасности принято называть уязвимостью типа TOCTOU (Time-of-Check to Time-of-Use) — гонкой между временем проверки и временем использования. В контексте Google Cloud Build это означало, что после того как владелец репозитория оставлял команду для запуска сборки, система извлекала актуальный SHA коммита напрямую из GitHub. Если в этот короткий промежуток времени автор pull request успевал внести новый коммит, сборка запускалась уже на базе этого изменённого кода, который владелец мог не видеть и, следовательно, не проверить. Такая ситуация открывала путь для злоумышленников: достаточно было убедить владельца оставить комментарий запуска сборки, сразу после чего мгновенно внести вредоносные изменения в пулл-реквест. В результате сборка выполнялась с контентом, который не был одобрен, а значит, мог содержать вредоносный код, красть секреты или выполнять другие нежелательные действия с теми привилегиями, которые были настроены для пайплайна.
Для демонстрации этой уязвимости использовалось несколько технических приёмов. Ключевой составляющей являлся скрипт, который с высокой частотой — примерно каждые 200 миллисекунд — проверял наличие триггерного комментария /gcbrun в pull request. Как только комментарий появлялся, скрипт моментально создавал и коммитил вредоносный cloudbuild.yaml в ветку с изменениями, на которую была направлена сборка. Таким образом, успевали выиграть гонку по времени: сборка начиналась на новом SHA, который только что был отправлен, минуя человеческий контроль.
Для понимания масштабности проблемы важно учитывать особенности работы pull request в GitHub. Pull request состоит из двух веток: основной (target) и источника (head). В случае публичных репозиториев любой разработчик может форкнуть проект и сделать pull request, не обладая правами записи в основной репозиторий. Контроль по комментариям как раз предназначен для таких случаев. Однако внутренняя схема безопасности GitHub и способы обработки webhook-событий создают сложные условия и увеличивают риск подобных атак из-за отсутствия надёжного и неизменного идентификатора коммита в событиях комментариев.
Google оперативно отреагировала на сообщение о баге, реализовав несколько ключевых изменений в поведении Cloud Build. Во-первых, была введена задержка в 5 секунд после появления нового коммита до того, как на него можно будет запустить сборку через комментарий. Это позволило избежать ситуации, когда комментарий и новый коммит появляются почти одновременно и запускают сборку на неожиданном коде. Во-вторых, если после комментария поддерживающего запуска сборки был отправлен новый коммит, Cloud Build просит пользователя явно указать полный SHA коммита, который необходимо использовать для сборки. Такой подход заставляет вручную выбирать конкретный, проверенный и зафиксированный код, что минимизирует возможность злоупотребления гонкой условий.
Дополнительно, Google проверила способы обхода исправления: попытки использовать подпись времени коммитов с точностью до секунды или подделывать commit timestamp не приводили к успешному эксплойту. Это говорит о продуманности решения и комплексном подходе к устранению уязвимости. Этот кейс подчёркивает важность глубокого понимания взаимодействия сложных систем. Интеграция между GitHub и Google Cloud Build требует не просто упрощённого контроля, а учёта особенностей обработки событий, временных меток и асинхронности. Каждый элемент интеграционной цепочки играет роль в безопасности и должен рассматриваться не изолированно, а как часть общей архитектуры.
Проблемы Time-of-Check to Time-of-Use характерны для многих систем, особенно где скорость и асинхронность влияют на принятие решений о безопасности. Это ещё раз напоминает разработчикам о необходимости связывать действия с неизменяемыми, детерминированными идентификаторами, такими как конкретные commit SHA, и минимизировать задержки между проверкой прав и выполнением операций. Преимущество данного инцидента для сообщества безопасности и разработчиков состоит не только в устранении конкретной уязвимости, но и в открытом обсуждении и демонстрации улучшений в режиме CI/CD. Он стал важным уроком, как человеческий фактор, технические ограничения в API и особенности систем могут привести к сложным для обнаружения проблемам безопасности. Для разработчиков и команд, использующих интеграции с GitHub, важно внимательно настраивать уровни доступа и особенности триггеров сборок.
Наличие функций вроде контроля комментариев следует рассматривать лишь как часть многоуровневой стратегии безопасности, а не как панацею. Необходимо тестировать новые механизмы с учётом временных условий и потенциальных гонок, а также стараться предоставлять пользователям прозрачность и инструменты для оценки актуального состояния сборки. В конечном итоге история с уязвимостью в Google Cloud Build — это пример того, как небольшая деталь в логике работы системы может стать входной точкой для масштабных атак, если не учесть все нюансы безопасности. В то же время она служит демонстрацией высокой ответственности крупных технологических компаний в области быстрого исправления багов и сотрудничества с исследователями безопасности, что обеспечивает более надёжную и безопасную среду для миллионов разработчиков по всему миру.
