Comment securiser votre pipeline CI/CD GitHub Actions en 7 etapes

Votre pipeline CI/CD est probablement le maillon le plus faible de votre securite. Il a acces a vos secrets, a votre code source, a vos credentials cloud, et il execute du code automatiquement a chaque push. En 2026, apres les attaques sur Grafana via GitHub Actions, la compromission d'actions tierces, et les CVE sur les runners self-hosted, la question n'est plus « est-ce que mon pipeline sera attaque ? » mais « est-ce que je suis pret quand ca arrivera ? ». Ce guide vous donne 7 etapes concretes pour securiser vos workflows GitHub Actions, avec des exemples de configuration que vous pouvez appliquer immediatement.

Etape 1 : Appliquer le principe de moindre privilege aux permissions

Par defaut, les workflows GitHub Actions ont des permissions larges sur le repository. La premiere etape, et la plus impactante, est de restreindre ces permissions au strict minimum. Au niveau du repository, allez dans Settings > Actions > General et selectionnez « Read repository contents and packages permissions ». Puis, dans chaque fichier workflow, declarez explicitement les permissions necessaires :

# Au niveau du workflow (s'applique a tous les jobs)
permissions:
  contents: read

# OU au niveau de chaque job pour plus de granularite
jobs:
  build:
    permissions:
      contents: read
      packages: write   # Seulement si ce job publie un package
  deploy:
    permissions:
      contents: read
      id-token: write   # Seulement pour OIDC

La regle d'or : ne jamais utiliser permissions: write-all ou laisser les permissions par defaut. Chaque job ne doit avoir acces qu'aux ressources dont il a reellement besoin. Un job de linting n'a pas besoin d'ecrire dans les packages. Un job de tests n'a pas besoin d'acceder aux secrets de deploiement. Separez vos workflows en jobs distincts avec des permissions isolees.

Etape 2 : Epingler toutes les actions tierces par SHA de commit

Les tags de version des GitHub Actions sont mutables. Un mainteneur (ou un attaquant qui compromet son compte) peut modifier le code derriere le tag v4 sans que vous ne le sachiez. C'est exactement ce qui s'est passe lors de l'attaque tj-actions/changed-files en mars 2025. La solution : epinglez chaque action par le hash SHA complet du commit.

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

# SECURISE : hash SHA immuable
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.7

