Chainguard Actions is Generally Available: Hardening 1,000+ GitHub Actions and removing transitive CI/CD risks

Today, Chainguard Actions is Generally Available (GA), bringing enterprise-grade supply chain security directly into your GitHub workflows. 

71% of organizations using GitHub Actions do not take basic hygiene steps, such as pinning actions to commit SHAs, according to Datadog's 2026 DevSecOps report. Even for the minority of teams that mandate SHA pinning, it doesn’t protect against sophisticated supply chain attacks. High-profile incidents like the tj-actions/changed-files compromise, which impacted over 23,000 repositories overnight by hijacking version tags, demonstrate how easily workflows can be weaponized to exfiltrate secrets and cloud credentials.

With this GA release, security and engineering teams can now protect their software delivery pipelines with a hardened catalog of over 1,000 popular actions, delivering broad coverage across the open source GitHub ecosystem without disrupting developer speed or requiring ongoing reviews for security teams.

Over 1,000 hardened actions deliver proactive security at scale

Building on our Open Beta foundation, the Chainguard Actions catalog now spans over 1,000 continuously verified and hardened actions.

Rather than relying on security teams to perform time-consuming action reviews, Chainguard Actions provides drop-in replacements for the actions developers already want to use. Each action in the catalog undergoes automated rule-based analysis and AI-augmented review to remove vulnerabilities while preserving original functionality.

We check for and remove:

• Script injections and command interpolation: Sanitizing untrusted inputs to prevent arbitrary code execution in runner environments.

• Unpinned uses: internal references: Eradicating tag mutability and floating ref vulnerabilities for each action’s internal references.

• GitHub environment injections: Preventing malicious payloads from modifying environment files (GITHUB_ENV, GITHUB_PATH).

• Hard-coded credentials and secrets leakage: Enforcing strict secret handling to block inadvertent secret exfiltration.

• Unsafe shells and missing permissions: Restricting workflow permissions to strict least-privilege defaults for each action’s repo's own workflows and for risky execution shells.

• Suspicious run content: Detecting anomalous baseline runtime behaviors before code reaches production.

It isn’t enough to just harden actions. Teams need to be able to verify how an action was hardened and prove their pipeline security controls to auditors and customers. Every hardened Action includes a HARDENING.md report detailing which vulnerabilities were found and removed to provide that visibility. 

As upstream maintainers ship updates, Chainguard automatically re-secures and re-verifies every action. If an Action your team relies on isn't in the catalog yet, our one-business-day SLA for new Action requests ensures you won’t have coverage gaps. Engineers can simply file a request, and Chainguard will harden and publish it in one day, preventing coverage gaps for new or infrequently used actions.

Static SHA pinning alone leaves critical security gaps

When security teams look to secure their GitHub workflows, the most common first step is mandating commit SHA pinning. They might ask: If our organization already requires SHA pinning, why do we need a hardened catalog like Chainguard Actions?

While SHA pinning is important, it solves a narrow problem. Pinning guarantees that code bytes don't change over time, but it cannot prove who wrote those bytes or whether they were ever actually part of the official project you intend to run. Because any fork commit is reachable from an upstream GitHub repository, an attacker can reference a malicious SHA that looks completely legitimate to your code reviewers, audit logs, and policy scanners.

The tj-actions/changed-files incident shows why SHA pinning alone isn't enough. When attackers gained access to the official repository, they pushed a malicious update to the action. A team that updated to the compromised release and pinned its SHA during the attack would have locked the malicious code into its workflow. Once executed, the action dumped secrets into the build logs. SHA pinning guarantees code immutability, but it cannot detect or stop malicious code from executing in your runner.

Furthermore, runtime risks persist even after pinning. When a Docker-based action is pinned to a commit SHA, it often still builds its container image dynamically at execution time. This leaves your build pipeline vulnerable to poisoned base images, altered upstream registries, and unpinned transitive runtime dependencies that execute outside the scope of your commit pin.

Chainguard Actions goes beyond SHA pinning by addressing the entire execution lifecycle. Every action in our catalog is systematically analyzed, rewritten to strip out dangerous execution patterns, and continuously verified so that what actually executes in your runner is demonstrably and functionally safe.

Transitive action hardening and dependency pinning neutralize hidden CI/CD threats

Hardening top-level actions only solves part of the problem. A major vector for modern pipeline exploits lies in transitive dependencies, the nested sub-actions, runtimes, and base container images pulled behind the scenes during workflow execution.

Chainguard Actions removes hidden transitive security risks directly within action definitions:

• Transitive hardening: Actions invoked within hardened actions are detected through recursive dependency discovery and remediated to the same standard as the parent, eliminating transitive supply chain exposure.

• Immutable container digest pinning: For actions that reference external container registries (runs.using: docker with docker://...), mutable image tags introduce severe vulnerability to tag-hijacking attacks. Chainguard’s analysis pass resolves mutable tags down to their immutable sha256 digests directly against the registry. The action code is rewritten to enforce the digest (e.g., image@sha256:<digest> # tag), guaranteeing deterministic, tamper-proof image pulls every time.

• In-place Dockerfile base image hardening: For actions built directly from an internal Dockerfile, Chainguard hardens the source configuration in place, systematically replacing vulnerable or unpinned base images (FROM instructions) to prevent upstream poisoning.

• Nested ref resolution: Unpinned sub-action dependencies (uses:) are detected and bound to strict, cryptographically verified commits, cutting off transitive supply chain propagation.

Security and engineering leaders trust Chainguard Actions

By combining catalog breadth, continuous maintenance, and transitive hardening, organizations are transforming how they protect their CI/CD infrastructure without slowing down engineering:

Your path to secure pipelines starts today

Securing your build and release infrastructure no longer requires trade-offs between speed and risk management.

Start your 30-day free trial of Chainguard Actions today:

1. Inventory your workflows: Use Guardener or the Chainguard Actions Migration Skill to scan your repositories or entire GitHub organization and generate a detailed usage report. 

2. Automate your migration: Both Guardener and the migration skill can then automate switching to the Chainguard Actions equivalent actions. Use the Migration Skill if you want to go repo by repo. Use Guardener in the Chainguard App to open pull requests that swap vulnerable actions for their hardened Chainguard equivalents.

Ready to secure your CI/CD pipelines? Start your 30-day free trial or explore the 1,000+ Action catalog today.