Sécuriser GitHub Actions : permissions, secrets et approbations

Chaque trigger GitHub Actions porte un niveau de confiance différent.

1. Lister les workflows et leurs événements.
2. Identifier les jobs qui écrivent dans le dépôt ou utilisent des secrets.
3. Distinguer CI sur pull request et publication après fusion approuvée.

# Rechercher dans .github/workflows :
# on: pull_request / push / workflow_dispatch
# permissions: ...
# environment: ...

Le moindre privilège réduit les dommages en cas de dépendance compromise.

1. Définir permissions: contents: read en haut du workflow CI.
2. Ajouter des permissions plus élevées seulement dans un job identifié.
3. Éviter de conserver les credentials Git sur le runner si aucun push n’est nécessaire.

name: CI sécurisée
on:
  pull_request:
    branches: [main]
permissions:
  contents: read
jobs:
  checks:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
        with:
          persist-credentials: false
      - run: echo 'Contrôles CI sur code non privilégié'

Un tag d’action peut évoluer, contrairement à la référence d’un commit approuvé.

1. Lister toutes les dépendances uses: des workflows.
2. Vérifier leur dépôt d’origine, le commit de version choisi et sa politique de mise à jour.
3. Remplacer les tags mouvants par les SHA complets après revue de la version.

# Épingler après vérification de provenance :
# uses: actions/checkout@<SHA-complet-valide>
# Vérifier aussi les actions tierces utilisées.

Les secrets de production ne sont pas nécessaires aux tests de code proposés par des contributeurs.

1. Utiliser des environnements GitHub pour les jobs de déploiement.
2. Exiger des approbateurs sur les environnements critiques lorsque disponible.
3. Préférer OIDC et les identités courtes durées aux secrets cloud statiques lorsque le fournisseur le permet.

# Exemple de job de déploiement (structure) :
# environment: production
# permissions:
#   contents: read
#   id-token: write  # seulement pour un flux OIDC approuvé

Une politique de sécurité doit être confirmée sur une exécution de recette.

1. Ouvrir une PR de documentation ne nécessitant aucun secret.
2. Vérifier que les contrôles s’exécutent sous permissions limitées.
3. Confirmer que le déploiement reste bloqué sans approbation de l’environnement protégé.

# Points de vérification dans GitHub :
# Actions > Run > Job > permissions
# Settings > Environments > production
# Pull request > Checks

La posture de sécurité se dégrade si les dépendances, les droits et les personnes habilitées ne sont pas suivis.

1. Documenter les propriétaires et versions des actions.
2. Réviser régulièrement les exceptions et les approbations.
3. Surveiller l’évolution des permissions et des déclencheurs dans les pull requests.

# Checklist de maintenance :
# Actions épinglées par SHA vérifié
# Token minimal
# Secrets d'environnement isolés
# Revue sur .github/workflows
# Déploiement après approbation