GitHub Actions acota el acceso a la caché de CI con cache-mode

GitHub generaliza cache-mode, un ajuste que aplica el mínimo privilegio a la caché de los flujos de trabajo de Actions. El objetivo es claro: cerrar la vía del envenenamiento de caché entre ramas sin alargar los tiempos de compilación.

#Una caché compartida es una superficie de ataque

La caché de Actions acelera la integración continua al conservar dependencias y artefactos entre ejecuciones. Su lógica de búsqueda cruza ramas: una ejecución restaura primero una entrada de su propia rama, luego recurre a la rama por defecto y a la rama base cuando el desencadenante es una pull request, incluso desde un repositorio bifurcado. Ese alcance amplio resulta cómodo, pero abre una brecha: una contribución no confiable puede escribir en la caché una entrada que después reutiliza un flujo de confianza. Es el envenenamiento de caché, resuelto durante años con claves cuidadosamente prefijadas y comprobaciones caseras en los servidores autoalojados mejor endurecidos.

#Cuatro modos, dos valores por defecto

El ajuste se reduce a una palabra clave que describe qué puede hacer una ejecución con la caché. Se aplican dos valores por defecto según la confianza del desencadenante.

#Configurarlo por flujo o por trabajo

La clave se coloca en el flujo completo o en un trabajo concreto, y el valor del trabajo prevalece sobre el del flujo. El patrón recomendado consiste en poner el flujo en modo solo restauración y abrir la escritura únicamente a los trabajos desencadenados por una rama de confianza.

name: CI
on: [push, pull_request]

# Default for every job: restore from cache, never write to it
cache-mode: read

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/cache@v4
        with:
          path: ~/.npm
          key: npm-${{ hashFiles('package-lock.json') }}
      - run: npm ci && npm test

  warm-cache:
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    # Only trusted pushes to main are allowed to repopulate the cache
    cache-mode: write
    steps:
      - uses: actions/checkout@v4
      - uses: actions/cache@v4
        with:
          path: ~/.npm
          key: npm-${{ hashFiles('package-lock.json') }}
      - run: npm ci

Un trabajo que nunca necesita escribir en la caché nunca debería poder hacerlo.

#Herencia en los flujos reutilizables

El modo lo impone el servicio de caché, no solo el ejecutor. Se propaga a los flujos reutilizables: un flujo invocado nunca recibe más acceso del que le concede quien lo invoca. Los equipos que centralizan su cadena de integración en flujos compartidos heredan así un techo de privilegios coherente, sin depender de la vigilancia de cada repositorio consumidor.

#Lo que hay que recordar

El control de acceso a la caché ya está disponible en todos los planes, sin configuración previa. Los proyectos bien ajustados no notarán ningún cambio, porque los valores por defecto siguen la lógica de confianza vigente. El beneficio es para quien maneja desencadenantes sensibles o contribuciones externas: por fin dispone de un mando explícito en lugar de un apaño artesanal. Revisar los flujos de integración para detectar trabajos que escriben sin necesidad lleva unos minutos y elimina toda una clase de ataques.

Para profundizar: el anuncio oficial en el GitHub Changelog y la documentación de caché de dependencias.