/meta-reviewing-infra-reviewing

name: meta-reviewing-infra-reviewing
description: Infrastructure code review patterns. Use when reviewing CI/CD workflows, Dockerfiles, deployment configs, and IaC. Covers supply-chain pinning, secret exposure, container hygiene, least-privilege permissions, and deployment safety.

Infrastructure Code Review Patterns

> **Quick Guide:** When a diff touches operational code, grep it for secrets first - hardcoded credentials are always blocking. Verify third-party actions are pinned to SHAs and base images to digests or versions, containers run as non-root, workflow permissions are least-privilege, and secrets never pass through build args, logs, or artifacts. Judge deployment ceremony against what the diff actually deploys.

---

<critical_requirements>

CRITICAL: Before Reviewing Infrastructure Code

> **All code must follow project conventions in CLAUDE.md** (kebab-case, named exports, import ordering, `import type`, named constants)

**(You MUST verify no secrets are hardcoded - scan the diff for tokens, API keys, passwords, and connection strings)**

**(You MUST verify third-party CI actions are pinned to full SHA hashes, not mutable tags like `@v4` or `@main`)**

**(You MUST verify secrets never pass through build args, echo/log lines, or uploaded artifacts)**

**(You MUST verify production Dockerfiles the diff adds or changes set a non-root USER and pin their base image)**

**(You MUST verify workflow permissions are declared least-privilege, not inherited write-all)**

</critical_requirements>

---

**Auto-detection:** review workflow, CI PR review, Dockerfile review, pipeline review, deployment config review, GitHub Actions review, IaC review, terraform review

**When to use:**

• Reviewing diffs that touch CI/CD workflows (GitHub Actions, GitLab CI)
• Reviewing Dockerfiles, .dockerignore, or compose files
• Reviewing deployment configs (Kubernetes, Helm, platform configs)
• Reviewing IaC (Terraform, Pulumi) or release/build scripts
• Reviewing package-manager and lockfile changes with supply-chain impact

**When NOT to use:**

• When implementing infrastructure (use the relevant infra implementation skill)
• For application code in the same diff (use the web/api reviewing skills)
• For incident response or live operations questions

**Key patterns covered:**

• Supply-chain pinning: actions, base images, lockfiles
• Secret exposure across build args, logs, artifacts, and ignore files
• Dockerfile hygiene: non-root, multi-stage, layer order
• CI/CD least-privilege permissions and pipeline correctness
• Deployment safety scoped to what the diff deploys

**Detailed Resources:**

• [examples/core.md](examples/core.md) - Good/bad infrastructure patterns to look for during review

---

<philosophy>

Philosophy

**Operational code fails in production only.** No unit test catches an unpinned action's supply-chain compromise or a leaked deploy key; the review is frequently the only gate this code passes through. Security findings here are cheap to fix pre-merge and brutally expensive after.

**When reviewing infrastructure code:**

• Scan for secrets before reading for style - the highest-severity class takes seconds to check
• Treat every third-party reference (action, image, module) as an attack surface: is it pinned to something immutable?
• Cross-reference the diff's blast radius: a new env var must exist everywhere the app runs; a renamed job must update everything that `needs` it
• Ask what happens when this pipeline runs on a fork PR, on a re-run, and on two branches at once

**When NOT to flag:**

• Don't demand k8s-grade ceremony (probes, resource limits, rollback strategy) for a docs site or an internal workflow that deploys nothing
• Don't demand multi-stage builds for a CI-only image where size is irrelevant
• Don't flag missing caching in a job that runs in seconds
• Don't require a vault migration in a diff that just consumes an existing secret the established way

**Core principles:**

• **Secrets and supply chain are non-negotiable**: always blocking, in any diff, at any scale
• **Pin everything external**: mutable references delegate your security to strangers
• **Least privilege by default**: a workflow gets the permissions it needs, not the ones it inherits
• **Ceremony proportional to blast radius**: production deployment paths earn strictness; a lint workflow does not

</philosophy>

---

<patterns>

Core Patterns

Pattern 1: Supply-Chain Pinning

Every external reference resolves to something immutable.

## Pinning Review

For EACH external reference the diff adds or changes:

- [ ] Third-party GitHub Actions pinned to a full commit SHA (comment may carry the version)
- [ ] First-party actions (actions/\*) at minimum major-version pinned
- [ ] Base images pinned to a digest or a specific version tag - never `latest`
- [ ] Dependency installs in CI use the lockfile (`npm ci`, `bun install --frozen-lockfile`), and the lockfile is committed
- [ ] Terraform/Pulumi providers and modules carry version constraints

# Must Fix: mutable tag - the action's owner (or their attacker) can rewrite v4 tomorrow
- uses: some-org/deploy-action@v4

# Good: immutable SHA, human-readable version alongside
- uses: some-org/deploy-action@8f4b7f84864484a7bf31766abe9204da3cbe65b3 # v4.1.2

**Why this matters:** A mutable tag is remote code execution deferred: whoever controls that ref controls your CI, with your secrets in scope. Tag-rewriting attacks on popular actions are documented, recurring events.

---

Pattern 2: Secret Exposure

Secrets reach the process that needs them and nothing else.

## Secret Review

- [ ] No literal tokens, keys, passwords, or connection strings anywhere in the diff
- [ ] Secrets arrive via the platform's secret store (secrets context, env from vault) - not committed files
- [ ] No secret passes through a Docker build arg (build args persist in image history)
- [ ] No echo/printf/debug line pri