GitHub объявил о всеобщей доступности параметра cache-mode для сервиса GitHub Actions. Настройка, ставшая доступной на всех тарифных планах с 10 сентября 2026 года, позволяет разработчикам применять принцип минимально необходимых привилегий к хранилищу кеша — на уровне как всего воркфлоу, так и отдельного задания (job).
До сих пор управление доступом к кешу в Actions было фактически бинарным: либо кеш доступен, либо нет. В сложных пайплайнах, где участвуют внешние контрибьюторы или выполняются задачи с разным уровнем доверия, это создавало риски: недоверенный шаг мог перезаписать кеш с зависимостями, что открывало путь для атак на цепочку поставок через подмену артефактов сборки.
Как работает иерархия прав cache-mode
Параметр cache-mode встраивается непосредственно в синтаксис YAML-конфигурации воркфлоу. Разработчик может задать одно из четырёх значений — read, write, read-write или write-only — как на уровне всего файла, так и для конкретного job. При этом настройка задания (job-level) полностью переопределяет глобальную настройку воркфлоу.
Важный архитектурный нюанс: cache-mode жёстко контролируется сервисом кеширования GitHub при использовании переиспользуемых воркфлоу (reusable workflows). Вызываемый дочерний воркфлоу не может получить больше прав на доступ к кешу, чем ему делегировал родительский процесс. Это предотвращает сценарии, при которых сторонний шаблон или экшен мог бы неявно расширить свои привилегии.
Защита от cache poisoning на низкодоверенных триггерах
Отдельное внимание в релизе уделено событиям с низким уровнем доверия — в первую очередь pull_request_target. Для таких триггеров Actions исторически устанавливает безопасный режим кеша только для чтения. Если разработчик явно объявляет cache-mode: write или cache-mode: write-only для такого события, платформа выводит предупреждающую аннотацию в интерфейсе GitHub Actions.
В официальном блоге GitHub подчёркивают: «Явное объявление write или write-only для этих событий может повысить риск cache poisoning, поэтому Actions добавляет предупреждающую аннотацию, когда объявленный режим предоставляет доступ на запись». Если параметр cache-mode не указан, воркфлоу продолжают использовать существующие безопасные настройки по умолчанию.
Практическое значение для AI/ML-пайплайнов
Для разработчиков, использующих CI/CD для сборки моделей машинного обучения, cache-mode даёт инструмент для разделения процессов, которые должны читать кеш, и тех, которые могут его записывать. Типичный сценарий: этап загрузки предобученных весов (например, из Hugging Face Hub или локального кеша pip) может работать в режиме read, а этап сборки артефактов обучения — только в режиме write.
В контексте публичных репозиториев, где внешние участники могут отправлять pull request, настройка только на чтение для недоверенных воркфлоу защищает базовые образы и кешированные зависимости от подмены на модифицированные бинарные файлы. Это особенно критично для сборок, включающих CUDA-зависимости, LLM-инструменты и большие кеши компиляции.
Что остаётся за кадром
GitHub не раскрывает, планируется ли поддержка cache-mode для self-hosted runners на системах с прокси или кеширующими серверами. В текущей документации указано, что изменения вступают в силу немедленно на серверах github.com для всех тарифных планов без необходимости обновления локальных агентов.
Для проектов, использующих экшены третьих сторон с доступом к кешу, рекомендуется провести аудит конфигурации перед включением режимов записи в контексте публичных пулл-реквестов. Разработчикам стоит проверить, не объявлен ли cache-mode: write в reusable workflows, которые вызываются из недоверенных контекстов.
Дополнительные источники
Официальный блог GitHub: https://github.blog/changelog/2026-09-10-control-github-actions-cache-access-with-cache-mode
Документация по синтаксису cache-mode: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#cache-mode