Contexte et motivations
Depuis le lancement de GitHub Actions, tout utilisateur disposant d’un accès en écriture pouvait déclencher un workflow. Cette liberté simplifie les contributions, mais elle crée un vecteur d’attaque : un compte compromis ou une pull request malveillante peut exploiter le pipeline pour exécuter du code non autorisé. GitHub signale que « un seul compte développeur compromis peut transformer une chaîne CI en chemin d’intrusion ». En réponse, la société a rendu disponible le 17 septembre 2026 les protections d’exécution de workflow, après une prévisualisation publique du 18 juin 2026.
Mécanisme des protections d’exécution
Les nouvelles règles s’articulent autour de deux axes : règles d’acteur et règles d’événement. Les règles d’acteur listent les identités autorisées : utilisateurs individuels, rôles de dépôt (Read, Maintain, Admin), applications GitHub, Copilot et Dependabot. Les règles d’événement spécifient les déclencheurs acceptés, parmi push, pull_request, pull_request_target et workflow_dispatch. Si l’acteur ou l’événement ne figure pas dans la liste blanche, le workflow est bloqué avant son lancement.
Une nouveauté majeure est la capacité de cibler des fichiers de workflow spécifiques. Ainsi, un fichier deploy.yml peut être limité à un groupe restreint, tandis que les workflows de test restent ouverts à l’ensemble des contributeurs. Cette granularité réduit le risque d’exposer des secrets dans des jobs qui ne nécessitent pas de droits élevés.
Gestion et gouvernance via API et insights
GitHub propose désormais des insights détaillés montrant l’évaluation des règles au niveau de l’entreprise, de l’organisation et du dépôt. Les administrateurs peuvent observer, avant le déploiement, quels workflows seraient bloqués grâce au mode d’évaluation, fonctionnant en mode « shadow ». Le même mode est disponible dans l’offre Enterprise Cloud.
Un REST API complet permet de créer, lire, mettre à jour et supprimer les règles aux trois niveaux, y compris les conditions de chemin de workflow. Cette API facilite l’intégration des politiques dans des pipelines d’infrastructure as code, assurant que les modifications de gouvernance sont soumises aux mêmes revues que le code applicatif.
Implications pour la sécurité des pipelines
Le principal risque ciblé est l’utilisation du déclencheur pull_request_target. Ce déclencheur s’exécute avec le jeton et les secrets du dépôt de base, ce qui signifie que du code provenant d’un fork non fiable peut accéder à des informations sensibles. GitHub introduit une règle par défaut désactivant pull_request_target dans les dépôts publics qui n’ont pas de politique d’événement explicite. Cette règle entre en vigueur le 2 novembre 2026 et s’applique uniquement aux dépôts publics ; les dépôts privés et internes restent hors de ce périmètre.
Les équipes doivent d’abord identifier les workflows utilisant pull_request_target, puis vérifier via les insights quelles exécutions auraient été bloquées. Si un workflow nécessite réellement ce déclencheur, deux solutions existent : ajouter une politique d’événement limitée à des fichiers précis, ou restructurer le processus en séparant l’analyse du code non fiable (lecture‑seule) d’une étape d’écriture distincte qui ne possède pas les secrets.
Enfin, les bots automatisés comme dependabot[bot] doivent être explicitement autorisés dans les règles d’acteur, faute de quoi leurs mises à jour automatisées seront bloquées. Cette exigence souligne la nécessité d’une cartographie précise des dépendances automatisées avant la mise en production des politiques.
