La liste de contrôle complète de sécurité pour GitHub Actions

attaques de la chaîne d’approvisionnement , GitHub Actions a été largement exploité dans de nombreuses attaques de la chaîne d’approvisionnement , et les erreurs de configuration des workflows ont joué un rôle majeur. Il est dangereux de faire cavalier seul ! Utilisez cette liste de contrôle.

Pourquoi y a-t-il autant de problèmes de sécurité avec GitHub Actions ?

GitHub Actions, le système intégré de CI/CD et d'automatisation de GitHub, ne présente pas de failles de sécurité intrinsèques, mais il offre bel et bien de nombreuses occasions de se tirer une balle dans le pied.

La plateforme fonctionne comme prévu, mais les paramètres par défaut sont généralement configurés dans un souci de commodité et de flexibilité, et non de sécurité. pull_request_target Cela s'explique, et les balises modifiables sont certes pratiques. Mais ces choix de conception ont créé une surface d'attaque qui n'est apparue clairement qu'ultérieurement.

GitHub Actions est également le système CI/CD par défaut de la plupart des projets open source, et la prise de contrôle d'un projet open source permet aux pirates d'atteindre les victimes les plus en aval. Les workflows contiennent souvent les identifiants nécessaires à la publication sur npm et PyPI ; ainsi, un workflow compromis peut publier une version malveillante d'un paquet, et tous les développeurs qui installent ce paquet en seront également affectés.

Une autre raison pour laquelle nous voyons sans cesse les mêmes vecteurs d'attaque réapparaître dans les incidents est que la surface d'attaque est largement documentée dans les recherches publiques depuis des années. Les pirates se contentent parfois de parcourir les dépôts à la recherche de ces erreurs de configuration afin de trouver des cibles faciles (voir prt-scan). GitHub s'engage à renforcer ses mesures de protection au cours de l'année à venir afin de mieux protéger ses utilisateurs, mais il incombe toujours en grande partie à ces derniers de configurer GitHub de manière sécurisée et correcte.

Le simple fait de suivre toutes les bonnes pratiques ne rendra pas pour autant vos flux de travail infaillibles. Même si vous ne pouvez pas vous protéger totalement contre un responsable de maintenance malveillant ou une faille « zero-day » dans l'infrastructure de GitHub, vous pouvez colmater bon nombre des failles que les pirates exploitent activement ces derniers temps, et faire en sorte que vos dépôts soient une cible plus difficile à atteindre que la plupart des autres.

Bonnes pratiques pour garantir la sécurité de vos workflows GitHub Actions

Commencez par là. Si vous ne devez retenir que cinq points de cette liste :

• Associer toutes les modifications apportées par des tiers à un SHA de commit complet
• Définir comme valeur par défaut GITHUB_TOKEN droits en lecture seule
• Jamais pull_request_target dans les dépôts publics
• Ne jamais interpoler ${{ github.* }} directement dans exécution : étapes
• Utilisez l'OIDC pour cloud plutôt que des secrets à durée de vie prolongée

Nous vous recommandons toutefois de lire attentivement la liste de contrôle, dans laquelle nous expliquons toutes nos recommandations de sécurité concernant GitHub Actions et pourquoi elles sont indispensables. N'hésitez pas non plus à consulter les outils proposés en bas de page, qui vous aideront à mettre en œuvre et à appliquer ces bonnes pratiques.

Configuration des déclencheurs

1. N'utilisez jamais `pull_request_target` dans les dépôts publics

pull_request_target Cette fonctionnalité a pour but de permettre l'exécution de workflows déclenchés par des pull requests issues de forks, tout en leur donnant accès aux secrets du dépôt de base. Elle vous permet d'ajouter automatiquement des étiquettes ou des commentaires aux pull requests provenant de contributeurs externes. C'est une bonne idée, mais l'accès aux secrets rend cette fonctionnalité dangereuse.

Contrairement au modèle standard pull request déclencheur, pull_request_target s'exécute dans le contexte du dépôt de base, quelle que PR la PR . N'importe qui peut ouvrir une PR un dépôt public. Si votre workflow se déclenche sur cette PR, même si elle n'est pas fusionnée, tous les secrets explicitement référencés dans le workflow sont chargés dans l'environnement du runner et deviennent accessibles à tout code s'exécutant dans ce runner. Le script de l'attaquant peut facilement les lire à l'aide d'une requête d'environnement telle que os.environ.get('MY_SECRET') et les renvoyer à un pirate sans laisser de traces.

