Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

GitHub Actions Security

devsecops

Définition

GitHub Actions Security couvre les pratiques de durcissement des workflows CI/CD exécutés sur la plateforme GitHub Actions, cible privilégiée d'attaques de supply chain logicielle ces dernières années. La permission minimale consiste à restreindre le champ permissions du token GITHUB_TOKEN au strict nécessaire (lecture seule par défaut plutôt que write global), limitant l'impact d'un workflow compromis. Le pinning des actions tierces par hash SHA complet, plutôt que par tag mutable comme @v3, empêche qu'une action malveillante substituée après coup s'exécute silencieusement dans le pipeline, une technique déjà exploitée lors de compromissions réelles d'actions populaires. La gestion des secrets passe par GitHub Secrets chiffrés, jamais exposés dans les logs ni passés en clair aux workflows de pull request externes, particulièrement sensibles sur les dépôts publics où pull_request_target peut exécuter du code non fiable avec accès aux secrets. L'authentification cloud sans credentials statiques via OIDC (OpenID Connect), qui permet à un workflow d'obtenir un rôle IAM temporaire chez AWS, Azure ou GCP, remplace avantageusement les clés d'accès stockées en secret. Une revue de code obligatoire avant merge et l'usage d'environnements protégés avec approbation manuelle pour les déploiements sensibles complètent ce dispositif de défense en profondeur.

Description

GitHub Actions sécurisé exige de pinner les actions tierces par SHA de commit (uses: actions/checkout@a5ac7e51), d'utiliser OIDC pour l'authentification cloud sans secrets statiques, de déclarer les permissions minimales (permissions: contents: read) et d'activer le code review des workflows.

Mise en œuvre

Configurer ACTIONS_RUNNER_DEBUG=false, stocker les secrets dans GitHub Secrets ou environments protégés, activer Dependabot pour les actions, et utiliser github.event.pull_request.head.sha plutôt que github.sha pour les PRs externes.

Points clés

  • OIDC cloud auth : aws-actions/configure-aws-credentials avec role ARN — zéro secret AWS
  • Script injection : toujours passer les données via env:, jamais directement dans run:
  • StepSecurity Harden-Runner : audit des sorties réseau des runners

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis