/cicd-security

name: cicd-security
description: "Audit CI/CD pipelines, GitHub Actions first and GitLab CI and CircleCI briefly, for the paths that give an outsider code execution, secrets or a write token: pull_request_target and workflow_run running untrusted code, expression injection into run steps, missing or broad workflow permissions, third-party actions not pinned to a commit SHA, OIDC trust policies with wildcard subjects, self-hosted runners on public repos, secrets reaching forks, cache and artifact trust between workflows, and AI agents in CI that read issue or PR text while holding a write token. Runs zizmor and actionlint read-only and writes findings.json. Use when the user mentions 'pull_request_target,' 'pwn request,' 'workflow injection,' 'zizmor,' 'actionlint,' 'pin actions to SHA,' 'GITHUB_TOKEN permissions,' 'self-hosted runner,' 'claude-code-action,' 'AI agent in CI,' 'GitLab CI security,' 'CircleCI security,' 'is this workflow safe,' or needs to secure a build pipeline."
allowed-tools: Read, Grep, Glob, WebSearch, Bash(zizmor --offline .), Bash(zizmor --offline --format=json .), Bash(zizmor --offline --format=sarif .), Bash(actionlint), Bash(actionlint -oneline), Bash(actionlint -format '{{json .}}'), Bash(gh workflow list:*), Bash(gh workflow view:*), Bash(gh run list:*)

CI/CD Security — Workflows, Runners, Tokens and Agents in the Pipeline

Review a repository's CI configuration the way you'd review authorization code. A workflow file decides who can run what, with which token, which secrets and which cloud role. The question for every job is the same: **can someone with less trust than the job (a fork PR author, any GitHub user who can comment, a third-party action maintainer) change what it runs or what it reads, and what does the job hold when they do?**

Cross-references: `dependency-audit` (packages, lockfiles, build context and release-artifact identity; this skill owns the workflow and runner side), `secrets-audit` (a secret that already reached a log, fork or artifact: rotation and history), `agent-supply-chain-audit` (skills, hooks and MCP servers on developer machines; this skill covers agents running inside CI), `prompt-injection` (LLM features in the user's own application), `iam-audit` (what the cloud role behind an OIDC trust policy can do), `cloud-audit` (repo security defaults and branch protection as part of a platform sweep), `scanner-pipeline` (running zizmor on every PR and on a schedule), `finding-triage` (disposition of a single finding).

When to use

• "Is this workflow safe?", a pasted `.github/workflows/*.yml`, or a PR that adds or changes CI
• A repo or org review of GitHub Actions: triggers, permissions, pins, runners, OIDC, caches, artifacts
• An AI agent action (claude-code-action, codex-action, run-gemini-cli, actions/ai-inference) wired to issues, PRs or comments
• GitLab CI (`.gitlab-ci.yml`) or CircleCI (`.circleci/config.yml`): the same classes, see

[references/gitlab-circleci.md](references/gitlab-circleci.md)

• zizmor or actionlint output that needs verdicts rather than a raw list

**Not for:** vulnerable packages or a lockfile diff → `dependency-audit`; a leaked key that needs rotating → `secrets-audit`; a Claude skill or MCP server someone is about to install → `agent-supply-chain-audit`; prompt injection in the product's chatbot → `prompt-injection`; designing least-privilege cloud roles → `iam-audit`; setting up a weekly scanner workflow → `scanner-pipeline`.

Authorization

• Review only repositories, organizations and CI systems the user owns or is authorized to audit. If ownership is

unclear, ask first.

• Pre-approved because they only read: reading files, the `zizmor --offline` and `actionlint` forms, and `gh workflow

list/view` and `gh run list`. None of them edits a workflow.

• Always prompts: `zizmor` in online mode (it sends a GitHub token to the API), any `gh api` call (the same command

takes `-X`/`-f` and becomes a write), `zizmor --fix` (rewrites workflow files), `gh run download`, re-running or dispatching a workflow, and changing any repository or org setting. Recommend those; let the owner run them.

• Never prove a finding by opening a PR, issue or comment on a repository to trigger a workflow, and never run a

workflow with a crafted payload. Write the exploit path as a trace and, where a live check is needed, a `validation_plan` the owner runs on a private fork or test repo.

• Never print secret values from workflow logs, environments or artifacts. Names only.

Step 1 — Inventory

Read every file that defines or feeds a pipeline, not just `.github/workflows/`:

| What | Where | |---|---| | Workflows | `.github/workflows/*.yml`, `*.yaml` | | Local actions and reusable workflows | `.github/actions/**/action.y*ml`, `action.y*ml` at the root, any `uses: ./…` path | | Remote reusable workflows | job-level `uses: org/repo/.github/workflows/x.yml@ref`: read them too, one level deep | | Config the jobs execute or the agent loads | `Makefile`, `package.json` scripts, scripts under `.github/`, `CLAUDE.md`, `AGENTS.md`, `.claude/`, `.mcp.json` | | Other CI | `.gitlab-ci.yml` and its `include:` files, `.circleci/config.yml`, `dependabot.yml` |

For each workflow, record: triggers (`on:`), top-level and job-level `permissions:`, each job's `runs-on`, `environment:`, `if:` gates, every `uses:` with its ref, the secrets and `id-token` it uses, and any AI agent step. That table is the coverage record for the report.

rg -n '^on:|^\s+(pull_request_target|workflow_run|issue_comment|issues|pull_request_review(_comment)?|discussion(_comment)?|workflow_call|workflow_dispatch)\b' .github/workflows
rg -n 'anthropics/claude-code(-base)?-action|openai/codex-action|google-github-actions/run-gemini-cli|actions/ai-inference' .github
# portable equivalents: grep -rnE with the same patterns

Remote repo without a clone: list with `gh workflow list -R owner/repo`; reading file contents needs `gh api repos/OW