GitHub Actions : sécuriser le cache CI

Sécuriser le cache GitHub Actions devient plus précis : GitHub permet désormais de choisir, au niveau d’un workflow ou d’un job, s’il peut lire, écrire, seulement écrire ou ne pas accéder au cache. Pour une équipe produit, ce réglage aide à conserver les gains de temps du CI tout en réduisant l’exposition des flux qui ne sont pas pleinement fiables.

Pourquoi le cache CI mérite une vraie règle d’accès

Un cache évite de télécharger ou recalculer les mêmes dépendances à chaque exécution. C’est utile, mais le contenu restauré influence directement le travail du pipeline. Lorsqu’un workflow s’exécute dans un contexte moins digne de confiance — par exemple autour d’une contribution externe — lui autoriser l’écriture ou la restauration de tous les caches n’est pas une décision neutre.

La nouveauté cache-mode, annoncée par GitHub le 10 septembre, rend cette séparation explicite. Le mode read restaure sans sauvegarder ; write lit et écrit ; write-only sauvegarde sans restaurer ; none coupe l’accès. Un réglage au niveau du job prend le pas sur celui du workflow, et les appels de workflows réutilisables ne peuvent pas recevoir davantage d’accès que leur appelant.

Sécuriser le cache GitHub Actions par contexte

La bonne configuration dépend de votre chaîne de livraison, pas d’une règle universelle. L’objectif est de séparer les étapes qui produisent des livrables de confiance de celles qui analysent une proposition de changement. Le cache peut ainsi rester un accélérateur, sans devenir un canal implicite entre ces contextes.

Un découpage pragmatique

1. Lister les caches utiles : dépendances, images de build, outils ou résultats intermédiaires, puis identifier les jobs qui les restaurent et ceux qui les produisent.
2. Réserver l’écriture aux flux maîtrisés : une branche protégée ou un pipeline de livraison peut conserver write si cela correspond à votre politique.
3. Réduire les droits des validations externes : attribuer read, write-only ou none selon ce que le test doit réellement faire.
4. Vérifier les workflows appelés : une réutilisation ne doit pas élargir les privilèges décidés à l’entrée du pipeline.

Ne pas confondre vitesse et confiance

GitHub conserve des valeurs par défaut adaptées aux événements à faible confiance et ajoute un avertissement lorsqu’un workflow demande une écriture dans ce contexte. Il est donc préférable de partir d’un accès minimal, puis de documenter chaque exception liée à un besoin réel de performance. Une exécution plus rapide ne doit pas faire disparaître la question : qui a pu influencer les éléments réutilisés par ce job ?

Ce réglage complète les autres protections du pipeline : permissions minimales du jeton, actions tierces épinglées, revue du code et analyses de sécurité. Il ne remplace pas ces contrôles ; il rend la frontière entre les workflows plus lisible et plus facile à faire évoluer.

Une amélioration à intégrer dans votre routine CI

Commencez par un dépôt représentatif, observez les restaurations et sauvegardes nécessaires, puis appliquez la règle aux workflows comparables. Cette approche évite de couper brutalement un cache qui soutient la livraison tout en faisant de la sécurité une propriété vérifiable de votre automatisation. La publication officielle de GitHub détaille les modes et leur portée.