Fuite de clés d’un Mac Runner auto-hébergé GitHub Actions : que faire ? Guide d’enquête 2026

Un flux de travail affiche une valeur sensible, une pull request déclenche un travail inattendu ou votre Mac Runner se comporte différemment après une exécution.

Réponse immédiate : suspendez les flux suspects, isolez le runner concerné, révoquez ou renouvelez les accès potentiellement exposés, puis vérifiez l’hôte et les permissions. Ne reprenez les builds qu’après le nettoyage requis et une validation avec du code fiable.

Ce guide est destiné aux développeurs indépendants qui construisent leurs propres dépôts sur un runner Mac auto-hébergé.
Il concerne aussi les freelances responsables de l’accès aux dépôts de leurs clients.
Les petites équipes à distance peuvent s’en servir pour coordonner le triage et une reprise maîtrisée.

Première décision : fuite confirmée ou exposition possible

Une alerte, une ligne de journal suspecte ou une exécution inhabituelle constitue un indice à vérifier, pas une preuve automatique qu’un secret a été volé. Distinguez trois états dans vos notes d’incident :

• Alerte sans exposition établie : vous avez repéré un déclencheur ou un comportement inattendu, mais n’avez pas confirmé que du code non fiable a eu accès à un secret.
• Exposition possible : un secret était accessible à un travail qui a exécuté du code non fiable, ou une sortie aurait pu le divulguer. Traitez l’accès comme potentiellement compromis jusqu’à vérification.
• Fuite confirmée : une valeur sensible apparaît dans une sortie accessible, ou les éléments disponibles démontrent qu’elle a été transmise à une partie non autorisée.

Cette distinction évite deux erreurs opposées : relancer un runner dangereux parce que l’alerte semble floue, ou déclarer une compromission certaine sans éléments. Notez le dépôt, le nom du flux, l’identifiant de l’exécution, le déclencheur, la branche et le runner concerné. Évitez de recopier une valeur secrète dans un ticket ou un canal de discussion.

La première vérification porte sur les journaux de l’exécution, son origine et les permissions accordées au travail. La documentation officielle sur l’utilisation des journaux de flux de travail explique comment les consulter et les télécharger. L’accès à un journal doit toutefois être contrôlé : il peut contenir des éléments sensibles même lorsque la valeur d’un secret n’y est pas visible.

À retenir : le masquage automatique des secrets dans les journaux est une protection, pas une preuve d’absence d’exposition. Une valeur transformée, encodée ou découpée peut ne pas être masquée comme vous l’attendez. La documentation sur les secrets GitHub Actions recommande de ne pas compter sur le masquage pour rendre sûre une divulgation.

Code de pull request : comprendre ce que le runner a réellement exécuté

Un GitHub Actions self-hosted runner exécute des tâches sur un système que vous gérez. Si une pull request permet à du code non fiable de s’exécuter sur ce Mac, ce code peut représenter un risque pour l’environnement et les accès que celui-ci peut atteindre. Le risque dépend donc du déclencheur, du code exécuté, des autorisations et des secrets disponibles — pas seulement du fait qu’une pull request ait été ouverte.

Reconstituez l’événement dans le fichier de flux de travail et dans les détails de l’exécution :

• La tâche a-t-elle été déclenchée par une pull request provenant d’un fork, d’une branche interne ou d’une autre source ?
• Le flux a-t-il compilé ou exécuté le code proposé, plutôt que de se limiter à lire des métadonnées ?
• La tâche a-t-elle eu accès à des secrets du dépôt ou d’un environnement protégé ?
• Le jeton associé au travail pouvait-il modifier du contenu, des versions ou d’autres ressources ?
• Des règles d’approbation ou des restrictions de branche s’appliquaient-elles réellement à cet événement ?

Examinez avec prudence tout flux utilisant pull_request_target. Cet événement peut s’exécuter dans le contexte privilégié du dépôt de base. Si le flux récupère puis exécute le contenu non fiable d’une pull request, l’association de ce code avec des permissions privilégiées est dangereuse. Consultez la documentation officielle sur l’utilisation sécurisée de pull_request_target et comparez ses recommandations au comportement exact de votre fichier. Ne contournez pas une approbation pour accélérer l’enquête.

Les permissions constituent une autre partie du diagnostic. La syntaxe des flux de travail et les permissions disponibles permettent de vérifier comment le flux définit les autorisations de ses tâches. Si aucune tâche n’a besoin de modifier le dépôt, ne lui accordez pas des droits d’écriture « au cas où ». Le fonctionnement de GITHUB_TOKEN est distinct de celui des secrets que vous avez ajoutés : consignez-les séparément et vérifiez leur portée individuellement.

Journaux et secrets : limiter la portée de l’exposition

