Cache trop ouvert ou droits difficiles à vérifier ? → définissez le mode au niveau le plus précis nécessaire, puis contrôlez son effet dans les journaux d’exécution. Pour votre Mac CI, le réglage d’un Job prévaut sur celui du flux de travail ; n’accordez donc pas une capacité d’écriture générale aux tâches qui n’en ont pas besoin. Les événements à faible niveau de confiance exigent une analyse particulière du risque d’empoisonnement du cache.

Cet article s’adresse aux développeurs qui entretiennent des caches de compilation pour des projets Apple, aux responsables de sécurité qui encadrent les événements de contribution, et aux équipes de plateforme qui déploient des flux réutilisables sur plusieurs dépôts.

Dernière mise à jour : 28 septembre 2026. Vérification effectuée à partir de l’annonce de GitHub sur cache-mode et de la documentation officielle sur la syntaxe des flux de travail. (annonce de lancement, référence de syntaxe)

GitHub Actions cache-mode pour Mac CI : les permissions à distinguer

Le changement important n’est pas de rendre chaque compilation plus rapide : c’est de pouvoir adapter l’accès au cache à la fonction et au niveau de confiance de chaque tâche. GitHub indique que cache-mode est disponible pour tous les forfaits et que le réglage peut être défini au niveau du flux de travail ou d’un Job. La documentation précise que le réglage du Job a priorité sur celui du flux de travail.

Pour décider, séparez trois capacités :

  • Restaurer un cache existant pour éviter de retélécharger ou de reconstruire des dépendances.
  • Enregistrer un cache à la fin d’une tâche, ce qui modifie les données mises à disposition d’exécutions ultérieures.
  • N’accéder à aucun cache lorsque la tâche ne doit ni lire ni écrire ces données.

Cette séparation importe dans un projet Apple parce qu’un même flux peut exécuter des tâches de confiance différente. Une compilation de branche protégée, une validation de demande de fusion et une tâche de maintenance ne justifient pas automatiquement les mêmes droits. Les fichiers de dépendances, les clés de cache et les étapes de sauvegarde doivent donc être examinés ensemble : une permission trop large peut ouvrir un chemin d’écriture dont la tâche n’a pas besoin.

La mise en cache n’est pas un mécanisme d’isolation complet. GitHub rappelle que des caches peuvent être accessibles selon le contexte des branches et des exécutions, et que des données empoisonnées peuvent influencer des tâches ultérieures. Les recommandations officielles sur la sécurité de la mise en cache des dépendances doivent donc compléter votre choix de mode, et non le remplacer.

Comparaison des modes selon la tâche

Le tableau ci-dessous sert à choisir une politique, pas à prédire un gain de temps. Les notes sont une appréciation éditoriale de l’adéquation au principe du moindre privilège ; elles ne représentent ni un résultat de mesure ni une garantie de sécurité.

Option d’accès Usage adapté Point de contrôle Appréciation
Lecture et restauration sans enregistrement Tâche de validation qui peut profiter d’un cache existant, mais ne doit pas le mettre à jour Confirmer dans les journaux que la restauration fonctionne et qu’aucune sauvegarde n’est effectuée 4/5 si la tâche n’a pas à publier de nouvelles dépendances
Lecture et écriture Compilation de confiance qui doit restaurer puis enregistrer un cache renouvelé Vérifier qui peut déclencher la tâche et d’où proviennent les fichiers incorporés au cache 3/5, réservé aux exécutions justifiées
Aucun accès au cache Tâche sensible, diagnostic isolé ou scénario de référence sans réutilisation Confirmer que la tâche ne restaure ni ne publie de cache 5/5 pour réduire l’exposition du cache, avec le coût éventuel de reconstruire les dépendances

Les capacités doivent être traduites dans les valeurs exactes proposées par la documentation en vigueur : évitez de recopier une valeur supposée à partir d’un exemple ancien ou d’un autre mécanisme de permission. L’annonce et la référence de syntaxe de GitHub font foi pour la configuration acceptée.

Le réglage d’un Job prévaut-il sur celui du flux de travail ?

Oui. Si le flux de travail déclare une politique générale et qu’un Job en déclare une autre, c’est le réglage du Job qui détermine l’accès de ce Job, conformément à la documentation de GitHub. Cela permet de donner une base prudente à l’ensemble du flux, puis d’ouvrir une capacité précise uniquement pour le travail qui la nécessite.

Cette priorité est utile, mais elle peut aussi rendre une configuration trompeuse. Une politique restrictive au niveau général ne prouve pas qu’un Job particulier est restreint : un réglage local peut changer le résultat. Inversement, une politique générale autorisant l’écriture peut exposer des Jobs qui n’en ont pas besoin, si aucun réglage plus précis ne les limite.

