Durcir les workflows GitHub Actions : actions épinglées par SHA, jetons à moindre privilège et entrées non fiables

Objectif

Un workflow dont le comportement ne peut pas être modifié par un tiers publiant une nouvelle version d'action, dont le jeton ne peut pas pousser de code ni de tags sauf si une tâche en a explicitement besoin, et dont les scripts ne peuvent pas être détournés par un titre de pull request forgé.

Prérequis

Un accès en écriture aux fichiers de workflow et aux paramètres du dépôt ; une liste de chaque référence uses: dans .github/workflows.

Étapes

1. Remplacer chaque uses: owner/action@v4 par le SHA de commit complet à 40 caractères, en conservant le tag en commentaire (# v4.2.1). La référence sur l'usage sécurisé citée indique que l'épinglage sur un SHA de commit complet est actuellement le seul moyen d'utiliser une action comme une version immuable, et que le SHA doit être vérifié comme provenant du dépôt de l'action et non d'un fork. Laisser un robot de mise à jour des dépendances ouvrir des pull requests pour les nouveaux SHA.
2. Fixer permissions: contents: read au niveau supérieur de chaque workflow. Selon la syntaxe de workflow citée, spécifier une quelconque permission fixe toutes celles non spécifiées à none ; ajouter packages: write ou id-token: write sur la seule tâche qui publie.
3. Traiter les données d'événement comme non fiables : ne jamais écrire ${{ github.event.pull_request.title }} ni un nom de branche à l'intérieur d'un script run:. Faire transiter la valeur par une variable env: et référencer "$TITLE" dans le shell, ou déplacer la logique dans une action qui reçoit la valeur en argument, comme le recommande la référence sur l'usage sécurisé.
4. Éviter de récupérer (checkout) le code d'une pull request dans des workflows pull_request_target ou workflow_run ; la référence citée signale que ces déclencheurs s'exécutent avec un accès en écriture au dépôt et les secrets, même pour des forks. Si une étape privilégiée doit lire le contenu d'un fork, la scinder en un workflow non privilégié qui téléverse un artefact et un workflow privilégié qui le consomme sans l'exécuter.
5. Placer les secrets de déploiement dans des environnements exigeant des relecteurs, afin qu'une tâche ne puisse pas les lire tant qu'elle n'a pas été approuvée.
6. Activer la politique d'organisation ou de dépôt qui exige l'épinglage par SHA, afin qu'une modification future ne puisse pas faire régresser l'étape 1.

Résultat attendu

Chaque fichier de workflow désigne un code exact pour chaque dépendance, n'accorde au jeton que ce dont une tâche a besoin, et ne contient aucune ligne shell qui concatène des chaînes contrôlées par un attaquant.

Limites et base de vérification

L'épinglage par SHA gèle aussi bien les correctifs de bugs que les portes dérobées ; sans propositions de mise à jour automatisées, il dégénère en actions obsolètes. Les workflows réutilisables et les actions composites apportent leurs propres lignes uses:, qui doivent elles aussi être épinglées. Les recommandations suivent la documentation GitHub citée.