GhostAction : pourquoi vos workflows méritent une revue de code

Un fichier de configuration peut avoir autant de pouvoir que l’application qu’il construit. Dans GitHub Actions, un workflow détermine les commandes exécutées et les accès nécessaires au déploiement. Une modification présentée comme un contrôle de sécurité mérite donc une véritable revue.

Une identité connue peut porter une modification malveillante

Dans son analyse de GhostAction, StepSecurity décrit des comptes de mainteneurs compromis utilisés pour ajouter des workflows qui transmettent des identifiants à un attaquant. La campagne documentée examine aussi l’historique Git à la recherche de secrets.

Le nom du contributeur et l’intitulé du fichier ne permettent pas de juger sa fiabilité. Le point de contrôle est le comportement réel du workflow : ce qu’il exécute, ce qu’il lit et les destinations auxquelles il se connecte.

Traiter les fichiers de déploiement comme du code sensible

Avant d’accepter un changement, la personne qui le relit doit pouvoir expliquer son déclenchement, ses permissions et ses dépendances. Une commande téléchargée depuis une URL, un jeton supplémentaire ou un nouvel accès réseau doit avoir une raison compréhensible.

• Identifier les personnes autorisées à modifier les workflows.
• Prévoir une revue adaptée aux fichiers de construction et de déploiement.
• Limiter les identifiants au service et à l’environnement nécessaires.
• Réexaminer les actions externes et leurs versions avant de les introduire.

Le guide de sécurité de GitHub Actions fournit le cadre technique pour ces réglages. Leur disponibilité et leur comportement doivent être vérifiés pour votre offre et votre dépôt.

Une recherche vide ne prouve pas l’absence de compromission

Retrouver un nom de fichier connu aide au tri initial. Mais une campagne peut changer de nom, de destination ou de méthode. Une revue utile examine les modifications récentes, les exécutions et les accès effectifs, avec une période et un périmètre documentés.

Il faut également distinguer les secrets présents aujourd’hui de ceux qui ont été retirés du dernier commit. Un identifiant conservé dans l’historique reste un élément à traiter. Le supprimer du fichier courant ne le révoque pas chez son fournisseur.

Préparer la réponse avant d’effacer les traces

En cas de workflow suspect, stoppez les exécutions concernées et conservez les éléments nécessaires à l’enquête. Faites révoquer et remplacer les accès exposés, puis examinez les systèmes auxquels ils donnaient accès. Retirer le fichier ne suffit pas à rétablir la confiance.

Pour une entreprise qui confie son logiciel à un prestataire, la question est concrète : qui peut modifier la chaîne de livraison, qui valide le changement et qui reprend les accès lors d’une transition ? Ces responsabilités devraient être identifiées avant le premier déploiement.