Le 17 mars 2026, Chainguard a annoncé Chainguard Actions : une offre qui ingère les GitHub Actions les plus utilisées du marketplace, les durcit automatiquement, puis republie des versions sécurisées que vous consommez à la place des originales. Je vais le dire franchement : c'est une excellente initiative, et une des rares annonces récentes qui s'attaque au bon maillon de la supply chain CI/CD. Depuis des années, je répète que les actions tierces sont un angle mort ; voir un acteur sérieux industrialiser leur durcissement est une très bonne nouvelle.
L'idée répond à une douleur bien réelle. L'attaque sur tj-actions/changed-files
avait exposé des secrets dans plus de 23 000 dépôts en réécrivant des tags
vers un commit malveillant, et un bot autonome baptisé hackerbot-claw a
montré qu'une IA pouvait scanner le web en continu pour trouver et exploiter des
configurations d'Actions vulnérables. Dans ce contexte, republier des briques
durcies et rebâties depuis les sources répond exactement au problème.
Dans ce billet, je détaille pourquoi je trouve l'approche saine, ce que la communauté en retient, et comment la compléter pour obtenir une chaîne CI/CD non seulement faite de bonnes briques, mais aussi bien assemblée de bout en bout. C'est là qu'un scanner comme plumber entre en scène, en partenaire naturel plutôt qu'en concurrent.
Une réponse directe à un vrai problème
Il faut saluer le timing et la justesse de la cible. Les incidents de
2025 et 2026 ont prouvé que l'angle mort des pipelines n'était plus
théorique. Les mêmes causes reviennent : tags mutables, permissions trop
larges, injection de commandes, pull_request_target mal maîtrisé.
J'en ai fait l'inventaire dans mon billet sur les 15 pièges de sécurité des
workflows GitHub Actions.
Chainguard place le curseur au bon endroit : la brique que vous n'avez pas écrite. Quand une action tierce est compromise, ce sont vos jetons GitHub, vos identifiants cloud et vos secrets qui partent. Réduire la confiance aveugle accordée à ces composants importés attaque le problème à sa racine, pas seulement ses symptômes. C'est cohérent avec la philosophie maison que j'ai déjà défendue dans mon analyse de l'incident Trivy et de la reconstruction depuis les sources : le dépôt source légitime et l'artefact digne de confiance ne sont pas la même chose.
Comment Chainguard Actions durcit vos actions
Le mécanisme est élégant. Chainguard ingère les actions populaires du marketplace, les passe dans des agents de durcissement qui combinent des règles codées en dur (motifs dangereux connus) et de l'IA pour repérer les cas plus subtils, puis republie des artefacts vérifiés.
Concrètement, l'offre corrige des classes de failles précises : injection de
commandes via interpolation non sûre dans les blocs run:, gestion
dangereuse des variables d'environnement, secrets interpolés directement
dans des commandes shell, et workflows trop permissifs. Chaque action durcie
est reconstruite depuis les sources, scannée en continu, et ses références
internes sont épinglées sur des SHA immuables. Chainguard met en avant la
prévention du tag hijacking, des abus de pull_request_target et de la
confusion de dépendances avant qu'ils n'atteignent le pipeline. Vous
consommez le tout via un préfixe chainguard-actions/*, avec une configuration
annoncée en trente secondes.
Le vrai atout, ce n'est pas l'IA. C'est le modèle de provenance : au lieu de tirer aveuglément une action publiée par un tiers, vous consommez une version rebâtie dans une chaîne maîtrisée, accompagnée d'un rapport de durcissement qui détaille ce qui a été corrigé, pourquoi et comment. Cette transparence change tout, parce qu'elle transforme un acte de foi en une décision documentée et vérifiable.
Ce que la communauté en retient
L'accueil a été globalement positif, avec quelques nuances utiles que je trouve saines. La presse spécialisée a surtout noté que la catégorie reste jeune : beaucoup d'ingénieurs plateforme et de professionnels sécurité ne distinguent pas encore clairement "durcir une action" de "sécuriser un pipeline". Interrogé sur le chevauchement avec GitHub lui-même, le PDG Dan Lorenc est resté prudent, signe que la frontière entre partenaire et concurrent de la plateforme reste à écrire. Et l'offre est encore en beta sur liste d'attente, ce qui invite logiquement à la tester avant de généraliser.
Le point technique le plus stimulant vient d'un billet très partagé, "The
comforting lie of SHA pinning". Il rappelle une subtilité importante :
épingler une action sur un SHA ne fait pas tout. GitHub résout un commit par
son contenu, pas par sa provenance, et un commit vit dans le graphe
d'objets partagé entre un dépôt et ses forks. Le SHA est donc universel
mais non scopé à owner/repo, là où le tag est scopé mais mutable. Ce
n'est pas une critique de Chainguard, qui épingle très bien ses briques ; c'est
un rappel que le pinning est une couche parmi d'autres, jamais la couche
finale.
Une brique de la chaîne, pas toute la chaîne
Voilà le seul point que je veux clarifier, non pas comme un reproche, mais comme une question de périmètre. Chainguard Actions sécurise les actions tierces que vous consommez. Par construction, il ne regarde pas votre propre fichier de workflow, et ce n'est pas son rôle.
Or une chaîne CI/CD, ce n'est pas seulement des briques : c'est aussi la façon
dont vous les assemblez. Vous pouvez appeler une action parfaitement durcie
depuis un workflow qui déclare permissions: write-all, qui expose un secret
dans votre propre bloc run:, ou qui utilise
pull_request_target
avec un checkout de code non fiable. Ces erreurs vivent dans votre dépôt,
dans votre assemblage, pas dans la brique importée.
Autre élément de périmètre à garder en tête : Chainguard Actions cible GitHub Actions. Si une partie de vos pipelines tourne sur GitLab CI, il faut une couche qui couvre aussi cet écosystème.
Bonne nouvelle : c'est exactement le genre de complément qui existe déjà, et qui s'articule parfaitement avec l'initiative de Chainguard.
plumber : valider que la chaîne est bien construite
C'est là qu'un scanner de pipeline comme plumber prend tout son sens. Là où Chainguard soigne la qualité des briques, plumber vérifie que la chaîne est bien construite et complète dans vos dépôts. Son cycle est explicite : cartographier tous vos pipelines, détecter les problèmes, aider à corriger, puis noter de A à E pour objectiver le niveau atteint.
Ce qu'il regarde couvre précisément ce que Chainguard laisse, à raison, hors de son périmètre :
- secrets exposés et variables non masquées dans vos jobs,
- registres non fiables et tags mutables dans vos images,
- actions tierces non épinglées ou vulnérables,
- permissions trop larges accordées au workflow,
- déclencheurs dangereux comme
pull_request_target, - absence de protection de branche.
Deux propriétés en font un partenaire idéal de l'approche Chainguard. D'abord, la CLI est open source et gratuite : elle scanne un pipeline depuis votre terminal ou votre CI, sans que rien ne quitte votre environnement. C'est une vérification que vous possédez, qui vient équilibrer la confiance placée dans un registre externe. Ensuite, plumber couvre GitHub Actions et GitLab CI, donc les deux écosystèmes qu'une offre GitHub-first ne peut pas adresser seule. Dans la même famille, mes guides sur zizmor et poutine montrent d'autres scanners statiques qui jouent ce rôle de contrôle de l'assemblage.
Ma recette pour une chaîne CI/CD complète
L'un ne remplace pas l'autre : ils s'empilent, et c'est toute la logique de la défense en profondeur. Voici comment je combinerais les deux.
- En amont, la qualité des briques. Consommer des actions durcies et rebâties depuis les sources réduit le risque qu'une brique importée soit malveillante. Chainguard Actions remplit ce rôle, dans la lignée de la reconstruction interne que je défends depuis l'incident Trivy.
- En continu, la validation de l'assemblage. Faire passer vos workflows dans plumber, zizmor ou poutine, dans la CI, à chaque commit, pour attraper les permissions, secrets et déclencheurs introduits par votre propre code.
- Comme socle, les réflexes indépendants de tout fournisseur.
Épingler sur SHA,
restreindre les permissions,
bannir
pull_request_targetsur du code non fiable. Ces réflexes restent valables en toute circonstance.
La bonne image : Chainguard vous livre des ingrédients mieux contrôlés, plumber vérifie que votre recette est complète et correctement suivie. Les deux ensemble donnent un plat sain.
À retenir
- Chainguard Actions (annoncé le 17 mars 2026, en beta) est une excellente initiative : il ingère, durcit et republie des GitHub Actions populaires, reconstruites depuis les sources.
- Il corrige des failles réelles des briques tierces : injection, secrets mal interpolés, workflows permissifs, tags mutables, le tout avec un rapport de durcissement transparent.
- La communauté salue l'approche, avec des nuances saines : catégorie jeune, positionnement à préciser face à GitHub, et rappel que le SHA pinning n'est qu'une couche.
- Par périmètre, l'offre soigne les briques, pas votre assemblage : permissions, secrets et déclencheurs de vos workflows restent votre responsabilité.
- Un scanner comme plumber complète l'initiative en validant que la chaîne est bien construite, en open source, sur GitHub Actions et GitLab CI.
- La bonne posture est complémentaire : briques durcies en amont, validation continue de l'assemblage, réflexes indépendants de tout fournisseur.