GitHub Actions sécurise ses caches avec cache-mode

GitHub généralise cache-mode, un réglage qui applique le principe du moindre privilège au cache de GitHub Actions. Une équipe peut désormais autoriser la lecture, l'écriture, l'écriture seule ou désactiver totalement le cache, au niveau d'un workflow comme d'un job.

La réponse rapide

Pourquoi le cache est une frontière de sécurité

Un cache accélère les installations et les compilations, mais il transporte aussi des fichiers entre plusieurs exécutions. Si un workflow peu fiable peut écrire dans une clé ensuite consommée par un déploiement privilégié, il peut tenter d'y placer un artefact malveillant. Le gain de temps devient alors un canal de propagation.

GitHub applique déjà des valeurs prudentes : les événements à faible confiance comme pull_request_target sont en lecture seule, tandis qu'un push de confiance conserve la lecture et l'écriture. Les workflows existants gardent ces défauts s'ils ne déclarent rien.

Un contrôle précis, y compris pour les workflows réutilisables

Le réglage d'un job l'emporte sur celui du workflow. Surtout, un workflow réutilisable ne peut pas recevoir davantage de droits que son appelant. Cette contrainte évite qu'une brique partagée réactive discrètement l'écriture dans un contexte où elle a été retirée.

GitHub avertit aussi lorsqu'un workflow accorde explicitement write ou write-only à un événement peu fiable. L'annotation ne remplace pas une revue, mais rend une exception risquée visible dans l'interface.

Comment l'adopter sans casser la CI

Commencez par inventorier les jobs qui restaurent ou sauvegardent réellement un cache. Les tests d'une pull request ont souvent seulement besoin de read; un job de construction sur la branche principale peut conserver write. Les étapes de publication qui n'utilisent pas le cache peuvent passer à none.

Surveillez ensuite les temps de pipeline et les échecs de restauration. Le mode write-only convient à un job chargé de produire un cache propre sans consommer un état précédent. Il doit rester rare et documenté.

Ce que les équipes doivent retenir

cache-mode ne corrige pas une action compromise et ne remplace ni l'épinglage des dépendances ni la protection des secrets. Il ferme cependant une permission implicite importante. Disponible pour tous les forfaits GitHub, il donne aux responsables CI un moyen simple de séparer les workflows qui consomment un cache de ceux qui sont autorisés à le publier.