# Automatiser la conversion avec pin-github-action
npx pin-github-action .github/workflows/*.yml

Conservez le commentaire avec le numero de version a cote du hash pour faciliter la maintenance. Utilisez pin-github-action de Mheap pour convertir automatiquement tous vos workflows. Configurez Dependabot ou Renovate pour mettre a jour les hashes quand de nouvelles versions sont publiees, en ajoutant une revue manuelle obligatoire.

Etape 3 : Remplacer les secrets permanents par OIDC

Stocker des cles AWS, des tokens GCP ou des credentials Azure dans les secrets GitHub, c'est placer une bombe a retardement dans votre pipeline. Si un workflow est compromis, ces secrets permanents donnent un acces illimite a votre infrastructure cloud. La solution : OIDC (OpenID Connect) permet a GitHub Actions d'obtenir des tokens temporaires directement aupres de votre fournisseur cloud.

# Avant : secret permanent (dangereux)
- name: Configure AWS
  uses: aws-actions/configure-aws-credentials@e3dd6a429d7300a6a4c196c26e071d42e0343502
  with:
    aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
    aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

# Apres : OIDC (securise, tokens temporaires)
jobs:
  deploy:
    permissions:
      id-token: write   # Necessaire pour OIDC
      contents: read
    steps:
      - uses: aws-actions/configure-aws-credentials@e3dd6a429d7300a6a4c196c26e071d42e0343502
        with:
          role-to-assume: arn:aws:iam::123456789:role/github-actions-deploy
          aws-region: eu-west-3

Avec OIDC, il n'y a plus de secret a voler. Le token JWT emis par GitHub contient l'identite du workflow (repository, branche, evenement), et votre fournisseur cloud ne delivre des credentials temporaires que si ces conditions matchent la politique IAM configuree. Un workflow fork ou un workflow modifie par un attaquant ne pourra pas obtenir de credentials car son identite ne correspondra pas a la politique de confiance. AWS, GCP et Azure supportent tous nativement OIDC avec GitHub Actions.

Etape 4 : Securiser et isoler vos runners

Les runners GitHub-hosted sont ephemeres et isoles par defaut : chaque job s'execute dans une VM fraiche qui est detruite apres execution. Si vous utilisez des runners self-hosted, la situation est tres differente. Un runner self-hosted persistant conserve l'etat entre les jobs : fichiers temporaires, credentials caches, processus residuels. Un workflow malveillant peut laisser un backdoor qui sera execute par le job suivant.

Pour les runners self-hosted, appliquez ces mesures : utilisez des runners ephemeres avec l'option --ephemeral qui detruit le runner apres chaque job. Executez les runners dans des conteneurs Docker ou des VMs dedicees, jamais sur des machines de production. Ne donnez jamais l'acces aux runners self-hosted aux repositories publics (un attaquant peut ouvrir une PR et executer du code sur votre runner). Apres la CVE-2026-3854 sur les runners, la mise a jour reguliere de l'agent runner est imperative.

Pour les runners GitHub-hosted, privilegiez les ubuntu-latest pour les jobs standards et les runners larger (4/8/16 vCPU) pour les builds lourds. Evitez macos-latest sauf necessite absolue : les runners macOS sont plus chers et historiquement moins isoles.

Etape 5 : Proteger et isoler vos secrets

Meme avec OIDC pour les credentials cloud, vos workflows ont probablement besoin d'autres secrets : tokens d'API, cles de signature, credentials de base de donnees. Voici comment les gerer de maniere securisee.

Utilisez les environnements GitHub pour isoler les secrets par contexte de deploiement. Creez des environnements staging et production avec des regles de protection differentes : revues obligatoires, branches autorisees, delais d'attente. Les secrets attaches a un environnement ne sont accessibles qu'aux jobs qui ciblent explicitement cet environnement.

jobs:
  deploy-production:
    environment:
      name: production       # Secrets isoles
      url: https://app.example.com
    # Seule la branche main peut deployer en production
    # Revue obligatoire avant deploiement
    steps:
      - name: Deploy
        env:
          DATABASE_URL: ${{ secrets.DATABASE_URL }}  # Secret specifique a production

Ne passez jamais de secrets dans les arguments de ligne de commande. Les arguments de processus sont visibles dans /proc sur Linux. Utilisez des variables d'environnement ou des fichiers temporaires. N'affichez jamais de secrets dans les logs : utilisez ::add-mask:: pour masquer dynamiquement des valeurs dans les logs GitHub Actions. Et surtout, ne creez jamais de secrets au niveau de l'organisation entiere sauf absolue necessite : plus le scope est large, plus le risque de fuite est eleve.

Etape 6 : Mettre en place un audit continu de vos workflows

La securite n'est pas un etat, c'est un processus. Vos workflows evoluent, de nouvelles actions sont ajoutees, des permissions sont modifiees. Sans audit continu, la configuration se degrade inevitablement. Voici les trois outils a integrer :

actionlint est un linter statique pour les fichiers de workflow GitHub Actions. Il detecte les erreurs de syntaxe YAML, les references invalides, les patterns d'injection dangereux (comme l'utilisation non filtree de github.event.pull_request.title dans un run:), et les permissions trop larges. Integrez-le dans votre CI pour qu'il analyse vos workflows a chaque modification.

StepSecurity Harden-Runner surveille le comportement reseau et fichier de vos jobs en temps reel. Il detecte les connexions sortantes inattendues (un signe de credential exfiltration), les acces fichiers suspects, et les processus non autorises. Ajoutez-le comme premiere etape de chaque job critique.

L'API GitHub Audit Log vous permet de surveiller toutes les modifications de workflows, les acces aux secrets, et les executions de workflows. Configurez des alertes automatiques quand un workflow est modifie pour ajouter des permissions, quand un nouveau secret est cree, ou quand un workflow s'execute depuis un fork.

Etape 7 : Deployer des guardrails organisationnels

Les mesures techniques ne suffisent pas si n'importe quel developpeur peut modifier un workflow et supprimer les protections. La derniere etape est de mettre en place des garde-fous au niveau de l'organisation :

CODEOWNERS pour les workflows. Ajoutez une entree dans .github/CODEOWNERS qui exige une revue de l'equipe securite pour toute modification des fichiers .github/workflows/. Aucun changement de workflow ne doit etre merge sans approbation explicite d'un proprietaire de code designe.

# .github/CODEOWNERS
.github/workflows/    @org/security-team
.github/actions/      @org/security-team

Politiques d'actions au niveau de l'organisation. Dans les parametres de l'organisation GitHub, restreignez les actions autorisees a une liste blanche d'actions verifiees. Bloquez les actions provenant de repositories personnels et limitez les actions tierces a celles publiees par des organisations verifiees (actions/*, github/*, aws-actions/*).

Branch protection rules. Sur les branches de deploiement (main, production), exigez des revues de PR, interdisez les force push, activez la verification du statut des checks, et activez la protection contre la suppression. Combinez avec des rulesets au niveau de l'organisation pour appliquer ces regles uniformement a tous les repositories.

Recapitulatif : pratiques securisees vs risquees

Par ou commencer ?

Si vous ne faites qu'une seule chose aujourd'hui, faites celle-ci : ajoutez permissions: read-all au niveau de votre workflow et testez que tout fonctionne encore. Ensuite, epinglez vos 3 actions les plus utilisees par SHA. Ces deux changements prennent 15 minutes et reduisent votre surface d'attaque de 60 pourcent.

La semaine prochaine, migrez vos credentials cloud vers OIDC. C'est un peu plus de travail (configurer les trust policies cote AWS/GCP/Azure) mais c'est le changement le plus impactant a moyen terme. Enfin, installez actionlint et Harden-Runner dans votre CI pour avoir une visibilite continue sur la securite de vos workflows. Pour aller plus loin, consultez le OWASP Top 10 CI/CD Security Risks et la documentation GitHub sur le durcissement des Actions.

La securite CI/CD n'est pas un projet a realiser une fois. C'est une pratique continue qui doit etre integree dans votre culture d'equipe, au meme titre que les revues de code ou les audits de dependances. Les 7 etapes de ce guide vous donnent une base solide. A vous de les adapter a votre contexte et de les maintenir dans le temps.