Informations de référence sur l’utilisation sécurisée

Trouvez des informations sur les meilleures pratiques de sécurité lorsque vous écrivez des flux de travail et utilisez des GitHub Actions fonctionnalités de sécurité.

Écriture de workflows

Utilisez des secrets pour les informations sensibles

Étant donné qu'il existe plusieurs façons de transformer une valeur secrète, la rédaction automatique n'est pas garantie. Respectez les meilleures pratiques suivantes pour limiter les risques associés aux secrets.

• Principe du privilège minimum
  • 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.
  • Les actions peuvent utiliser GITHUB_TOKEN en y accédant à partir du contexte github.token. Pour plus d’informations, consultez « Référence des 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 « Utiliser GITHUB_TOKEN pour l’authentification dans les flux de travail ».
• Masquer les données sensibles
  • Les données sensibles ne doivent jamais être stockées en clair dans les fichiers de flux de travail. Masquez toutes les informations sensibles qui ne sont pas un GitHub secret à l’aide de ::add-mask::VALUE. Cela implique que la valeur est traitée comme un secret et retirée des journaux d’activité. Pour plus d’informations sur comment masquer les données, consultez « Commandes de flux de travail pour GitHub Actions ».
• Supprimer et faire tourner les secrets exposés
  • La suppression des secrets est assurée par vos exécuteurs de workflows. Cela signifie qu’un secret sera retiré uniquement s’il a été utilisé dans un projet et est accessible par l’exécuteur. Si un secret non masqué est transmis à un journal d’activité de workflow, vous devez supprimer ce journal et renouveler le secret. Pour plus d’informations sur la suppression des journaux, consultez Utilisation des journaux d’exécution de flux de travail.
• 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 non prévus ni imprimés explicitement dans les logs.
  • 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. Pour plus d'informations sur la façon de nettoyer des journaux de flux de travail susceptibles de contenir involontairement des données sensibles, consultez « Utilisation des journaux d’exécution de flux de travail ».
• Auditer et renouveler les secrets enregistrés
  • 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 « Utilisation de secrets dans GitHub Actions » et « Gestion des environnements pour le déploiement ».

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

Approches recommandées pour atténuer le risque d’injection de script dans vos flux de travail :

Utilisez une action plutôt qu'un script intégré

L’approche recommandée consiste à créer une action JavaScript qui traite la valeur de contexte en tant qu’argument. Cette approche n’est pas vulnérable à l’attaque par injection, dans la mesure où la valeur du contexte n’est pas utilisée pour générer un script shell, mais est transmise à l’action en tant qu’argument :

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

Utilisez 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, ce qui est reflété par les lignes suivantes dans le journal :

   env:
     TITLE: a"; ls $GITHUB_WORKSPACE"
PR title did not start with 'octocat'

Avec cette approche, la valeur de l’expression ${{ github.event.pull_request.title }} est stockée en mémoire et utilisée en tant que variable et n’interagit pas avec le processus de génération de script. En outre, envisagez d’utiliser des variables shell de 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 n’est pas spécifique à GitHub Actions.

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 « Utiliser GITHUB_TOKEN pour l’authentification dans les flux de travail ».

Atténuer les risques liés à la vérification de code non fiable

Tout comme les attaques par injection de script, les contenus de pull request non fiables qui déclenchent automatiquement des actions peuvent également présenter un risque pour la sécurité. Les déclencheurs de flux de travail pull_request_target et workflow_run , lorsqu’ils sont utilisés avec l’extraction d’une demande de tirage non approuvée, exposent le référentiel à des compromissions de sécurité. Ces flux de travail sont privilégiés, ce qui signifie qu'ils partagent le même cache de la branche principale avec d'autres déclencheurs de flux de travail privilégiés, et peuvent avoir un accès en écriture au référentiel et un accès aux secrets référencés. Ces vulnérabilités peuvent être exploitées pour prendre le contrôle d’un référentiel.

Pour plus d'informations sur ces déclencheurs, leur utilisation et les risques associés, consultez Événements qui déclenchent des flux de travail et Événements qui déclenchent des flux de travail.

Pour plus d’exemples et de conseils sur les risques liés à la récupération de code non fiable, consultez Preventing pwn requests de GitHub Security Lab ainsi que la documentation Dangerous-Workflow d’OpenSSF Scorecard.

Bonnes pratiques

