Un fichier de quelques lignes dans .github/workflows peut télécharger du code, lire des jetons, publier un paquet ou déployer en production. Lorsqu'un compte GitHub est compromis, modifier ce fichier donne à l'attaquant un chemin direct vers la chaîne CI/CD. GitHub ajoute désormais une barrière : certains workflows Actions considérés comme potentiellement malveillants sont suspendus avant leur exécution.

Le run ne démarre qu'après la revue et l'approbation d'un collaborateur disposant d'un accès en écriture. Cette approbation doit être effectuée depuis une session web authentifiée. La protection est automatique, mais son périmètre est limité aux dépôts publics hébergés sur github.com. GitHub Enterprise Server n'en bénéficie pas à ce stade.

Ce que change le nouveau contrôle

GitHub explique avoir observé des attaques de supply chain dans lesquelles des identifiants compromis servent à pousser un workflow malveillant. Celui-ci tente ensuite de voler des secrets CI/CD ou d'enchaîner d'autres actions sur le dépôt et ses systèmes connectés.

Le nouveau mécanisme ajoute un état intermédiaire :

  1. une modification ou un événement déclenche normalement un workflow ;
  2. GitHub détecte des signaux qu'il considère suspects ;
  3. le run est placé en attente avant qu'un runner ne l'exécute ;
  4. un collaborateur avec un droit d'écriture examine le changement ;
  5. l'approbation web libère le workflow, ou l'équipe le laisse bloqué et enquête.

Aucune configuration n'est nécessaire pour activer cette protection sur le périmètre concerné. GitHub ne détaille pas publiquement tous les signaux de détection, ce qui évite aussi de fournir une recette de contournement trop précise.

Pourquoi un workflow est une cible privilégiée

Un pipeline n'est pas seulement un script de test. Il peut recevoir un GITHUB_TOKEN, accéder à des secrets du dépôt ou d'un environnement, utiliser une identité cloud via OIDC, écrire dans un registre et lancer un déploiement. Les runners auto-hébergés peuvent en outre avoir accès au réseau interne ou à des fichiers persistants.

Un attaquant n'a donc pas besoin de modifier directement le produit. Il peut ajouter une étape qui envoie une variable vers un serveur externe, remplacer une action par une version compromise, détourner un script appelé par le pipeline ou profiter d'une expression construite à partir d'une donnée non fiable.

Le danger vient de la combinaison entre code modifiable et contexte privilégié. Une ligne apparemment anodine comme l'ajout d'une permission d'écriture, d'un curl ou d'une action tierce doit être examinée en fonction des droits du job entier.

Ce filtre n'est pas l'approbation classique des forks

GitHub permet déjà d'exiger une validation pour les workflows provenant de pull requests externes. Selon les paramètres du dépôt, l'approbation peut concerner les nouveaux contributeurs, les contributeurs n'ayant jamais été intégrés ou tous les contributeurs externes.

Cette politique repose principalement sur l'origine de la contribution et la relation de son auteur avec le projet. Le nouveau contrôle annoncé vise, lui, des workflows identifiés comme potentiellement malveillants dans le contexte d'attaques utilisant des comptes compromis.

Les deux protections sont complémentaires. Un contributeur connu peut se faire voler son compte. À l'inverse, un workflow provenant d'un nouveau contributeur peut être légitime tout en nécessitant une revue. Les mainteneurs ne doivent pas interpréter l'absence de blocage automatique comme une validation de sécurité.

La revue à effectuer avant de cliquer

Le bouton d'approbation ne doit jamais devenir une formalité destinée à faire repartir une CI rouge. Avant de libérer le run, il faut comparer la modification au comportement attendu.

Une revue utile vérifie au minimum :

  • les fichiers modifiés dans .github/workflows, les actions composites et les scripts appelés ;
  • l'événement déclencheur, notamment pull_request_target, workflow_run, push et workflow_dispatch ;
  • toute hausse des permissions du GITHUB_TOKEN ;
  • l'accès à des secrets de dépôt, d'organisation ou d'environnement ;
  • les identités cloud demandées avec id-token: write ;
  • les commandes réseau, téléchargements et envois de données ;
  • les actions tierces ajoutées ou dont la référence a changé ;
  • le runner utilisé et son éventuel accès au réseau interne ;
  • les artefacts, caches et sorties provenant d'un workflow moins privilégié.

