Утечка секретов на GitHub: 844 МБ CISA и ваши репо

Последние два года я встраиваю сканирование публичных репозиториев в recon-фазу каждого внешнего пентеста. TruffleHog запускается раньше Nmap - и это не фигура речи: секреты утекают обычным коммитом. Когда в публичных репозиториях CISA - агентства, которое само пишет стандарты кибербезопасности США - предположительно нашли 844 МБ данных с конфигурациями и скриптами (точные детали инцидента требуют независимой верификации), никто в индустрии не удивился. По отчёту GitGuardian State of Secrets Sprawl (данные за 2025 год, требуют независимой верификации), за один 2024-й на публичном GitHub обнаружено порядка 23,8 миллиона утёкших секретов. Около 70% тех, что попали в открытый доступ ещё в 2022-м, предположительно до сих пор активны. Два года - а ключи работают.

Утечка CISA на GitHub и масштаб проблемы​

CISA (Cybersecurity and Infrastructure Security Agency) - федеральное агентство, которое само выпускает рекомендации по управлению credentials и защите кода. Сообщения о появлении 844 МБ их данных в публичных репозиториях (детали инцидента требуют независимой верификации) - кейс показательный не содержимым, а контекстом: если организация такого уровня допускает credential exposure, проблема утечки секретов на GitHub - системная.

Что обычно валяется в подобных утечках из государственных и корпоративных репозиториев:

• Конфигурации IaC (Terraform, CloudFormation) с hardcoded secrets - ключами к облачным сервисам и connection strings к базам
• Скрипты деплоя с токенами CI/CD (GitHub Actions, Jenkins API tokens)
• Файлы .env и .config, не попавшие в .gitignore
• Jupyter Notebook с API-ключами к облачным платформам и ML-сервисам - по данным GitGuardian, notebooks и Python-скрипты лидируют по частоте утечек среди AI-компаний
• SSH-ключи и сертификаты, захваченные git add .

Масштаб растёт каждый год. По данным GitGuardian, число обнаруженных секретов достигает десятков миллионов в год. GitHub со своей стороны фиксирует десятки миллионов детектированных секретов в репозиториях на платформе. А honeytokens (поддельные ключи для мониторинга) проверяются ботами на валидность в течение минуты после публикации. Минуты - не часа.

Отдельный вектор - использование GitHub как канала эксфильтрации. По публикации StepSecurity, червь Sha1-Hulud предположительно экспортировал украденные credentials в виде JSON-блобов в свежесозданные публичные репозитории: по оценкам, тысячи таких репо появились за несколько часов. Это значит, что поиск секретов в публичных репозиториях - не только recon по целевой организации, но и мониторинг появления ваших собственных ключей в чужих репо.

Как hardcoded secrets попадают в публичные репозитории​

Каналов несколько, и каждый формирует отдельную поверхность атаки.

Прямой коммит. Разработчик пишет const API_KEY = "AKIA...", пушит в публичный репозиторий. Файл удалён следующим коммитом через тридцать секунд - а в git history секрет остаётся навсегда, пока историю не перезапишут принудительно.

Иллюзия force-push. git push --force после очистки истории не решает проблему полностью. Reflog на стороне сервера может хранить старые объекты, а клоны и форки, созданные до force-push, содержат оригинальную историю с секретом. На пентесте я всегда проверяю существующие форки целевого репозитория - разработчики часто забывают, что форк сделан коллегой до ротации ключей.

Форки как архив утечек. При форке создаётся полная копия с историей. Секрет, удалённый из оригинала после форка, живёт в каждой копии. Для пентестера: проверяем не только основной репозиторий, но и все его форки через GitHub API.

CI/CD логи и секреты второго порядка. Платформы CI/CD пытаются маскировать секреты в выводе, но обходятся элементарно. echo "$SECRET" | rev в CI-платформах выводит токен задом наперёд - мимо маскировки. Кодирование секрета в base64 перед сохранением в переменную окружения - тоже потенциальный обход: раскодированное значение не совпадает с исходным, и ряд CI-платформ его не замаскирует. GitHub Actions с 2022–2023 года частично детектирует base64/hex-кодированные формы секретов в логах, но большинство платформ не анализирует произвольные трансформации вроде rev - это рабочий обход и в 2025 году. TruffleHog, в отличие от них, автоматически раскодирует base64 в процессе сканирования.

Артефакты сборки. Build-артефакты в GitHub Releases или доступные через CI могут содержать конфигурации с API ключами в открытом доступе - credentials, не вычищенные из финального билда. Это так называемые секреты второго порядка: платформа не знает об их существовании и не маскирует.

Сканирование репозиториев на секреты: TruffleHog и Gitleaks​

. На выходе - JSON с находками: тип секрета, файл, строка, хеш коммита.

Главная сила Gitleaks для пентестера - кастомные правила. Если в recon-фазе удалось определить формат внутренних токенов целевой организации (из документации, error messages, утёкших конфигов), пишем правило в .gitleaks.toml:
Такой подход даёт находки, которые ни TruffleHog, ни GitGuardian не обнаружат - формат специфичен для конкретной организации. На одном проекте кастомное правило для внутренних JWT-токенов клиента дало три верифицированных credential exposure, которые стандартные детекторы пропустили. Три ключа - мимо 800 детекторов.

TruffleHog и Gitleaks - сравнение инструментов для пентестера​

На практике оптимальная связка: Gitleaks для быстрого первичного прогона с кастомными паттернами под конкретную цель, TruffleHog с --only-verified для финального отчёта с подтверждёнными находками. Первый даёт скорость и гибкость, второй - уверенность.