• Évitez d'utiliser le déclencheur de flux de travail pull_request_target si ce n'est pas nécessaire. Pour la séparation des privilèges entre les flux de travail, workflow_run est un meilleur déclencheur. N'utilisez ces déclencheurs de flux de travail que lorsque le flux de travail a réellement besoin du contexte privilégié.

• Évitez d'utiliser les déclencheurs de flux de travail pull_request_target et workflow_run avec des pull requests ou du contenu de code non fiables. Les flux de travail qui utilisent ces déclencheurs ne doivent pas explicitement extraire du code non fiable, y compris à partir de fourches de demandes de tirage ou de référentiels qui ne sont pas sous votre contrôle. Les flux de travail déclenchés sur workflow_run doivent traiter avec prudence les artefacts téléchargés à partir d'autres flux de travail.

• CodeQL peut analyser et détecter les flux de travail potentiellement vulnérables GitHub Actions . Vous pouvez configurer la configuration par défaut du référentiel et vous assurer que l’analyse GitHub Actions est activée. Pour plus d’informations, consultez « Définition de la configuration par défaut pour l’analyse du code ».

• Les cartes de performance OpenSSF peuvent vous aider à identifier les flux de travail potentiellement vulnérables, ainsi que d’autres risques de sécurité lors de l’utilisation GitHub Actions. Voir Utilisation des tableaux de bord OpenSSF pour sécuriser les dépendances des flux de travail plus loin dans cet article.

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 y a un risque important dans les actions d’approvisionnement à partir de référentiels tiers sur GitHub. Pour plus d’informations sur certaines des étapes qu’un attaquant pourrait suivre, consultez « Informations de référence sur l’utilisation sécurisée ».

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

• Épingler les actions à un SHA de commit complet

  L’épinglage d’une action à un SHA de commit complet constitue actuellement l’unique méthode permettant d’utiliser une action comme 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. Lorsque vous sélectionnez un SHA, vous devez vérifier qu’il provient du dépôt de l’action et non d’une fourche de dépôt.

  Pour un exemple illustrant l’utilisation d’un SHA de commit complet dans un workflow, consultez AUTOTITLE.

• 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.

• Épinglez les actions à une balise uniquement si vous faites confiance au 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éutiliser des workflows ».

fonctionnalités de sécurité de GitHub

GitHub fournit de nombreuses fonctionnalités pour rendre votre code plus sécurisé. Vous pouvez utiliser GitHubles fonctionnalités intégrées pour comprendre les actions dont dépendent vos flux de travail, vous assurer que vous êtes averti des vulnérabilités dans les actions que vous consommez ou automatiser le processus de conservation des actions dans vos workflows à jour. Si vous publiez et gérez des actions, vous pouvez utiliser GitHub pour communiquer avec votre communauté sur les vulnérabilités et comment les corriger. Pour plus d’informations sur les fonctionnalités de sécurité qui GitHub proposent, consultez fonctionnalités de sécurité GitHub.

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 .github/workflows, vous pouvez ajouter ce répertoire à la liste des propriétaires du code, de sorte que toute modification proposée à ces fichiers devra d'abord être approuvée par un réviseur désigné.

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

Gestion des autorisations des GitHub Actions paramètres de votre organisation

Vous pouvez appliquer le principe du moindre privilège au pipeline CI/CD de votre organisation grâce à GitHub Actions, en administrant des rôles personnalisés de l’organisation. Un rôle d’organisation personnalisé est un moyen d’octroyer à une personne ou à une équipe de votre organisation la possibilité de gérer certains sous-ensembles de paramètres sans lui accorder le contrôle administratif complet de l’organisation et de ses référentiels.

Pour GitHub Actions, vous pouvez activer l’une des autorisations suivantes pour les personnes ou les équipes de votre organisation.

• Gérer les stratégies Action de l’organisation : accès pour gérer tous les paramètres dans la page des paramètres « Actions générales », à l’exception des paramètres des exécuteurs auto-hébergés.
• Gérer les exécuteurs d’organisation et les groupes d’exécuteurs : accès pour créer et gérer des exécuteurs hébergés par GitHub, des exécuteurs auto-hébergés et des groupes d’exécuteurs, et contrôler où les exécuteurs auto-hébergés peuvent être créés.
• Gérer les secrets Actions de l’organisation : accès pour créer et gérer des secrets d’organisation Actions.
• Gérer les variables Actions de l’organisation : accès pour créer et gérer des variables d’organisation Actions.

