/meta-reviewing-infra-reviewing

name: meta-reviewing-infra-reviewing
description: Infrastructure code review — supply-chain pinning, secret exposure, workflow triggers and untrusted input, container hygiene, deployment safety. Load when reviewing a diff that touches CI/CD workflows, Dockerfiles, deployment configs or IaC.

Infrastructure Code Review Patterns

> **Quick Guide:** Review operational code for what it can leak and what it lets a stranger run. Secrets, mutable third-party references and outsider input reaching a privileged job block the merge in any diff, at any scale; deployment ceremony scales with what the diff actually deploys. Recent facts that change the answer: `actions/checkout` v7 refuses fork-PR code under `pull_request_target` and `workflow_run` unless told otherwise; since December 2025 `pull_request_target` always runs the default branch's copy of the workflow; an organisation can enforce SHA pinning so a tag-pinned action fails at job setup; and GitHub's workflow dependency lockfile (public preview) pins what a `uses:` tag resolves to.

**Detailed Resources:**

• [examples/core.md](examples/core.md) — a good/bad pair for each pattern below: pinned actions and installs, secret mounts and log hygiene, permissions, privileged triggers and script injection, the non-root Dockerfile, deploy ordering, signal-safe startup

---

<critical_requirements>

Before reviewing infrastructure code

**Grep the diff for credentials before reading it for anything else.** A pushed secret stays reachable through clones, forks and the pull request's own refs, so the fix to ask for is revocation, not a follow-up commit — and the check takes seconds.

**Resolve every external reference to something immutable.** A tag or branch on an action, base image, provider or module runs whatever its owner — or whoever holds the owner's token — points it at next, with this pipeline's secrets in scope.

**Trace each secret from its store to the one process that needs it.** A build arg lands in image history, a job-level `env:` reaches every step including third-party actions, and log masking matches only the exact registered string — each hop the diff adds is a place it leaks.

**Read a workflow's trigger and `permissions:` before its steps.** Under `pull_request_target` and `workflow_run` the job holds the base repository's secrets and token while handling fork-controlled input, and a missing `permissions:` block inherits a default set in settings the diff never shows.

**Treat every value an outsider can set as code.** A PR title, branch name or comment body written as `${{ }}` inside `run:` is spliced into the script before the shell parses it, so a quote in that value ends the string and the rest runs as commands.

**Check that a production image ends on a non-root `USER`.** Without one the process runs as root, and an application compromise starts one container-escape bug away from the host.

</critical_requirements>

---

**Auto-detection:** `.github/workflows`, `uses:`, `permissions:`, `pull_request_target`, `workflow_run`, `GITHUB_TOKEN`, `secrets.`, `allow-unsafe-pr-checkout`, `concurrency:`, `.gitlab-ci.yml`, `Dockerfile`, `.dockerignore`, `compose.yaml`, `FROM`, `USER`, `ARG`, `RUN --mount=type=secret`, Kubernetes manifest, Helm chart, `readinessProbe`, `terraform`, `.terraform.lock.hcl`, Pulumi, CI review, Dockerfile review, IaC review

**Applies to:**

• Diffs touching CI/CD workflow files — triggers, permissions, pinned references, secrets, job ordering
• Dockerfiles, `.dockerignore` and compose files
• Deployment manifests and platform configs — readiness, resources, shutdown, per-environment config
• IaC — provider and module pinning, state, plan and apply in CI
• Release and build scripts — what they publish, sign and tag, and which credentials they read
• Lockfile and package-manager changes with supply-chain reach

**Handled elsewhere:**

• Application code in the same diff — reviewed against its own layer's conventions; this skill reviews what builds, ships and runs it.
• Severity vocabulary, comment format and the approve-or-request-changes call — the general review practice, which this skill's severities slot into.
• Designing or restructuring a pipeline — a review names the defect and its fix; the platform's shape belongs to whoever owns it.
• Incident response and live operations — a review gates a diff, not a running system.

---

<philosophy>

Philosophy

Operational code fails in production only. No unit test catches an unpinned action's compromise or a leaked deploy key, so the review is often the one gate this code passes — and a finding costs a line before merge and a rotation after.

Ceremony scales with blast radius: a production deploy path earns strictness, a lint workflow that deploys nothing does not. Read the diff against what it reaches —

• A new env var must exist in every environment the app runs in; a renamed job or output must change everywhere that `needs` or reads it.
• Ask what the pipeline does on a fork PR, on a re-run, and on two branches at once.

**Don't flag:**

• Probes, resource limits or rollback strategy on a docs site or a workflow that deploys nothing
• A multi-stage build for a CI-only image whose size nothing depends on
• Missing caching in a job that runs in seconds
• A vault migration in a diff that consumes an existing secret the established way

</philosophy>

---

<decision_framework>

Severity for infrastructure findings

Must Fix blocks approval. Should Fix travels with the approval, for the author to fix before merging, and needs a cost concrete in this diff. Nice to Have is the author's to take or leave.

Does the diff introduce a security defect?
├─ Credential literal, or a secret through ARG/ENV, a log line or an artifact → MUST FIX
├─ Third-party action on a tag, or any action on a branch (@v3, @main) → MUST FIX
├─ ${{ }} of outsider-controlled input inside run: → MUST FIX
├─ pull_request_target / workflow_run that checks out or runs PR h