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