Comment configurer cache-mode dans GitHub Actions ? Guide 2026 contre l’empoisonnement du CI Mac en entreprise

Le 10 septembre 2026, GitHub a annoncé une commande cache-mode destinée à contrôler l’accès au cache des workflows dans son annonce officielle. Décision à appliquer : réservez read ou none aux tâches dont le code n’est pas fiable, et laissez les workflows de confiance gérer les écritures. cache-mode limite les accès au cache ; il ne nettoie pas un Mac Runner et ne sépare ni les fichiers de travail ni les identifiants.

Cette analyse s’adresse aux responsables IT et plateforme qui définissent la politique GitHub Actions d’une entreprise.
Elle aide les responsables iOS et macOS CI à examiner le passage du risque du cache aux tâches exécutées sur de vrais Mac.
Les responsables sécurité peuvent s’en servir pour vérifier la séparation entre code non fiable, tâches de production et identifiants de signature.

Dernière vérification : 24 septembre 2026, à partir de l’annonce GitHub et de la documentation officielle sur la syntaxe, les caches et la sécurité des Runner. Vérifiez ces pages avant déploiement : les comportements et le périmètre pris en charge peuvent évoluer.

Les modes de cache ne donnent pas tous les mêmes droits

Choisissez le mode d’après les deux opérations réellement nécessaires : restaurer un cache existant et enregistrer un nouvel état. L’annonce de GitHub décrit quatre modes, mais la portée d’un cache reste aussi liée aux règles de clé et de branche documentées par GitHub. Le tableau résume la décision d’accès ; vérifiez la syntaxe exacte et les valeurs acceptées dans la référence officielle de la syntaxe des workflows.

Cette distinction répond au choix entre lecture, écriture et absence d’accès : write autorise l’usage du cache existant autant que son actualisation, tandis que write-only évite la restauration. Utilisez none lorsque même une entrée de cache potentiellement contrôlée par une tâche antérieure est indésirable. Si un workflow ne déclare pas explicitement son mode, ne déduisez pas son comportement d’un ancien fichier YAML : confirmez la valeur par défaut applicable dans la documentation de la version et de l’action réellement utilisées.

Le mode porte sur l’accès au cache, pas sur l’autorisation générale du workflow. Les permissions GITHUB_TOKEN, les secrets disponibles, le code exécuté et les accès réseau constituent des contrôles distincts. Consultez la syntaxe officielle des workflows pour régler les permissions du jeton séparément.

Pour les configurations d’entreprise, attribuez une note d’adéquation plutôt qu’une impression vague : favorable si la tâche est fiable, ses entrées sont maîtrisées et son besoin d’écriture est justifié ; conditionnelle si elle ne doit que restaurer des dépendances contrôlées ; défavorable si du code non fiable peut écrire dans un cache consommé par une tâche privilégiée. Cette appréciation est un outil de revue de politique, pas une mesure de sécurité fournie par GitHub.

Quel mode choisir pour un workflow pull_request ?

Un workflow pull_request qui compile du code soumis depuis un fork doit être traité comme une tâche à entrées non fiables. Donnez-lui read seulement si la restauration est nécessaire, si le contenu récupéré est traité comme une entrée non fiable et si l’interface du cache ne lui permet pas de modifier le cache de confiance. Sinon, choisissez none. Ne lui accordez pas write au seul motif que la compilation échoue sans sauvegarde.

GitHub documente les limites d’accès aux caches selon les branches et les événements ; vérifiez-les dans la référence sur la mise en cache des dépendances. La conséquence opérationnelle est importante : la séparation entre clés et portées réduit certains croisements, mais ne remplace pas une règle d’accès explicite.

Le déclencheur détermine si une tâche peut publier un cache

Un nom de branche ne constitue pas une preuve de confiance. Il faut examiner qui peut déclencher l’événement, quel code le workflow récupère, quels secrets sont accessibles et si une étape exécute des scripts issus de la demande de fusion. La documentation des événements qui déclenchent les workflows précise les contextes associés aux déclencheurs ; faites cette vérification avant d’associer un mode d’écriture.

Un événement pull_request_target est particulièrement sensible : il s’exécute dans le contexte du dépôt de base. La documentation de sécurité de GitHub sur pull_request_target met en garde contre l’exécution de code non fiable dans ce contexte. Une étape qui récupère puis exécute le code de la demande peut faire passer une entrée externe dans un workflow privilégié ; lui donner un mode de cache restrictif ne corrige pas cette erreur de conception.