Si vous souhaitez mettre en place cette fonctionnalité dans un dépôt privé, exigez que les pull requests des nouveaux contributeurs soient approuvées par un responsable avant de pouvoir déclencher un workflow. GitHub prend en charge cette fonctionnalité de manière native dans la section Paramètres > Actions > Workflows de pull request de fork.

Dans la réalité : Trivy de mars 2026 a été perpétrée en exploitant pull_request_target. Les ingénieurs pensaient que le système était sûr, car il n'était pas autorisé à exécuter quoi que ce soit, mais cela n'a pas suffi. Le PR les identifiants à l'attaquant, qui s'en est servi pour se connecter à leurs comptes. Peu après, un attaquant a commencé à parcourir GitHub spécialement pour les dépôts contenant pull_request_target a activé et ouvert plusieurs centaines de PR en l'espace d'environ une journée.

2. Évitez d'utiliser `workflow_run` dans les dépôts publics

workflow_run vous permet d'enchaîner des workflows de sorte qu'un workflow en aval se déclenche dès qu'un workflow en amont est terminé. Le problème est que le workflow en aval s'exécute avec des droits d'écriture et un accès aux secrets, quel que soit ce qui a déclenché le workflow en amont, y compris une demande de modification PR un contributeur externe.

Si un élément en amont pull request le workflow est vulnérable à l'injection de scripts ; un attaquant peut ainsi corrompre l'artefact de sortie via une PR. Le workflow en aval utilise alors le contenu contrôlé par l'attaquant dans un contexte privilégié avec accès aux secrets ; ainsi, le contenu contrôlé par l'attaquant provenant d'une PR non fiable PR désormais atteint un workflow disposant d'un accès aux secrets via un saut supplémentaire. Le chemin d'attaque est plus long que pull_request_target mais aboutit au même résultat.

La meilleure solution consiste à éviter ce schéma. Si un déploiement ne doit avoir lieu qu'à chaque push vers la branche « main », déclenchez-le directement lors d'un push sur « main » plutôt que de le chaîner via workflow_run. Si vous en avez vraiment besoin workflow_run, voir github.event.workflow_run.event avant d'effectuer toute action privilégiée. Si le déclencheur en amont était un pull request plutôt que d'attendre qu'un responsable vous y oblige, mieux vaut abandonner le projet avant de déployer quoi que ce soit ou d'écrire quoi que ce soit.

postes :
  déployer :
    si: github.event.workflow_run.event == 'push'

zizmor signalera workflow_run les workflows qui effectuent des actions privilégiées sans vérification des événements, si vous souhaitez une détection automatisée dans l'ensemble de votre parc de dépôts.

3. Auditer les flux de travail à l'aide d'autres déclencheurs privilégiés

En plus de pull_request_target et workflow_run, faites attention aux autres déclencheurs qui s'exécutent avec un accès aux secrets. Parmi ceux-ci, on trouve ajouter un commentaire, problèmes, révision_d'une_demande_de_fusion, et commentaire_sur_la_révision_d'une_demande_de_fusion. Comme ils s'exécutent tous en mode confidentiel, ils peuvent être affectés par des facteurs externes. Les mêmes règles relatives à l'injection de scripts s'appliquent : il ne faut jamais interpoler directement les valeurs de ces événements dans exécution : étapes. Nous en parlerons plus en détail dans la section suivante.

Gestion des données d'entrée non fiables

1. Empêcher l'injection de scripts en considérant tous les noms de branches, PR , messages de commit et corps de tickets comme des données non fiables

C'est le même principe que l'injection SQL. Les valeurs fournies par l'utilisateur qui se retrouvent dans une commande shell sont interprétées comme du code, et non comme des données ; il ne faut donc jamais les interpoler github.* directement dans exécution : Étapes. La solution consiste à attribuer d'abord la valeur à une variable d'environnement, puis à faire référence à cette variable dans le script shell :

# vulnerable
- run: echo "Branch is ${{ github.head_ref }}"

# safe
- run: echo "Branch is $BRANCH"
  env:
    BRANCH: ${{ github.head_ref }}

Lorsque la valeur est attribuée à une variable d'environnement, le shell la lit comme une chaîne de caractères lors de l'exécution plutôt que de l'interpréter comme une syntaxe lors de l'analyse. Cela s'applique à tout ce qui provient d'une entrée contrôlée par l'utilisateur : github.head_ref, github.event.pull_request.title, github.event.issue.body, github.event.commits[0].message, ainsi que des valeurs de contexte similaires. Un bon SAST comme Aikido ce problème et proposera une correction dans une pull request.

