GitHub Actions Hardening

A focused security reviewer for GitHub Actions workflows. It reasons about the Actions-specific threat model — where trust boundaries live in trigger types, token scopes, and string interpolation — rather than the application-code vulnerabilities a general security scanner looks for. Most workflow risks are invisible to language linters because the dangerous code is the YAML itself and the way GitHub expands ${{ }} expressions into a shell before your script runs.

When to Use This Skill

Use this skill when the request involves:

• Reviewing, auditing, or hardening any file under .github/workflows/
• Authoring a new workflow and wanting it secure by default
• A workflow that uses pullrequesttarget, workflowrun, or issuecomment triggers
• Questions about GITHUB_TOKEN permissions or the permissions: key
• Pinning actions to commit SHAs vs tags vs branches
• Handling untrusted input (issue titles, PR bodies, branch names, commit messages) in run: steps
• OIDC / cloud authentication from Actions, or secret handling in CI
• Self-hosted runners on public repositories
• Any request like "is this workflow safe?", "secure my CI", or "review this GitHub Action"

The Core Insight

In a workflow, **${{ <expr> }} is expanded by the runner into the script before the shell executes it.** So a step like:

- run: echo "Title: ${{ github.event.issue.title }}"

is not passing a variable — it is pasting attacker-controlled text directly into your shell command. An issue titled "; <attacker-command> # is concatenated into the script and executed. This single mechanism is the most common real-world Actions vulnerability, and models routinely generate it. Treat every ${{ }} that contains data an outside contributor can influence as a code-injection sink.

Execution Workflow

Follow these steps in order for every workflow reviewed.

Step 1 — Map the Triggers and Trust Level

Read every on: trigger and classify the workflow's privilege:

• push, pull_request (from same repo) → runs with the contributor's own trust
• pull_request from a fork → runs with a read-only token, no secrets (safe by design)
• pullrequesttarget, workflowrun, issuecomment, issues → run in the context of the

base repository with a read/write token and full access to secrets, but can be triggered by outside contributors. These are the dangerous triggers.

Read references/triggers-and-privilege.md for the full trust matrix.

Step 2 — Hunt for Script Injection

For every run: block, every script: in actions/github-script, and every input to a custom action, list the ${{ }} expressions and check whether any resolve to attacker-controllable data. High-risk contexts include:

• github.event.issue.title, github.event.issue.body
• github.event.pullrequest.title, github.event.pullrequest.body, .head.ref, .head.label
• github.event.comment.body, github.event.review.body
• github.event.pages..pagename, github.event.commits..message, github.event.headcommit.*
• github.head_ref and any github.event.* field a fork author can set

Read references/injection.md for the complete sink list and the safe-pattern fixes.

Step 3 — Check Privileged Triggers Don't Execute Untrusted Code

If a pullrequesttarget or workflowrun workflow checks out PR/fork code (ref: ${{ github.event.pullrequest.head.sha }}) and then runs it (build, test, install scripts, npm install with lifecycle scripts, etc.), that is remote code execution against a privileged token. Flag it as CRITICAL. The safe pattern is to split into two workflows: an unprivileged pullrequest workflow that runs the untrusted code, and a privileged workflowrun workflow that only consumes its results.

Step 4 — Audit permissions:

• If there is no permissions: block, the workflow inherits the repository default, which may

be read/write to everything. Flag it.

• Recommend a top-level permissions: {} (deny-all) or contents: read, then grant the minimum

per job (e.g. pull-requests: write only on the job that comments).

• Flag any permissions: write-all or broad write scopes that the steps don't actually need.

Read references/permissions-and-tokens.md for the per-scope guidance and OIDC setup.

Step 5 — Audit Action References (Supply Chain)

For every uses::

• Third-party actions (not actions/ or github/) MUST be pinned to a full 40-character

commit SHA, not a tag or branch. Tags and branches are mutable; a compromised upstream action can rewrite v1 to malicious code that runs with your token and secrets.

• First-party actions/* are lower risk but SHA-pinning is still the hardened recommendation.
• Flag @main, @master, or any branch reference as HIGH — that is "latest" and can change under

you at any time.

• Note the human-readable version in a trailing comment: uses: foo/bar@<sha> # v2.1.0.

Read references/supply-chain.md for pinning, Dependabot for actions, and artifact/cache risks.

Step 6 — Check Secret and Output Handling

• No secrets echoed, printed, or written to logs; no set -x / bash -x in steps that touch

secrets.

• Secrets must not be passed to steps that run untrusted code or to untrusted third-party actions.
• Untrusted multiline data written to $GITHUBENV or $GITHUBOUTPUT can inject environment

variables or step outputs — use the random-delimiter heredoc form and never write raw user input.

• actions/checkout leaves a token on disk by default; set persist-credentials: false when the

job later runs untrusted code.

Step 7 — Produce the Report

Output findings using the format in references/report-format.md: a severity summary table first, then grouped findings with file, the exact offending YAML, the risk in plain English, and a concrete before/after fix. Never auto-apply changes — present them for review.

Severity Guide

Output Rules

• Always show a findings summary table (counts by severity) first.
• Group by issue type, not by file.
• Be exact — quote the offending line and give the line location.
• Always pair every CRITICAL/HIGH with a concrete corrected YAML snippet.
• Never claim a fork pull_request is dangerous just because it runs untrusted code — it has

no secrets and a read-only token. Reserve CRITICAL for the privileged triggers.

• If the workflow is already hardened, say so and list what was checked.

Reference Files

Load these as needed:

• references/triggers-and-privilege.md — Trust matrix for every trigger, why pullrequesttarget

and workflowrun are privileged, and the two-workflow safe pattern. + Search patterns: pullrequesttarget, workflowrun, issue_comment, fork, secrets, read-only token, trust boundary

• references/injection.md — Full list of attacker-controllable ${{ }} contexts and the

env:-variable safe pattern for each sink (run, github-script, action inputs). + Search patterns: script injection, github.event, head_ref, issue title, env, intermediate variable, actions/github-script

• references/permissions-and-tokens.md — GITHUB_TOKEN scopes, least-privilege permissions:

recipes per job type, and OIDC for cloud auth instead of long-lived secrets. + Search patterns: permissions, GITHUB_TOKEN, write-all, contents: read, id-token, OIDC, least privilege

• references/supply-chain.md — SHA-pinning third-party actions, Dependabot for github-actions,

artifact and cache poisoning across workflow_run, and self-hosted runner exposure. + Search patterns: SHA pin, uses, mutable tag, Dependabot, download-artifact, cache, self-hosted runner

• references/report-format.md — Output template: summary table, finding cards, and before/after

remediation blocks. + Search patterns: report, format, finding, summary, remediation, before, after