Pour vérifier l’intention, examinez chaque Job susceptible de restaurer ou d’enregistrer un cache et notez :

  • le réglage défini au niveau du flux de travail ;
  • le réglage défini localement dans le Job, s’il existe ;
  • la capacité attendue pour ce Job, avec une justification liée à sa fonction.

Un contrôle statique du fichier de configuration permet de repérer les divergences, mais ne suffit pas à prouver que le comportement à l’exécution correspond à l’intention. Faites aussi tourner le flux dans un dépôt de test contrôlé et consultez les journaux associés aux étapes de cache. Si un Job enregistre encore un cache alors que sa tâche est censée seulement en restaurer un, resserrez d’abord son réglage local ; si le comportement persiste, contrôlez l’architecture du flux et les actions appelées avant de généraliser la modification.

Les flux déclenchés par pull_request_target doivent-ils pouvoir écrire dans le cache ?

Ne leur accordez pas l’écriture par défaut. Ce déclencheur a des implications de sécurité spécifiques : GitHub avertit que son utilisation peut exposer un dépôt à des risques si le flux exécute du code ou traite des données provenant d’une contribution non fiable avec des privilèges excessifs. L’accès en écriture au cache doit donc être examiné comme une capacité sensible, et pas comme une simple optimisation. (guide officiel sur l’utilisation sécurisée de pull_request_target)

Le risque d’empoisonnement du cache apparaît lorsqu’un contenu contrôlé par une source peu fiable peut contribuer à des données ensuite réutilisées par une exécution de confiance. Le mode de cache aide à réduire les possibilités d’accès, mais ne prouve pas, à lui seul, que les clés, les chemins, les scripts ou les actions utilisés sont sûrs. Il ne garantit pas non plus l’élimination de toute attaque par cache.

Avant d’autoriser l’écriture, vérifiez donc que le flux n’exécute pas de code non fiable avec des permissions excessives, que les données sauvegardées sont déterminées par des entrées que vous contrôlez et que les exécutions de confiance ne consomment pas sans contrôle un état produit par une demande de fusion. Si vous ne pouvez pas démontrer ces conditions, retirez l’écriture à la tâche concernée ou désactivez l’accès au cache pour ce parcours. Pour une vue plus large des précautions à prendre, consultez le guide GitHub sur l’utilisation sécurisée des Actions.

Un flux réutilisable peut-il dépasser les permissions accordées par l’appelant ?

Non : un flux réutilisable ne peut pas obtenir une permission supérieure à celle que l’appelant lui accorde. Cette limite ne dispense pas de vérifier les deux côtés. Le dépôt appelant détermine les permissions disponibles pour l’appel, tandis que le flux appelé définit la manière dont il les utilise dans les Jobs concernés. La documentation GitHub sur les flux de travail réutilisables décrit ces règles de transmission.

Pour un déploiement Mac CI, examinez l’appel et la définition appelée comme un seul ensemble :

  • Dans le dépôt appelant, relevez les permissions effectivement accordées au flux réutilisable.
  • Dans le dépôt contenant le flux appelé, vérifiez si un réglage local de Job modifie le niveau d’accès au cache.
  • Dans le dépôt de test, exécutez un scénario autorisé à restaurer, puis un scénario devant pouvoir enregistrer, et comparez les résultats avec l’intention documentée.
  • Si l’appelant n’accorde pas une capacité nécessaire, corrigez son autorisation seulement après avoir établi pourquoi le flux appelé en a besoin.
  • Si le flux appelé demande une capacité inutile, réduisez son accès au lieu d’élargir les droits de tous ses appelants.

Un appel réutilisable ne doit pas être traité comme une frontière de sécurité qui rendrait automatiquement sûr un réglage large. Les droits hérités, le code exécuté et les données de cache doivent rester cohérents avec le niveau de confiance du dépôt et de l’événement.

Preuves d’acceptation : droits, journaux et résultat de compilation

Un cache qui semble fonctionner n’est pas la preuve que ses permissions sont correctes. Un temps de compilation plus court ne démontre ni que le Job a uniquement restauré des données, ni qu’une tâche non fiable ne peut pas écrire. Séparez trois critères d’acceptation :

  • Autorisation prévue : le réglage effectif du flux et celui de chaque Job correspondent à la politique décidée.
  • Comportement du cache : les journaux indiquent si une restauration ou une sauvegarde a été tentée et si elle a réussi.
  • Résultat Apple : le Job termine ou échoue sur ses étapes de compilation, de test ou de traitement des ressources Xcode.

