Truffle Security запустила бесплатную программу, рассчитанную на отзыв скомпрометированных ключей: речь идёт примерно о 1,4 млн публично доступных секретов, которые до сих пор остаются рабочими. Для разработчиков и компаний это неприятное напоминание: случайно опубликованный API-ключ не становится безопаснее только потому, что репозиторий давно закрыли или о находке отправили письмо.
Программа Secrets Revocation Program должна свести владельцев платформ, выпускающих ключи, с проверенными утечками и помочь отключать их без ожидания реакции клиента, сообщает BleepingComputer. Truffle Security использует свой инструмент TruffleHog, чтобы проверить, что найденный токен или ключ действительно валиден, а затем передаёт информацию эмитенту через endpoint для отзыва либо webhook. Если поставщик подключился к схеме, он может аннулировать секрет в течение 14 дней.
Проблема выглядит банальной ровно до тех пор, пока не приходится разбирать последствия. Ключи попадают в открытый доступ через публичные Git-репозитории, историю коммитов, Docker-образы, пакеты, CI-логи, конфигурационные файлы приложений и наборы данных. Один забытый файл .env может дать постороннему доступ к облачному аккаунту, сервису рассылок, LLM API или внутренней инфраструктуре. А после публикации секрет обычно успевают скопировать боты и сканеры — удалить строку из последнего коммита уже недостаточно.
Truffle Security занимается поиском таких данных с 2022 года. Ранее компания сообщала о 543 тыс. действующих учётных данных в публичных репозиториях GitHub. В другом исследовании она нашла более 431 тыс. секретов AWS в кодовых репозиториях, Git-истории, датасетах, Docker-образах, реестрах контейнеров и журналах CI. Это не оценка «потенциально опасных строк»: новая программа нацелена именно на секреты, которые удалось проверить на работоспособность.
Самый болезненный факт для команд безопасности — низкая эффективность обычных уведомлений. По данным Truffle Security, через шесть месяцев после сообщений исследователей рабочими оставался 81% ключей, о которых компания уведомляла владельцев годом ранее. У уведомления слишком много шансов затеряться: контакт в репозитории устарел, письмо попало в спам, автор коммита ушёл из компании, а у команды нет понятного процесса, кто и как должен перевыпускать ключи.
В программу уже вошли 16 эмитентов, включая Hugging Face, Notion, Vercel, Resend, RubyGems и Twilio. Модель не заменяет безопасную разработку, но меняет последний этап инцидента: если владелец секрета молчит, риск не должен оставаться на пользователях сервиса и его клиентах. Для поставщика API это также способ централизованно обработать утечку, а не ждать, пока чужой ключ используют для счёта за облако, рассылки фишинга или доступа к данным.
Показателен опыт Google. С 16 июня 2024 года компания начала по умолчанию отключать обнаруженные в открытом доступе ключи сервисных аккаунтов Google Cloud. Когда подход ограничивался уведомлением владельцев, Truffle Security находила активными 72% утёкших секретов. После автоматического отключения доля снизилась до 11%. Нуля здесь не будет: клиенты могут отказаться от автоматического отзыва, а часть сценариев требует сначала подготовить замену ключу. Но разница между «мы сообщили» и «ключ больше не работает» слишком велика, чтобы считать её косметической.
Отдельно растёт риск вокруг инструментов для AI-разработки. Truffle Security утверждает, что с января 2025 года обнаружила 2 655 работающих ключей в конфигурационных файлах таких инструментов; годом ранее эта категория практически не фигурировала в её находках. Чем больше сервисов, агентов и локальных интеграций разработчик подключает к проекту, тем больше мест, где секрет может оказаться в домашней директории, шаблоне конфигурации или опубликованном артефакте сборки.
Для российских команд практический вывод не зависит от участия конкретного зарубежного провайдера в программе: секреты нужно хранить вне кода, сканировать до коммита и в CI, ограничивать их права, регулярно ротировать и иметь отработанный сценарий перевыпуска. Отзыв скомпрометированных ключей становится не аварийной процедурой для редкого инцидента, а базовой функцией платформы. Чем раньше эмитенты API начнут брать на себя эту часть ответственности, тем меньше утечек будут превращаться из неловкой ошибки разработчика в полноценный взлом.
