Что теперь можно заблокировать

По официальному changelog, repository rulesets теперь позволяют блокировать слияние pull request, если он вносит алерты secret scanning - то есть если в коммитах этого pull request найден потенциально утёкший секрет: API-ключ, токен доступа, пароль или другая конфиденциальная строка.

Как настроить

Настройка находится в разделе Repository, затем Rulesets настроек репозитория. Там нужно создать новый набор правил или отредактировать существующий и выбрать пункт «Require secret scanning alerts are resolved» - требовать, чтобы все алерты secret scanning были разрешены перед слиянием. То же самое можно настроить программно: через REST API параметром require_secret_scanning_alert_resolution или через GraphQL - это удобно, если правила настраиваются массово через инфраструктуру как код.

Какие секреты проверяются

Проверка охватывает два типа находок: секреты, совпадающие с паттернами известных провайдеров - они проверяются по умолчанию без дополнительной настройки, - и секреты по пользовательским или общим (generic) шаблонам, которые нужно включить отдельно, если это нужно конкретному репозиторию.

Важная техническая деталь: когда именно срабатывает проверка

Блокировка происходит не мгновенно при открытии pull request, а только после того, как сканирование секретов полностью завершилось для головного коммита - и подтвердило, что открытых алертов на секреты, внесённые именно коммитами этого pull request, не осталось. Это значит, что правило дополняет уже существующую push protection (защиту на этапе отправки коммита), а не заменяет её - это второй, а не единственный уровень защиты от случайной публикации секретов.

Кому доступно и что это меняет на практике

Функция находится в публичном превью и требует подписки GitHub Secret Protection или GitHub Advanced Security. На практике это закрывает конкретный сценарий: раньше найденный секрет в pull request был просто предупреждением, которое легко пропустить при беглом просмотре кода; теперь разработчики без специальных прав на обход правила физически не могут слить такой pull request, пока не устранят каждый обнаруженный алерт.

Частые вопросы
Когда вышла эта функция GitHub?
9 сентября 2026 года.
Где включить блокировку слияния с утёкшими секретами?
В настройках репозитория, раздел Repository, затем Rulesets, правило «Require secret scanning alerts are resolved».
Останавливает ли это правило секрет уже на этапе push?
Нет, правило срабатывает только после завершения сканирования секретов для головного коммита pull request - это дополнительный, второй уровень защиты, а не замена push protection.
Какие типы секретов проверяются по умолчанию?
Секреты, совпадающие с паттернами известных провайдеров - проверяются автоматически; пользовательские и общие шаблоны нужно включать отдельно.
На каких тарифах доступна функция?
Она в публичном превью и требует подписки GitHub Secret Protection или GitHub Advanced Security.
Можно ли настроить правило программно, а не только через интерфейс?
Да, через REST API параметром require_secret_scanning_alert_resolution или через GraphQL.
Источники (1)
  1. Block pull requests with exposed secrets from merging - GitHub Changelog
← Все статьи блога