Un résultat de compilation doit être évalué indépendamment des droits d’accès. Si un cache ne peut pas être restauré, vérifiez d’abord la politique attendue, la clé, les chemins et les traces des étapes concernées ; ne concluez pas immédiatement que la compilation est cassée. Si la compilation réussit, ne concluez pas davantage que le cache est correctement protégé.

GitHub fournit également une documentation pour consulter et gérer les caches. Appuyez-vous sur les journaux d’exécution et les outils de gestion disponibles pour confirmer le comportement observé, mais gardez une trace distincte de la règle attendue. En cas d’écart, le correctif dépend du constat : retirer l’écriture si une sauvegarde était inattendue, rétablir le droit de lecture si une restauration autorisée échoue, ou désactiver le cache pour isoler un scénario difficile à auditer.

Procédure de déploiement et de retour arrière

Appliquez la politique progressivement plutôt que de modifier tous les dépôts à la fois.

Définissez les catégories de tâches. Classez chaque Job selon son rôle : validation de contribution, compilation de confiance, publication ou diagnostic. Pour chaque catégorie, écrivez si elle doit restaurer, enregistrer ou ne pas accéder au cache. Cette décision évite de confondre « ce Job utilise une compilation » avec « ce Job a besoin d’écrire ».

Choisissez la portée du réglage. Utilisez le niveau du flux de travail pour établir une règle générale, puis un réglage de Job uniquement lorsqu’une tâche a un besoin différent. Cette organisation rend les exceptions visibles. Référez-vous à la syntaxe officielle des flux de travail pour les règles et les valeurs acceptées.

Inspectez les déclencheurs. Repérez les demandes de fusion, les événements provenant de dépôts externes et toute utilisation de pull_request_target. Pour chaque parcours à faible confiance, décidez si la lecture est acceptable et si l’écriture est vraiment nécessaire. En l’absence d’une justification et d’un test convaincants, n’accordez pas le droit de sauvegarde.

Vérifiez les appels réutilisables. Comparez les permissions accordées par l’appelant avec celles demandées ou configurées dans le flux appelé. Corrigez la source du décalage au niveau concerné, sans donner par défaut des droits plus élevés à l’ensemble des dépôts.

Testez dans un dépôt représentatif. Choisissez un projet Apple dont le flux comporte à la fois une tâche de validation et une compilation de confiance. Contrôlez les journaux des étapes de cache et le résultat de compilation séparément. Si le dépôt utilise Xcode, ne confondez pas une erreur de résolution de dépendances, une erreur de construction et un refus d’accès au cache.

Documentez et déployez par étapes. Conservez, pour chaque catégorie de tâche, la justification du mode retenu, le scénario testé, le résultat attendu et la procédure de retour arrière. Si le comportement observé n’est pas conforme, rétablissez la dernière configuration vérifiée, réduisez les permissions du Job en cause et reprenez les essais avant de propager le changement aux autres dépôts.

Cette séquence fournit des éléments d’audit réutilisables : intention, configuration, traces et décision de correction. Elle évite également qu’un cache apparemment performant masque une permission plus large que prévu.

Étendre les contrôles sans confondre sécurité et matériel

La politique cache-mode concerne les droits d’accès au cache. Elle ne valide pas à elle seule les versions de Xcode, les outils de signature, la conservation des artefacts, les secrets ou les étapes de livraison. Pour une équipe qui met en place un poste distant de test, les modalités d’accès et les besoins matériels restent également à évaluer. Vous pouvez consulter les informations de SSHMac sur l’accès VNC à un Mac et sur la location d’un Mac mini lorsque vous comparez un environnement local à un environnement Mac distinct.

Un Mac déjà disponible peut convenir si les exécutions sont occasionnelles, si vous pouvez isoler proprement les projets et si les tâches ne nécessitent pas une capacité d’exécution dédiée. En revanche, une machine partagée entre développement quotidien et essais de CI peut compliquer la séparation des environnements, laisser des dépendances ou des états locaux difficiles à reproduire, et imposer de maintenir un poste disponible pendant les tests. L’achat d’une machine réservée à ces essais évite certaines collisions, mais immobilise du matériel si le besoin est temporaire ou limité à des validations ponctuelles.

La location via SSHMac peut être une option à évaluer lorsque vous avez besoin d’un environnement Mac temporaire sans réserver immédiatement une machine à l’achat. Elle ne remplace pas une politique de permissions correctement configurée et ne convient pas à tous les cas : si vos tâches sont continues et fortement sollicitées, si elles exigent des périphériques physiques précis ou si vous devez maîtriser entièrement le matériel sur site, un Mac détenu et administré par votre équipe peut être plus approprié. Pour choisir, comparez la durée d’usage prévue, les contraintes d’accès, la reproductibilité requise et la charge de maintenance, puis validez les droits de cache séparément du choix de la machine.