gha-security-review

GHA Security Review

Review GitHub Actions workflows like an attacker would. Only report issues that can be reached from a realistic external trigger.

When to Use

• Reviewing .github/workflows/*.yml or .github/workflows/*.yaml changes before merge
• Auditing a repository that runs PR, issue comment, or reusable workflow automation
• Checking whether workflow files expose secrets, write tokens, or command execution
• Investigating CI/CD compromise paths involving fork PRs or untrusted workflow inputs

When NOT to Use

Instead of gha-security-review	Use
Broad application security review	security-scan
General repository trust scorecard	evaluate-repository
Threat modeling a system architecture	threat-model-analyst

Threat Model

Assume an attacker does not have repository write access.

They can:

• open pull requests from forks
• create issues
• comment on issues or PRs
• control PR titles, branch names, commit content in forked code, and comment bodies

They cannot:

• push to protected branches
• trigger workflow_dispatch manually
• modify repository secrets directly

If exploitation requires write access, do not report it as an in-scope finding.

Workflow

1. Map the workflow attack surface

Review:

• .github/workflows/*.yml or .github/workflows/*.yaml
• action.yml or action.yaml
• local reusable actions under .github/actions/
• config or scripts loaded by workflows such as AGENTS.md, CLAUDE.md, Makefile, and shell scripts

Start by listing relevant files:

git --no-pager ls-files --cached --others --exclude-standard |
  Select-String "^(\\.github/(workflows|actions)/.+|scripts/.+|.+\\.sh|action\\.ya?ml|Makefile|AGENTS\\.md|CLAUDE\\.md)$" |
  ForEach-Object { $_.Line }

2. Classify triggers first

For each workflow, identify which external triggers matter:

• pull_request_target
• pull_request
• issue_comment
• workflow_call
• push
• schedule
• workflow_dispatch