Dans la nature : Dans la Attaque d'Ultralytics, un pirate a nommé une branche à l'aide d'une commande curl qu'un workflow a directement intégrée dans un exécution : étape, en l'exécutant sous forme de code. Le Attaque Nx/s1ngularity, repéré pour la première fois par Aikido , a combiné cela avec pull_request_target, où une PR une branche obsolète a déclenché un workflow vulnérable qui a entraîné une fuite de GITHUB_TOKEN disposant de droits de lecture et d'écriture, qui a ensuite été utilisé pour publier des paquets npm malveillants.

2. Pour les agents IA dans les flux de travail personnalisés, utilisez des jetons en lecture seule et veillez à ce que les données brutes saisies par l'utilisateur n'apparaissent pas dans les invites

Les agents IA exécutés dans les workflows GitHub Actions disposent des mêmes droits d'accès que n'importe quelle autre étape. Si un agent traite des titres d'issues, PR ou des messages de commit dans le cadre de son invite, un attaquant peut insérer des instructions dans ce texte et manipuler l'agent pour qu'il effectue des actions privilégiées, telles que la modification de fichiers ou l'exfiltration de données via n'importe quel outil auquel il a accès. Comme il n'existe aucun moyen d'empêcher l'injection d'invite dans les LLM, ne donnez pas aux agents IA d'autres droits que la lecture, et ne leur permettez pas de recevoir des titres d'issues, PR ou des messages de commit bruts comme entrée d'invite.

Dans la pratique : Aikido l'ont démontré avec PromptPwnd: un titre de ticket malveillant intégré à un workflow de l'interface CLI de Gemini a conduit l'agent à publier des secrets du référentiel dans un fil de discussion public du ticket en utilisant son propre gh accès aux outils.

3. Considérer les résultats générés par les grands modèles de langage (LLM) comme des données non fiables

Lorsqu'un workflow utilise un modèle de langage de grande envergure (LLM) pour générer une commande, un script ou un chemin d'accès à un fichier et transmet directement ce résultat à un exécution : Cette étape présente le même risque d'injection que l'interpolation d'un nom de branche ou PR . La sécurité des résultats générés par un LLM n'est pas garantie, et un attaquant capable d'influencer la requête peut ainsi influencer ce qui sera exécuté. Comme nous l'avons vu dans la section précédente consacrée à l'injection de requêtes, il convient d'abord d'attribuer le résultat du LLM à une variable d'environnement, de le valider dans la mesure du possible, et de ne jamais l'intégrer directement dans une commande shell.

4. N'enregistrez jamais de données non fiables dans GITHUB_ENV ou GITHUB_PATH

À l'attention de GITHUB_ENV définit les variables d'environnement pour toutes les étapes suivantes du travail. L'écriture dans GITHUB_PATH ajoute des entrées au PATH du système pour toutes les étapes suivantes. Si du contenu non fiable parvient à l'un ou l'autre de ces fichiers, un pirate peut définir des variables d'environnement arbitraires, telles que OPTIONS_DU_NŒUD qui déclenchent l'exécution de code. Ils pourraient également injecter un fichier binaire malveillant au début du PATH, qui serait alors appelé à la place d'un outil de confiance. La vulnérabilité réside dans un flux de travail qui télécharge un artefact ou lit des données fournies par l'utilisateur et les écrit directement dans $GITHUB_ENV sans validation. Traitez tout ce qui est écrit dans ces fichiers avec la même prudence que exécution : étape.

Manipulation des objets

5. Décompressez les fichiers dans un répertoire temporaire tel que /tmp plutôt que dans l'espace de travail, afin d'éviter d'écraser les fichiers de workflow

L'extraction d'un artefact directement dans l'espace de travail pourrait permettre à une archive contenant du contenu malveillant d'écraser des fichiers de workflow, des scripts ou des outils dont dépendent les étapes suivantes. L'extraction vers /tmp ou un autre répertoire isolé permet de séparer le contenu des artefacts de tout ce que votre flux de travail considère comme fiable. GitHub prend également en charge la vérification des hachages SHA-256 si vous avez besoin de garanties d'intégrité plus solides.

