Правило по умолчанию GitHub Actions pull_request_target: как проверить Mac CI? 2026

Сначала установите, какие репозитории действительно подпадают под правило. GitHub объявил, что workflow execution protections доступны и что для публичных репозиториев без применимой политики событий предусмотрена оценка воздействия. Автоматическое применение к затронутым репозиториям запланировано на 2 декабря 2026 года. Частные и внутренние репозитории это правило по умолчанию не охватывает. Эти условия и дата указаны в объявлении о доступности workflow execution protections.

Какие репозитории затронет правило по умолчанию? Публичные репозитории, у которых нет применимой политики событий, ограничивающей выполнение workflow. Не переносите это заключение на всю организацию: проверьте видимость каждого репозитория и действующую для него политику. Публичность сама по себе ещё не доказывает, что конкретный репозиторий обязательно изменит поведение.

Соберите список репозиториев, где есть workflow с pull_request_target. Для каждого укажите владельца, назначение workflow, расположение файла, используемый тип Runner и ответственную команду. Файл workflow обычно находится в каталоге .github/workflows; сверяйте путь с фактической конфигурацией репозитория, а не с внутренним каталогом проектов.

Чтобы не спутать правила для разных уровней управления, сопоставьте настройки репозитория с документацией GitHub по управлению выполнением workflow. Если управление централизовано, зафиксируйте, какая политика применяется и на какую область она распространяется. Не делайте вывод о фактическом ограничении только по названию настройки или по тому, что один похожий репозиторий уже работает.

Режим оценки нужен, чтобы увидеть потенциальное влияние правила, а не чтобы считать нежелательные запуски уже заблокированными. Проверяйте события и workflow, которые система относит к недопустимым при выбранной политике. Само наличие успешного запуска не подтверждает, что после включения правила такой запуск останется разрешённым. Назначение оценки и дату будущего исполнения сверьте с объявлением GitHub.

Как найти в Insights Mac CI, который может быть заблокирован? Используйте GitHub Actions Insights как источник наблюдений, затем свяжите каждый результат с репозиторием, событием и конкретным файлом workflow. Не ограничивайтесь общим числом запусков: для решения об исключении нужны сведения о том, что именно запускается и зачем.

В документации GitHub по просмотру метрик Actions проверьте доступные представления и данные, после чего выполните такую сверку:

• [ ] Определите репозитории и workflow, которые появляются в результатах оценки.
• [ ] Сопоставьте каждый запуск с событием, путём к файлу workflow и ответственным владельцем.
• [ ] Установите, относится ли работа к сборке, тестированию, комментированию PR или другому действию.
• [ ] Зафиксируйте, какие результаты оценки требуют изменения политики, а какие — дополнительной проверки владельцем.
• [ ] Сохраните дату проверки и снимок конфигурации, чтобы сопоставить их с последующим тестированием.

Информация в Insights — не долгосрочная гарантия отсутствия влияния. Набор workflow меняется, новые PR создают другие сценарии запуска, а данные оценки могут отражать только изученный период. Если запись не удаётся связать с файлом или ответственным, считайте её неразобранной: назначьте владельца и выясните источник до решения о разрешении.

Не записывайте «в Insights ничего опасного нет» по результатам одного просмотра. Фиксируйте, какие репозитории, workflow и периоды вы проверили, а также какие неизвестные остались.

pull_request_target требует анализа не по названию события, а по фактическим действиям workflow. Особое внимание нужно уделить тому, загружает ли он код из fork и затем выполняет ли этот код, а также доступны ли ему права базового репозитория или секреты. GitHub отдельно предупреждает об этих рисках в документации по безопасному использованию pull_request_target.

Для каждого workflow проследите путь данных от события до команды на Runner:

• Откуда берётся проверяемый код: из базовой ветки, ветки PR или внешнего fork?
• Выполняются ли скрипты, сборочные фазы, тесты либо другие команды, контролируемые автором PR?
• Может ли процесс обращаться к токену, секрету подписи, приватным артефактам или ресурсам организации?
• Какие права реально нужны: чтение, запись или отдельное действие?
• Сохраняются ли на Mac Runner файлы, ключи либо состояние между заданиями?

Правило события не изолирует Mac физически и не очищает его хранилище. Риск определяется доверием к коду, разрешениями и средой выполнения. Поэтому не считайте выбор Mac Runner доказательством безопасности. В руководстве GitHub по безопасному использованию self-hosted Runner отдельно рассматриваются риски выполнения потенциально недоверенных заданий на таких узлах.

Для необходимых разрешений проверьте ключ permissions в workflow и оставьте только доступ, обоснованный задачей. Синтаксис и значения сверяйте с описанием настройки прав в workflow. Если workflow одновременно проверяет PR-код и использует привилегированные данные, разделите эти обязанности: проверку недоверенного кода проектируйте без доступа к секретам; привилегированные действия выполняйте только при контролируемом источнике кода и проверенных условиях запуска.