Pour transférer un résultat vers un workflow de confiance, séparez la production et la consommation. Le workflow non fiable peut produire un artefact limité, sans secret et sans droit d’écriture sur le cache partagé. Un workflow distinct doit alors valider la provenance, le contenu et le format avant de réutiliser ou de mettre à jour un cache. N’accordez pas un droit d’écriture simplement parce que le déclencheur aval est réputé fiable : les données qu’il reçoit peuvent venir d’une tâche à risque.

Comment empêcher une demande non fiable d’écrire dans le cache d’une branche protégée ?

Faites appliquer la politique au workflow qui reçoit le code, pas uniquement au nom de la clé. Attribuez read ou none aux tâches de demandes de fusion non fiables, supprimez toute voie d’écriture indirecte, et réservez l’actualisation des caches à un workflow de confiance déclenché après les contrôles requis. Les restrictions de portée indiquées par GitHub sont un garde-fou supplémentaire, non une autorisation de fusionner sans examen des chemins d’exécution.

Les clés et le contenu restauré fixent l’étendue de l’impact

Un cache contient des données réutilisées par une tâche ultérieure. Il peut s’agir de dépendances, de résultats de compilation ou d’autres fichiers de travail ; si un élément restauré est ensuite exécuté ou interprété, son origine et son intégrité comptent. La documentation GitHub sur la sécurité des caches rappelle de ne pas y placer de secrets ou de données sensibles et de traiter avec prudence les contenus accessibles depuis des workflows moins fiables. Reportez-vous à la documentation officielle sur les risques de sécurité de la mise en cache.

Examinez les clés comme des règles de partage. Une clé trop générale peut faire réutiliser un état entre des tâches qui n’ont ni le même niveau de confiance ni les mêmes dépendances. Une clé dérivée de fichiers de verrouillage et du contexte utile au projet aide à éviter les collisions accidentelles, mais ne prouve pas que les fichiers restaurés sont sûrs. Les clés de restauration de secours élargissent encore les correspondances possibles : documentez chaque préfixe et vérifiez ce qu’il peut sélectionner.

Pour un projet Xcode CI, distinguez les téléchargements de dépendances des produits de compilation susceptibles d’être exécutés. Ne mettez pas dans le cache de jeton d’accès, de certificat de signature, de profil contenant des informations sensibles ou de configuration secrète. Contrôlez aussi les scripts de préparation de dépendances : restaurer un cache puis lancer automatiquement un script issu d’un état dont la provenance est incertaine associe le risque de cache à celui de l’exécution.

Un cache peut accélérer une compilation sans être une source de vérité. Si une tâche privilégiée dépend d’un état restauré, définissez qui peut le produire, comment sa clé est construite et quel contrôle s’applique avant son exécution.

La documentation générale de GitHub sur les caches de dépendances explique leur rôle et leur fonctionnement. Servez-vous-en pour identifier les données réellement réutilisées, puis appliquez séparément les règles de confiance propres à votre dépôt. Le mode ne valide pas le contenu du cache ; il contrôle les opérations autorisées dans le contexte prévu par GitHub.

Un droit distant ne nettoie pas un Mac Runner persistant

Le cache GitHub et l’état local d’un self-hosted Mac Runner sont deux surfaces différentes. Même avec none, un processus exécuté sur un Runner persistant peut laisser des fichiers dans le répertoire de travail, modifier des outils installés ou tenter d’accéder à des identifiants accessibles à la tâche. Le mode de cache ne réinitialise pas macOS, ne supprime pas les clés présentes sur le disque et ne cloisonne pas des utilisateurs qui partagent le même hôte.

La documentation GitHub sur l’utilisation sécurisée des Runner auto-hébergés insiste sur les risques qu’entraîne l’exécution de workflows dans une infrastructure que l’entreprise contrôle. Traduisez ces recommandations en limites concrètes : séparez les groupes de Runner selon la confiance des tâches, ne rendez pas un Runner privilégié accessible aux demandes externes, et privilégiez un environnement éphémère ou reconstruit après une tâche sensible lorsque votre architecture le permet.

Les droits de cache protègent-ils un Mac Runner persistant ?

Non. Ils limitent l’accès au cache selon le mode configuré, mais ils n’isolent pas le système hôte. Pour protéger un Mac persistant, vous devez aussi traiter la durée de vie du compte, les répertoires de travail, les processus résiduels, les outils modifiables, les secrets et les identifiants de signature. Si vous ne pouvez pas prouver qu’une tâche non fiable ne peut pas affecter une tâche suivante, ne réutilisez pas le même environnement privilégié pour les deux.