Pour plus d’informations, consultez « Autorisations des rôles d’organisation personnalisés ».

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 « OpenID Connect ».

Utilisation Dependabot version updates pour maintenir les actions à jour

Vous pouvez utiliser Dependabot pour vous assurer que les références aux actions et aux flux de travail réutilisables utilisés dans votre référentiel sont actualisées. Les actions sont souvent mises à jour avec des correctifs de bogues et de nouvelles fonctionnalités pour rendre les processus automatisés plus rapides, plus sûrs et plus fiables. Dependabot vous évite d'avoir à gérer vos dépendances, car le fait automatiquement pour vous. Pour plus d’informations, consultez « Maintenir vos actions à jour avec Dependabot » et « À propos des mises à jour de sécurité Dependabot ».

Autorisation de l’accès des workflows aux dépôts internes et privés

Si vous rendez un référentiel privé accessible aux workflows GitHub Actions dans d’autres référentiels, les collaborateurs externes des autres référentiels peuvent indirectement accéder au référentiel privé, même s’ils n’ont pas d’accès direct à ces référentiels. Les collaborateurs externes peuvent consulter les journaux des exécutions de workflow lorsque des actions ou des workflows du référentiel privé sont utilisés. Pour plus d’informations, consultez Partage d’actions et de workflows au sein de votre entreprise.

Pour permettre aux exécuteurs de télécharger ces actions, GitHub transmet un jeton d’installation délimité à l’exécuteur. Ce jeton a un accès en lecture au référentiel et expire automatiquement après une heure.

Empêcher GitHub Actions de créer ou d’approuver des pull requests

Vous pouvez choisir d’autoriser ou d’empêcher les flux de travail GitHub Actions de créer ou d’approuver des demandes de tirage. Autoriser les workflows, ou toute autre automatisation, à créer ou à approuver des pull requests peut présenter un risque de sécurité si la pull request est fusionnée sans contrôle approprié.

Pour plus d’informations sur la configuration de ce paramètre, consultez Application de stratégies pour GitHub Actions dans votre entreprise,Désactivation ou limitation GitHub Actions pour votre organisation et Gestion des paramètres de GitHub Actions pour un référentiel.

Utilisation des Scorecards OpenSSF pour sécuriser les dépendances du flux de travail

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 modèle de workflow pour suivre les meilleures pratiques en matière de sécurité. Une fois configurée, l’action Scorecards s’exécute automatiquement lors de modifications du dépôt et alerte les développeurs sur les pratiques risquées de la chaîne d’approvisionnement grâce à l’expérience intégrée code scanning. 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 fixées.

Renforcement pour GitHubles exécuteurs hébergés

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

Les exécuteurs auto-hébergés pour GitHub n’offrent aucune garantie quant à leur exécution dans des machines virtuelles éphémères propres et peuvent être compromis de manière persistante par du code non fiable dans un flux de travail.

très prudent lors de l’utilisation de runners auto-hébergés sur des dépôts privés ou internes, car toute personne pouvant créer un fork du dépôt et ouvrir une pull request (généralement toute personne disposant d’un accès en lecture au dépôt) peut compromettre l’environnement du runner auto-hébergé, notamment accéder aux secrets et au GITHUB_TOKEN qui, selon sa configuration, peut accorder un 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é.

Les propriétaires d’entreprise et d’organisation peuvent choisir les référentiels autorisés à créer des exécuteurs auto-hébergés au niveau du référentiel. Les utilisateurs disposant de l’autorisation « Gérer les exécuteurs d’organisation et les groupes d’exécuteurs » peuvent uniquement choisir les référentiels autorisés à créer des exécuteurs auto-hébergés au niveau du référentiel pour les référentiels de votre organisation.

Pour plus d’informations sur les rôles d’organisation personnalisés, consultez « Autorisations des rôles d’organisation personnalisés ».

Pour plus d’informations, consultez Application de stratégies pour GitHub Actions dans votre entreprise et Désactivation ou limitation des GitHub Actions pour votre organisation.

