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