GitHub 9 сентября 2026 года добавил новый уровень защиты pull request: repository rulesets теперь могут запрещать merge, пока secret scanning не завершён или пока в PR остаются открытые alerts по обнаруженным секретам.
Это не замена push protection, а дополнительный security gate перед попаданием изменений в защищённую ветку. Для команд, где код проходит через pull request и обязательное ревью, новая настройка закрывает важный сценарий: секрет мог попасть в коммиты PR, но до merge проблема должна быть явно устранена.
Что именно добавил GitHub
Новая настройка называется Require secret scanning alerts are resolved. Она добавляется в branch ruleset и проверяется перед merge pull request.
По официальному анонсу GitHub правило блокирует merge в двух случаях:
- secret scanning ещё не завершил проверку head commit pull request;
- в коммитах pull request есть открытый secret scanning alert, подходящий под выбранный тип секретов.
Пока одно из этих условий не выполнено, разработчик без bypass-разрешения не сможет завершить merge.
Почему это отличается от push protection
Push protection старается остановить утечку раньше — непосредственно при попытке отправить поддерживаемый секрет в репозиторий. Это полезно, потому что потенциально чувствительное значение не должно вообще попадать в историю Git.
Новый ruleset работает на другом этапе. Он становится дополнительной проверкой именно перед merge pull request. Это важно для командных процессов, где изменения могут приходить из разных веток, автоматизаций, fork-репозиториев или сценариев, в которых ранняя защита не сработала либо была обойдена.
Иными словами, push protection пытается остановить проблему на входе, а merge protection не позволяет закрыть PR, пока обнаруженная проблема остаётся нерешённой.
Какие секреты могут блокировать merge
По умолчанию GitHub применяет правило к секретам, обнаруженным через provider patterns. Это шаблоны известных поставщиков токенов и ключей.
Дополнительно администратор может настроить блокировку для:
- provider patterns;
- custom patterns;
- generic patterns.
В документации GitHub отдельно указано, что AI-detected secrets сейчас этим правилом не поддерживаются. Функция находится в public preview, поэтому состав возможностей ещё может меняться.
Как включить блокировку merge
Настройка выполняется через rulesets. В репозитории, организации или enterprise нужно открыть раздел с правилами репозиториев, создать или изменить branch ruleset и включить пункт Require secret scanning alerts are resolved.
После этого выбираются типы секретов, которые должны блокировать merge, и ветки, к которым применяется ruleset.
Для работы механизма у целевых репозиториев должны быть включены GitHub Secret Protection или GitHub Advanced Security, а также сам secret scanning.
Что происходит, когда GitHub находит секрет
Если pull request содержит подходящий открытый alert, merge становится недоступен для участников без bypass permission. Чтобы снять блокировку, alert нужно разрешить в соответствии с процессом secret scanning.
Сам факт закрытия alert не означает, что скомпрометированный секрет снова безопасен. Если реальный токен, API key или credential уже попал в Git, обычно нужно отдельно оценить риск, отозвать или ротировать credential и только после этого разбираться с историей репозитория.
Что стоит проверить перед включением ruleset
- включён ли secret scanning на нужных репозиториях;
- какие provider, custom и generic patterns действительно должны блокировать merge;
- кому разрешён bypass ruleset и нужен ли он вообще;
- не конфликтует ли новое правило с существующими branch protection и required checks;
- есть ли у команды понятный процесс ротации найденных credentials;
- как security alerts обрабатываются в CI/CD и кто отвечает за их закрытие.
Для крупных организаций особенно важно не включать новое правило изолированно от остальной модели доступа. Rulesets, CODEOWNERS, обязательные ревью, code scanning и secret scanning должны работать как единая система, а не как набор несвязанных чекбоксов.
Можно ли настроить правило через API
Да. GitHub указывает, что правило доступно через REST API как тип require_secret_scanning_alert_resolution с параметром secret_types. В GraphQL используется значение REQUIRE_SECRET_SCANNING_ALERT_RESOLUTION.
Для команд с большим количеством репозиториев это полезнее ручной настройки: rulesets можно стандартизировать и раскатывать через инфраструктурные скрипты или внутреннюю DevOps-автоматизацию.
Где новая защита особенно полезна
Наибольший эффект она даёт там, где pull request является обязательной частью процесса разработки: корпоративные продукты, SaaS, агентства, команды с несколькими окружениями и проекты с большим количеством интеграций.
Если репозиторий активно использует GitHub Actions, облачные API, сторонние SaaS, deployment tokens или приватные registry, цена случайно закоммиченного секрета выше. Поэтому проверка перед merge дополняет более ранние меры защиты.
Похожий принцип применяется и в других security gate GitHub. Например, мы уже разбирали изменения CodeQL и возможности GitHub Enterprise Server 3.22: полезнее всего security-инструменты работают, когда встроены в общий CI/CD-процесс.
Ограничения public preview
На момент анонса функция имеет статус public preview. GitHub может менять интерфейс, поддерживаемые типы секретов и детали поведения до выхода в общую доступность.
Поэтому для критичных production-процессов разумно сначала включить правило на ограниченной группе репозиториев, проверить ложные срабатывания, процесс bypass и фактическое время обработки secret scanning, а уже затем расширять политику.
Итог
Новая защита GitHub переносит secret scanning из режима только обнаружения ещё и в обязательный merge gate. Pull request нельзя объединить с защищённой веткой, если проверка ещё не закончилась или соответствующий secret alert остаётся открытым.
Это не отменяет push protection, ротацию credentials и нормальную настройку прав доступа. Но в связке с rulesets, review и CI/CD новый механизм делает вероятность случайного попадания активного секрета в основную ветку ниже.
Если нужно привести в порядок GitHub rulesets, CI/CD, webhooks или автоматизацию вокруг репозиториев, можно описать задачу A.S Groups. Сначала имеет смысл проверить текущую схему доступа и pipeline, а уже затем включать дополнительные блокирующие правила.
Обсуждение
Вопросы и комментарии
Можно уточнить детали статьи или поделиться своим опытом. Первый комментарий проходит проверку.