6. Exclure les fichiers secrets (.env, fichiers de configuration, identifiants) des artefacts téléchargés et éviter chemin : . des tendances qui balayent tout sur leur passage

Le chemin : . motif dans un actions/télécharger-un-fichier Cette étape télécharge tout ce qui se trouve dans le répertoire de travail, ce qui peut inclure .env des fichiers, des fichiers de configuration contenant des identifiants intégrés ou des secrets mis en cache et enregistrés sur le disque par d'autres étapes. Précisez clairement ce que vous téléchargez afin de ne pas publier accidentellement vos identifiants sur Internet. Indiquez des répertoires ou des types de fichiers spécifiques plutôt que de sélectionner l'ensemble de l'espace de travail, et ajoutez .env, *.pem, ainsi que les fichiers similaires, dans votre .gitignore et les modèles d'exclusion des artefacts.

Références d'action modifiables

7. Associez toutes les modifications apportées par des tiers à un SHA de commit complet, et non à une balise ou à une branche

Les balises sont pratiques car elles permettent de gagner du temps, mais en contrepartie, elles ne sont pas statiques. Les balises et les branches sont modifiables, ce qui signifie que le propriétaire d'un dépôt peut à tout moment les rediriger vers un autre commit, et c'est d'ailleurs ce à quoi on s'attend avec des balises comme @main. Lorsque l'on fait référence à une version spécifique avec utilisations : some-action@v3, nous nous attendons à ce que le commit reste inchangé. Mais si le compte du responsable de l'action est piraté, un attaquant peut rediriger cette balise vers un commit malveillant, et tous les workflows en aval le reprendront lors de leur prochaine exécution, sans PR autre indication. Pour éviter cela, la meilleure pratique consiste à ancrer la balise au SHA complet du commit à la place : utilise : some-action@abc123def456..... Cela peut bien sûr s'avérer un peu fastidieux à gérer ; vous pouvez donc utiliser Dependabot, Renovate ou pinact pour maintenir à jour les SHA épinglés. Les fichiers de verrouillage natifs figurent dans la feuille de route de GHA ; espérons donc qu'ils seront disponibles d'ici 2027.

Dans la nature : en mars 2025, des pirates ont redirigé 76 des 77 balises de version dans trivy vers des commits malveillants contenant un programme de vol d'informations. Tous les workflows faisant référence à ces balises par leur nom ont automatiquement intégré le code malveillant.

8. Examiner minutieusement les actions des tiers avant l'adoption

Avant d'ajouter un utilisations : Passez deux minutes à examiner le dépôt de l'action. Vérifiez si son créateur est certifié par GitHub, quand le dépôt a été mis à jour pour la dernière fois, combien il compte de contributeurs et quel est son score sur la fiche d'évaluation OpenSSF. Une action très utilisée, gérée par un seul responsable non certifié et ne présentant aucune activité récente, constitue une cible de choix pour le piratage de compte.

9. Privilégiez les actions comportant moins de dépendances transitives

Plus vous avez de dépendances, plus vous êtes vulnérable aux attaques de la chaîne d’approvisionnement; optez donc pour des actions comportant moins de dépendances lorsque vous avez le choix. Une action peut elle-même faire référence à d’autres actions, et ces dépendances transitives sont résolues au moment de l’exécution. Le fait de fixer la signature SHA de votre dépendance directe ne vous protège pas si celle-ci importe ses propres dépendances de manière modifiable.

Dans la nature : Le tj-actions compromis se propage en partie par ce mécanisme. Les flux de travail en aval associés à tj-actions/changed-files, mais fichiers modifiés référencé de manière transitive reviewdog/action-setup en raison d'une balise modifiable ; ainsi, lorsque Reviewdog a été piraté, tous les pipelines en aval ont exécuté le code malveillant.

Dépendances de paquets modifiables

10. Définir explicitement les versions des paquets npm et PyPI

Les gammes de versions flottantes telles que ^1.2.0 ou >=2.0.0 Cela signifie que votre workflow installe la dernière version compatible disponible au moment de l'exécution. Si un paquet est compromis et qu'une nouvelle version malveillante est publiée dans votre plage de versions, votre workflow l'intègre automatiquement lors de la prochaine exécution. Fixer des versions exactes (1.2.3) afin que votre flux de travail n'installe que ce que vous avez explicitement sélectionné. Ne vous fiez pas à la plage.

