GitHub добавил в repository rulesets правило, которое может блокировать слияние pull request, если проверка secret scanning обнаружила в изменениях потенциально утёкшие секреты. Обновление доступно с 9 сентября 2026 года в публичной превью для клиентов GitHub Secret Protection и GitHub Advanced Security.
Правило называется require_secret_scanning_alert_resolution. Оно рассчитано на команды, которые хотят контролировать защиту сразу в нескольких репозиториях через единый набор правил, а не полагаться только на локальные настройки отдельных проектов.
Для разработчиков, работающих с API-ключами, токенами и конфигурацией AI-сервисов, изменение добавляет отдельную точку контроля: даже если секрет прошёл предыдущую проверку, pull request можно остановить до попадания изменений в целевую ветку.
Что именно блокирует новое правило
По описанию GitHub, правило применяется к открытым pull request. По умолчанию оно проверяет секреты, найденные по шаблонам провайдеров. Если такое предупреждение остаётся неразрешённым, разработчик без права обхода ruleset не сможет завершить слияние.
Администратор может дополнительно указать другие категории обнаружений — например, пользовательские custom patterns или generic patterns. Это позволяет разделить политику для разных типов данных. Команда может строже контролировать шаблоны, созданные самостоятельно, даже если для них не включена блокировка на этапе отправки коммита.
Под «разрешением» предупреждения GitHub понимает обработку каждого обнаружения в рамках secret scanning. Само наличие правила не означает, что любой найденный фрагмент автоматически является действующим ключом или паролем: решение по конкретному предупреждению по-прежнему требует проверки команды.
Чем это отличается от push protection
GitHub позиционирует новое правило как дополнительный уровень защиты, а не замену push protection. Push protection пытается остановить секрет в момент отправки изменений, до их попадания в репозиторий. Правило repository rulesets работает позже — на уровне открытого pull request и проверки возможности слияния.
Такое разделение полезно для проектов, где невозможно или нежелательно блокировать каждый push. Например, команда может оставить push protection выключенной для generic patterns, но запретить слияние PR, если такие обнаружения появились в изменениях.
Официальное описание возможностей secret scanning и push protection опубликовано в документации GitHub: https://docs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning
Новая схема не устраняет риск уже существующих секретов в истории репозитория. Она также не превращает pull request в универсальный аудит безопасности: правило проверяет категории обнаружений, которые настроены для конкретного repository ruleset.
Настройка через rulesets и API
Включить защиту можно через настройки repository rulesets. GitHub также добавил поддержку управления правилом через API:
- в REST API используется тип правила require_secret_scanning_alert_resolution;
- параметр secret_types позволяет задать категории секретов, на которые распространяется блокировка;
- в GraphQL применяется значение REQUIRE_SECRET_SCANNING_ALERT_RESOLUTION.
Такая настройка может быть полезна организациям, которые создают правила для большого числа репозиториев программно. Вместо ручного повторения конфигурации команда может централизованно определить, какие типы обнаружений должны препятствовать слиянию.
Документация GitHub по repository rulesets описывает общие принципы применения правил и исключения для пользователей с правом обхода: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets
При этом право bypass остаётся важной частью политики. Если оно выдано слишком широкому кругу пользователей, блокировка будет действовать не для всех участников процесса. Если же исключения запрещены полностью, ложное срабатывание может задержать выпуск изменений до ручной проверки.
Что изменится для команд, работающих с AI-инструментами
В проектах с генеративными моделями секреты часто появляются не только в основном коде. Токены провайдеров API могут попасть в примеры, тестовые сценарии, файлы конфигурации, журналы запуска агентов или шаблоны автоматизации.
Новая проверка особенно актуальна для репозиториев, где pull request создаются автоматически — например, ботами обновления зависимостей, внутренними агентами разработки или системами генерации кода. Автоматический автор PR может не распознать, что строка похожа на ключ доступа, а ruleset остановит слияние до проверки человеком.
Однако GitHub в исходном объявлении не приводит независимые измерения точности обнаружения, число поддерживаемых провайдеров или статистику ложных срабатываний. Поэтому нельзя заранее считать, что включение правила одинаково хорошо подойдёт всем проектам. Поведение будет зависеть от выбранных типов секретов и текущей конфигурации secret scanning.
Что проверить перед включением
Перед активацией правила команде стоит проверить четыре настройки.
Какие категории секретов должны блокировать PR: только provider patterns или также custom и generic patterns.
2. Кто получает право bypass и в каких случаях оно может применяться.
3. Как разработчики должны обрабатывать предупреждения: удалять секрет, заменять его безопасной переменной или подтверждать ложное срабатывание.
4. Совместима ли новая проверка с уже действующими правилами веток, обязательными статусами CI и код-ревью.
Для начала безопаснее включить правило на нескольких репозиториях с активными pull request и посмотреть, какие обнаружения реально будут останавливать слияние. Отдельно стоит проверить автоматические PR от ботов и обновлений зависимостей: именно они могут чаще всего сталкиваться с неожиданными generic patterns.
Функция находится в публичной превью, поэтому GitHub может изменить её поведение, параметры API и состав доступных настроек до общего релиза. Сейчас она предназначена для клиентов с GitHub Secret Protection или GitHub Advanced Security. Дополнительные сведения о push protection опубликованы в документации GitHub: https://docs.github.com/en/code-security/secret-scanning/push-protection/about-push-protection