Lorsqu’un exécuteur auto-hébergé est défini au niveau de l’organisation ou de l’entreprise, GitHub peut planifier des flux de travail à partir de plusieurs référentiels 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 flux de travail, les organisations et les référentiels qui peuvent accéder 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, Azure ou les services de métadonnées 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 runner auto-hébergé exécute une seule tâche. Certaines tâches utilisent des secrets comme paramètres de ligne de commande, qui peuvent être vus par une autre tâche s'exécutant sur le même exécuteur, tel que ps x -w. Cela peut entraîner des fuites d'informations confidentielles.

Utilisation des exécuteurs juste-à-temps

Pour améliorer la sécurité de l’inscription des exécuteurs, vous pouvez utiliser l’API REST pour créer des exécuteurs éphémères juste-à-temps (JIT). Ces exécuteurs auto-hébergés effectuent tout au plus un travail avant d’être automatiquement supprimés du dépôt, de l’organisation ou de l’entreprise. Pour plus d’informations sur la configuration de JIT runners, consultez Points de terminaison d’API REST pour les exécuteurs auto-hébergés.

Une fois que vous avez le fichier de configuration à partir de la réponse de l'API REST, vous pouvez le passer à l'exécuteur au démarrage.

./run.sh --jitconfig ${encoded_jit_config}

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 : au niveau de l’entreprise, de l’organisation ou du référentiel. 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 déployer sur un fournisseur de cloud ou si vous envisagez d’utiliser HashiCorp Vault pour la gestion des secrets, nous vous recommandons d’utiliser OpenID Connect pour créer des jetons d’accès à courte durée et bien étendus pour vos exécutions de flux de travail. Pour plus d’informations, consultez « OpenID Connect ».

Événements d’audit GitHub Actions

Vous pouvez utiliser le journal de sécurité pour surveiller l’activité de votre compte d’utilisateur et le journal d’audit pour surveiller l’activité dans votre organisation ou votre entreprise. Le journal de sécurité et d'audit enregistre le type d'action, quand celle-ci 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.

Pour obtenir la liste complète des événements que vous trouverez dans le journal d'audit pour chaque type de compte, consultez les articles suivants :

• Événements du journal de sécurité
• Événements du journal d’audit pour votre organisation
• Événements du journal d’audit pour votre entreprise

Comprendre les dépendances dans vos flux de travail

Vous pouvez utiliser le graphe des dépendances pour explorer les actions que les flux de travail de votre référentiel utilisent. Le graphe de dépendances est un résumé des fichiers manifeste et des fichiers de verrouillage stockés dans un dépôt. Il reconnaît également les fichiers en ./github/workflows/ tant que manifestes, ce qui signifie que toutes les actions ou flux de travail référencés à l’aide de la syntaxe jobs[*].steps[*].uses ou jobs.<job_id>.uses seront analysés en tant que dépendances.

Le graphe des dépendances affiche les informations suivantes sur les actions utilisées dans les flux de travail :

• Compte ou organisation propriétaire de l’action.
• Fichier de flux de travail qui fait référence à l’action.
• La version ou le SHA auquel l’action est épinglée.

Dans le graphe des dépendances, les dépendances sont automatiquement triées en fonction de la gravité de la vulnérabilité. Si l’une des actions que vous utilisez contient des avis de sécurité, elles s’affichent en haut de la liste. Vous pouvez accéder à l’avis à partir du graphe des dépendances et des instructions d’accès pour résoudre la vulnérabilité.

Les propriétaires d’entreprise peuvent configurer le graphique des dépendances et Dependabot alerts pour une entreprise. Pour plus d’informations, consultez Activation du graphe de dépendances pour votre entreprise.

Connaître les vulnérabilités de sécurité dans les actions que vous utilisez

Pour les actions disponibles sur la Place de marché, GitHub passe en revue les avis de sécurité associés, puis ajoute ces avis au GitHub Advisory Database. Vous pouvez rechercher dans la base de données des actions que vous utilisez pour trouver des informations sur les vulnérabilités existantes et des instructions sur la façon de les corriger. Pour simplifier votre recherche, utilisez le GitHub Actions filtre dans le GitHub Advisory Database.

Vous pouvez configurer vos dépôts afin de :

• Recevoir des alertes lorsque les actions utilisées dans vos flux de travail reçoivent un rapport de vulnérabilité. Pour plus d’informations, consultez « Supervision de l’activité dans vos flux de travail ».
• Vous êtes averti des avis existants lorsque vous ajoutez ou mettez à jour une action dans un flux de travail. Pour plus d’informations, consultez « Filtrage des actions pour les vulnérabilités dans les flux de travail nouveaux ou mis à jour ».

