The complete GitHub Actions security checklist

What it is

Aikido's GitHub Actions security checklist, focused on the trigger-configuration attack surface that has driven recent CI/CD supply-chain incidents. The fetched text covers the "start here" top-five priorities plus two detailed sections: pull_request_target (pwn requests) and workflow_run chaining. It cites the March 2026 Trivy attack and a new actions/checkout v7 default behavior (effective June 18, 2026).

The five priorities

If you do nothing else:

• Pin all third-party actions to a full commit SHA
• Set default GITHUB_TOKEN permissions to read-only
• Never use pull_request_target in public repos
• Never interpolate ${{ github.* }} directly into run: steps
• Use OIDC for cloud credentials instead of long-lived secrets

How the trigger attacks work

pull_request_target runs in the base repository's context regardless of PR origin, loading referenced secrets into the runner. The trigger is safe by default (it runs base-branch code, not fork code); the danger is only when you explicitly check out the fork's code, which then executes with secret access — a "pwn request." Any external contributor can open a PR to trigger it, and injected code exfiltrates secrets via e.g. os.environ.get('MY_SECRET') with no merge and no trace.

workflow_run reaches the same place via an extra hop: the downstream workflow runs with write permissions and secret access regardless of what triggered the upstream one. If an upstream pull_request workflow is vulnerable to script injection, an attacker poisons the output artifact via a PR, and the privileged downstream workflow consumes that attacker-controlled content.

What to do

• pull_request_target: avoid in public repos. In private repos, require maintainer approval for first-time contributors under Settings > Actions > Fork pull request workflows.
• workflow_run: prefer triggering directly (e.g. push on main) rather than chaining. If you must chain, gate privileged jobs on the upstream trigger type:

jobs:
  deploy:
    if: github.event.workflow_run.event == 'push'

• actions/checkout v7 (as of 2026-06-18) blocks common pwn-request checkouts in both pull_request_target and workflow_run by default, refusing fork PR code unless you set allow-unsafe-pr-checkout: true. Upgrading is a concrete mitigation; do not set that flag.

Caveats

The page states best practices won't make workflows bulletproof — a compromised maintainer or a GitHub-infrastructure zero-day remains out of scope; these steps close the vectors attackers are actively exploiting. Note the pull_request_target default state is safe; the risk is specifically adding a fork checkout, so blanket "never use it" advice is stricter than the mechanism strictly requires. The In-the-wild claim: after the Trivy compromise, an attacker scanned GitHub for pull_request_target-enabled repos and opened several hundred PRs in roughly a day.