cicd-security

CI/CD Pipeline Security

Rules (for AI agents)

ALWAYS

• Pin every third-party GitHub Action by commit SHA (full 40-char), never by a floating tag (@v1, @main, @latest) — tags can be re-pushed. The tj-actions/changed-files March 2025 incident exfiltrated secrets from 23,000+ repositories specifically because consumers used floating tags. Same applies to GitLab CI include: references and reusable workflows. Renovate / Dependabot can keep the SHA pins fresh.
• Declare permissions: at the workflow or job level and default to contents: read only. Grant additional scopes (id-token: write, packages: write, etc.) job-by-job, never workflow-wide.
• Use OIDC (id-token: write + cloud provider trust policy) for short-lived cloud credentials. Never store long-lived AWS / GCP / Azure keys as GitHub Secrets.
• Treat pull_request_target, workflow_run, and any pull_request job that uses actions/checkout with ref: ${{ github.event.pull_request.head.ref }} as trusted-context-on-untrusted-code — the "pwn request" pattern documented by GitHub Security Lab. Either don't run them, or run with no secrets and no write tokens. A fork's GitLab merge-request pipeline is the same shape — it runs the fork's own .gitlab-ci.yml on your runners: isolate them, expose no protected variables.
• Echo every untrusted expression (${{ github.event.* }}) through an environment variable first; never interpolate it directly into run: body — that's the canonical GitHub Actions script-injection sink. The GitLab sink has the same shape: $CI_* / $TRIGGER_* interpolated into bash -c or eval, where merge-request metadata carries the shell metacharacters.
• Sign release artifacts (Sigstore / cosign) and publish SLSA provenance attestations. Verify provenance in any consumer pipeline that pulls the artifact.
• Pin runs-on to a dated runner image (ubuntu-24.04), not a floating label (ubuntu-latest) — the label moves underneath you. On GitLab, use ephemeral Docker-executor runners with privileged: false; a shared shell runner with privileged: true gives a compromised job root on the host. An egress firewall on runners handling secrets (StepSecurity Harden-Runner or equivalent) is defense-in-depth on top of that, not a substitute.
• Require a human reviewer on a dependency-bump PR when supply-chain-security raises a trust-boundary change — a maintainer or ownership change, a new or changed install hook, a registry or source transition, a provenance regression. Gate on that signal, not on the version number: a patch release that changes maintainer warrants more review than a major bump that does not.
• Consult supply-chain-security before any dependency install step (npm install, pip install, docker pull) — in CI it is untrusted code execution on a runner holding your credentials. It owns install-script risk (postinstall, setup.py, build.rs) and registry pinning; container-security names the command that fixes the lockfile half (npm ci, --frozen-lockfile) rather than adding flags to npm install.