Dans une chaîne de build iOS, séparez au minimum les tâches de validation de code et les tâches disposant d’identifiants de signature de production. Une compilation de demande de fusion ne devrait pas hériter automatiquement des certificats, des profils ni du contexte local du travail de publication. Faites correspondre cette séparation à des groupes de Runner et à des permissions de workflow distincts, puis vérifiez qu’aucune étape de transfert ne réintroduit les mêmes droits.

Si votre équipe évalue des nœuds Mac ou compare les coûts d’un parc, la présentation des tarifs Mac mini peut aider à cadrer le choix matériel. Elle ne remplace pas une revue de sécurité : les règles d’accès, le nettoyage de l’environnement et la séparation des identifiants doivent être établis et vérifiés dans votre propre configuration.

Validez la politique avec des preuves de restauration et d’écriture

Avant le déploiement général, testez des cas contrôlés dans un dépôt de validation. Comparez un workflow de confiance et un workflow non fiable, puis examinez les journaux de restauration et de sauvegarde. Ne concluez pas qu’un cache est inaccessible simplement parce qu’une compilation a réussi : vous devez confirmer le mode effectif, l’absence d’écriture là où elle est interdite et le comportement en cas d’échec.

Utilisez cette liste lors de la revue conjointe entre plateforme, sécurité et équipe iOS :

• [ ] Identifier chaque déclencheur et classer la provenance du code exécuté, y compris les scripts de dépendances.
• [ ] Définir explicitement read, write, write-only ou none pour chaque type de workflow.
• [ ] Vérifier la syntaxe et le comportement attendu dans la documentation GitHub applicable à la configuration déployée.
• [ ] Contrôler les clés, les préfixes de restauration et les branches susceptibles de partager ou de restaurer un cache.
• [ ] Confirmer qu’aucun secret, certificat, profil de signature ou autre donnée sensible n’est enregistré dans le cache.
• [ ] Comparer les journaux d’une tâche de confiance et d’une tâche non fiable pour vérifier restauration, absence d’écriture et résultat en cas d’échec.
• [ ] Examiner séparément les permissions de GITHUB_TOKEN, les secrets disponibles et les règles réseau.
• [ ] Vérifier qu’un Runner qui reçoit du code non fiable ne conserve pas un état exploitable par une tâche privilégiée ultérieure.
• [ ] Consigner le responsable de l’approbation, les exceptions et la condition qui déclenche une nouvelle revue.

Évaluez ensuite la preuve de bout en bout. Favorable : mode explicite, journaux cohérents, cache sans données sensibles, et environnement Runner approprié à la confiance des tâches. Conditionnel : les droits de cache sont maîtrisés, mais le nettoyage ou la séparation des identifiants reste à démontrer. Défavorable : une tâche non fiable peut écrire un état consommé par la production, ou le Runner persistant conserve un état dont l’origine n’est pas vérifiée. Dans ce dernier cas, bloquez l’accès aux tâches de signature jusqu’à correction.

La règle d’entreprise doit séparer cache, hôte et signature

Vous pouvez inscrire la règle suivante dans votre politique de plateforme : « Les tâches dont le code n’est pas fiable utilisent read uniquement lorsque la restauration est nécessaire et justifiée, sinon none. Seuls les workflows approuvés peuvent utiliser write ou write-only. Aucun cache ne contient de secret. Les tâches non fiables n’accèdent pas aux Runner ni aux identifiants de signature réservés à la production. »

Adaptez cette règle à vos contrôles de revue et à vos besoins de build, sans traiter la mise en cache comme une frontière de sécurité complète. Si la vérification du mode, des journaux, du nettoyage et des identifiants est concluante, vous pouvez étendre le pilote. Si la confiance du code ou l’état local du Mac reste incertain, gardez les tâches séparées et corrigez l’environnement avant toute montée en charge.

Les workflows exécutés sur des Mac locaux peuvent offrir un contrôle direct, mais exigent l’achat, l’entretien et la sécurisation de machines disponibles pour l’équipe. Une infrastructure distante peut éviter d’immobiliser immédiatement du matériel, mais elle ne dispense pas de définir vos politiques d’accès, de persistance et de secrets ; une instance cloud généraliste ne garantit pas non plus, à elle seule, l’isolation requise. Si votre besoin est temporaire — valider une architecture, tester une séparation de tâches ou compléter une capacité Mac — la location d’un Mac auprès de MacDate peut être comparée à ces options sans présumer de mécanismes de nettoyage ou de garanties non documentés. Consultez les options MacDate puis vérifiez les contrôles et les conditions adaptés à votre organisation avant d’y placer une tâche sensible.