gha-security-review

A project's automated jobs run on pull requests sent in by complete strangers; this hunts for the ones a stranger could turn against the project, and reports nothing it cannot spell out as a working attack.

WHEN TO USE

SCOPE

USE FOR

Check a workflow's elevated pull-request trigger for a 'pwn request' that runs fork code with full repo access.
Find expression injection where a PR title or branch name lands inside a shell run block.
Confirm whether a third-party GitHub Action is locked to a specific commit instead of a tag that can move.
Decide whether a workflow bug needs write access to exploit, and rule it out if so.

NOT FOR

Not for issues that need write access to exploit, like workflow_dispatch input injection.
Not for auditing workflows in other repositories or GitHub App install permissions.

This is a saved copy of the skill's SKILL.md instructions. It may differ from the upstream file or the version you install.

In this document (9)

GitHub Actions Security Review

Find exploitable vulnerabilities in GitHub Actions workflows. Every finding MUST include a concrete exploitation scenario — if you can't build the attack, don't report it.

This skill encodes attack patterns from real GitHub Actions exploits — not generic CI/CD theory.

Scope

Review the workflows provided (file, diff, or repo). Research the codebase as needed to trace complete attack paths before reporting.

Files to Review

.github/workflows/*.yml — all workflow definitions
action.yml / action.yaml — composite actions in the repo
.github/actions/*/action.yml — local reusable actions
Config files loaded by workflows: CLAUDE.md, AGENTS.md, Makefile, shell scripts under .github/

Out of Scope

Workflows in other repositories (only note the dependency)
GitHub App installation permissions (note if relevant)

Threat Model

Only report vulnerabilities exploitable by an external attacker — someone without write access to the repository. The attacker can open PRs from forks, create issues, and post comments. They cannot push to branches, trigger workflow_dispatch, or trigger manual workflows.

Do not flag vulnerabilities that require write access to exploit:

workflow_dispatch input injection — requires write access to trigger
Expression injection in push-only workflows on protected branches
workflow_call input injection where all callers are internal
Secrets in workflow_dispatch/schedule-only workflows

Confidence

Report only HIGH and MEDIUM confidence findings. Do not report theoretical issues.

Confidence	Criteria	Action
HIGH	Traced the full attack path, confirmed exploitable	Report with exploitation scenario and fix
MEDIUM	Attack path partially confirmed, uncertain link	Report as needs verification
LOW	Theoretical or mitigated elsewhere	Do not report

For each HIGH finding, provide all five elements:

Entry point — How does the attacker get in? (fork PR, issue comment, branch name, etc.)
Payload — What does the attacker send? (actual code/YAML/input)
Execution mechanism — How does the payload run? (expression expansion, checkout + script, etc.)
Impact — What does the attacker gain? (token theft, code execution, repo write access)
PoC sketch — Concrete steps an attacker would follow

If you cannot construct all five, report as MEDIUM (needs verification).

Step 1: Classify Triggers and Load References

For each workflow, identify triggers and load the appropriate reference:

Trigger / Pattern	Load Reference
`pull_request_target`	`references/pwn-request.md`
`issue_comment` with command parsing	`references/comment-triggered-commands.md`
`${{ }}` in `run:` blocks	`references/expression-injection.md`
PATs / deploy keys / elevated credentials	`references/credential-escalation.md`
Checkout PR code + config file loading	`references/ai-prompt-injection-via-ci.md`
Third-party actions (especially unpinned)	`references/supply-chain.md`
`permissions:` block or secrets usage	`references/permissions-and-secrets.md`
Self-hosted runners, cache/artifact usage	`references/runner-infrastructure.md`
Any confirmed finding	`references/real-world-attacks.md`

Load references selectively — only what's relevant to the triggers found.

Step 2: Check for Vulnerability Classes

Check 1: Pwn Request

Does the workflow use pull_request_target AND check out fork code?

Look for actions/checkout with ref: pointing to PR head
Look for local actions (./.github/actions/) that would come from the fork
Check if any run: step executes code from the checked-out PR

Check 2: Expression Injection

Are ${{ }} expressions used inside run: blocks in externally-triggerable workflows?

Map every ${{ }} expression in every run: step
Confirm the value is attacker-controlled (PR title, branch name, comment body — not numeric IDs, SHAs, or repository names)
Confirm the expression is in a run: block, not if:, with:, or job-level env:

Check 3: Unauthorized Command Execution

Does an issue_comment-triggered workflow execute commands without authorization?

Is there an author_association check?
Can any GitHub user trigger the command?
Does the command handler also use injectable expressions?

Check 4: Credential Escalation

Are elevated credentials (PATs, deploy keys) accessible to untrusted code?

What's the blast radius of each secret?
Could a compromised workflow steal long-lived tokens?

Check 5: Config File Poisoning

Does the workflow load configuration from PR-supplied files?

AI agent instructions: CLAUDE.md, AGENTS.md, .cursorrules
Build configuration: Makefile, shell scripts

Check 6: Supply Chain

Are third-party actions securely pinned to full SHAs?

