Как настроить cache-mode в GitHub Actions? Руководство по защите корпоративного Mac CI от отравления в 2026 году

10 сентября 2026 года GitHub объявил о настройке доступа к Actions cache через cache-mode — дата указана в официальном объявлении. Если задача запускает недоверенный код, не разрешайте ей запись в общий кэш: назначайте read или none, а обновление кэша поручайте доверенному процессу. Режим кэша управляет доступом к кэшу, но не очищает Mac Runner и не изолирует на нём код и секреты.

Эта статья предназначена для вас, если вы отвечаете за политику GitHub Actions, безопасность корпоративного iOS/macOS CI или конфигурацию self-hosted Mac Runner. Вы сможете определить, какие задачи вправе восстанавливать и сохранять кэш, и какие проверки нужны до допуска сборки к доверенной среде.

Последняя проверка: 24 сентября 2026 года. Сведения сверены с объявлением GitHub о cache-mode, официальной документацией по синтаксису рабочих процессов, кэшированию зависимостей и безопасности self-hosted Runner. Перед внедрением повторно проверьте поддерживаемые режимы и поведение событий: именно актуальная документация определяет действующие правила.

Настройка cache-mode GitHub Actions для предприятия: права важнее ускорения

В объявлении перечислены четыре режима: read, write, write-only и none. Для выбора важен не ярлык, а то, разрешён ли конкретной задаче доступ на чтение, запись или оба действия. Сопоставляйте режим с доверием к коду, который выполняется в задаче, а не только с названием события. Документация GitHub описывает назначение режимов и управление доступом к кэшу.

Таблица задаёт модель принятия решений, а не обещает одинаковую область доступа для всех событий, веток и конфигураций. Перед внедрением проверьте фактическое значение cache-mode, условия восстановления и сохранения, а также правила области действия кэша в вашем рабочем процессе.

У GitHub есть отдельные настройки разрешений рабочего процесса и доступа к кэшу. Не выводите режим кэша из permissions автоматически: проверяйте оба слоя по синтаксису GitHub Actions и по фактическим сообщениям выполнения. Минимизация прав токена полезна, но сама по себе не доказывает, что задача не сможет записать кэш.

Чем read, write и none отличаются в реальной политике? read позволяет задаче использовать допустимый кэш, но не обновлять его; write допускает и чтение, и запись; none исключает доступ к нему. write-only нужен лишь тогда, когда задаче требуется сохранить результат, но не восстанавливать кэш. Сверяйте эти разрешения с актуальным объявлением GitHub, а не с предположением, основанным на названии параметра.

Не используйте один режим как универсальный ответ для всех workflows. Установка none для каждого задания уменьшает риск загрязнения, но может лишить доверенные сборки полезного кэша. Разрешение write всем задачам создаёт обратную проблему: код с меньшим уровнем доверия получает возможность влиять на данные последующих запусков. Настройка должна отражать границы между источниками кода и задачами, которые потребляют результаты.

Доверие к событию — основание разрешать запись

Риск определяется тем, чей код попадает в выполнение, какие действия выполняет workflow и какие ресурсы ему доступны. Название триггера само по себе не является проверкой безопасности. Для каждого события разберите, откуда берутся checkout, скрипты и зависимости, и может ли код автора изменения попасть в задачу с доступом к кэшу или секретам.

• Запуск из доверенной ветки. Запись можно рассматривать, если изменение прошло требуемую проверку, workflow не исполняет произвольный ввод и кэш не становится мостом между разными уровнями доверия.
• Запрос на слияние из fork. Считайте код недоверенным. GitHub документирует ограничения доступа к кэшу для событий с запросами из fork; проверьте действующие правила восстановления и сохранения для используемого триггера в справке по событиям GitHub Actions. Не полагайтесь на отсутствие сообщения об ошибке как на доказательство нужной политики.
• pull_request_target. Это событие работает в контексте базового репозитория, поэтому исполнение кода из запроса на слияние требует особой осторожности. Официальное руководство по безопасному использованию pull_request_target предупреждает о рисках, связанных с исполнением недоверенного кода. Не превращайте workflow, получающий привилегированный контекст, в способ обхода запрета на запись в общий кэш.
• workflow_run. Сам факт, что workflow запущен после другого, не делает его входные данные доверенными. Проверьте, какие артефакты и значения он получает, откуда они пришли и может ли он исполнять содержимое, созданное низкодоверенной задачей.
• Доверенный push или отдельное обслуживание кэша. Это более подходящее место для обновления кэша, когда код и зависимые источники прошли принятую в организации проверку. Сохраняйте такое обслуживание отдельно от задач, которые тестируют изменения из внешних веток.

Какой режим назначать workflow для pull_request? Начинайте с read, если сборке нужны ранее сохранённые зависимости, но она не должна обновлять общий кэш. Выбирайте none, если восстановленные данные тоже могут повлиять на чувствительную проверку или если задача вообще не нуждается в кэше. Разрешайте write только после проверки источника кода и области, в которой другой workflow сможет использовать сохранённое значение.

Для принятия решения заведите таблицу политик в конфигурации команды, а не оставляйте выбор режима неявным. Зафиксируйте событие, источник кода, допустимость восстановления, допустимость записи, используемые секреты и Runner, на котором работает задача. Если разработчик не может объяснить, кто будет потребителем сохранённого кэша, не выдавайте задаче право его обновлять.

Общий кэш: ключ, область действия и содержимое

