GitHub Actions security : OIDC, permissions et protection de la supply chain CI/CD

Pourquoi GitHub Actions est une cible privilégiée

GitHub Actions est devenu l'outil CI/CD dominant, mais sa popularité en fait une cible de choix. Depuis 2022, les incidents de sécurité liés aux pipelines CI/CD se sont multipliés : actions tierces malveillantes, secrets volés dans les logs, injections de commandes via des inputs non sanitisés. L'affaire CodeCov (2021) a montré comment un script de couverture de code compromis pouvait voler les secrets CI/CD de 29 000 entreprises, dont HashiCorp, Twilio et GitHub lui-même.

Les vecteurs d'attaque sur GitHub Actions

• Secrets exposés dans les logs : afficher accidentellement `echo $AWS_SECRET_KEY` dans les logs du workflow, visibles publiquement dans les repos publics
• Injection via `${{ github.event.pull_request.head.ref }}` : inputs non sanitisés dans les expressions GitHub permettant l'injection de commandes shell
• Actions tierces compromises : une action `uses: some-org/some-action@v2` exécute du code tiers avec accès à tous vos secrets et tokens
• Permissions GITHUB_TOKEN excessives : le token GitHub par défaut peut avoir les droits d'écriture sur le repo, permettant l'injection de code malveillant
• Workflow déclenchés par des PRs de forks : des contributeurs malveillants peuvent tenter d'exfiltrer des secrets via des workflows `pull_request`

OIDC : éliminer les secrets statiques AWS/Azure/GCP

OpenID Connect (OIDC) permet à GitHub Actions de s'authentifier auprès des providers cloud (AWS, Azure, GCP) sans stocker de credentials long-lived. C'est la pratique recommandée pour tout déploiement cloud depuis une CI/CD.

Comment fonctionne OIDC pour GitHub Actions

Lors de l'exécution d'un workflow, GitHub génère un JWT signé contenant des claims sur le workflow (repo, branch, environment, actor). AWS, Azure ou GCP vérifient ce token auprès de GitHub et accordent un accès temporaire (15 minutes) via un rôle IAM configuré.

• AWS : configurer un Identity Provider OIDC dans IAM pointant vers token.actions.githubusercontent.com, puis créer un rôle IAM avec la condition sur le repo/branch/environment
• Azure : créer une Federated Credential sur l'App Registration Azure AD avec la configuration du repo GitHub
• GCP : configurer Workload Identity Federation avec le provider GitHub OIDC
• Avantage clé : les credentials expirent après 15 minutes, ne sont jamais stockés dans GitHub Secrets, et sont auditables via CloudTrail/Azure Monitor

Workflow GitHub Actions avec OIDC (AWS)

• Permission `id-token: write` requise dans le workflow pour demander le JWT OIDC
• Action `aws-actions/configure-aws-credentials` avec `role-to-assume` et `aws-region`
• La condition IAM peut être restreinte au repo, à la branch, ou à un GitHub Environment (ex. `production`)
• Combiner avec des GitHub Environments pour avoir des approbations manuelles avant les déploiements en production

Permissions minimales : GITHUB_TOKEN et permissions: block

Par défaut, `GITHUB_TOKEN` a des permissions de lecture sur le repo et d'écriture sur les packages. En 2022, GitHub a changé le défaut à `read-all` pour les nouvelles organisations — mais il faut vérifier et configurer explicitement les permissions.

• Principe du moindre privilège : déclarer `permissions: ` au niveau du job (lève toutes les permissions) et ne ré-accorder que ce qui est nécessaire
• Lecture seule par défaut : au niveau de l'organisation, définir le GITHUB_TOKEN à `read` par défaut dans les settings
• Permissions granulaires : `contents: read`, `pull-requests: write`, `id-token: write` — ne jamais mettre `permissions: write-all`
• Séparer les jobs : un job de build (permissions read) et un job de deploy (permissions write) évite de donner des permissions write au code de build