En pleine nature : L' attaque d'Ultralytics a démontré comment une version compromise d'un paquet publié sur PyPI peut atteindre des workflows qui ne sont pas verrouillés. La première version malveillante est restée en ligne pendant des heures avant d'être détectée, suffisamment longtemps pour affecter les builds utilisant des dépendances flottantes.

11. Définissez un âge minimum de publication lorsque votre gestionnaire de paquets le prend en charge (pnpm, yarn)

Même avec les versions épinglées, un paquet malveillant récemment publié peut correspondre exactement à la version vers laquelle vous déciderez par la suite de mettre à jour. Les paramètres d'âge minimum des versions indiquent à votre gestionnaire de paquets de refuser les paquets publiés depuis moins d'un délai spécifié, généralement 72 heures, ce qui laisse à la communauté le temps de détecter et de signaler les versions malveillantes avant qu'elles n'atteignent vos builds. pnpm et yarn prennent en charge cette fonctionnalité en natif, mais ce n'est pas encore le cas de npm. Aikido Chain peut pallier cette lacune pour npm (voir ci-dessous).

12. Vérifier la provenance des paquets à l'aide des attestations disponibles

Certains registres de paquets prennent désormais en charge les attestations de provenance, qui consistent en des enregistrements cryptographiques reliant un paquet publié au commit source spécifique et au pipeline de compilation qui l'ont généré. La vérification de ces attestations avant l'installation d'un paquet permet de s'assurer qu'il a bien été compilé à partir de la source qu'il prétend provenir. npm prend en charge cette fonctionnalité pour les paquets publiés via GitHub Actions. Il s'agit encore d'une pratique récente et la prise en charge par les outils n'est pas encore totale, mais cela vaut la peine de l'activer si votre registre et votre gestionnaire de paquets le permettent.

Traitement des informations confidentielles

13. Utilisez des variables d'environnement pour passer des paramètres secrets, jamais des arguments de ligne de commande

Les arguments de ligne de commande apparaissent dans les listes de processus ; par conséquent, les autres processus du serveur d'exécution ayant accès à /proc peut les lire. En transmettant un secret sous forme de variable d'environnement, on évite qu'il figure dans la table des processus. Dans votre workflow, définissez le secret dans un env : bloc et référence $SECRET_NAME dans la ligne de commande plutôt que ${{ secrets.MY_SECRET }} en ligne.

En pratique : les actions tj ont permis d'exfiltrer des secrets en les affichant dans le journal (problème lié à la commande echo et au masquage), et Trivy a abouti au vol d'un PAT. La gestion des secrets consiste à limiter leur accès à l'ensemble du système afin que, en cas de problème, un attaquant ne puisse pas s'emparer d'identifiants valides.

14. Limiter, dans la mesure du possible, la portée des secrets au niveau du dépôt à des environnements GitHub spécifiques

Les environnements GitHub vous permettent de restreindre l'accès aux secrets à l'aide de règles de protection des déploiements, de sorte qu'un secret tel que MOT_DE_PASSE_BASE_DE_DONNÉES n'est accessible qu'aux workflows ciblant l'environnement de production. Sans cette configuration, n'importe quel workflow du dépôt peut lire n'importe quel secret au niveau du dépôt. Vous pouvez configurer cette option dans Paramètres > Environnements.

15. Définissez les secrets au niveau des étapes du flux de travail, et non au niveau des tâches

Le fait de limiter les secrets aux étapes spécifiques d'une tâche qui en a besoin permet d'appliquer le principe du privilège minimal afin de réduire l'ampleur des répercussions en cas de compromission d'une action. Un secret déclaré au niveau d'une tâche env : Ce bloc est accessible à toutes les étapes de ce travail, y compris aux actions tierces.

Dans la nature : Dans l' attaque Shai-Hulud, des jetons ayant une portée de workflow ont été réutilisés sur plusieurs victimes. Une portée plus restreinte aurait permis de limiter l'ampleur des dégâts.

16. Utilisez l'OIDC pour obtenir cloud à durée de vie limitée plutôt que des secrets statiques à durée de vie illimitée, lorsque le cloud le prend en charge (AWS, Azure, GCP)

cloud statiques stockés sous forme de secrets GitHub sont valables indéfiniment ; par conséquent, s'ils sont volés, le risque de préjudice est considérable. L'OIDC permet à votre workflow de demander directement un jeton à durée de vie limitée à AWS, Azure ou GCP, limité à la tâche et valable pendant quelques minutes, de sorte qu'il n'y a pas d'identifiants qu'un attaquant pourrait voler. AWS, Azure et GCP prennent tous en charge cette fonctionnalité de manière native. La mise en place de ce système implique de configurer une relation de confiance entre votre cloud et le point de terminaison OIDC de GitHub.

