GitHub Actions : le Mac Runner auto-hébergé est-il sûr ? Liste de contrôle 2026

GitHub avertit que du code de workflow non fiable peut compromettre un Runner auto-hébergé et les secrets auxquels il a accès (guide officiel sur l’utilisation sécurisée de GitHub Actions). Cette semaine, vérifiez les déclencheurs, les autorisations et le nettoyage avant de confier des identifiants de signature à un Mac Runner auto-hébergé dans GitHub Actions. Un dépôt privé ou une approbation d’environnement ne suffit pas à prouver que les tâches sont isolées. Si vous ne pouvez pas séparer les modifications non fiables des tâches de publication signées, n’utilisez pas ce Runner pour publier en production.

Vous préparez l’intégration de GitHub Actions et d’un Mac auto-hébergé pour compiler une app iOS : ce contrôle vous aidera à décider si l’environnement peut recevoir des secrets.
Vous gérez des certificats, des clés ou des identifiants de publication en petite équipe : vous pourrez vérifier qui peut y accéder et à quel moment.
Vous partagez des Runners entre dépôts ou équipes : vous pourrez déterminer si cette mutualisation est défendable ou si elle doit être limitée.

Sécurité d’un Mac Runner auto-hébergé : les frontières à prouver

La sécurité d’un Runner dépend de plusieurs frontières distinctes, et non du fait que l’ordinateur soit un Mac. Il faut savoir qui peut déclencher du code, quels droits possède la tâche, quels secrets lui sont accessibles, qui peut planifier du travail sur l’hôte et ce qui reste après la tâche. Une compilation réussie ne démontre rien sur ces frontières.

Pour orienter votre examen, distinguez les éléments suivants :

• Confiance dans le code : le changement provient-il d’une branche contrôlée ou d’une contribution dont vous n’avez pas vérifié le contenu ?
• Droit de déclencher : quel événement démarre le workflow, et la personne à l’origine de l’événement peut-elle influencer le code exécuté ?
• Droits du workflow : quelles actions le jeton GITHUB_TOKEN peut-il effectuer sur le dépôt ?
• Accès à la machine : quels dépôts et workflows peuvent envoyer des tâches à ce Runner ?
• État résiduel : le travail suivant peut-il retrouver un fichier, un trousseau ou une trace laissé par le précédent ?

Le guide de GitHub recommande de traiter avec prudence le code non fiable et les Runners auto-hébergés. Les protections liées aux environnements peuvent régir l’accès à un secret ou l’approbation d’un déploiement, mais elles ne transforment pas à elles seules une machine partagée en environnement isolé. Votre preuve doit porter sur le chemin réel entre le déclencheur, le code récupéré, les secrets et l’hôte.

PR externes : valider le code sans lui donner les clés

Une contribution externe peut être utile à tester sans être digne de confiance pour signer une version. La question importante n’est donc pas seulement de savoir si vous acceptez les PR, mais de vérifier quel événement les déclenche, quel code est exécuté et sur quel Runner.

L’événement pull_request et l’événement pull_request_target n’ont pas les mêmes implications de sécurité. GitHub explique que pull_request_target s’exécute dans le contexte de la branche de base et avertit du risque associé à l’exécution de code fourni par la PR dans ce contexte (documentation des événements déclencheurs et guide de sécurité de pull_request_target). Ne faites pas récupérer et exécuter automatiquement le code de la contribution par une tâche privilégiée sous prétexte qu’un autre événement a démarré le workflow.

Examinez la configuration complète, pas seulement le nom du déclencheur :

• La tâche de validation s’exécute-t-elle sur un Runner sans certificat, clé privée ni identifiant App Store Connect ?
• Le workflow récupère-t-il le commit de la PR, la branche de base ou une autre référence ?
• Une étape de validation déclenche-t-elle ensuite un workflow disposant de secrets ?
• Un script provenant du dépôt peut-il modifier le comportement d’une tâche privilégiée ?
• Les journaux ou artefacts de la validation peuvent-ils être réutilisés par une tâche de publication sans contrôle ?

Le tableau suivant sert à distinguer les usages. Il décrit des conditions de décision, pas une garantie automatique de sécurité.

Une PR provenant d’un dépôt public peut donc être testée, mais la validation doit être conçue comme une exécution de code potentiellement hostile. Un dépôt privé n’est pas une preuve suffisante : une personne ayant le droit de modifier un workflow, un script ou une dépendance peut changer ce que la machine exécute.

Branches de confiance : réduire les droits au lieu de les présumer

Un workflow exécuté sur une branche de confiance n’a pas automatiquement besoin de droits étendus. Pour chaque tâche, établissez les opérations réellement nécessaires et comparez-les à la configuration permissions. GitHub documente la syntaxe qui permet de définir les autorisations du jeton au niveau du workflow ou de la tâche (référence de la syntaxe des workflows).

Vérifiez les points suivants dans le fichier de workflow et dans les paramètres du dépôt :