Кэш — это не только ускорение загрузки зависимостей. Его содержимое может быть результатом предыдущего выполнения, которое получило доступ к другой версии кода или прошло через другой уровень проверки. GitHub рекомендует учитывать модель угроз кэширования зависимостей и не сохранять в кэше секреты или чувствительные данные; детали приведены в официальном руководстве по безопасности dependency caching.

До включения записи разберите три компонента:

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

Как предотвратить запись недоверенного PR в кэш доверенной ветки? Не предоставляйте низкодоверенной задаче режим записи. Разделите обслуживание кэша и тестирование запроса на слияние: первый процесс обновляет его из проверенного источника, второй получает только те права на чтение, которые допускает действующая политика GitHub. Дополнительно проверьте области веток, ключи и fallback-ключи, чтобы восстановление не расширяло доступ незаметно.

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

Постоянный Mac Runner и удалённый кэш — разные границы риска

Управление доступом к удалённому кэшу не удаляет файлы с диска Mac и не возвращает Runner в исходное состояние после задачи. На self-hosted Runner после выполнения могут остаться рабочая копия, временные файлы, кэш пакетного менеджера, созданные скриптом данные и доступные учётные данные. Даже при режиме none эти локальные состояния требуют отдельной политики.

Для оценки корпоративной конфигурации сравните не только способы ускорить сборку, но и сохранение состояния между задачами. В этой статье баллы — качественная оценка влияния на риск, а не результат измерений или обещание GitHub.

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

Защитит ли cache-mode постоянный Mac Runner? Нет. Он регулирует доступ задачи к Actions cache, но не является механизмом очистки хоста, изоляции процессов или удаления локальных учётных данных. Руководство GitHub по безопасному использованию self-hosted Runner описывает отдельные риски выполнения недоверенных workflows на самостоятельно размещённых узлах. Для чувствительных задач предусмотрите отдельные Runner-группы, чистую среду или пересоздание узла после выполнения — выбор должен опираться на модель доступа вашей инфраструктуры.

Если ваша команда рассматривает физический Mac вместо виртуализированной среды, сначала проверьте различия в границах исполнения и обслуживании: в сравнении bare-metal и виртуализации macOS можно сверить, какие факторы следует включить в архитектурное решение. Ни физическая машина, ни виртуальная среда сами по себе не гарантируют безопасную изоляцию.

Этап проверки: доказательства перед запуском в продуктиве

Перед пилотом проведите контролируемые запуски с доверенным и недоверенным кодом. Не делайте вывод по одному успешному workflow. В журналах сопоставьте назначенный cache-mode с сообщениями о восстановлении и сохранении, а затем проверьте, не получил ли следующий доверенный запуск содержимое, созданное низкодоверенной задачей.

Используйте список приёмки. Отмечайте пункт только после проверки конфигурации или журналов, а не на основании устного подтверждения.

• [ ] Для каждого триггера зафиксированы источник кода, уровень доверия и владелец политики.
• [ ] Эффективный cache-mode определён для каждого job; отдельно проверены настройки workflow permissions.
• [ ] Для недоверенных изменений разрешены только обоснованные действия с кэшем: чтение либо отсутствие доступа.
• [ ] Сохранение кэша выполняется только в определённом доверенном процессе, а область действия записи задокументирована.
• [ ] В кэш не попадают секреты, подписи, временные учётные данные и иные чувствительные данные.
• [ ] После завершения задачи проверены рабочая область, временные файлы и остаточное состояние Mac Runner.
• [ ] Секреты подписи iOS не доступны задачам, выполняющим низкодоверенный код.
• [ ] Поведение отказа проверено: если кэш недоступен или не может быть использован, задача завершается предсказуемо, а не меняет режим на более привилегированный без согласования.

Документируйте ожидаемый результат проверки: при недоверенном событии задача не записывает общий кэш; доверенная задача может обслуживать только утверждённую область; доступ к производственным сертификатам отделён от тестирования внешнего кода. Если логи не позволяют установить, почему кэш был восстановлен или сохранён, остановите расширение пилота и улучшите наблюдаемость. Не подменяйте отсутствие явной ошибки доказательством отсутствия доступа.

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

Когда менять политику, а когда менять Mac-среду

Если задача не доверена, начните с ограничения доступа к кэшу, а не с попытки компенсировать риск настройкой ключа. Если доверенная сборка не может безопасно делить кэш с тестами внешних изменений, разделите процессы обслуживания и потребления. Если задачи с разным уровнем доверия продолжают использовать одну постоянную Mac-среду, решайте проблему на уровне Runner: ограничивайте доступ, разделяйте узлы и проверяйте очистку после выполнения.

До допуска пилота должны быть подтверждены три вещи: недоверенная задача не обновляет общий кэш, восстановленное содержимое рассматривается как входные данные, а локальные остатки и подписи не переносятся в доверенную сборку. Если хотя бы один пункт не подтверждён, оставьте режим записи отключённым и не расширяйте доступ к секретам.

Использование собственных постоянных Mac даёт команде физический контроль, но требует закупки, обслуживания, мониторинга и организации очистки; общая облачная среда уменьшает часть операционных задач, но не отменяет необходимости проверить изоляцию, сохранность состояния и доступ к подписи. Аренда Mac не является автоматической заменой политике безопасности: перед выбором оцените Runner и подтверждения изоляции для ваших workflows. MacDate можно рассматривать, если вам нужна временная или дополнительная Mac-среда для пилотирования CI; перед решением проверьте условия и состав доступных вариантов в информации о тарифах MacDate, не предполагая заранее конкретные механизмы очистки или разделения узлов.