Dès qu’une sortie révèle une valeur sensible, interrompez le flux concerné et empêchez sa réutilisation. Avant de nettoyer ou supprimer des éléments, conservez les informations nécessaires à l’enquête selon la procédure de votre organisation : identifiant de l’exécution, horodatage disponible, fichier de flux, branche, origine de la pull request et liste des accès potentiellement concernés. N’enregistrez pas la valeur elle-même dans vos notes.

Identifiez ensuite la catégorie d’identifiant en cause. Un secret du dépôt peut être disponible dans plusieurs flux ; un secret d’environnement dépend de ses règles d’accès ; GITHUB_TOKEN est lié aux permissions accordées au travail ; une clé d’un service externe peut avoir sa propre procédure de révocation. Le remplacement de la valeur dans les paramètres du dépôt ne suffit pas toujours à invalider un identifiant déjà copié. Révoquez-le auprès du service qui l’a émis, puis créez un remplacement uniquement si le flux en a encore besoin.

Les secrets GitHub Actions ont une taille maximale documentée de 48 Ko ; cette limite est une caractéristique de stockage, pas une mesure de sécurité. Elle ne permet pas de déterminer si un secret a été exposé. La documentation sur les secrets décrit également le masquage et les précautions à prendre pour leur utilisation.

Vérifiez aussi la conservation des journaux avant de supposer qu’ils resteront disponibles pour l’enquête. La documentation des journaux indique une période de rétention par défaut de 90 jours, susceptible de varier selon les paramètres du dépôt ou de l’organisation. Téléchargez les éléments nécessaires dans un espace autorisé et appliquez les règles de conservation internes ; ne prolongez pas leur accès à davantage de personnes que nécessaire. Consultez les instructions officielles sur les journaux de flux de travail pour les modalités de consultation et de téléchargement.

Point de contrôle : si vous ne savez pas si un identifiant a été accessible, raisonnez selon les droits qu’il détenait et les personnes ou tâches qui pouvaient les utiliser. Une valeur absente d’une sortie ne prouve ni qu’elle n’a pas été lue ni qu’elle n’a pas quitté le runner.

Chronologie d’intervention et remise en service

La séquence ci-dessous vise à limiter le risque sans transformer une suspicion en conclusion prématurée. Suivez en parallèle le plan de réponse de votre organisation, en particulier si le runner traite des dépôts clients ou des données réglementées.

À l’alerte — arrêter la propagation. Désactivez le déclencheur ou suspendez le flux concerné. Si vous ne pouvez pas isoler proprement une seule tâche, retirez le runner du groupe de travail ou empêchez sa mise à disposition pour de nouveaux travaux. Évitez de lancer un diagnostic qui exécute encore du code sur l’hôte suspect.

Pendant le triage — préserver les éléments utiles. Relevez l’exécution, le déclencheur, la branche, le dépôt, les autorisations et les sorties associées. Vérifiez si le runner était partagé entre plusieurs dépôts ou flux. Si l’hôte est potentiellement compromis, n’utilisez pas ce Mac pour ouvrir des secrets ou effectuer une nouvelle construction avant d’avoir choisi une méthode d’examen sûre.

Après l’identification des accès — révoquer et réduire. Désactivez les clés qui ont pu être exposées auprès de leur émetteur, puis remplacez seulement celles qui restent nécessaires. Réduisez les permissions de GITHUB_TOKEN, supprimez les secrets inutilisés et contrôlez les autorisations d’environnement. Un jeton de travail peut expirer à la fin du travail ou après 24 heures au maximum, selon la documentation ; cela ne révoque pas une clé externe ni ne neutralise un secret déjà copié. Vérifiez la description officielle de GITHUB_TOKEN et les règles du service qui a émis chaque autre identifiant.

Avant la reprise — traiter l’état du Mac. Un runner auto-hébergé ne garantit pas que chaque exécution démarre dans un environnement temporaire propre et isolé. Si du code non fiable a pu modifier l’hôte, gardez-le hors service jusqu’à ce que la personne responsable ait évalué la nécessité d’une analyse, d’un nettoyage ou d’une reconstruction. Le retirer puis le réenregistrer ne constitue pas, à lui seul, un nettoyage du système. La procédure officielle de retrait d’un runner auto-hébergé indique comment le retirer de la configuration ; elle ne remplace pas la réponse à incident sur la machine.

À la validation — tester avec du code fiable. Réautorisez le runner seulement lorsque son état est jugé acceptable selon votre procédure. Démarrez avec un flux contrôlé qui vérifie l’accès aux outils nécessaires, les permissions du jeton et la disponibilité des secrets strictement requis. Utilisez un test qui ne révèle aucune valeur sensible. Comparez le résultat attendu aux journaux, puis ouvrez progressivement les déclencheurs habituels.

Reprise contrôlée et prévention d’un nouvel incident

