В публичных репозиториях GitLab Cloud обнаружено масштабное количество утекших учетных данных и API‑ключей. Анализ 5,6 млн открытых проектов показал, что тысячи действующих секретов — от токенов облачных платформ до ключей ботов и баз данных — продолжают находиться в свободном доступе и могут быть использованы злоумышленниками для атак на инфраструктуру компаний.
Масштаб проблемы: 17 430 «живых» секретов в GitLab Cloud
В ходе исследования было проанализировано 5,6 млн публичных репозиториев GitLab Cloud. В результате обнаружено 17 430 подтвержденных, все еще действующих секретов, принадлежащих более чем 2800 уникальным доменам. Под «секретами» подразумеваются API‑ключи, пароли, токены доступа к сервисам и другие чувствительные данные, которые должны храниться только в защищенных хранилищах.
По сравнению с аналогичным анализом Bitbucket (2,6 млн репозиториев и 6212 найденных секретов) утечка в GitLab оказалась значительно масштабнее. Плотность утечек — количество секретов на один репозиторий — в GitLab примерно на 35% выше, что указывает на более серьезную проблему управления секретами в экосистеме этой платформы.
Как проводилось сканирование GitLab: TruffleHog и AWS-автоматизация
Для поиска секретов использовался специализированный опенсорс‑инструмент TruffleHog, предназначенный для обнаружения ключей, паролей и токенов в Git‑истории и содержимом файлов. Чтобы обработать миллионы репозиториев GitLab, была развернута полностью автоматизированная облачная инфраструктура.
Архитектура исследования
С помощью публичного API GitLab Python‑скрипт поочередно перебирал все проекты, сортируя их по идентификатору (ID) и отправляя очередь задач в AWS Simple Queue Service (SQS). Далее для каждого репозитория автоматически запускалась функция AWS Lambda, которая вызывала TruffleHog, выполняла сканирование и фиксировала результаты в логах.
Полное сканирование заняло немногим более суток и обошлось в около 770 долларов США вычислительных затрат. Такой подход показывает, что массовый анализ репозиториев на предмет утечек секретов давно уже не является задачей, доступной только крупным государственным структурам: его может выполнить любой мотивированный исследователь — и, что важно, злоумышленник.
Какие секреты оказались под угрозой
Большинство обнаруженных секретов относятся к относительно недавнему периоду — начиная с 2018 года. Однако в репозиториях были найдены и ключи 2009 года выпуска, которые до сих пор оставались валидными. Это особенно опасно, поскольку такие данные часто связаны с «легаси»-системами, которые редко мониторятся и хуже защищены.
Наиболее часто раскрываемые данные
Анализ показал, что чаще всего разработчики случайно публиковали учетные данные Google Cloud Platform (GCP) — более 5200 случаев. Помимо GCP, в открытом доступе оказались:
— ключи и строки подключения MongoDB;
— токены для Telegram‑ботов;
— ключи доступа к OpenAI и другим AI‑платформам;
— свыше 400 секретов, относящихся непосредственно к сервисам GitLab.
Комбинация таких данных нередко достаточна для полного компрометации инфраструктуры: от несанкционированного доступа к базам данных и облачным ресурсам до рассылки фишинговых сообщений через легитимных ботов и сервисы.
Реакция компаний и роль bug bounty‑программ
Из-за того что найденные секреты были связаны с 2804 уникальными доменами, вручную уведомить всех владельцев оказалось практически невозможно. Для автоматизации были использованы web‑поиск, Python‑скрипты и генерация уведомлений с помощью языковой модели Claude Sonnet 3.7.
Многие организации после уведомления оперативно отозвали раскрытые ключи и заменили их новыми. Часть инцидентов была оформлена в рамках bug bounty‑программ, что принесло исследователю суммарно около 9000 долларов США вознаграждений. Однако значительная доля секретов по-прежнему доступна в публичных репозиториях, что подчеркивает системный характер проблемы.
Что должны сделать компании и разработчики
Массовая утечка секретов из GitLab и других платформ (Bitbucket, публичные датасеты вроде Common Crawl, ранее также сканировавшиеся исследователями) показывает, что проблема носит не столько технический, сколько организационный характер. Основные принципы снижения риска можно сформулировать следующим образом:
1. Запрет хранения секретов в репозиториях кода. Использовать менеджеры секретов (например, секретные хранилища облачных провайдеров, HashiCorp Vault и аналоги), а в репозитории помещать только ссылки и идентификаторы.
2. Автоматическое сканирование репозиториев. Интегрировать инструменты наподобие TruffleHog, Gitleaks и аналогичных решений в CI/CD‑конвейеры, чтобы любой коммит автоматически проверялся на наличие ключей и токенов до слияния в основную ветку.
3. Регулярная ротация ключей и токенов. Даже если секрет случайно попал в историю Git, его воздействие ограничивается сроком действия. Политика короткоживущих токенов и автоматической ротации существенно сокращает возможный ущерб.
4. Обучение разработчиков безопасным практикам. Ошибки часто связаны с быстрыми экспериментами, отладкой или временными «заглушками». Важно доносить до команд, что публичный репозиторий — не место для тестовых ключей, а приватный репозиторий также не гарантирует безопасность в случае компрометации аккаунта.
Продемонстрированное исследованием состояние безопасности публичных репозиториев GitLab ясно показывает: управление секретами должно стать приоритетным направлением для любой команды разработки. Компании, использующие облачные сервисы, базы данных и сторонние API, обязаны регулярно пересматривать процессы DevOps и DevSecOps, внедрять автоматизированное сканирование кода и отработанные процедуры отзыва ключей. Чем раньше такие меры будут приняты, тем ниже вероятность того, что следующий публичный отчет об утечке секретов будет касаться именно их инфраструктуры.
