Security hardening reviewer for GitHub Actions workflow files (.github/workflows/*.yml). Reasons about the Actions threat model that pattern matchers and general code linters miss — untrusted-input script injection, privileged triggers running fork code, mutable action references, and over-scoped to

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 pull request target , workflow run , or issue comment 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: 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) pull request target , workflow run , issue comment , 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.pull request.title , github.event.pull request.body , .head.ref , .head.label github.event.comment.body , github.event.review.body github.event.pages. .page name , github.event.commits. .message , github.event.head commit. 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 pull request target or workflow run workflow checks out PR/fork code ( ref: ${{ github.event.pull request.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 pull request workflow that runs the untrusted code, and a privileged workflow run 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 $GITHUB ENV or $GITHUB OUTPUT 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 Severity Meaning Example 🔴 CRITICAL Token/secret theft or RCE reachable by an outside contributor pull request target checking out and running fork code; ${{ github.event. }} in a run: on a privileged trigger 🟠 HIGH Exploitable supply chain or scope problem Third party action on a mutable tag/branch; write all permissions; injection sink on issue comment 🟡 MEDIUM Risk under conditions or chaining Missing permissions: block; secret reachable by a non fork PR author 🔵 LOW Hardening gap, low direct risk First party action not SHA pinned; persist credentials left default on a non privileged job ⚪ INFO Observation, not a vulnerability Version comment missing next to a pinned SHA 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 pull request target and workflow run are privileged, and the two workflow safe pattern. + Search patterns: pull request target , workflow run , 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

github-actions-hardening