Après la rotation, faites l’inventaire de tous les endroits où l’ancien identifiant pouvait être présent : secrets de dépôt, secrets d’environnement, variables locales, scripts de construction, fichiers de configuration et services externes. Vérifiez la révocation chez l’émetteur, au lieu de vous fier uniquement au fait qu’une valeur différente s’affiche dans GitHub Actions. Pour valider sans risque, testez que l’ancien accès est refusé dans un contexte contrôlé et que le nouvel accès ne fonctionne que pour la tâche qui en a besoin.

Réexaminez ensuite les déclencheurs et les autorisations comme un ensemble. Séparez les flux qui doivent tester une contribution non fiable de ceux qui nécessitent des secrets. Contrôlez les approbations, les environnements protégés, les permissions de jeton et les sources des actions utilisées. Les dépendances de flux sont aussi du code exécuté : gardez une trace des versions ou références approuvées selon la politique de votre équipe.

Pour les projets clients, définissez explicitement qui peut modifier le flux, qui autorise une exécution privilégiée et qui peut accéder aux secrets. Ne partagez pas un runner entre dépôts sans avoir évalué les conséquences d’une séparation imparfaite. Une règle utile est de donner à chaque tâche le minimum d’accès indispensable, puis d’examiner à nouveau cette décision lorsque le dépôt, les collaborateurs ou la chaîne de construction change.

Enfin, choisissez un seuil de reprise clair : l’hôte est-il considéré comme fiable ? Les identifiants exposés ont-ils été révoqués auprès de leur émetteur ? Les permissions et déclencheurs ont-ils été revus ? Le flux contrôlé s’exécute-t-il sans exposer de secret ? Si l’une de ces réponses reste incertaine, laissez le runner en pause et demandez l’avis de la personne responsable de la sécurité ou de l’administration de l’organisation.

Pour évaluer la frontière entre votre environnement de construction et les données confiées à une infrastructure, vous pouvez aussi consulter le guide de protection des données. La documentation sur la préparation d’un environnement Mac distant peut aider à établir les contrôles à vérifier avant une migration ; elle ne remplace ni votre procédure de réponse à incident ni la vérification des responsabilités d’accès et d’isolement.

Questions fréquentes

Que faire en premier si un runner auto-hébergé semble avoir exposé un secret ?

Suspendez le flux de travail suspect et empêchez le runner concerné d’accepter de nouveaux travaux. Conservez les éléments utiles à l’enquête, notamment l’identifiant de l’exécution, l’heure et les journaux disponibles. Ensuite, déterminez quels accès étaient disponibles et révoquez ou renouvelez ceux qui ont pu être exposés. Ne remettez pas l’hôte en service avant d’avoir évalué son état.

Comment vérifier si du code de pull request a pu accéder aux secrets ?

Reconstituez le déclencheur du flux de travail, l’origine de la branche et les règles d’approbation appliquées. Vérifiez si le fichier de flux de travail a exécuté le code de la pull request, si un événement à privilèges comme pull_request_target était en jeu et quels secrets ou permissions le travail pouvait atteindre. Une alerte seule ne prouve pas la fuite, mais une exécution de code non fiable sur un runner accessible justifie l’isolement.

Faut-il réenregistrer le Mac Runner après l’exécution de code non fiable ?

Le réenregistrement ne nettoie pas le système d’exploitation et ne supprime pas une éventuelle persistance. Si l’environnement a pu être modifié, gardez-le isolé et suivez la procédure de réponse de votre organisation pour l’examiner, le nettoyer ou le reconstruire. Une fois l’état du Mac jugé fiable, vous pourrez le réautoriser ou l’enregistrer de nouveau selon les consignes applicables.

Comment vérifier qu’un ancien secret reste inutilisable après sa rotation ?

Confirmez d’abord que l’ancien identifiant a été révoqué auprès du service qui l’a émis : remplacer une valeur dans les secrets du dépôt ne désactive pas nécessairement une clé déjà copiée. Effectuez ensuite un test contrôlé qui vérifie le refus de l’ancien accès sans imprimer de valeur secrète. Contrôlez aussi les journaux d’audit disponibles et limitez les permissions de la nouvelle valeur.

Si votre runner actuel ne permet pas de vérifier clairement qui administre l’hôte, comment il est isolé ou comment les accès sont gérés, ne migrez pas l’incident vers une nouvelle machine sans avoir clarifié ces responsabilités. Pour une charge temporaire ou un environnement de test macOS, comparez d’abord ces exigences à la formule proposée par macminirent et confirmez que les permissions, l’isolement et la gestion des identifiants répondent à votre politique. Si vous devez garder le contrôle physique de la machine ou maintenir une charge lourde et permanente, conserver ou acheter votre propre Mac peut être plus approprié ; une location ne dispense jamais de révoquer les clés exposées ni de valider votre chaîne de construction.

Questions fréquentes