• Le jeton peut-il écrire dans le dépôt, publier une version ou modifier un contenu qui n’est pas nécessaire à la tâche ?
• Les autorisations sont-elles déclarées au périmètre le plus étroit possible, plutôt que laissées à une valeur implicite ?
• Les actions tierces sont-elles identifiées et leur version est-elle fixée de manière contrôlable ?
• Qui peut modifier le workflow et les scripts appelés par celui-ci ?
• Quels dépôts peuvent planifier des tâches sur le Runner, et qui peut changer cette liste ?

Le code d’une action tierce s’exécute dans le cadre du workflow : traiter sa provenance et sa version comme des détails décoratifs serait une erreur. Gardez une trace des actions utilisées, du motif de leur présence et du mécanisme retenu pour éviter qu’une modification inattendue change leur contenu. Lorsqu’une action peut lire un secret, examinez aussi les étapes qui la précèdent et la suivent.

Le statut « réussi » d’un build ne valide pas ces réglages. Une compilation peut aboutir alors que le jeton dispose de droits excessifs ou qu’un workflow non nécessaire est autorisé à envoyer des tâches à la même machine. Le contrôle porte sur la configuration qui rend la réussite possible, pas uniquement sur le résultat produit.

Signature iOS : réserver l’identité aux tâches qui en ont besoin

Une tâche de compilation et une tâche de publication ne devraient pas recevoir les mêmes accès par commodité. Faites l’inventaire des certificats, des clés privées et des identifiants App Store Connect, puis associez chaque élément à une tâche et à un besoin précis. Apple décrit l’identité de signature comme reposant sur un certificat de développement et la clé privée correspondante (documentation Apple sur le partage des certificats de signature). Le certificat seul ne représente donc pas toute l’identité à protéger.

Pour votre gestion des justificatifs de signature iOS, vérifiez le chemin complet :

• La clé privée n’est-elle importée que par le travail qui doit signer ?
• Le trousseau est-il verrouillé ou supprimé selon une procédure vérifiable à la fin du travail ?
• Les secrets sont-ils absents des arguments de commande, des scripts enregistrés et des sorties de diagnostic ?
• Les fichiers temporaires, les archives et les artefacts issus d’un échec sont-ils inspectés avant conservation ou transfert ?
• Les identifiants App Store Connect sont-ils limités au besoin de publication plutôt que mis à disposition de toutes les compilations ?

Évitez de placer une clé dans un fichier suivi par Git ou dans un exemple de configuration réutilisable. Ne publiez pas de valeur réelle dans les journaux, même temporairement, et ne supposez pas qu’un fichier est protégé parce qu’il se trouve dans un répertoire de travail. Les tâches qui exécutent des scripts du projet peuvent lire les fichiers auxquels le compte de l’agent a accès.

Si la signature est nécessaire à chaque build de confiance, séparez au minimum les autorisations et le parcours d’accès aux secrets. Si la signature ne sert qu’à la distribution, réservez-la à la tâche de publication et examinez ses déclencheurs indépendamment de ceux des tests.

Tâches successives : vérifier ce que le Mac conserve réellement

Un Runner auto-hébergé ne doit pas être considéré comme un environnement propre après chaque tâche. La documentation GitHub sur les Runners auto-hébergés décrit les précautions à prendre face au code exécuté et à la persistance de l’environnement (référence des Runners auto-hébergés). L’inscription temporaire ou la suppression d’un enregistrement ne prouve pas, à elle seule, que le système sous-jacent a été nettoyé.

Vérifiez, dans l’ordre, ce qui peut subsister après la fin d’une tâche :

1. Répertoire de travail : les sources, scripts générés et dépendances temporaires sont-ils supprimés ou remplacés avant le travail suivant ?
2. Trousseau : l’identité de signature a-t-elle été retirée, et le trousseau est-il inutilisable pour un autre processus ?
3. Fichiers temporaires : contrôlez les répertoires de cache, les fichiers de configuration, les journaux de commande et les données exportées.
4. Artefacts : assurez-vous que les archives et les fichiers de diagnostic ne contiennent pas de données sensibles non prévues pour être partagées.
5. Fin de tâche : testez aussi l’échec ou l’interruption ; un nettoyage exécuté uniquement après une sortie normale laisse un angle mort.

Demandez des éléments que vous pouvez vérifier : configuration de nettoyage, journaux d’exécution expurgés, inspection du répertoire après un travail représentatif et procédure après échec. Si vous ne pouvez pas établir ce qui arrive à la clé et à l’espace de travail entre deux tâches, ne considérez pas le Runner comme réutilisable pour des charges de confiance différente.

Partage entre dépôts : limiter qui peut planifier le Runner

Partager une machine peut simplifier l’administration, mais augmente le nombre de workflows et d’équipes susceptibles d’interagir avec elle. Vérifiez la portée d’inscription du Runner, les groupes utilisés et les dépôts autorisés à l’employer. La documentation GitHub sur la gestion de l’accès explique les contrôles à vérifier pour les Runners et groupes de Runners (gestion de l’accès aux Runners auto-hébergés).

