Github-Actions-Hardening

# 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:

- 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)

* `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/