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.

Utilisation de modèles de flux de travail pour code scanning

Code scanning vous permet de trouver des vulnérabilités de sécurité avant qu’elles atteignent la production. GitHub fournit des modèles de flux de travail pour code scanning. Vous pouvez utiliser ces flux de travail suggérés pour construire vos code scanning flux de travail, au lieu de commencer à partir de zéro. Le flux de travail de GitHub, le Workflow d’analyse CodeQL, est alimenté par CodeQL. Il existe également des modèles de workflow tiers disponibles.

Pour plus d’informations, consultez « À propos de l’analyse du code » et « Configuration avancée de l’analyse du code ».

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

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.

GitHub propose des stratégies au niveau du référentiel, de l’organisation et de l’organisation pour exiger que les actions soient épinglées à une sha de validation complète : * Pour configurer la stratégie au niveau du référentiel, consultez Gestion des paramètres de GitHub Actions pour un référentiel. * Pour configurer la stratégie au niveau de l’organisation, consultez Désactivation ou limitation des GitHub Actions pour votre organisation.

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

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

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 Désactivation ou limitation GitHub Actions pour votre organisation et Gestion des paramètres de GitHub Actions pour un référentiel.

Utiliser code scanning pour sécuriser les flux de travail

Code scanning peut détecter et suggérer automatiquement des améliorations pour les modèles vulnérables courants utilisés dans GitHub Actions les flux de travail. Pour plus d’informations sur l’activation code scanning, consultez Définition de la configuration par défaut pour l’analyse du code.

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

GitHub-les exécuteurs hébergés prennent des mesures pour vous aider à atténuer les risques de sécurité.

Vérification de la chaîne d’approvisionnement pour les exécuteurs hébergés sur GitHub

Pour GitHubles exécuteurs hébergés créés à partir d’images gérées par GitHub, vous pouvez afficher une facture logicielle de matériaux (SBOM) pour voir quel logiciel a été préinstallé sur l’exécuteur. 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 de runner Ubuntu, Windows et macOS maintenues par GitHub, y compris les runners basés sur ARM. 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.

Refus d'accès aux hôtes

Les exécuteurs hébergés GitHub sont approvisionnés avec un fichier etc/hosts qui bloque l’accès réseau à différents pools d’exploration de données de crypto-monnaie et sites malveillants. Les hôtes tels que MiningMadness.com et cpu-pool.com sont redirigés vers localhost afin qu’ils ne présentent pas de risque de sécurité significatif. Pour plus d’informations, consultez Exécuteurs hébergés par GitHub.

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

** GitHub-les exécuteurs hébergés** exécutent du code dans des machines virtuelles éphémères et propres isolés, ce qui signifie qu’il n’existe aucun moyen de compromettre cet environnement de manière persistante ou d’accéder à plus d’informations que ce qui a été placé dans cet environnement pendant le processus de démarrage.

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.

Par conséquent, les runners auto-hébergés ne doivent presque jamais être utilisés pour des dépôts publics sur GitHub, car n’importe quel utilisateur peut ouvrir des pull requests sur le dépôt et compromettre l’environnement. De même, soyez 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’organisation peuvent choisir les référentiels autorisés à créer des exécuteurs auto-hébergés au niveau du référentiel.

Pour plus d’informations, consultez 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 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

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

Le graphique de dépendances est activé pour les dépôts publics et vous pouvez choisir de l’activer sur des dépôts privés. Pour plus d’informations sur l’utilisation du graphique de dépendances, consultez Exploration des dépendances d’un dépôt.

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.

Vous pouvez activer Dependabot alerts pour votre compte personnel, pour un dépôt ou pour une organisation. Pour plus d’informations, consultez Configuration d’alertes Dependabot.

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.

Protection des actions que vous avez créées

GitHub permet la collaboration entre les personnes qui publient et gèrent des actions et des reporters de vulnérabilité afin de promouvoir le codage sécurisé. Les avis de sécurité des référentiels permettent aux gestionnaires de dépôts publics de discuter d’une faille de sécurité dans un projet et de la résoudre en privé. Après avoir collaboré sur un correctif, ils peuvent publier l’avis de sécurité pour rendre publique la vulnérabilité de sécurité auprès de la communauté du projet. En publiant des avis de sécurité, les chargés de maintenance des dépôts facilitent la mise à jour des dépendances de package pour leur communauté et la recherche de l’impact des vulnérabilités de sécurité.

Si vous êtes une personne qui gère une action utilisée dans d’autres projets, vous pouvez utiliser les fonctionnalités suivantes GitHub pour améliorer la sécurité des actions que vous avez publiées.

• Utilisez l’affichage dépendants dans le graphe des dépendances pour voir quels projets dépendent de votre code. Si vous recevez un rapport de vulnérabilité, cela vous donne une idée de la personne avec laquelle vous devez communiquer avec la vulnérabilité et comment la corriger. Pour plus d’informations, consultez « Exploration des dépendances d’un dépôt ».
• Utilisez des conseils de sécurité de référentiel pour créer un avis de sécurité, collaborer en privé pour résoudre la vulnérabilité dans une fourche privée temporaire et publier un avis de sécurité pour alerter votre communauté de la vulnérabilité une fois qu’un correctif est publié. Pour plus d’informations, consultez « Configuration de rapports de vulnérabilité privés pour un dépôt » et « Création d’un avis de sécurité de dépôt ».