GitHub Actions a un gestionnaire de paquets, mais il peut être catastrophique

• GitHub Actions a une structure qui, via la syntaxe uses: des fichiers de workflow, déclare et exécute les dépendances de paquets, ce qui lui permet d’assurer en pratique le rôle de gestionnaire de paquets
• Pourtant, il n’existe aucune des fonctionnalités que proposent par défaut les autres gestionnaires de paquets, comme le lockfile, le hash d’intégrité, le pinning des dépendances transitives et la visibilité de l’arbre des dépendances
• Selon la recherche, la plupart des utilisateurs de GitHub Actions exécutent du code externe non vérifié, et des vulnérabilités d’injection de code ont été trouvées dans des milliers de workflows
• Bien que GitHub ait introduit quelques mesures d’atténuation (releases immuables, politique de pinning SHA, etc.), les problèmes de dépendances transitives et de reproductibilité restent encore non résolus
• Ces défauts structurels affectent la sécurité globale de la chaîne d’approvisionnement logicielle et le même problème se propage aussi aux autres systèmes CI fondés sur GitHub Actions

---

Structure de gestion des paquets et problèmes de GitHub Actions

• Une syntaxe comme uses: actions/checkout@v4 est une déclaration de dépendance, que GitHub interprète pour télécharger et exécuter
  • C’est le même comportement que celui d’un gestionnaire de paquets classique, mais en l’absence de lockfile, une version différente peut être choisie à chaque exécution
• Comparé à d’autres gestionnaires de paquets (npm, Cargo, NuGet, etc.), Actions n’offre aucune fonctionnalité, comme le lockfile, le pinning transitif, la vérification d’intégrité, la visibilité de l’arborescence des dépendances ou la spécification d’interprétation
• L’absence du lockfile est le problème central, car l’interprétation des dépendances peut changer à chaque exécution, ce qui provoque des builds non déterministes

Résultats de recherche et vulnérabilités de sécurité

• Selon la recherche USENIX Security 2022, 99,7 % des dépôts exécutent les Actions de développeurs externes, 97 % sont des auteurs non vérifiés, 18 % sont sans mise à jour de sécurité
• Une étude ultérieure a trouvé des vulnérabilités d’injection de code dans plus de 4 300 workflows sur 2,7 millions
• GitHub Actions ne fournit pas pleinement des propriétés de sécurité CI/CD essentielles comme le contrôle d’admission, le contrôle d’exécution, le contrôle du code et le contrôle d’accès aux secrets

Principales défaillances techniques

• Problème de version variable : une étiquette comme @v4 peut être rebalisée par un mainteneur avec un nouveau commit, ce qui modifie silencieusement le code
  • Avec un lockfile, il serait possible d’enregistrer quel SHA a été résolu pour cette étiquette
• Opacité des dépendances transitives : les Actions appelées dans une Composite Action ne sont ni visibles ni contrôlables
  • Selon la recherche, 54 % des Actions JavaScript comportent des vulnérabilités, dont la plupart surviennent via des dépendances transitives
  • Avec l’incident tj-actions/changed-files, une attaque de fuite de secrets a eu lieu via la mise à jour d’une dépendance transitive
• Absence de vérification d’intégrité : npm ou Cargo enregistrent les hashs pour vérifier les téléchargements, tandis que Actions ne repose que sur la confiance basée sur SHA
• Non-reproductibilité lors des réexécutions : GitHub indique que « lorsqu’une version est forcée, la version la plus récente est récupérée », donc même avec le même workflow, un code différent peut être exécuté
• Non-visibilité de l’arbre des dépendances : il n’existe pas d’équivalent à npm ls de npm ou cargo tree de Cargo, donc aucun moyen de voir la structure complète des dépendances
• Règles d’interprétation non publiées : l’interprétation des dépendances d’Actions n’est pas documentée, et ActionManager.cs ne contient qu’une logique de téléchargement récursif simple

Limitations structurelles supplémentaires

• Absence de registre central : Actions vit dans un dépôt Git, sans fonction de scan de sécurité, détection de malware ou prévention de typosquatting
• Problème d’environnement partagé : plusieurs Action modifient le même $PATH, donc les résultats changent selon l’ordre d’exécution
• Impossible d’exécuter hors ligne : GitHub doit télécharger à chaque fois, donc impossible de l’exécuter sans réseau
• Vulnérabilité du namespace : le nom d’utilisateur GitHub sert de namespace, exposant au détournement de compte ou aux attaques par faute de frappe
  • Avec un lockfile et un hash d’intégrité, une modification de code serait détectée par un échec de build

Contexte de conception et effets de propagation

• Le runner Actions est à l’origine basé sur Azure DevOps pour un usage en environnement interne de confiance
  • Lorsqu’un tel modèle a été étendu par GitHub au marketplace public, le modèle de confiance n’a pas été redéfini
• C’est pourquoi des fonctions de base comme le lockfile, la vérification d’intégrité, le pinning des dépendances transitives et la visibilité des dépendances sont absentes
• La généralisation de la fonctionnalité de déploiement automatique de paquets basée sur OIDC a fait en sorte que les failles de sécurité de Actions affectent la chaîne d’approvisionnement de l’ensemble du registre de paquets
• GitLab CI a introduit le mot-clé integrity pour la vérification de hash, mais GitHub a mis fin à cette demande avec le statut “no plan”
• Les systèmes CI compatibles GitHub comme Forgejo Actions doivent aussi conserver la même structure, donc les défaillances se propagent à l’ensemble de l’écosystème

Propositions d’amélioration et état actuel

• La communauté a demandé la prise en charge du lockfile (issue #2195), mais GitHub l’a fermée en 2022 avec le statut “no plan”
• La recherche de Palo Alto a montré qu’un pinning SHA seul ne permet pas de protéger les dépendances transitives
• Certaines équipes compensent avec mise à jour Dependabot, vendor en interne dans leur propre dépôt, le scanner de sécurité zizmor, etc.
• La solution fondamentale est d’introduire un lockfile enregistrant SHA et hash d’intégrité de toutes les Actions et de leurs dépendances transitives
• Tant que GitHub ne l’adopte pas, il est impossible de garantir la fiabilité de la chaîne d’approvisionnement CI/CD