Сначала спросите владельца workflow, можно ли отказаться от pull_request_target или разделить сценарий на менее привилегированные этапы. Если задача сводится к проверке изменений PR, не сохраняйте событие по инерции. Изучите доступные варианты триггеров и определите, какой из них подходит без передачи ненужных прав или секретов.

Как ограничить исключение, если событие всё ещё необходимо? Укажите конкретную потребность и разрешайте только тот workflow, которому она нужна. GitHub описывает возможности политик выполнения, включая выбор файлов workflow. Сверьте точную область настройки и применяемые ограничения с документацией для вашей политики, не полагаясь на предположение, что исключение автоматически охватывает только один файл.

В записи об исключении укажите обоснование, утверждающего, затронутый репозиторий и путь к workflow. Добавьте используемые права и секреты, оценённый риск выполнения PR-кода и условие, при котором разрешение нужно пересмотреть. Не расширяйте разрешение на другие файлы только потому, что они принадлежат той же команде.

Если политика управляется программно, проверяйте фактическую конфигурацию после изменения, а не только запланированное значение. Для инвентаризации и автоматизированного контроля можно свериться с документацией Actions policies REST API. API помогает читать или управлять политиками, но не заменяет решение владельца безопасности о допустимом доверии к коду.

Проверка должна охватывать не только итоговый статус задания. В контролируемом репозитории испытайте разрешённый сценарий и сценарий, который новая политика должна отклонить. Сопоставьте фактическое выполнение с записью оценки, настройкой политики, журналами workflow и результатом на Mac Runner. Применяйте тесты так, чтобы не подвергать доступные секреты или производственную среду риску.

Что именно проверять в Mac CI? Убедитесь, что ожидаемые PR-проверки продолжают запускаться, нежелательные триггеры не проходят, а задания не получают больше доступа, чем нужно. Для каждого проверочного прогона сохраните его событие, выбранный workflow, результат политики и сведения о том, какой код выполнялся.

• [ ] Проверьте, что разрешённый workflow запускается только в предусмотренном сценарии.
• [ ] Подтвердите, что запрещённое событие получает ожидаемый отказ, а не запускается с неожиданным набором прав.
• [ ] Убедитесь, что тестовый этап не извлекает и не исполняет недоверенный код в привилегированном контексте.
• [ ] Проверьте доступность сертификатов, ключей подписи и токенов отдельно от обычной PR-проверки.
• [ ] Осмотрите рабочие каталоги и артефакты Mac Runner на предмет сохранённых данных между заданиями.
• [ ] Назначьте ответственного за разбор ошибок, вызванных изменением политики, и за возврат к безопасной конфигурации.

Если для сборки iOS workflow использует подпись, отделите проверку исходного кода от шага, которому действительно нужны подписывающие материалы. Не передавайте секреты в задания, которые могут выполнить код из недоверенного PR. Для self-hosted Mac Runner проверьте также его права на репозитории и ресурсы, доступные с узла. Политика pull_request_target не заменяет аудит секретов, очистку среды и контроль доступа к Runner.

К 2 декабря 2026 года GitHub планирует автоматически применить правило к затронутым публичным репозиториям без применимой политики событий; условия и срок приведены в официальном объявлении. Перед этой датой оформите одно из решений для каждого разобранного workflow: запретить событие, выдать ограниченное исключение либо остановить изменение до устранения выявленной проблемы.

Сохраните доказательства, достаточные для повторной проверки:

• перечень репозиториев с их видимостью и действующей политикой;
• файлы workflow, назначение и владельцев;
• результаты Insights и дату оценки;
• итог аудита кода, прав, секретов и Runner;
• конфигурацию правила до и после изменения;
• записи испытаний разрешённого и отклонённого сценариев;
• утверждённые исключения, их область и условие пересмотра.

После включения политики наблюдайте за ошибками запусков и обращениями владельцев CI. Если PR-проверка перестала запускаться, сначала установите событие, репозиторий и workflow, которые получили отказ; не расширяйте правило или исключение на всю организацию ради восстановления одного задания. При изменении официальной даты, области действия или поведения политики повторите оценку по документации GitHub и обновите внутреннее решение.

Если после проверки вам нужен отдельный macOS-контур для контролируемых сборок, оцените его по требованиям к доступу, секретам, сроку использования и ответственности за обслуживание. На странице CALMVPS можно изучить удалённый Mac, а условия и цены CALMVPS — сопоставить с вашей моделью затрат. Удалённый Mac не устраняет риски небезопасного workflow и не заменяет политику GitHub: он имеет смысл, когда нужен выделенный среде Mac для задач CI, а не как способ обойти проверку доверия. Для постоянной тяжёлой нагрузки или сценариев, которым необходим физический доступ к устройству, сравните аренду с собственным оборудованием и заранее оцените операционные требования.