On 17 March 2026, Chainguard announced Chainguard Actions: a service that ingests the most used GitHub Actions from the marketplace, hardens them automatically, then republishes secured versions you consume instead of the originals. Let me say it plainly: this is an excellent initiative, and one of the few recent announcements that targets the right link in the CI/CD supply chain. I have been repeating for years that third-party actions are a blind spot, so watching a serious vendor industrialise their hardening is very good news.
The idea answers a real pain. The attack on tj-actions/changed-files exposed
secrets across more than 23,000 repositories by rewriting tags to a malicious
commit, and an autonomous bot called hackerbot-claw proved that an AI could
continuously scan the web for vulnerable Actions configurations. In that context,
republishing bricks that are hardened and rebuilt from source addresses
exactly the right problem.
This post covers why I find the approach sound, what the community took away from it, and how to complement it so your CI/CD chain is not only made of good bricks, but also correctly assembled end to end. That is where a scanner like plumber comes in, as a natural partner rather than a competitor.
A direct answer to a real problem
The timing and the target are both right. The incidents of 2025 and 2026
proved the pipeline blind spot was no longer theoretical. The same causes
keep coming back: mutable tags, overly broad permissions, command
injection, and mishandled pull_request_target.
Chainguard puts the cursor in the right place: the brick you did not write. When a third-party action is compromised, it is your GitHub tokens, your cloud credentials and your secrets that walk out the door. Reducing the blind trust placed in imported components attacks the problem at its root, not just its symptoms. The legitimate source repository and the trustworthy artifact are not the same thing, a distinction the Trivy incident made painfully concrete.
How Chainguard Actions hardens your actions
The mechanism is elegant. Chainguard ingests popular actions from the marketplace, runs them through hardening agents that combine hard-coded rules for known dangerous patterns with AI for subtler cases, then republishes verified artifacts.
In practice, the service fixes precise vulnerability classes: command
injection through unsafe interpolation in run: blocks, dangerous
environment variable handling, secrets interpolated directly into shell
commands, and overly permissive workflows. Every hardened action is rebuilt
from source, continuously scanned, and its internal references are pinned to
immutable SHAs. Chainguard highlights prevention of tag hijacking,
pull_request_target abuse and dependency confusion before they reach your
pipeline. You consume everything through a chainguard-actions/* prefix.
The real asset is not the AI. It is the provenance model. Instead of blindly pulling an action published by a third party, you consume a version rebuilt in a controlled chain, with a hardening report detailing what was fixed, why and how. That transparency is what changes the equation, because it turns an act of faith into a documented, verifiable decision.
What the community took away
Reception was broadly positive, with a few healthy caveats. Trade press noted that the category is still young: many platform engineers and security professionals do not yet clearly separate "hardening an action" from "securing a pipeline". Asked about the overlap with GitHub itself, CEO Dan Lorenc stayed cautious, a sign that the line between partner and competitor to the platform remains to be drawn. The service is also still in waitlisted beta, which logically invites testing before any broad rollout.
The most stimulating technical point came from a widely shared post, "The
comforting lie of SHA pinning". It restates an important subtlety: pinning an
action to a SHA does not do everything. GitHub resolves a commit by its
content, not by its provenance, and a commit lives in an object graph
shared between a repository and its forks. The SHA is therefore universal
but not scoped to owner/repo, whereas the tag is scoped but mutable. This
is not a criticism of Chainguard, which pins its bricks properly; it is a
reminder that pinning is one layer among several, never the final one.
One brick in the chain, not the whole chain
This is the single point I want to clarify, as a matter of scope rather than criticism. Chainguard Actions secures the third-party actions you consume. By construction, it does not look at your own workflow file, and that is not its job.
Yet a CI/CD chain is not only bricks: it is also how you assemble them. You
can call a perfectly hardened action from a workflow that declares
permissions: write-all, that leaks a secret in your own run: block, or that
uses pull_request_target with an untrusted code checkout. Those mistakes live
in your repository, in your assembly, not in the imported brick.
One more scoping point: Chainguard Actions targets GitHub Actions. If part of your pipelines runs on GitLab CI, you need a layer that covers that ecosystem too.
plumber: checking the chain is properly built
This is where a pipeline scanner earns its place. Where Chainguard takes care of brick quality, plumber verifies that the chain is properly built and complete inside your repositories. Its cycle is explicit: map all your pipelines, detect problems, help fix them, then grade from A to E to make the level objective.
What it inspects covers precisely what Chainguard rightly leaves out of scope:
- exposed secrets and unmasked variables in your jobs,
- untrusted registries and mutable tags in your images,
- unpinned or vulnerable third-party actions,
- overly broad permissions granted to the workflow,
- dangerous triggers such as
pull_request_target, - missing branch protection.
Two properties make it an ideal partner to the Chainguard approach. First, the CLI is open source and free: it scans a pipeline from your terminal or your CI, without anything leaving your environment. That is a check you own, balancing the trust placed in an external registry. Second, plumber covers GitHub Actions and GitLab CI, the two ecosystems a GitHub-first offering cannot address on its own.
My recipe for a complete CI/CD chain
One does not replace the other: they stack, and that is the whole logic of defence in depth. Here is how I would combine them.
- Upstream, brick quality. Consuming hardened actions rebuilt from source reduces the risk that an imported brick is malicious. Chainguard Actions fills that role.
- Continuously, assembly validation. Run your workflows through plumber, zizmor or poutine, in CI, on every commit, to catch the permissions, secrets and triggers introduced by your own code.
- As a foundation, vendor-independent reflexes. Pin to SHAs, restrict
permissions, and ban
pull_request_targeton untrusted code. These hold in every circumstance.
The right image: Chainguard delivers better controlled ingredients, plumber checks that your recipe is complete and correctly followed. Together they produce a sound dish.
Key takeaways
- Chainguard Actions (announced 17 March 2026, in beta) is an excellent initiative: it ingests, hardens and republishes popular GitHub Actions, rebuilt from source.
- It fixes real flaws in third-party bricks: injection, badly interpolated secrets, permissive workflows, mutable tags, with a transparent hardening report.
- The community welcomed the approach with healthy caveats: young category, positioning to clarify against GitHub, and a reminder that SHA pinning is only one layer.
- By scope, the service takes care of bricks, not your assembly: permissions, secrets and triggers in your workflows remain your responsibility.
- A scanner such as plumber completes the initiative by validating that the chain is properly built, open source, across GitHub Actions and GitLab CI.
- The right posture is complementary: hardened bricks upstream, continuous assembly validation, vendor-independent reflexes.