Surveillance des actions dans vos flux de travail

Vous pouvez utiliser Dependabot pour surveiller les actions dans vos flux de travail et vous permettre Dependabot alerts de vous avertir lorsqu’une action que vous utilisez présente une vulnérabilité signalée. Dependabot effectue une analyse de la branche par défaut des référentiels où elle est activée pour détecter les dépendances non sécurisées. Dependabot génère Dependabot alerts lorsqu’un nouvel avis est ajouté à l’action GitHub Advisory Database ou lorsqu’une action que vous utilisez est mise à jour.

Un propriétaire de l’entreprise doit d’abord configurer Dependabot pour votre entreprise avant que vous puissiez gérer Dependabot alerts pour votre référentiel. Pour plus d’informations, consultez Activation de Dependabot pour votre entreprise.

Vous pouvez afficher tous les éléments ouverts et fermés Dependabot alerts et Dependabot security updates correspondants dans l’onglet Dependabot de votre dépôt. Pour plus d’informations, consultez Affichage et mise à jour des alertes Dependabot.

Actions de filtrage des vulnérabilités dans les flux de travail nouveaux ou mis à jour

Lorsque vous ouvrez des pull requests pour mettre à jour vos flux de travail, il est conseillé d'utiliser l’examen des dépendances pour comprendre l’impact des changements appliqués aux actions sur la sécurité. Une révision des dépendances vous aide à comprendre les changements de dépendances et l’impact de ceux-ci sur la sécurité à chaque demande de tirage. Cette fonctionnalité fournit une visualisation facilement compréhensible des changements de dépendances avec des différences enrichies sous l’onglet « Fichiers modifiés » d’une demande de tirage (pull request). Une révision des dépendances vous informe de ce qui suit :

• Dépendances ajoutées, supprimées ou mises à jour, ainsi que leurs dates de publication
• Nombre de projets utilisant ces composants
• Données de vulnérabilité pour ces dépendances

Si l’une des modifications apportées à vos flux de travail est signalée comme vulnérable, vous pouvez éviter de les ajouter à votre projet ou de les mettre à jour vers une version sécurisée.

Pour plus d’informations sur la révision de dépendances, consultez « À propos de la vérification des dépendances ».

Le « action de révision des dépendances » fait référence à l’action spécifique qui peut signaler les différences dans une demande de tirage dans le contexte GitHub Actions. Consultez l’article dependency-review-action. Vous pouvez utiliser action de révision des dépendances pour appliquer des révisions de dépendances sur les demandes de tirage (pull requests) dans votre référentiel. L’action analyse les versions vulnérables des dépendances introduites par les modifications de version de package dans les demandes de tirage et vous avertit des vulnérabilités de sécurité associées. Cela vous donne une meilleure visibilité de ce qui change dans une demande de tirage et contribue à éviter l’ajout de vulnérabilités à votre dépôt. Pour plus d’informations, consultez À propos de la vérification des dépendances.

Maintenir les actions dans vos flux de travail sécurisés et à jour

Vous pouvez utiliser Dependabot pour vous assurer que les références aux actions et aux flux de travail réutilisables utilisés dans votre référentiel sont actualisées. Les actions sont souvent mises à jour avec des correctifs de bogues et de nouvelles fonctionnalités pour rendre les processus automatisés plus rapides, plus sûrs et plus fiables. Dependabot vous évite d'avoir à gérer vos dépendances, car le fait automatiquement pour vous. Pour plus d’informations, consultez « Maintenir vos actions à jour avec Dependabot » et « À propos des mises à jour de sécurité Dependabot ».

Les fonctionnalités suivantes peuvent mettre à jour automatiquement les actions dans vos flux de travail.

• Dependabot version updates ouvre des pull requests pour mettre à jour les actions vers leur dernière version lorsqu’une nouvelle version est publiée.
• Dependabot security updates ouvrez des pull requests pour mettre à jour les actions présentant des vulnérabilités signalées vers la version minimale corrigée.

Pour plus d’informations sur la Dependabot version updatesconfiguration, consultez Configuration de mises à jour de version Dependabot.

Pour plus d’informations sur la Dependabot security updatesconfiguration, consultez Configuration des mises à jour de sécurité Dependabot.