Утечки ключей API в публичном коде Gitee оказались не архивной проблемой: исследователь Бен Циммерманн обнаружил 26 400 учётных данных, которые продолжали работать на момент проверки. Для российских команд, использующих облака, внешние API и ИИ-модели, вывод неприятно прямой: удалённый из файла секрет не становится безопасным, если он уже попал в историю Git.
Циммерманн просканировал 7,25 млн публичных репозиториев китайского хостинга исходного кода Gitee. Проверка заняла около месяца, а о результатах он сообщил 28 октября; по данным The Hacker News, исследователь применил два сканера секретов — TruffleHog и Kingfisher. Инструменты не просто искали строки, похожие на токены: они пытались проверить найденные учётные данные у соответствующих сервисов и учитывали только действующие.
Крупнейшая группа находок — 9 473 пары Alibaba Cloud AccessKey. Далее идут 3 805 ключей YouTube API, 3 170 ключей DeepSeek, 1 489 ключей платформы BigModel компании Zhipu и 1 348 ключей OpenAI. В меньшем количестве встречались секреты GitHub, AWS, Google Cloud и Gemini. Отдельно исследователь упомянул активные права администратора организации в крупной корпоративной ИИ-платформе, не назвав ни сам сервис, ни доступный владельцу токена объём полномочий.
Это не означает, что все 26 400 ключей уже были использованы злоумышленниками: Циммерманн не исследовал историю злоупотреблений. Неизвестно и то, в какие именно даты проводилась валидация. Но риск от этого не становится теоретическим. Рабочий ключ OpenAI позволяет постороннему расходовать лимиты владельца, создавать неожиданные расходы и лишить команду доступа к API в самый неподходящий момент. Неразграниченный ключ Google Cloud или YouTube API может работать с любым совместимым API проекта, а облачный AccessKey способен открыть путь к ресурсам, данным и операциям, которые разработчик вообще не планировал отдавать наружу.
Важная деталь исследования — сканеры читали полную историю коммитов. То есть секрет мог давно исчезнуть из актуальной версии приложения, но остаться в старом коммите, форке или ветке. Всего 12 242 действующих учётных данных были привязаны к коммитам 2025 года — почти половина массива. Встречались и значительно более старые секреты, датированные концом 2000-х. Git помнит дольше, чем многие процессы реагирования на инциденты.
Авторы проверки передали списки поставщикам сервисов с наибольшим числом найденных ключей, но не связывались с разработчиками, которые их опубликовали. На момент публикации не было подтверждения, что поставщики уже отозвали все скомпрометированные данные. Поэтому любой ключ, когда-либо попавший в публичный репозиторий Gitee, разумно считать раскрытым — даже если код затем подчистили, а репозиторий переписали.
Один сканер — это не контроль
Проверка показала ещё одну проблему, которую легко недооценить при настройке DevSecOps. TruffleHog обнаружил 12 737 действующих учётных данных, Kingfisher — 14 664, однако оба инструмента одновременно нашли лишь 1 001 секрет. Каждый в одиночку увидел примерно половину итогового набора. TruffleHog нашёл почти все пары Alibaba Cloud, тогда как Kingfisher обнаружил все 1 489 ключей BigModel: у TruffleHog нет детектора для ключей Zhipu.
Для команды это означает, что формальная галочка «secret scanning включён» мало что говорит о фактическом покрытии. Нужно сверять набор детекторов с реальными зависимостями продукта: облачными аккаунтами, LLM-провайдерами, CI/CD, картографическими, платёжными и аналитическими API. Особенно это актуально для компаний, которые быстро добавляют ИИ-сервисы в прототипы и внутренние инструменты: ключ сначала оказывается в локальном .env, затем в тестовом скрипте, потом в коммите «на пять минут» — и становится частью истории проекта.
Сравнивать Gitee с другими хостингами по этой работе пока рано. Общий показатель составил 3,64 рабочего секрета на тысячу проверенных репозиториев — выше, чем в прежних сканированиях GitLab с 3,11 и Bitbucket с 2,39. Однако предыдущие исследования использовали только TruffleHog. Если считать для Gitee лишь его результаты, получается 1,76 на тысячу репозиториев, но тогда из анализа выпадают сервисы без поддерживаемых детекторов, включая Zhipu. Цифры скорее измеряют инструменты и наборы поддерживаемых платформ, чем дисциплину разработчиков на разных сайтах.
Что проверить до следующего коммита
Практический план при подозрении на утечки ключей API прост, хотя и не всегда приятен. Сначала отзовите старый секрет у провайдера и выпустите новый; затем обновите переменные окружения, секрет-хранилища, CI/CD и приложения. Для Alibaba Cloud рекомендуется создать новую пару AccessKey, перевести на неё приложения, отключить и удалить старую. После этого нужно проверить расходы, созданные или удалённые ресурсы и вызовы API в ActionTrail за доступные 90 дней; операции с данными в OSS и SLS придётся искать в журналах самих сервисов.
Для Google и YouTube API ключ следует ротировать, обновить приложения и удалить прежний, а затем ограничить его только необходимыми API. Владельцам ключей OpenAI стоит немедленно выполнить ротацию в панели API Keys и задать лимиты расходов. Наконец, необходимо проверить не только текущую ветку, но и всю историю репозитория, форки, примеры конфигураций, CI-логи и артефакты сборок. Переписывание истории может убрать секрет из удобного просмотра, но не отменяет уже случившуюся компрометацию.
История с Gitee не про экзотический китайский сервис, а про старую инженерную привычку считать ключ короткой строкой, а не доступом к деньгам и данным. Чем больше облачных и ИИ-провайдеров появляется в стеке, тем дороже обходится эта привычка: следующий инцидент может начаться не со сложной атаки, а с одного токена, оставленного в коммите ради скорости.