17. Exiger une validation manuelle pour les exécutions de flux de travail qui utilisent des environnements de production

Configurez votre environnement GitHub de manière à ce qu'un workflow doive être validé par un autre utilisateur avant de pouvoir accéder aux secrets d'un environnement ou y effectuer un déploiement. Cette approche est plus adaptée aux petites équipes ou à celles qui effectuent des déploiements peu fréquents. Pour les équipes plus importantes, la solution la plus évolutive consiste à utiliser l'OIDC avec des identifiants à durée de vie limitée.

18. Évitez d'afficher ou de répéter des valeurs confidentielles, même dans les messages de débogage

GitHub masque les valeurs de secrets connues dans les journaux, mais uniquement lorsqu'il s'agit de correspondances exactes. Ainsi, si un secret est encodé en Base64 ou réparti sur deux appels « echo », le masquage ne fonctionne pas. La règle la plus sûre consiste tout simplement à ne jamais afficher de secrets. Si vous devez vérifier qu'un secret est bien défini, vérifiez qu'il s'agit d'une chaîne non vide plutôt que d'afficher la valeur.

Coureurs

19. N'utilisez pas de runners auto-hébergés sur des dépôts publics

N'importe qui peut ouvrir une PR un dépôt public, ce qui signifie que n'importe qui peut potentiellement déclencher l'exécution d'un workflow. Les paramètres d'approbation par défaut de GitHub pour les nouveaux contributeurs atténuent ce risque sur les runners hébergés par GitHub, où l'environnement est de toute façon éphémère et isolé. Sur un runner auto-hébergé, un paramètre d'approbation mal configuré ou trop permissif signifie que PR même PR l'exécution de code sur votre infrastructure. GitHub recommande d'utiliser les runners hébergés par GitHub pour les dépôts publics et de renforcer la politique d'approbation en « exigeant l'approbation pour tous les collaborateurs externes ».

En conditions réelles : des chercheurs ont mené une attaque de la chaîne d'approvisionnement sur PyTorch en soumettant une PR banale PR a déclenché un workflow sur un runner auto-hébergé, obtenant ainsi un accès root à la machine.

20. Utilisez des processus de fond éphémères plutôt que des processus de fond permanents

Un exécuteur statique conserve l'état entre les tâches, ce qui signifie qu'une tâche compromise peut laisser des fichiers malveillants, des binaires modifiés ou des caches corrompus qui affectent les exécutions suivantes sur cette machine. Les exécuteurs éphémères démarrent à zéro et sont supprimés après chaque tâche. Utilisez Actions Runner Controller pour les configurations basées sur Kubernetes, ou transmettez le --éphémère cocher cette case lors de l'inscription manuelle d'un coureur.

Dans la nature : Shai-Hulud enregistrait des runners auto-hébergés persistants dans des dépôts compromis et les utilisait comme canal C2 persistant, invisible pour la surveillance du réseau car tout le trafic passait par github.com.

21. Limiter les sorties du réseau des runners à une liste blanche

L'action la plus dangereuse d'un workflow compromis consiste souvent à exfiltrer des informations confidentielles vers un serveur contrôlé par un attaquant. Limiter l'accès réseau sortant aux seuls domaines dont votre workflow a réellement besoin rend cette opération nettement plus difficile. Harden-Runner et bullfrog fonctionnent tous deux sur les runners hébergés par GitHub. Pour les runners auto-hébergés, des règles de pare-feu au niveau du réseau permettent d'obtenir le même résultat.

Si vous utilisez GitHub Enterprise avec des runners auto-hébergés, les listes d'adresses IP autorisées pour les jetons offrent un contrôle supplémentaire. Elles limitent les adresses IP autorisées à utiliser un jeton, ce qui empêche qu'un jeton volé puisse être utilisé depuis l'infrastructure d'un pirate.

Autorisations des jetons

22. Définir comme valeur par défaut GITHUB_TOKEN autorisations en lecture seule au niveau de l'organisation ou du dépôt

Le GITHUB_TOKEN est automatiquement disponible à chaque exécution d'un workflow. Par défaut, il dispose d'un accès complet en lecture et en écriture à l'ensemble du dépôt ; ainsi, tout workflow compromis peut modifier votre dépôt, créer des versions ou approuver des pull requests. Définissez le paramètre par défaut sur « lecture seule » dans Paramètres > Actions > Général, puis n'accordez explicitement des autorisations d'écriture que lorsque cela est nécessaire.

