GitHub Actions durci : checklist sécurité 2026

On a tous fait ça. Activer un workflow GitHub Actions en 2 minutes, coller un YAML trouvé sur un gist, pousser, regarder les logs. Ça marche. Et puis un jour, tu réalises que ton CI a plus de droits que ton compte perso… et que tu exécutes du code qui vient de partout. Forks, actions tierces, dépendances NPM, scripts shell. Bref, une surface d’attaque énorme.

Donc voilà une checklist claire, version 2026, pour durcir GitHub Actions sans transformer ton repo en bunker inutilisable.

1) Verrouiller les permissions par défaut

Premier réflexe : limiter le GITHUB_TOKEN. En 2026, c’est toujours le point le plus sous-estimé.

Dans ton workflow, mets ça au niveau global :

yaml permissions: {}

Puis tu réouvres uniquement ce qui est nécessaire, job par job :

yaml jobs: build: permissions: contents: read

Si un job doit publier une release ou pousser un tag, OK. Mais tu le fais explicitement. Pas de droits implicites.

À vérifier aussi dans les réglages du repo : Settings → Actions → General → Workflow permissions. Choisis lecture seule par défaut.

2) Épingler les actions par commit SHA

Épingler une action sur @v4, c’est pratique. Mais c’est aussi accepter qu’un tag bouge, ou qu’une supply chain compromise te touche au mauvais moment.

Mieux : utiliser le SHA.

yaml

• uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11

Oui, c’est moins lisible. Mais c’est stable. Et tu peux gérer les updates via Dependabot.

Petite règle simple : actions internes ou ultra critiques, SHA obligatoire. Les autres, au minimum tag majeur + revue régulière.

3) Bloquer les PR non fiables et les workflows piégés

Deux pièges classiques :

1. pull_request_target mal utilisé.
2. exécution de code d’une PR avec des secrets accessibles.

Si tu utilises pull_request_target, rappelle toi que ça s’exécute dans le contexte du repo cible. Donc secrets potentiellement exposés si tu checkout le code de la PR et que tu l’exécutes.

Approche safe :

• pull_request pour tester du code non approuvé, sans secrets.
• workflow_dispatch ou push sur branches protégées pour les étapes qui ont accès aux secrets.

Et si tu dois faire du pull_request_target (par exemple pour commenter une PR) : ne lance jamais de build basé sur le code de la PR dans le même job.

4) Protéger les secrets et passer aux permissions fines

Évite les secrets globaux disponibles partout. Utilise les Environments avec approbation.

Exemple : production avec reviewers obligatoires.

yaml environment: production

Et pour les accès cloud, en 2026, le standard c’est OIDC. Moins de secrets statiques, plus d’identités temporaires.

• AWS : assume-role-with-web-identity
• GCP : Workload Identity Federation
• Azure : federated credentials

Résultat : même si un job se fait exfiltrer quelque chose, la fenêtre est courte.

5) Durcir l’exécution : runners, réseau, shell

Runners

• Si tu es sur GitHub-hosted : accepte que ce soit éphémère, c’est bien. Mais durcis le reste.
• Si tu es sur self-hosted : isole. Vraiment. VM dédiée, pas la même machine que ton infra interne, réseau segmenté.

Checklist self-hosted :

• pas de secrets persistants sur le disque
• mise à jour automatique de l’OS
• exécution en user non privilégié
• rotation et réinstallation régulière des runners

Shell

Ajoute des gardes fous :

yaml defaults: run: shell: bash

Et dans tes scripts :

bash set -euo pipefail

C’est bête, mais ça évite des comportements inattendus, et ça rend les erreurs visibles.

6) Empêcher les exfiltrations via logs et artefacts

Règles pratiques :

• ne jamais echo un secret, même masqué
• attention aux commandes qui dumpent l’environnement
• contrôler ce que tu upload en artifacts

Et configure une rétention courte des artifacts si tu n’en as pas besoin longtemps. Les artifacts, c’est souvent un « oubli » qui devient un coffre à données.

7) Vérifier les dépendances et la provenance

Ton workflow, c’est aussi :

• actions tierces
• packages (pip, npm, maven)
• images Docker

Checklist :

