The CI/CD threat model — who attacks, what they want, how they get in

A CI/CD pipeline is not infrastructure that runs the application. A CI/CD pipeline is the actor that produces the artifact, attests to the source, holds the secrets, and pushes to the registry. Every other component in the software supply chain hands bytes or identities to the CI pipeline and trusts the pipeline to behave honestly. The attacker who compromises the CI pipeline compromises the trust anchor. The threat model of a CI/CD pipeline is the threat model of a single actor with delegated production trust across every supply-chain boundary.

Who attacks a CI/CD pipeline

Four attacker classes target a CI/CD pipeline. They are not the same class; their capabilities, motivations, and detection profiles differ.

• Outsider. An attacker with no privileged access to the repository, the CI platform, or the artifact registry. The outsider’s capability is the public attack surface: a vulnerable workflow input, a third-party action with a CVE, a public registry that can be subverted. The outsider’s motivation is opportunistic — they find the easiest pipeline to compromise and they compromise it.
• Insider. An attacker who is a developer on the team, with legitimate commit and PR rights. The insider’s capability is the trust the repository has granted them: the ability to land code, to push tags, to trigger workflows, and to approve deploys. The insider’s motivation is malicious intent — financial, ideological, coerced, or compromised at the personal level.
• Compromised insider. A legitimate developer’s account or workstation has been taken over. The attacker’s capability is identical to the insider — they have the developer’s PAT, the developer’s SSH key, the developer’s browser session. The attacker’s motivation is whatever the external operator chose; the developer may not know their account is compromised.
• Compromised supply chain. The attacker is upstream — the maintainer of a third-party action, the publisher of a public dependency, the operator of a base image, or the vendor of a CI plugin. The attacker’s capability is the trust the team has delegated to that upstream component by pinning to it, pulling from it, or running it.

flowchart LR
    A["Outsider"] --> A1["public attack surface"]
    B["Insider"] --> B1["legitimate repo trust"]
    C["Compromised insider"] --> C1["stolen PAT / session"]
    D["Upstream"] --> D1["third-party action / pkg"]
    A1 --> X["CI/CD pipeline"]
    B1 --> X
    C1 --> X
    D1 --> X
    X --> Y["Production trust"]

The four classes converge on the same target: the CI/CD pipeline. The defences differ by class, but the threat model is the same — the pipeline is the actor.

What they want

The assets a CI/CD pipeline protects are not the application code. The application code is the output; the assets the attacker wants are the trust.

• Production credentials. Cloud roles, registry push tokens, signing keys, deploy identities. These are the credentials the pipeline uses to publish; the attacker wants to use them.
• Signing identity. The key the pipeline uses to sign artifacts and attestations. The attacker who holds the signing identity can forge any artifact the verifier will accept.
• Artifact substitution. The attacker wants to publish a malicious artifact under the team’s name, signed by the team’s key, attested to by the team’s pipeline.
• Backdoor in a popular upstream. The attacker wants the team’s build to pull their code. The SolarWinds and xz-utils attacks succeeded by being upstream of the build they wanted to compromise.
• Persistent access. The attacker wants a foothold inside the CI environment that survives the job. A persistent foothold is the difference between a single-pipeline incident and an organisation-wide compromise.

The six attack surfaces

The CI/CD pipeline exposes six surfaces. Each is a distinct attack path; each is defended by a different control.

1. Source. The commit, the PR, the branch, the review. The attacker who lands a malicious commit has compromised the artifact’s source.
2. Identity. The PAT, the SSH key, the OIDC token, the GitHub App installation. The attacker who steals a developer’s identity can do anything that developer can do.
3. Dependency. The third-party action, the npm package, the base image. The attacker who compromises the upstream compromises every consumer that pulls.
4. Build. The runner, the build step, the script. The attacker who compromises the runner can substitute bytes between the source and the artifact.
5. Secret. The secrets.* context, the env var, the mounted file. The attacker who reads a secret at build time can use it elsewhere.
6. Artifact. The registry, the digest, the tag, the attestation. The attacker who writes to the registry without writing through the build has substituted an artifact.

flowchart LR
    A["Source: commit"] --> P["Pipeline"]
    B["Identity: PAT"] --> P
    C["Dependency: action / pkg"] --> P
    P --> D["Build: runner / step"]
    P --> E["Secret: secrets.*"]
    P --> F["Artifact: registry"]
    D -. "compromise" .-> A
    D -. "compromise" .-> C
    E -. "exfil" .-> B
    F -. "substitute" .-> P

Each surface is the topic of one lesson in this part. The six lessons do not enumerate the controls — the controls are in Parts LXV through LXX. The six lessons enumerate the attacks: how the attacker gets in, what they do once inside, and what the audit trail looks like after.

How they get in

The entry points map to the four attacker classes. The outsider enters through a public surface: a workflow that takes attacker-controlled input, an action with a CVE, a public container registry that allows anonymous pushes. The insider enters through the workflow itself: a PR that lands, a tag they push, a release they publish. The compromised insider enters through whatever the legitimate developer used — a phished PAT, a session cookie, a stolen SSH key. The upstream attacker enters through the dependency: a tag-swap on a third-party action, a typosquatted package, a compromised base image.

The single rule that covers every entry point is: the attacker will choose the cheapest path through the chain. The chain is the six surfaces above; the cheapest path is the surface the defender did not verify. The defence is to verify at every surface.

Production discipline

1. Treat the pipeline as the actor, not the application. The threat model of a CI/CD pipeline is the threat model of a delegated trust boundary, not of a build script.
2. Model the attacker class. The outsider, the insider, the compromised insider, and the upstream attacker all have different capabilities. The control for one is not the control for another.
3. Identify the six surfaces. Source, identity, dependency, build, secret, artifact. Each is a separate attack path.
4. Verify at every surface. The attacker will choose the cheapest path; the defender closes every path or the chain is broken.

Cross-course references

• Git, CI/CD & GitOps — Part LXV (Supply Chain Trust Boundaries) is the general model; LXXI is the CI/CD-specific instance.
• Git, CI/CD & GitOps — Parts LXVI-LXVIII (Third-party Actions, Pinning, Allowlisting) are the dependency controls.
• Container Security for Production Sysadmins — Part III (Image Trust) covers the artifact-side controls.
• Linux for Production Sysadmins — Part XII (RepoSecurity) covers the upstream trust model.

Quiz