23. Déclarer explicitement autorisations : des blocages au niveau du flux de travail ou de la tâche afin de limiter certaines tâches

La définition d'un paramètre par défaut en lecture seule au niveau de l'organisation permet de créer ce paramètre par défaut, mais certains processus nécessitent bien sûr des autorisations plus étendues. Lorsqu'un processus nécessite un accès privilégié, déclarez un autorisations : bloquer au niveau de la tâche plutôt qu'au niveau du flux de travail. De cette manière, le jeton avec droits étendus n'est valable que pour cette tâche, et toutes les autres tâches du flux de travail restent en lecture seule.

postes :
  déploiement :
    autorisations :
      contenu : lecture
      jeton d'identification : écriture

En pratique : les attaques de type « tj-actions », Trivy » et « prt-scan » ont toutes tiré parti du fait que les jetons disposaient de droits d'accès plus étendus que nécessaire. Le resserrement des autorisations accordées aux jetons permet de réduire l'ampleur des répercussions à tous les niveaux.

Paramètres de l'organisation et du dépôt

24. Désactiver la possibilité pour les Actions d'approuver les PR

Par défaut, GitHub permet aux workflows d'approuver les pull requests à l'aide de la GITHUB_TOKEN. Cela signifie qu'un workflow compromis pourrait approuver ses propres modifications malveillantes sans passer par aucun processus de révision. Désactivez cette option dans Paramètres > Actions > Général > « Autoriser GitHub Actions à créer et approuver des pull requests ». (Certaines équipes laissent cette option activée pourmerge Dependabot , mais il est préférable de créer Dependabot compte bot dédié Dependabot , doté de droits explicites de réviseur, plutôt que d'activer l'approbation par workflow pour l'ensemble de l'organisation.)

25. Limiter les sources d'actions aux créateurs vérifiés ou à des dépôts spécifiques

Le paramètre par défaut de GitHub permet d'utiliser dans vos workflows toute action publiée sur GitHub Marketplace. Limiter les sources aux créateurs vérifiés ou à une liste blanche spécifique signifie qu'une action malveillante nouvellement publiée ne peut pas être intégrée à vos workflows sans autorisation explicite. Les développeurs doivent alors demander l'autorisation à la personne responsable des paramètres de votre organisation GitHub (généralement l'équipe de la plateforme ou DevOps), qui peut l'ajouter à la liste blanche. Configurez cette option sous Paramètres > Actions > Général > « Autoriser les actions et les workflows réutilisables ».

En pratique : Les compromission de tj-actions a touché 23 000 dépôts, en partie parce que les équipes n'avaient aucune restriction quant aux actions qu'elles pouvaient intégrer.

26. Surveillez les inscriptions inattendues de runners auto-hébergés et les dépôts publics nouvellement créés au sein de votre organisation

Un jeton volé permet à un attaquant d'enregistrer un exécuteur malveillant afin d'implanter une porte dérobée persistante. Les attaquants créent également régulièrement des dépôts publics pour y stocker les identifiants volés. L'enregistrement d'un exécuteur et la création d'un dépôt sont deux événements que votre équipe doit détecter immédiatement, mais GitHub ne génère pas d'alerte par défaut pour ces incidents. La solution consiste à les surveiller manuellement. Transférez le journal d'audit de votre organisation vers un système SIEM et configurez des alertes pour self_hosted_runners.register événements et création de dépôts. En l'absence de SIEM, vous pouvez interroger le journal d'audit via l'API GitHub ou le consulter manuellement dans Paramètres > Journal d'audit.

En milieu réel : lors de l'attaque Shai-Hulud, les machines compromises ont été enregistrées sous le nom de des runners auto-hébergés nommés SHA1HULUD, et les identifiants volés ont servi à créer des dépôts publics utilisés comme réservoirs d’exfiltration. Une surveillance de ces deux éléments aurait permis de détecter la campagne à un stade précoce.

27. Utilisez CODEOWNERS pour exiger une révision axée sur la sécurité pour les modifications apportées à .github/workflows/

