GitHub Actions borne l’accès au cache CI avec cache-mode

GitHub généralise cache-mode, un réglage qui applique le principe de moindre privilège au cache des workflows Actions. L’enjeu est concret : refermer la voie de l’empoisonnement de cache entre branches sans allonger les temps de build.

#Un cache partagé, une surface d’attaque

Le cache d’Actions accélère l’intégration continue en conservant dépendances et artefacts entre deux exécutions. Sa logique de résolution traverse les branches : une exécution restaure d’abord une entrée de sa propre branche, puis se rabat sur la branche par défaut, et sur la branche de base quand le déclencheur est une pull request, y compris depuis un dépôt forké. Cette portée large est utile, mais elle ouvre une brèche : une contribution non fiable peut écrire dans le cache une entrée que réutilisera ensuite un workflow de confiance. C’est le scénario d’empoisonnement de cache, longtemps traité à coups de clés soigneusement préfixées et de vérifications maison sur les serveurs d’auto-hébergement les mieux durcis.

#Quatre modes, deux valeurs par défaut

Le réglage se résume à un mot-clé qui décrit ce qu’une exécution a le droit de faire avec le cache. Deux valeurs par défaut s’appliquent automatiquement selon la confiance accordée au déclencheur.

#Configuration au niveau workflow ou job

La clé se pose sur le workflow entier ou sur un job précis, le réglage du job l’emportant sur celui du workflow. Le schéma recommandé consiste à passer le workflow en restauration seule, puis à n’ouvrir l’écriture qu’aux jobs déclenchés par une branche de confiance.

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 job qui n’a jamais besoin d’écrire dans le cache ne devrait jamais en avoir le droit.

#Héritage dans les workflows réutilisables

Le mode est imposé par le service de cache, pas seulement par le coureur. Il se propage aux workflows réutilisables : un workflow appelé ne peut jamais recevoir plus d’accès que son appelant ne lui en accorde. Les projets qui centralisent leur chaîne d’intégration dans des workflows partagés héritent donc d’un plafond de privilèges cohérent, sans dépendre de la vigilance de chaque dépôt consommateur.

#Ce qu’il faut retenir

Le contrôle d’accès au cache est désormais disponible pour tous les comptes, sans configuration préalable. Les projets bien réglés ne verront rien changer, puisque les défauts reprennent la logique de confiance déjà en place. Le gain revient à ceux qui manipulent des déclencheurs sensibles ou des contributions externes : ils disposent enfin d’un cadran explicite plutôt que d’un contournement fait main. Passer en revue ses workflows d’intégration pour repérer les jobs qui écrivent sans nécessité prend quelques minutes et retire une classe entière d’attaques.

Pour aller plus loin : l’annonce officielle sur le GitHub Changelog et la documentation de mise en cache des dépendances. Voir aussi, côté serveurs, les outils en ligne de commande qui aident à inspecter une chaîne d’intégration.