Il faut également confirmer l'identité de l'auteur par un autre canal si le changement est inhabituel. Un commit signé ou un compte protégé réduit certains risques, mais un poste déjà compromis peut encore produire une modification crédible.

Les déclencheurs privilégiés restent sensibles

La documentation GitHub souligne le risque de pull_request_target et de workflow_run lorsqu'ils récupèrent du code non fiable. Ces déclencheurs peuvent fonctionner dans le contexte de la branche principale, avec des permissions ou des secrets absents d'un simple workflow pull_request.

Le scénario dangereux consiste à exécuter du code contrôlé par une pull request dans ce contexte privilégié. Même si le fichier YAML semble sain, un checkout de la branche externe puis un script d'installation peuvent donner le contrôle au contributeur.

Une architecture plus sûre sépare les étapes : le workflow non privilégié compile ou teste du code sans secrets, puis un workflow distinct consomme uniquement des résultats strictement vérifiés. Les artefacts et caches doivent eux aussi être considérés comme des entrées non fiables, pas comme des zones neutres.

Réduire l'impact si un workflow passe

La détection de GitHub ajoute une chance d'arrêter l'attaque, mais le principe du moindre privilège limite les dégâts lorsqu'elle échoue. Chaque workflow devrait déclarer ses permissions au niveau le plus bas possible, idéalement en lecture seule par défaut, puis ouvrir seulement le droit requis pour un job précis.

Pour les déploiements, les secrets d'environnement et les règles de protection peuvent retarder l'accès aux identifiants sensibles jusqu'à une validation dédiée. OIDC évite certains secrets cloud de longue durée, à condition que la politique du fournisseur limite précisément le dépôt, la branche, l'environnement et l'audience autorisés.

Les actions tierces méritent d'être épinglées sur un SHA complet plutôt que sur un tag mutable. Les runners auto-hébergés ne devraient pas exécuter du code externe non fiable sur une machine persistante connectée au réseau de production.

Enfin, les journaux d'audit, les alertes sur les modifications de workflows et la rotation rapide des identifiants doivent faire partie du plan d'incident. Si un run suspect a déjà démarré, annuler le job ne suffit pas : il faut supposer que les secrets accessibles ont pu être lus.

Que faire face à un run suspendu ?

Une équipe peut formaliser une procédure courte :

  1. ne pas approuver immédiatement, même si le changement semble urgent ;
  2. conserver l'identifiant du run, le commit, l'acteur et l'heure ;
  3. comparer le diff avec la demande métier ou le ticket attendu ;
  4. contacter l'auteur via un canal indépendant ;
  5. examiner les connexions récentes du compte et les autres commits associés ;
  6. refuser ou neutraliser le workflow en cas de doute ;
  7. révoquer les sessions et faire tourner les secrets si une exécution antérieure paraît suspecte ;
  8. documenter la décision afin d'améliorer les règles internes.

L'approbateur doit disposer du temps et des compétences nécessaires. Donner l'accès en écriture uniquement pour permettre de cliquer sur un bouton élargit inutilement la surface d'attaque.

Une barrière utile, pas un verdict

Le contrôle automatique intervient au bon endroit : avant l'exécution d'un fichier capable de transformer un compte compromis en accès aux systèmes de livraison. Il peut casser la vitesse d'une attaque qui comptait sur une CI automatique et silencieuse.

Mais GitHub ne promet ni de détecter chaque workflow dangereux ni de couvrir les dépôts privés et les installations Enterprise Server avec cette annonce. Une modification non suspendue peut être malveillante, et une modification suspendue peut être légitime.

La valeur du mécanisme dépendra donc de la qualité de la revue humaine. Une équipe qui vérifie les permissions, les secrets, le code récupéré et l'identité de l'auteur transforme l'attente en véritable contrôle de sécurité. Une équipe qui approuve mécaniquement ne fait que déplacer l'exécution de quelques minutes.