Les fichiers de workflow sont des scripts qui s'exécutent en ayant accès à vos secrets et jetons. En l'absence de règles explicites de propriété, tout développeur disposant d'un accès en écriture au dépôt peut modifier un workflow et merge sans qu'il ne fasse l'objet d'un contrôle de sécurité. Ajoutez une entrée CODEOWNERS indiquant .github/workflows/ à un réviseur ou à une équipe qui maîtrise les enjeux de sécurité, et l'associer à des règles de protection de branche exigeant l'approbation des CODEOWNERS avant merge.

Protégez vos workflows GitHub Actions avec Aikido

Aikido détecte les workflows GitHub Actions non sécurisés et aide les développeurs à les corriger avant qu'ils ne soient exploités.

Il détecte des problèmes tels que :

• Utilisation dangereuse de pull_request_target
• Injection de script via une source non fiable github.* entrée
• Injection de modèles et de prompts dans les flux de travail basés sur l'IA
• Actions de tiers non épinglées
• Trop privilégié GITHUB_TOKEN autorisations
• Gestion risquée des informations confidentielles dans les flux de travail

Aikido également :

• Créer automatiquement des tickets de correction
• Détecter les schémas de flux de travail non sécurisés dans l'ensemble des dépôts
• Marquer les références mutables des actions GitHub qui doivent être associées à un SHA de commit complet

La chaîneAikido contribue à protéger les installations de colis en :

• Blocage des paquets npm et PyPI connus pour être malveillants
• Application des règles relatives à l'âge minimum requis pour l'achat de produits de consommation

Par exemple, Aikido les entrées utilisateur non validées dans exécution : et propose automatiquement le modèle de variable d'environnement le plus sûr.

C'est gratuit, lancez-vous ici.

Prêt à sécuriser les workflows GitHub Actions

Gardez cette liste de contrôle à portée de main pendant que vous travaillez à la sécurisation de vos workflows GitHub Actions. Essayez de mettre en place dès que possible les mesures qui ne prennent que quelques minutes, et partagez-la avec vos collègues afin que tout le monde soit au courant des changements.

‍

FAQ : Sécurité de GitHub Actions

Quelle est la méthode la plus courante d'exploitation des workflows GitHub Actions ?

‍L'injection de script est le vecteur d'attaque le plus courant. Les pirates insèrent du code malveillant dans les noms de branches, PR ou le corps des tickets, et les workflows qui intègrent directement ces valeurs dans exécution : Ces étapes s'exécutent sous forme de commandes shell. Le fait d'associer des actions à des SHA de commit et d'utiliser des variables d'environnement plutôt que l'interpolation en ligne permet de réduire considérablement cette surface d'attaque.

Qu'est-ce que pull_request_target et pourquoi est-ce dangereux ?

‍pull_request_target Il s'agit d'un déclencheur de workflow qui s'exécute en ayant accès aux secrets du dépôt de base, même lorsque la PR qui le déclenche PR d'un fork. Étant donné que n'importe qui peut ouvrir une PR un dépôt public, tout workflow utilisant ce déclencheur expose ses secrets à des contributeurs externes. Évitez-le systématiquement sur les dépôts publics.

Que signifie « associer des actions à un SHA de commit » et pourquoi est-ce important ?

‍La plupart des flux de travail font référence à des actions tierces par balise, comme utilisations : some-action@v3. Les balises sont modifiables ; ainsi, si le compte d'un responsable d'action est piraté, un attaquant peut discrètement rediriger cette balise vers du code malveillant. L'ancrage à un SHA de commit complet, comme utilise : some-action@abc123... Cela signifie que votre flux de travail n'exécute que ce que vous avez validé.

Dois-je utiliser des runners auto-hébergés sur des dépôts publics ?

Non. N'importe qui peut ouvrir une PR un dépôt public et déclencher un workflow. Sur les runners hébergés par GitHub, cela reste gérable car l'environnement est éphémère et isolé. Sur un runner auto-hébergé, une politique d'approbation mal configurée signifie que des contributeurs externes peuvent exécuter du code directement sur votre infrastructure.

Qu'est-ce que l'OIDC et pourquoi est-ce préférable à la conservation cloud sous forme de secrets ?

Les identifiants statiquesenregistrés en tant que secrets GitHub sont valables indéfiniment ; ainsi, un secret volé reste dangereux longtemps après la violation. L'OIDC permet à votre workflow de demander à AWS, Azure ou GCP un jeton à durée de vie limitée, spécifique à cette tâche et valable pendant quelques minutes. Il n'y a donc pas d'identifiants à long terme à voler.

‍