GitHub расширил Secret Scanning и добавил новые детекторы для Supabase, Lovable Labs и Pydantic Services.

Изменение небольшое по объёму changelog, но практическое: ключ, который случайно попал в commit, теперь может быть распознан автоматически ещё одним уровнем защиты.

Для части secret types в публичных репозиториях GitHub также может передать информацию самому провайдеру, чтобы credential успели отозвать или ротировать до злоупотребления.

Какие секреты добавил GitHub

В обновлении от 5 октября 2026 года появились новые детекторы:

• Lovable Labs — lovable_api_key;
• Pydantic Services — logfire_token;
• Pydantic Services — pydantic_ai_gateway_api_key;
• Supabase — supabase_oauth_access_token;
• Supabase — supabase_scoped_personal_access_token.

Это именно конкретные форматы secrets. Secret Scanning ищет признаки таких credentials в содержимом репозитория.

Lovable стала новым secret scanning partner

Lovable Labs присоединилась к GitHub Secret Scanning Partnership Program.

Для partner secret логика отличается от обычного локального alert. Если такой ключ найден в публичном репозитории, GitHub может сообщить о нём провайдеру.

Провайдер получает возможность отозвать или ротировать credential до того, как его успеют использовать злоумышленники.

Что происходит с Supabase-токенами

Для Supabase добавлены детекторы OAuth access token и scoped personal access token.

GitHub относит их к user secrets. При обнаружении такие секреты создают secret scanning alert в поддерживаемых публичных или приватных репозиториях.

Это полезно для проектов, где Supabase используется из CI, CLI, серверных scripts или внутренних tooling.

Почему .env в .gitignore не решает проблему полностью

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

Если секрет уже был committed, а потом файл добавили в .gitignore, credential остаётся в Git history.

То же самое относится к ситуации, когда ключ удалили следующим commit. Старое значение всё ещё может находиться в предыдущей версии файла.

Удалить ключ из последнего commit недостаточно

Если credential уже попал в удалённый repository, безопасная реакция выглядит иначе:

1. считать секрет скомпрометированным;
2. отозвать или ротировать его у провайдера;
3. обновить secret в GitHub Actions, Vercel, сервере или другом месте использования;
4. после этого при необходимости очищать Git history;
5. проверить audit/logs провайдера на подозрительное использование.

Главный шаг — именно ротация. Переписывание истории не превращает уже опубликованный ключ обратно в безопасный.

Где чаще всего утекают credentials

• .env и его резервные копии;
• временные config-файлы;
• пример кода с настоящим token вместо placeholder;
• GitHub Actions workflow;
• debug logs;
• скрипты миграции и импорта;
• локальные helper-скрипты, которые случайно попали в commit;
• frontend bundle, если server secret ошибочно используется на клиенте.

Особенно важно различать публичный и серверный ключ

Не каждое значение, связанное с API, является секретом.

Некоторые платформы специально имеют публичные client-side identifiers или publishable keys. Но service role, personal access token, OAuth access token и административные credentials нельзя переносить во frontend только потому, что приложение должно обращаться к API.

Для Supabase это особенно важно: архитектура должна учитывать не только хранение ключа, но и Row Level Security и реальные права конкретного credential.

Secret Scanning не заменяет нормальное управление секретами

Детектор — это страховка, а не основной способ хранения credentials.

Правильнее изначально использовать:

• GitHub Actions Secrets или environment secrets;
• переменные окружения на сервере;
• секреты платформы деплоя;
• ограниченные по scope токены;
• короткоживущие credentials там, где это поддерживается;
• раздельные ключи для production, staging и development.

Что проверить в существующем репозитории

Что изменилось именно сейчас

Обновление GitHub не меняет базовый принцип Secret Scanning. Оно расширяет библиотеку известных форматов и партнёрских интеграций.

Но с ростом количества AI-инструментов и внешних API это становится всё полезнее. Код всё чаще собирается из нескольких сервисов, а вместе с этим растёт число токенов, которые разработчик может случайно оставить в commit.

Если CI/CD уже строится на GitHub, можно дополнительно автоматизировать проверки через GitHub Actions. Для общего подхода к security полезен материал про права, обновления и логи.

Официальный источник

GitHub Changelog — Secret scanning adds detectors for Lovable, Supabase, and more