Pin third-party / external actions and reusable workflows only
Do not flag first-party actions/* or github/* on version tags
Do not flag same-repo / vendored (./.github/actions/...) as supply-chain pinning issues
Only report when the job has secrets, OIDC, write token, release, deploy, package, or signing power — unprivileged read-only CI is not a finding

Check 7: Permissions and Secrets

Are workflow permissions minimal? Are secrets properly scoped?

Check 8: Runner Infrastructure

Are self-hosted runners, caches, or artifacts used securely?

Safe Patterns (Do Not Flag)

Before reporting, check if the pattern is actually safe:

Pattern	Why Safe
`pull_request_target` WITHOUT checkout of fork code	Never executes attacker code
`${{ github.event.pull_request.number }}` in `run:`	Numeric only — not injectable
`${{ github.repository }}` / `github.repository_owner`	Repo owner controls this
`${{ secrets.* }}`	Not an expression injection vector
`${{ }}` in `if:` conditions	Evaluated by Actions runtime, not shell
`${{ }}` in `with:` inputs	Passed as string parameters, not shell-evaluated
Third-party actions pinned to full SHA	Immutable reference
First-party `actions/` / `github/` on version tags	Outside third-party pinning policy — do not flag
Same-repo / vendored local actions	Not third-party supply chain (review pwn-request separately)
`pull_request` trigger (not `_target`)	Runs in fork context with read-only token
Any expression in `workflow_dispatch`/`schedule`/`push` to protected branches	Requires write access — outside threat model

Key distinction: ${{ }} is dangerous in run: blocks (shell expansion) but safe in if:, with:, and env: at the job/step level (Actions runtime evaluation).

Step 3: Validate Before Reporting

Before including any finding, read the actual workflow YAML and trace the complete attack path:

Read the full workflow — don't rely on grep output alone
Trace the trigger — confirm the event and check if: conditions that gate execution
Trace the expression/checkout — confirm it's in a run: block or actually references fork code
Confirm attacker control — verify the value maps to something an external attacker sets
Check existing mitigations — env var wrapping, author_association checks, restricted permissions, SHA pinning

If any link is broken, mark MEDIUM (needs verification) or drop the finding.

If no checks produced a finding, report zero findings. Do not invent issues.

Step 4: Report Findings

## GitHub Actions Security Review

### Findings

#### [GHA-001] [Title] (Severity: Critical/High/Medium)
- **Workflow**: `.github/workflows/release.yml:15`
- **Trigger**: `pull_request_target`
- **Confidence**: HIGH — confirmed through attack path tracing
- **Exploitation Scenario**:
  1. [Step-by-step attack]
- **Impact**: [What attacker gains]
- **Fix**: [Code that fixes the issue]

### Needs Verification
[MEDIUM confidence items with explanation of what to verify]

### Reviewed and Cleared
[Workflows reviewed and confirmed safe]

If no findings: "No exploitable vulnerabilities identified. All workflows reviewed and cleared."

This skill ships inside the Sentry Engineering Skills plugin. Listed package contents include 2 agents. Installed components and skill versions may vary by AI tool.

Install just this skill

Run this outside your AI tool, using Node.js 22.20.0 or newer. Skills CLI 1.7.2 skips skill selection; prompts cancel installation without an interactive terminal. If choosing Project when asked about installation scope, open your project's folder before running this.

Install checklist

Check selected tools if a picker appears; Claude Code may be unchecked under Additional agents. ↑/↓ moves, Space toggles selections, Enter confirms.
Without a tool picker, check Installing to: for your intended tool. Stop if it names a different tool.
If asked, choose Symlink (Recommended) for shared files or Copy to all agents for separate copies; review the summary before confirming installation.
Install the find-skills skill? defaults to Yes, adding another skill for all projects. Choose No if you don't want that extra installation.

Skills CLI 1.7.2 sends install data to skills.sh by default, including the source, skill names, target tools and file details; GitHub sources are reported only when GitHub confirms the repository is public, while other remote sources can also be reported. Confirmed-public GitHub sources also trigger a security-audit request. Before installing, set the environment variable DO_NOT_TRACK=1 or DISABLE_TELEMETRY=1 to disable both.

npx skills add getsentry/skills --skill "gha-security-review" --full-depth

After installing for Claude Code, open it in the installation project if you chose Project; Global makes the skill available across projects on this computer. Once Claude Code loads the skill, its description helps Claude decide when to use it.

If installation created a top-level skills folder that did not exist when your Claude Code session started, run /reload-skills in that session. Run it again after later changes in that folder.

Install the whole plugin

This route installs the Sentry Engineering Skills plugin package selected for your AI tool.

Claude Code

Add Sentry's marketplace, then install the plugin

Run both lines in a terminal. The first adds Sentry's marketplace, which is this repository; the second installs the sentry-skills plugin, which Sentry describes as agent skills for its employees, plus two subagents. It installs for you in every project; restart Claude Code afterwards, as Sentry's README says.

claude plugin marketplace add getsentry/skills

claude plugin install sentry-skills@sentry-skills

Open plugin page ↗

What's inside

Files included with this skill.

View on GitHub