• activer Dependabot sur .github/workflows/ et sur les manifests
• utiliser npm ci et lockfiles
• préférer des registries connus, et si possible un proxy interne
• scanner les images Docker et les dépendances

Tu peux aussi générer un SBOM, au minimum sur les builds release. C’est devenu un prérequis dans pas mal de boîtes.

8) Ajouter des garde fous organisationnels

Quelques réglages GitHub qui valent de l’or :

• Restreindre les actions autorisées : allowlist d’actions (ex. actions/*, github/*, tes actions internes).
• Exiger une revue pour les modifications de workflows (CODEOWNERS sur .github/workflows/).
• Branch protection : status checks obligatoires, pas de push direct sur main.

Et pense aux « petits » repos. Ceux qu’on oublie. C’est souvent par là que ça rentre.

9) Mini checklist rapide à copier

À cocher, sans réfléchir :

• permissions: {} par défaut, puis permissions minimales par job
• actions épinglées par SHA (au moins pour les critiques)
• pas de secrets sur pull_request venant de forks
• Environments + approbations pour prod
• OIDC pour cloud, pas de clés long terme
• runners isolés (self-hosted) ou jobs sans état
• artifacts contrôlés + rétention courte
• Dependabot sur workflows + dépendances
• CODEOWNERS sur .github/workflows/
• allowlist d’actions dans les settings GitHub

Pour finir

Durcir GitHub Actions, ce n’est pas « ajouter une étape sécurité » à la fin. C’est surtout enlever des permissions, réduire la confiance implicite, et rendre les chemins dangereux impossibles ou coûteux.

Si tu veux, je peux publier une version « template » de workflow durci sur Le Blog Tech Pro de Samyn-Antoy ABASSE (avec OIDC, permissions minimales, et protections PR), et tu l’adaptes à ton stack. Passe sur https://monblog-sa-abasse.blogspot.com et dis moi ton langage principal, je te fais ça propre.

Questions fréquemment posées

Pourquoi est-il important de verrouiller les permissions par défaut dans GitHub Actions ?

Limiter le GITHUB_TOKEN par défaut réduit la surface d'attaque en empêchant les workflows d'avoir plus de droits que nécessaire. En 2026, cette pratique reste cruciale pour éviter des accès implicites et protéger votre CI contre l'exécution de code malveillant.

Comment épingler une action GitHub sur un commit SHA améliore-t-il la sécurité ?

Épingler une action sur un commit SHA garantit que vous utilisez une version stable et immuable de l'action, évitant ainsi les risques liés aux tags mouvants ou aux compromissions de la chaîne d'approvisionnement. Cela permet un contrôle précis des mises à jour via Dependabot.

Quels sont les risques liés à l'utilisation incorrecte de pull_request_target dans les workflows ?

pull_request_target s'exécute dans le contexte du dépôt cible avec accès aux secrets, ce qui peut exposer ces derniers si le code d'une PR non fiable est exécuté. Il est recommandé d'utiliser pull_request pour tester du code non approuvé sans secrets et réserver pull_request_target à des actions sans exécution de code dangereux.

Comment protéger efficacement les secrets dans GitHub Actions en 2026 ?

Il faut éviter les secrets globaux accessibles partout et utiliser les Environments avec approbation manuelle, comme un environnement production. L'adoption des identités temporaires via OIDC (AWS assume-role-with-web-identity, GCP Workload Identity Federation, Azure federated credentials) limite la durée d'exposition en cas de compromission.

Quelles bonnes pratiques appliquer pour durcir l'exécution des runners GitHub Actions ?

Pour les runners self-hosted, isolez-les sur des VM dédiées avec réseau segmenté, évitez les secrets persistants sur disque, assurez-vous des mises à jour automatiques de l'OS, exécutez les jobs en utilisateur non privilégié et effectuez une rotation régulière des runners. Pour GitHub-hosted, acceptez leur nature éphémère mais renforcez la sécurité ailleurs.

Comment empêcher l'exfiltration de données sensibles via logs et artefacts dans GitHub Actions ?

Ne jamais afficher ou enregistrer un secret même masqué dans les logs, faire attention aux commandes qui exposent l'environnement complet, contrôler précisément ce qui est uploadé en artefacts et configurer une rétention courte pour ces derniers afin d'éviter qu'ils deviennent une source involontaire de fuite de données.