GitGuardian занимает отдельную нишу - коммерческая платформа мониторинга утечек с 550+ детекторами, ML-компонентом для снижения ложных срабатываний и сканированием публичного GitHub за 6–8 лет истории. Для пентестера GitGuardian - не offensive-инструмент, а индикатор: если целевая организация его использует, часть находок в публичных репо уже могла быть обнаружена и ротирована. Впрочем, по данным того же GitGuardian, 70% секретов остаются активными годами - так что рассчитывать на ротацию я бы не стал.

Поиск API ключей в открытом доступе: валидация находок​

Сканер показал строку AKIA + 16 символов в истории коммитов. Это живой AWS-ключ или пример из README? Валидация - этап, который отделяет полезный аудит безопасности репозитория от потока шума.

Контекст файла. Секрет в test/mock_config.py или example.env.template - с высокой вероятностью тестовый. Секрет в deploy/production.sh или .github/workflows/deploy.yml - кандидат на проверку. Команда git log -S "AKIA" --all покажет, в каком коммите секрет появился и кто его добавил - это помогает оценить, production это или dev-среда.

Энтропия строки. Реальные сгенерированные ключи имеют Shannon entropy > 4.5 для строк длиной 20+. Значения вроде mysecretpassword123 - низкая энтропия, скорее всего placeholder. TruffleHog считает энтропию автоматически, Gitleaks - через настраиваемый порог в конфиге.

Формат провайдера. AWS Access Key ID: AKIA + 16 alphanumeric. GitHub PAT: ghp_ + base62. Slack bot token: xoxb-. Совпадение с документированным форматом - сильный сигнал. Если паттерн не совпадает ни с одним известным провайдером, но энтропия высокая - проверяем контекстно.

Верификация без побочных эффектов. Для AWS ключей - [URL='https://docs.aws.amazon.com/STS/latest/APIReference/API_GetCallerIdentity.html']sts:GetCallerIdentity[/URL] через AWS CLI: aws sts get-caller-identity --access-key-id AKIA... --secret-access-key .... Для GitHub-токенов - curl -H "Authorization: token ghp_..." https://api.github.com/user. Оба запроса read-only и не оставляют следов в целевой инфраструктуре.

OPSEC на пентесте. Разница между «проверил валидность ключа через GetCallerIdentity» и «использовал ключ для листинга S3-бакетов» - это разница между разведкой в скоупе и потенциальным нарушением scope of work. Каждый шаг валидации документируем до его выполнения. Если scope не покрывает использование найденных credentials - фиксируете находку как unverified и согласовываете расширение скоупа с заказчиком. Без согласования - ни шагу дальше.

Предотвращение утечки credentials и мониторинг​

Offensive-знание конвертируется в рекомендации по защите. Вот что стоит включить в отчёт после аудита.

Pre-commit hooks. Последний рубеж перед попаданием секрета в историю. И TruffleHog, и Gitleaks поддерживают интеграцию через pre-commit framework:
После pre-commit install каждый git commit проходит проверку. Ограничение: разработчик может обойти хук через [URL='https://git-scm.com/docs/git-commit']git commit --no-verify[/URL] - поэтому pre-commit нельзя рассматривать как единственную линию защиты. Это скорее напоминалка, а не забор.

Push protection на стороне GitHub. Встроенная push protection блокирует пуш с обнаруженными секретами до того, как они попадут в репозиторий. Покрытие - 160+ типов секретов, по документации GitHub. Платформа автоматически отзывает собственные GitHub PAT, обнаруженные в публичных репозиториях, а для токенов сторонних сервисов - уведомляет их провайдеров через партнёрскую программу (secret scanning partner program), и решение об отзыве принимает сам провайдер.

CI-пайплайн как страховочная сеть. Запуск Gitleaks или TruffleHog как шага в CI гарантирует, что ни один PR с секретом не пройдёт merge, даже если разработчик обошёл pre-commit. Неудавшийся scan ставит обязательный status check - без ручного вмешательства секрет в main-ветку не попадёт.

GitGuardian мониторинг утечек для организаций. Для компаний с десятками или сотнями репозиториев непрерывный мониторинг через GitGuardian покрывает не только собственные репо, но и публичный GitHub, где могут всплыть секреты из форков и вкладов сотрудников в open source. GitHub, по ряду публикаций, тоже предлагает возможности мониторинга утечек секретов enterprise-организации за пределами принадлежащих ей репозиториев (точное название и охват функции - в актуальной документации GitHub).

Скорость реакции - критический фактор. Honeytokens проверяются ботами в течение минуты. Окно между утечкой и эксплуатацией измеряется минутами, не часами. Автоматическая ротация при обнаружении - не рекомендация, а необходимость. Организации, серьёзно подходящие к проблеме, переходят от долгоживущих статических ключей к short-lived tokens (AWS STS, GCP Workload Identity Federation), где credential живёт секунды и привязан к конкретному workload.

Разговоры про утечку секретов на GitHub обычно сводятся к выбору сканера: TruffleHog или Gitleaks, 800 детекторов или 140, верификация или скорость. Инструменты решают симптом, но не причину. Корневая проблема - секреты до сих пор существуют как статические строки, которые разработчик видит глазами и может скопировать в код. Пока API-ключ - это текст, а не ephemeral token, привязанный к workload, утечки будут продолжаться при любом сканере в CI.

В 2022 году 70% утёкших секретов оставались активными. Два года спустя принципиально ничего не изменилось - не потому что нет инструментов, а потому что ротация и управление жизненным циклом credentials как процесс мало кем выстроены. Кейс CISA на 844 МБ - не аномалия, а норма. Единственное отличие - масштаб внимания прессы. Если хочешь потренировать сбор и эксплуатацию credentials из репозиториев в контролируемой среде - задачи из категорий web и forensics на HackerLab.pro дают как раз этот формат.