GitHub Actions est devenu l’une des plateformes CI\/CD les plus largement adopt\u00e9es. Sa flexibilit\u00e9, son int\u00e9gration \u00e9troite avec les d\u00e9p\u00f4ts GitHub et son riche \u00e9cosyst\u00e8me en font un choix attractif pour les \u00e9quipes de toutes tailles.<\/p>\n
Parall\u00e8lement, les runners GitHub Actions sont apparus comme une surface d’attaque critique dans les attaques modernes contre la cha\u00eene d’approvisionnement logicielle.<\/p>\n
Les runners ex\u00e9cutent du code non fiable, manipulent des secrets sensibles et op\u00e8rent souvent avec des permissions \u00e9tendues sur les d\u00e9p\u00f4ts, les registres d’artefacts et les environnements cloud.<\/p>\n
Cet article explique le fonctionnement des runners GitHub Actions, pourquoi ils sont fr\u00e9quemment cibl\u00e9s par les attaquants, et comment concevoir des architectures de runners qui r\u00e9duisent significativement les risques sans perturber les workflows des d\u00e9veloppeurs.<\/p>\n
Un runner est l’environnement d’ex\u00e9cution dans lequel les workflows GitHub Actions s’ex\u00e9cutent r\u00e9ellement. Chaque job d’un workflow est ex\u00e9cut\u00e9 sur un runner.<\/p>\n
Du point de vue de la s\u00e9curit\u00e9, les runners sont le composant le plus sensible de l’architecture GitHub Actions car ils :<\/p>\n
Si un runner est compromis, l’attaquant peut \u00eatre en mesure de :<\/p>\n
Comprendre la s\u00e9curit\u00e9 des runners commence par comprendre les types de runners. GitHub Actions prend en charge plusieurs mod\u00e8les de runners, chacun avec des caract\u00e9ristiques de confiance et de risque diff\u00e9rentes.<\/p>\n
Les runners h\u00e9berg\u00e9s par GitHub sont g\u00e9r\u00e9s par GitHub et fournis sous forme de machines virtuelles \u00e9ph\u00e9m\u00e8res. Chaque job s’ex\u00e9cute g\u00e9n\u00e9ralement sur une VM neuve qui est d\u00e9truite apr\u00e8s l’ex\u00e9cution.<\/p>\n
Caract\u00e9ristiques de s\u00e9curit\u00e9 :<\/p>\n
Du point de vue de la s\u00e9curit\u00e9, les runners h\u00e9berg\u00e9s par GitHub offrent une base solide pour les charges de travail non fiables telles que les pull requests.<\/p>\n
Cependant, ils ne sont pas sans risque. L’exposition des secrets, l’utilisation abusive des permissions et la logique de workflow malveillante peuvent toujours conduire \u00e0 une compromission.<\/p>\n
Les runners self-hosted s’ex\u00e9cutent sur une infrastructure g\u00e9r\u00e9e par l’organisation : machines virtuelles, serveurs physiques ou conteneurs.<\/p>\n
Ils sont souvent utilis\u00e9s pour :<\/p>\n
Du point de vue de la s\u00e9curit\u00e9, les runners self-hosted introduisent des risques significatifs :<\/p>\n
Sans une isolation forte, un seul job compromis peut affecter les builds futurs ou d’autres d\u00e9p\u00f4ts.<\/p>\n
Les runners self-hosted \u00e9ph\u00e9m\u00e8res combinent la flexibilit\u00e9 des runners self-hosted avec les avantages s\u00e9curitaires de l’\u00e9ph\u00e9m\u00e9rit\u00e9.<\/p>\n
Chaque job s’ex\u00e9cute sur un runner fra\u00eechement provisionn\u00e9 qui est d\u00e9truit apr\u00e8s la fin de l’ex\u00e9cution.<\/p>\n
Ce mod\u00e8le r\u00e9duit significativement :<\/p>\n
Du point de vue de la s\u00e9curit\u00e9, les runners self-hosted \u00e9ph\u00e9m\u00e8res sont fortement pr\u00e9f\u00e9r\u00e9s aux runners persistants.<\/p>\n
Les runners se situent \u00e0 l’intersection des entr\u00e9es non fiables et des op\u00e9rations privil\u00e9gi\u00e9es. Cela en fait des cibles attractives pour les attaquants.<\/p>\n
Les workflows peuvent ex\u00e9cuter du code provenant de :<\/p>\n
N’importe laquelle de ces sources peut \u00eatre influenc\u00e9e par un attaquant. Si du code non fiable s’ex\u00e9cute sur un runner disposant de secrets ou de permissions \u00e9lev\u00e9es, la compromission est imm\u00e9diate.<\/p>\n
Les secrets sont couramment expos\u00e9s aux runners via des variables d’environnement.<\/p>\n
Si les conditions du workflow sont mal configur\u00e9es, les secrets peuvent \u00eatre accessibles par :<\/p>\n
Une fois qu’un secret est expos\u00e9, il est souvent difficile de le d\u00e9tecter ou de le contenir.<\/p>\n
Les runners compilent et empaquettent les artefacts logiciels.<\/p>\n
Si un attaquant modifie le r\u00e9sultat du build, l’artefact r\u00e9sultant peut \u00eatre distribu\u00e9 avec une confiance totale en aval.<\/p>\n
Sans v\u00e9rifications d’int\u00e9grit\u00e9 des artefacts, il peut \u00eatre impossible de d\u00e9tecter la compromission.<\/p>\n
La mod\u00e9lisation des menaces sur les runners r\u00e9v\u00e8le des sch\u00e9mas d’attaque r\u00e9currents.<\/p>\n
Un attaquant soumet une pull request qui modifie la logique du workflow ou introduit des \u00e9tapes de build malveillantes.<\/p>\n
Si le workflow expose des secrets ou des tokens privil\u00e9gi\u00e9s aux builds de PR, l’attaquant peut exfiltrer les identifiants.<\/p>\n
Cette attaque ne n\u00e9cessite aucune vuln\u00e9rabilit\u00e9 \u2014 seulement une mauvaise configuration de la confiance.<\/p>\n
Les workflows utilisent fr\u00e9quemment des actions tierces.<\/p>\n
Si une action est compromise en amont ou r\u00e9f\u00e9renc\u00e9e sans \u00e9pinglage sur un commit sp\u00e9cifique, l’attaquant peut injecter un comportement malveillant dans les workflows.<\/p>\n
Le runner ex\u00e9cute l’action avec les m\u00eames permissions que le code de workflow interne.<\/p>\n
Sur les runners self-hosted persistants, un attaquant peut :<\/p>\n
Les workflows futurs peuvent ex\u00e9cuter du code contr\u00f4l\u00e9 par l’attaquant sans le savoir.<\/p>\n
Les runners self-hosted ont souvent un acc\u00e8s r\u00e9seau aux syst\u00e8mes internes ou aux environnements cloud.<\/p>\n
Un runner compromis peut \u00eatre utilis\u00e9 comme pivot pour attaquer d’autres services internes.<\/p>\n
S\u00e9curiser les runners GitHub Actions est un probl\u00e8me d’architecture, pas un probl\u00e8me de checklist.<\/p>\n
Une s\u00e9curit\u00e9 efficace des runners repose sur quelques principes fondamentaux.<\/p>\n
Les runners ex\u00e9cutent des entr\u00e9es non fiables par conception.<\/p>\n
Ils ne devraient jamais \u00eatre implicitement consid\u00e9r\u00e9s comme fiables, m\u00eame s’ils fonctionnent au sein d’une infrastructure interne.<\/p>\n
Les secrets, l’acc\u00e8s r\u00e9seau et les privil\u00e8ges doivent \u00eatre limit\u00e9s en cons\u00e9quence.<\/p>\n
Tenter de \u00ab nettoyer \u00bb un runner compromis n’est pas fiable.<\/p>\n
D\u00e9truire et recr\u00e9er les runners apr\u00e8s chaque job offre une garantie de s\u00e9curit\u00e9 bien plus forte.<\/p>\n
Les runners \u00e9ph\u00e9m\u00e8res \u00e9liminent la persistance et r\u00e9duisent significativement le temps de s\u00e9jour de l’attaquant.<\/p>\n
Chaque job ne devrait recevoir que les permissions dont il a besoin.<\/p>\n
Cela inclut :<\/p>\n
\u00c9vitez d’accorder des permissions globales ou des permissions d’\u00e9criture par d\u00e9faut.<\/p>\n
Les builds de pull requests, les contributions externes et le code non fiable doivent s’ex\u00e9cuter dans des environnements s\u00e9par\u00e9s des jobs de release ou de d\u00e9ploiement fiables.<\/p>\n
Cette s\u00e9paration peut \u00eatre appliqu\u00e9e via :<\/p>\n
Minimisez ce qui est disponible sur les runners :<\/p>\n
Une surface d’attaque r\u00e9duite limite les options de l’attaquant.<\/p>\n
Les pratiques suivantes r\u00e9pondent aux risques les plus courants li\u00e9s aux runners sans modifier fondamentalement les workflows des d\u00e9veloppeurs.<\/p>\n
Pour les pull requests et les contributions externes, les runners h\u00e9berg\u00e9s par GitHub offrent une isolation forte et une \u00e9ph\u00e9m\u00e9rit\u00e9 automatique.<\/p>\n
\u00c9vitez d’exposer des secrets \u00e0 ces jobs sauf en cas de n\u00e9cessit\u00e9 absolue.<\/p>\n
Si des runners self-hosted sont n\u00e9cessaires, rendez-les \u00e9ph\u00e9m\u00e8res.<\/p>\n
Chaque job devrait :<\/p>\n
Ce mod\u00e8le r\u00e9duit consid\u00e9rablement le risque de persistance.<\/p>\n
Utilisez le mod\u00e8le de permissions granulaires de GitHub.<\/p>\n
D\u00e9finissez les permissions au niveau du workflow ou du job au lieu de vous appuyer sur les valeurs par d\u00e9faut.<\/p>\n
Examinez les modifications de permissions aussi attentivement que les modifications de code.<\/p>\n
\u00c9pinglez toujours les actions sur un SHA de commit sp\u00e9cifique.<\/p>\n
\u00c9vitez d’utiliser des actions qui :<\/p>\n
Traitez les actions comme faisant partie de votre cha\u00eene d’approvisionnement.<\/p>\n
\u00c9vitez d’exposer des secrets aux workflows d\u00e9clench\u00e9s par :<\/p>\n
Pr\u00e9f\u00e9rez les identifiants \u00e0 dur\u00e9e de vie courte et l’acc\u00e8s bas\u00e9 sur l’identit\u00e9 plut\u00f4t que les secrets statiques.<\/p>\n
Ne pr\u00e9sumez pas que les artefacts produits par les runners sont fiables.<\/p>\n
Utilisez :<\/p>\n
Cela garantit que des runners compromis ne peuvent pas empoisonner silencieusement les releases.<\/p>\n
La s\u00e9curit\u00e9 des runners est une composante de la s\u00e9curit\u00e9 des pipelines, mais elle ne peut pas fonctionner seule.<\/p>\n
Elle doit \u00eatre combin\u00e9e avec :<\/p>\n
Sans ces \u00e9l\u00e9ments, m\u00eame des runners bien s\u00e9curis\u00e9s peuvent encore produire des r\u00e9sultats non fiables.<\/p>\n
Les runners GitHub Actions sont un puissant outil d’automatisation, mais ils repr\u00e9sentent \u00e9galement un environnement d’ex\u00e9cution \u00e0 haut risque.<\/p>\n
Ils ex\u00e9cutent du code non fiable, manipulent des identifiants sensibles et produisent des artefacts auxquels les syst\u00e8mes en aval font confiance.<\/p>\n
S\u00e9curiser les runners n\u00e9cessite des d\u00e9cisions architecturales : \u00e9ph\u00e9m\u00e9rit\u00e9, isolation, moindre privil\u00e8ge et s\u00e9paration explicite des niveaux de confiance.<\/p>\n
Les organisations qui traitent les runners comme des environnements d’ex\u00e9cution jetables et non fiables \u2014 plut\u00f4t que comme une infrastructure de confiance \u2014 sont bien mieux positionn\u00e9es pour se d\u00e9fendre contre les attaques modernes visant les pipelines CI\/CD et la cha\u00eene d’approvisionnement.<\/p>\n