Sécuriser les actions tierces : pin sur SHA

`uses: actions/checkout@v4` fait confiance au tag `v4` qui peut pointer vers n'importe quel commit. Un attaquant contrôlant le repo de l'action peut modifier le code sans changer le tag. La solution : pin les actions sur leur SHA de commit exact.

• Pin sur SHA : `uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683` (SHA immuable)
• Outil Ratchet (Sethvargo) : automatise la conversion des tags vers des SHA dans les workflows YAML
• Dependabot pour Actions : activer Dependabot dans `.github/dependabot.yml` avec `package-ecosystem: github-actions` pour des mises à jour automatiques des SHA
• Audit des actions autorisées : dans les settings d'organisation, limiter les actions aux actions GitHub officielles et aux actions de confiance listées
• Policy : pas d'actions non vérifiées : interdire l'utilisation d'actions provenant de repos publics non vérifiés dans les workflows sensibles (déploiement en production)

SLSA : sécurité de la supply chain logicielle

SLSA (Supply Chain Levels for Software Artifacts) est un framework Google définissant des niveaux de sécurité pour la chaîne d'approvisionnement logicielle. GitHub Actions peut aider à atteindre SLSA niveau 3 :

• SLSA niveau 1 : provenance documentée (quel code a produit quel artefact) — GitHub Actions génère automatiquement les attestations SLSA
• SLSA niveau 2 : hébergé CI/CD (GitHub Actions est un CI/CD hébergé) + provenance signée
• SLSA niveau 3 : builder sécurisé avec isolation des jobs, provenance non altérable. GitHub Artifact Attestations permet de signer les artefacts produits par les workflows
• Sigstore / Cosign : signer les images Docker et les binaires produits par la CI/CD pour permettre leur vérification cryptographique lors du déploiement
• SBOM automatique : générer un Software Bill of Materials à chaque build pour tracer toutes les dépendances

Branch protection et environments

Les règles de protection des branches et les environments GitHub ajoutent des contrôles de gouvernance sur les déploiements :

• Branch protection rules : requérir des reviews sur les PRs avant merge sur `main`, interdire les force push, requérir des status checks (CI verte)
• GitHub Environments : créer des environments (`staging`, `production`) avec des secrets spécifiques à chaque environment et des règles d'approbation
• Required reviewers : déploiement en production nécessitant l'approbation manuelle d'un ou plusieurs reviewers désignés
• Deployment branches : limiter quelles branches peuvent déployer dans quel environment (seule `main` peut déployer en production)
• Wait timer : ajouter un délai avant le déploiement en production pour permettre l'annulation en cas d'erreur détectée post-merge

Scanning de sécurité dans les workflows

• Secrets scanning : activer GitHub Advanced Security pour détecter automatiquement les secrets commités (clés API, tokens, mots de passe)
• Code scanning (CodeQL) : analyse statique du code source dans chaque PR pour détecter les vulnérabilités SAST
• Dependency scanning : Dependabot Alerts pour les dépendances vulnérables (CVE dans package.json, requirements.txt, pom.xml)
• Container scanning : Trivy ou Grype pour scanner les images Docker produites par la CI/CD avant le push vers le registry
• IaC scanning : Checkov ou tfsec pour scanner les fichiers Terraform/CloudFormation dans les workflows de déploiement

Conclusion

GitHub Actions est un vecteur d'attaque de plus en plus ciblé. L'adoption de l'OIDC pour éliminer les secrets statiques, le pin des actions sur SHA, et la configuration des permissions minimales constituent les mesures prioritaires. Les GitHub Environments avec des approbations manuelles ajoutent une couche de gouvernance sur les déploiements en production. Mis ensemble, ces contrôles permettent d'atteindre un niveau SLSA 2-3 et de réduire significativement le risque d'attaque supply chain via votre CI/CD.