Pipeline security and poisoned builds

Why the runner is a high-value target

Before you read this section: what would happen if the code running inside your build job right now were hostile? Think through the answer, then continue.

A CI runner is not “just a build box.” For the duration of a job it holds every secret you handed the pipeline — deploy keys, registry credentials, cloud tokens, signing keys — and it has two things an attacker wants: outbound network access (to exfiltrate) and write access to the artifacts you’re about to ship (to tamper). That second capability is the SolarWinds-class threat: an attacker who controls the build doesn’t need to break into production at all. They modify the artifact as it’s built, your own pipeline signs and ships it, and every customer pulls a backdoored binary that passed all your checks. SLSA models exactly this — threats against the build process and the provenance of what it emits, not just the source.

So the pipeline is a system that must be threat-modeled like any other. The governing question for every job is: if the code running in this job were hostile, what could it reach? The answer is “every secret and credential in scope, plus the artifact.” That framing is what makes the rest of the lesson’s defenses obvious.

Poisoned Pipeline Execution: the core failure mode

Poisoned Pipeline Execution (PPE) is the umbrella name for the central attack: an adversary gets your CI to run their code with the pipeline’s privileges. They don’t need to compromise a runner or steal credentials up front — they convince the pipeline to execute attacker-controlled code in a privileged context, and the secrets fall out for free.

On GitHub, the canonical PPE vector is a trigger choice. Compare the two pull-request triggers:

# SAFE DEFAULT for fork PRs: low-privilege, no secrets, read-only token.
on: pull_request

# DANGEROUS when it runs PR code: base-repo context, secrets + write token.
on: pull_request_target

pull_request runs in a deliberately restricted context for fork PRs: no secrets, a read-only GITHUB_TOKEN. That is the correct place to build and test untrusted code, because even if the PR ships a malicious postinstall or a poisoned test, there’s nothing valuable in scope to steal. pull_request_target is the opposite: it exists for workflows that need to comment, label, or triage, so it runs in the base repo’s context — with your secrets and a write-scoped token. The trigger itself is not the bug. The bug is the combination: a pull_request_target workflow that then checks out the PR’s head and executes it.

# ANTI-PATTERN — do not do this. pull_request_target + checkout of untrusted head.
on: pull_request_target
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}   # attacker-controlled code
      - run: npm ci && npm test                             # runs it with secrets in scope

The moment that build step runs, attacker-controlled code is executing in a context that has your secrets. A fork PR from anyone on the internet can read secrets.* and exfiltrate it. No merge, no approval, no review of the code that actually ran — npm ci alone executes the PR’s lifecycle scripts. The defense is structural: never check out and run untrusted PR code in a job that has secrets. Keep secret-bearing steps physically separate from untrusted-code steps, require manual approval before a first-time contributor’s workflow runs at all, and treat the PR head as hostile input the way you’d treat a request body.

Least-privilege GITHUB_TOKEN

Even when a job legitimately runs your own code, the automatically-provided GITHUB_TOKEN is a credential worth scoping down. By default a workflow’s token can be broad; an attacker who achieves code execution in a job with a write-scoped token can do more than read — they can push commits, cut releases, or move tags, turning a build compromise into a source compromise. The fix is default-deny: set top-level permissions to the minimum, then grant only what each job needs, per job.

# Default-deny at the top; grant the minimum, per job.
permissions: {}                 # nothing by default
jobs:
  build:
    permissions:
      contents: read            # this job only reads the repo
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm run build

Scope tokens per job, not per workflow: the job that runs untrusted code should have permissions: {} and no secrets, while a separate publish job gets exactly the write scope it needs and nothing more. A write token in a job that runs untrusted code is a self-inflicted PPE.

OIDC instead of long-lived secrets

The deeper fix for “the runner holds stealable secrets” is to stop storing the stealable secret at all. A long-lived cloud key sitting in CI secrets is broad, rarely rotated, and a single exfiltration hands it over for as long as it lives. OIDC removes the standing secret: the runner requests a short-lived, signed identity token that encodes which repo, branch, and environment it’s running as; the cloud provider verifies that token against a trust policy and exchanges it for temporary credentials scoped to that workload.

# OIDC: no standing cloud key in secrets. The runner mints a short-lived identity,
# the cloud provider exchanges it for temporary credentials.
permissions:
  id-token: write              # allow the runner to request the OIDC token
  contents: read
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::111122223333:role/deploy-prod
          aws-region: us-east-1

There’s a real trade: OIDC needs trust-policy setup on the cloud side (which role trusts which repo and branch), versus pasting one key into a secret. But the blast radius of a stolen credential goes from “a broad, long-lived key” to “a token that expires in minutes and only works for one workload” — often near zero. The standing secret an attacker would exfiltrate simply doesn’t exist anymore.

Untrusted dependency execution at build time

PPE has a quieter cousin that doesn’t need a malicious maintainer or a misconfigured trigger: a malicious dependency. When the build installs packages, their install and build lifecycle scripts (preinstall, postinstall, build hooks) run on the runner with the job’s privileges — the same blast radius as any other code in the job. A compromised transitive dependency can read whatever secrets the job holds and exfiltrate them, all during a routine npm ci.

The mitigations stack: run installs with --ignore-scripts where you can so lifecycle hooks don’t fire automatically; use ephemeral, isolated runners so a compromised build can’t persist or pivot; apply egress filtering so a build that has no business calling an unknown host simply can’t; and — the cheapest, most effective control — don’t give the build job secrets it doesn’t need. A build that compiles code does not need your deploy key in scope. Move the deploy key to the deploy job, which doesn’t run untrusted dependency code.