{"meta":{"title":"Обход запросов для защиты от пуша","intro":"Узнайте, как работают запросы на обход, когда блоки защиты от пуша фиксируют секреты.","product":"Безопасность и качество кода","breadcrumbs":[{"href":"/ru/code-security","title":"Безопасность и качество кода"},{"href":"/ru/code-security/concepts","title":"Concepts"},{"href":"/ru/code-security/concepts/secret-security","title":"Секретная охрана"},{"href":"/ru/code-security/concepts/secret-security/bypass-requests","title":"Обход запросов"}],"documentType":"article"},"body":"# Обход запросов для защиты от пуша\n\nУзнайте, как работают запросы на обход, когда блоки защиты от пуша фиксируют секреты.\n\n## О запросах на обход защиты от пуша\n\nКогда защита от пуша блокирует коммит, содержащий секрет, участникам может понадобиться обойти блок, чтобы завершить свой push. Если делегированный обход для защиты от пуша включен, участники без прав обхода должны подать запрос на обход и ждать одобрения от назначенных рецензентов. Это позволяет организациям поддерживать контроль за безопасностью, одновременно допуская легитимные исключения при необходимости. Дополнительные сведения см. в разделе [Делегированный обход для защиты от push-уведомлений](/ru/code-security/concepts/secret-security/delegated-bypass).\n\nЕсли делегированный обход для защиты от пуша не включён, участники могут обойти защиту от пуша по своему усмотрению.\n\nПри включении делегированного обхода для защиты от push владельцы организаций или администраторы репозиториев решают, какие лица, роли или команды могут рассматривать (одобрять или отклонять) запросы для обхода защиты от push-файлов.\n\nЕсли вы являетесь назначенным рецензентом, вы должны рассматривать запросы на обход и либо одобрять, либо отклонять их, исходя из деталей запроса и политики безопасности вашей организации.\n\n## Как работают запросы на обход\n\nКогда участник без прав обхода запрашивает отправку коммита с секретом, запрос на обход отправляется рецензентам. Назначенная группа рецензентов:\n\n* Получает уведомление по электронной почте с ссылкой на запрос\n* Проверяет запрос на странице «Обход запросов» репозитория или в обзоре безопасности организации.\n* У него есть **7 дней** , чтобы либо одобрить, либо отклонить запрос до истечения срока действия запроса\n\n### Информация, доступная рецензентам\n\nGitHub отображается следующая информация для каждого запроса:\n\n* Имя пользователя, который попытался выполнить толчок\n* Хранилище, где была предпринята попытка продвижения\n* Коммит хэш пуша\n* Временная метка пуша\n* Информация о пути и ветках файла (информация о ветках доступна только для отправок на отдельные ветки)\n\n### Результаты\n\nУчастник получает уведомление по электронной почте о решении и должен предпринять необходимые действия:\n\n* **Если запрос одобрен**: участник может отправить коммит, содержащий секрет, в репозиторий.\n* **Если запрос отклонён**: участник должен удалить секрет из коммита до успешного отправления коммита в репозиторий.\n\n## Автоматические проверки запросов на обход\n\nВы можете использовать GitHub Apps их с тонкими правами для программного рассмотрения и одобрения запросов на обход защиты от пуша. Это позволяет применять последовательные политики безопасности, интегрироваться с внешними инструментами безопасности или снижать нагрузку на ручную проверку.\n\n> Дополнительные сведения о разрешениях см. в разделе [\"Разрешения организации обходить запросы на сканирование секретов\".](/ru/enterprise-cloud@latest/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#organization-permissions-for-organization-bypass-requests-for-secret-scanning)\n\n## Дальнейшие действия\n\n* Чтобы узнать, как управлять запросами обхода на защиту от push в качестве рецензента, см. [раздел AUTOTITLE.](/ru/code-security/how-tos/secure-your-secrets/manage-bypass-requests/manage-bypass-requests)"}