В публичных репозиториях GitHub нашли 543 тысячи действующих секретов

12 октября 2026 года, как пишет Хабр, Truffle Security представила результаты анализа публичных репозиториев GitHub. Аналитики изучили 224 млн репозиториев и 58 млрд файлов и обнаружили 543 тысячи токенов, ключей и паролей, которые продолжают использоваться. Исследование показывает не только масштаб публикации секретов в коде, но и то, как долго они могут оставаться в открытом доступе.

Секреты остаются открытыми годами

В среднем найденные данные находились в публичном доступе 784 дня. Самые старые обнаруженные ключи, которые всё ещё действовали, датировались 2009 годом. Иными словами, давняя публикация не обязательно становится безобидной со временем: имеет значение, был ли прекращён доступ по опубликованным данным.

Доля действующих данных сильно различалась в зависимости от сервиса. Среди 101 886 найденных токенов NPM действующим оказался только один — около 0,001%. Для GitHub результат составил 260 из 73 048 токенов, или 0,35%. Среди 30 437 токенов Hugging Face действовали 15 — примерно 0,05%.

У данных для подключения к PostgreSQL соотношение оказалось другим: активными оставались 11 465 из 12 985, или 88%. Для MySQL исследователи указали долю 74%. У Google Cloud действовали 69 041 из 126 963 найденных данных — 54%; у SendGrid — 9 189 из 22 800, или 40%; у Docker Hub — 1 244 из 3 790, или 33%.

Разница между этими показателями важна для оценки результатов. Большое количество найденных токенов само по себе не говорит, сколько из них ещё действует. Но и низкую долю действующих токенов одного сервиса нельзя переносить на доступы к другому: в опубликованных данных для подключения к PostgreSQL исследователи увидели совсем иную картину.

Что пропустила блокировка при отправке кода

Около 200 тысяч единиц данных попали в репозитории после того, как GitHub по умолчанию включил механизм блокировки утечек при отправке изменений. Он проверяет содержимое на этапе push и способен распознавать токены ряда популярных сервисов: GitHub, AWS, Slack, SendGrid, Stripe и GCP.

Судя по результатам анализа, этого недостаточно, чтобы перехватить все публикации секретов. Часть данных находилась в форматах файлов, которые механизм не поддерживает, поэтому проверка их не распознала. У защиты есть и ограничения по типам данных: она пропускает параметры подключения к базам данных, ключи доступа к API Google и закрытые ключи.

Для параметров подключения к базам данных причина такого решения указана отдельно — стремление избежать ложных срабатываний. Это объясняет ограничение, но не меняет его последствий для репозитория: опубликованные данные подключения могут остаться вне этой автоматической проверки.

Поэтому успешная отправка изменений говорит лишь о том, что механизм не остановил конкретный push. Она не означает, что среди файлов нет секретов. Особенно важно различать эти вещи, когда речь идёт о форматах, не охваченных проверкой, или о типах доступов, которые она намеренно пропускает.

Что это значит для сайтов и команд

Практический вывод для команды, которая ведёт публичный репозиторий, — проверять его на секреты и выяснять, продолжают ли обнаруженные данные действовать. Если доступ остаётся активным, его нужно своевременно заменить. Удаление строки из текущего файла и прекращение действия опубликованного секрета — разные задачи.

Владельцу сайта не обязательно различать все виды токенов, чтобы задать команде конкретный вопрос: проверялся ли опубликованный код и что сделали с найденными действующими доступами. Для разработчика результаты исследования дают ориентир, на что обратить внимание при такой проверке: среди обнаруженного могут быть не только токены сервисов, но и данные подключения к базе.

Моё мнение: успешный push не повод успокаиваться

Я пишу первые приложения на TypeScript и как раз учусь не превращать работу с базой в приключение, поэтому сильнее всего меня задел показатель по PostgreSQL. Из найденных данных подключения активными оставались 88%. Для меня это хороший повод внимательнее смотреть на собственный код перед публикацией и не считать, что очевидные токены — единственное, что может там оказаться.

Мне нравится сама идея остановить ошибку при отправке изменений: предупреждение на этом этапе полезно. Но после этих цифр я бы не стал воспринимать отсутствие предупреждения как итог проверки. Мне спокойнее сначала поискать секреты в репозитории, затем разобраться, действуют ли найденные доступы, и при необходимости заменить их. Автоматическая блокировка помогает, но привычку проверять опубликованный код она за меня не создаст.

Источники

Откуда новость. Текст — пересказ своими словами, факты — из источника, мнение — автора.

1. Аналитики Truffle Security нашли в открытом доступе на GitHub 543 тыс. активных токенов, ключей и паролей habr.com

Об авторе

Лев Истрати

начинающий fullstack-разработчик

Пишу первые приложения на TypeScript и учусь не превращать каждый запрос к базе в приключение. Сейчас собираю каталог местных мастерских, чтобы потренировать фронтенд и API.

Все публикации автора