Votre contrôle doit répondre à des questions précises : un dépôt sans responsabilité de publication peut-il planifier une tâche sur la machine ? Qui peut modifier les droits du groupe ? Une tâche issue d’un projet secondaire peut-elle accéder au même trousseau ou au même répertoire de travail ? Les responsables du code et ceux qui gèrent les secrets sont-ils identifiables ?

La règle d’accès doit être observable dans les paramètres de GitHub et cohérente avec les responsabilités de l’équipe. Une liste de dépôts dans un document interne ne suffit pas si les paramètres réels autorisent davantage de projets. Si la séparation entre code et secrets ne peut pas être prouvée, réduisez le partage avant d’ajouter des publications de production.

FAQ : situations courantes de sécurité

Les PR d’un dépôt public peuvent-elles être vérifiées sur le Mac de publication ?

Elles peuvent être vérifiées si le code de la PR ne reçoit ni secret de publication ni accès indirect à une tâche privilégiée. Vérifiez l’événement, la référence réellement récupérée et le Runner sélectionné. Réservez l’hôte de signature à des travaux de confiance ; une approbation ajoutée à une autre étape ne compense pas une exécution antérieure de code non fiable sur cet hôte.

Où conserver le certificat et la clé privée iOS ?

Ne rendez pas la clé privée accessible à toutes les compilations. Apple associe l’identité de signature au certificat et à sa clé correspondante : protégez les deux et limitez leur usage à la tâche qui signe réellement. Contrôlez également le trousseau, les fichiers temporaires et les traces de diagnostic. Une clé qui n’apparaît pas dans le dépôt peut malgré tout être lisible par un script exécuté sur la machine.

Plusieurs workflows peuvent-ils partager une seule machine ?

Oui, si les autorisations des dépôts, les règles de planification et l’accès aux secrets sont cohérents et vérifiables. La question n’est pas le nombre de workflows, mais leur niveau de confiance et leurs possibilités d’interaction avec la machine. Si des projets sans lien peuvent lire les mêmes fichiers ou demander un Runner qui détient une identité de signature, réduisez le périmètre ou séparez les environnements.

Comment démontrer que le travail précédent n’a laissé aucun secret ?

Examinez l’état de la machine après une tâche terminée et après un échec représentatif : répertoire de travail, trousseau, fichiers temporaires, journaux et artefacts. Vérifiez aussi la procédure de nettoyage elle-même, au lieu de vous fier à la seule fin du processus. La suppression de l’inscription du Runner n’est pas une preuve de nettoyage du système ou de l’espace de travail.

Décision avant mise en production : un contrôle défendable

Évaluez chaque frontière sur une échelle définie pour votre examen, et non comme une certification officielle : 0 signifie « aucune preuve », 1 « preuve partielle », 2 « preuve vérifiable ». Ces notes sont un outil interne de décision, pas un score publié par GitHub ou Apple.

Appliquez ensuite ces conditions de décision :

• Si chaque frontière nécessaire à la publication dispose d’une preuve vérifiable, vous pouvez envisager la mise en production, après un test représentatif et une revue des tâches réellement déclenchées.
• Si une preuve est partielle, gardez le Runner hors du parcours de signature jusqu’à ce que le contrôle manquant soit démontré ; poursuivez les validations sans secrets dans un environnement adapté.
• Si une frontière essentielle n’a aucune preuve, n’y envoyez pas de tâche de publication. Réduisez les droits, restreignez les dépôts ou séparez la machine avant de reprendre l’évaluation.
• Si une tâche échoue, conservez un compte rendu expurgé des secrets, inspectez les résidus et indiquez explicitement si la procédure de nettoyage a été exécutée.

Votre dossier d’acceptation devrait réunir les déclencheurs autorisés, les droits du jeton, les actions utilisées, la portée d’accès au Runner, les tâches qui peuvent lire les secrets et les preuves de nettoyage. Notez aussi les risques non résolus, leur responsable et la condition qui empêchera la publication. Cette démarche transforme la sécurité CI iOS en vérifications reproductibles, plutôt qu’en conclusion fondée sur le fait qu’un build a fonctionné.

Choisir l’environnement selon le risque que vous pouvez maîtriser

Un Mac auto-hébergé convient à une chaîne iOS si vous pouvez contrôler les accès, les secrets et l’état entre tâches. À l’inverse, un Runner partagé dont les droits sont opaques expose les tâches signées à des déclencheurs difficiles à auditer ; une machine locale dédiée peut demander un investissement initial, de l’entretien et une disponibilité que vous devez assurer vous-même. Aucun de ces choix n’efface la nécessité de séparer les tâches de confiance différente.

Si votre configuration actuelle ne permet pas cette séparation, ne transformez pas un besoin de publication immédiate en exception permanente. Vous pouvez d’abord examiner les informations générales sur les solutions Mac de VPSMAC, puis comparer l’accès et les conditions de livraison avec les exigences de votre workflow. Pour étudier un environnement Mac proposé à la location, consultez également les informations sur les Mac proposés par VPSMAC. Un Mac loué peut offrir une autre organisation qu’une machine achetée ou un Runner partagé, mais il ne constitue pas à lui seul une preuve de sécurité : appliquez les mêmes contrôles à l’environnement retenu.