Компания Truffle Security обнаружила более полумиллиона учётных данных в общедоступных репозиториях GitHub, которые были действительны на момент проверки исследователями. Некоторые из них оставались активными более 16 лет.
Охранная компания просканировала The Stack v3 — большой набор общедоступных кодов, включающий 224 553 295 репозиториев GitHub и более 58,4 миллиарда файлов. Сканирование охватывает ветку по умолчанию каждого репозитория в том виде, в котором она была на момент закрытия набора данных 7 августа 2025 года.
27 и 28 июля 2026 года исследователи проверили обнаруженные учётные данные на соответствие сервисам, выдавшим их. Из них 543 699 уникальных учётных данных успешно прошли аутентификацию. По данным Truffle Security, в среднем раскрытые учетные данные находились в открытом коде 784 дня, а 10% из них — более 6,3 лет.
Самое старое рабочее учетное имя, обнаруженное исследователями, было создано в июне 2009 года. Это был набор учетных данных для доступа к базе данных, хранящийся в файле конфигурации веб-сервера Erlang, который оставался действительным спустя 16,1 года. Среди других сохранившихся примеров 2009 года — логин для FTP и ключ доступа к AWS.
The findings also show that GitHub’s push protection is helping, but only for the credential types it recognizes and blocks.
29 февраля 2024 года GitHub по умолчанию включил защиту от отправки изменений в публичные репозитории. По данным Truffle Security, за 12 месяцев, предшествовавших этому событию, количество поддерживаемых типов учетных данных, попадающих в публичный код, сократилось примерно на 53%.
Тем не менее 199 843 учетных данных, обнаруженных в ходе исследования, были зафиксированы после того, как защита от отправки изменений стала применяться по умолчанию.
Одна из причин — охват. По данным исследователей, 51,8% всех все еще активных учетных данных относились к типам, которые GitHub не блокирует по умолчанию, включая строки подключения к базам данных, закрытые ключи и ключи Google API.
Например, в ходе сканирования было обнаружено 51 067 активных строк подключения к MongoDB и 33 343 действующих ключа Google API. Также было выявлено 31 374 активных ключа Gemini API, при этом средняя дата утечки — февраль 2025 года.
Однако исследование указывает на то, что более серьезной проблемой является отзыв учетных данных.
Из 101 886 токенов npm, обнаруженных в наборе данных, только один оставался активным. Аналогичная ситуация наблюдалась с токенами GitHub: из 73 048 обнаруженных токенов 260 все еще работали, а из 30 437 токенов Hugging Face — только 15.
Учетные данные для доступа к базам данных сильно различались. Из 12 985 строк подключения к PostgreSQL 11 465 все еще были активны, что составляет 88 % выживаемости. Для MySQL 1806 из 2421 учетных данных оставались пригодными для использования, то есть около 75 %.
По мнению Truffle Security, во многом такая разница объясняется автоматическим отзывом. Такие провайдеры, как GitHub и npm, могут автоматически аннулировать скомпрометированные токены после их обнаружения. В отличие от них, у строк подключения к PostgreSQL обычно нет центрального эмитента, который мог бы отозвать их автоматически.
GitHub также реализует партнерскую программу по сканированию секретов, в рамках которой провайдеры могут получать уведомления о том, что их учетные данные появились в общедоступных репозиториях. Однако провайдеры не обязаны отзывать эти учетные данные после получения уведомления.
Исследователи утверждают, что предотвращение попадания секретов в репозиторий и их последующая отмена — это разные проблемы. Защита от отправки значительно снижает вероятность утечек, но не может отключить учетные данные, которые уже были раскрыты.
Судя по набору данных, реальное количество утекших учетных данных, скорее всего, превышает 543 699 подтвержденных в ходе исследования. Stack v3 включает только ветку по умолчанию на момент сканирования и не содержит удаленных коммитов, переписанной истории, отмененных секретов или учетных данных, хранящихся только в других ветках.
Рекомендация Truffle Security проста: если учетные данные были зафиксированы в публичном репозитории, их следует считать скомпрометированными и немедленно сменить. Разработчикам также следует проверять историю репозитория и, по возможности, отдавать предпочтение краткосрочным учетным данным с автоматическим истечением срока действия.
Источник: Truffle Security
