Guide: How to Harden GitHub Actions Against Supply-Chain Attacks
Summary
An updated guide to hardening GitHub Actions after recent supply-chain compromises, with advice on limiting permissions and secrets, pinning actions, protecting workflows, and securing runners.
Key points
- The guide cites the March 2026 Trivy-action compromise and malicious Axios versions as examples of attacks that stole credentials and enabled further supply-chain compromises.
- Restrict workflow permissions, limit actions to trusted sources, enforce SHA pinning, and consider delaying adoption of new action versions.
- Limit secrets to the jobs and steps that need them; prefer short-lived credentials and OIDC where supported.
- Review privileged triggers and attacker-controlled inputs to reduce poisoned pipeline execution and command-injection risks.
- Isolate self-hosted runners by trust level, avoid using them with public repositories, and favor ephemeral infrastructure.
- GitHub’s 2026 roadmap includes workflow lockfiles and centralized execution policies; the guide also recommends workflow linting.
Article Details
- Defense Focus
- Reduce GitHub Actions supply-chain and pipeline compromise risk by hardening permissions, action dependencies, workflow triggers, secrets, and runner infrastructure; detect insecure configurations and signs of runner compromise.
- Detection Methods
- Scan workflow YAML for insecure configurations, dangerous triggers, risky inputs, excessive permissions, and potential secret leaks.
- Lint workflows for unpinned actions, template injection, and dangerous triggers.
- Review third-party Actions for contributor count, code complexity, popularity, version pinning, and other safeguards.
- Monitor self-hosted runner processes and activity for signs of compromise; inspect runner behavior.
- Monitor GitHub-hosted runner egress for unexpected outbound connections.
- Use GitHub Actions dependency visibility in the SBOM to identify third-party Actions and map them to workflows.
- Use pre-built queries to assess exposure to supply-chain incidents.
- Data Sources
- GitHub Actions workflow YAML and permissions
- GitHub Actions dependency and SBOM data
- Self-hosted runner process and activity logs
- Runner network egress
- Repository visibility and workflow configuration
- Rule Types
- Static workflow analysis and linting
- Configuration and posture checks
- Pre-built exposure queries
- Network egress monitoring
- Platforms
- GitHub Actions
- Wiz
- Defensive Actions
- Set workflow token permissions to read-only by default and grant only job-level permissions required.
- Restrict permitted Actions to verified sources and an allowlist; enforce commit-SHA pinning and block compromised Actions when needed.
- Use repository allowlists for workflow adoption and restrict self-hosted runners to specific repositories.
- Disable workflow permission to create and approve pull requests; configure branch protections, dismiss stale approvals, and require approval from someone other than the last pusher where practical.
- Enable immutable releases for published Actions.
- Prefer repository-scoped secrets, scope secrets to only the required jobs or steps, and avoid exposing the full secrets context or using secrets: inherit.
- Prefer short-lived credentials and OIDC; consider GitHub Apps for high-value release or deployment credentials.
- Delay adoption of new Action versions by 7–14 days and automate the cooldown where possible.
- Audit high-privilege triggers and do not execute untrusted pull-request code in privileged workflow contexts.
- Validate or avoid interpolating attacker-controlled values in shell commands; do not write attacker-controlled content to GITHUB_ENV or GITHUB_PATH.
- Set persist-credentials: false for actions/checkout unless credential persistence is required; avoid publishing artifacts containing credentials.
- Isolate self-hosted runners by trust level, do not use them with public repositories, and prefer ephemeral runners.
- Apply default-deny outbound network policies to self-hosted runners, with explicit allowlists for required destinations.
Threat Actors
Vendors
Products
GitHubOver the past four years, researchers have highlighted the risks associated with GitHub Actions. In March 2025, these threats became manifest with the tj-actions incident, a cascading compromise that moved from aGitHub ActionsOver the past four years, researchers have highlighted the risks associated with GitHub Actions. In March 2025, these threats became manifest with the tj-actions incident, a cascading compromise that moved from aGitHub AppsFor high-value operations like releases or deployments, consider moving automation credentials into GitHub Apps rather than storing them as workflow secrets. Workflows mix code and secrets in the same attackTrivyTeamPCP / Trivy-action: Attackers compromised 75 of 76 trivy-action version tags via force-push, exfiltrating secrets from every pipeline that ran a Trivy scan. Stolen credentials cascaded into PyPI compromises
Tools
allstarallstar: a GitHub App to set and enforce security policies on GitHub organizations or repositories, from OpenSSFGato-Xtrajan and Gato-X: enumeration and attack tools for testing your GitHub Actions securitypinactcatches 80-90% of supply chain attacks, which typically have detection windows under one week. Tools like pinact (--min-age 7) and Renovate (minimumReleaseAge) can enforce this automatically.Renovateattacks, which typically have detection windows under one week. Tools like pinact (--min-age 7) and Renovate (minimumReleaseAge) can enforce this automatically.trajantrajan and Gato-X: enumeration and attack tools for testing your GitHub Actions securityzizmorLint your workflows: Tools like zizmor catch common vulnerabilities (unpinned actions, template injection, dangerous triggers) before they ship. Strongly consider adding workflow linting to your CI pipeline.