Threat modeling is a well-established practice in application security. Teams routinely model threats against APIs, backend services, and production environments.
However, CI/CD pipelines are often excluded from formal threat modeling exercises, despite being one of the most critical components of modern software systems.
This is a dangerous gap.
CI/CD pipelines sit at the intersection of untrusted inputs, high privileges, and trusted outputs. They are precisely the kind of system where threat modeling provides the most value—yet they are frequently treated as “just automation.”
This article explains how to threat model CI/CD pipelines effectively, with a focus on identifying trust boundaries, understanding attack paths, and prioritizing controls that actually reduce risk.
Why threat modeling CI/CD pipelines is different
Traditional threat modeling approaches often assume a relatively stable system boundary: an application running in production, with defined users, data flows, and assets.
CI/CD pipelines break many of these assumptions.
A pipeline is not a single system. It is a dynamic chain of systems that:
- Consumes inputs from multiple sources
- Executes untrusted code
- Operates with elevated privileges
- Produces artifacts that downstream systems trust implicitly
In other words, pipelines are not just part of the delivery process— they are a trust transformation mechanism.
Threat modeling CI/CD pipelines therefore requires a shift in mindset:
The goal is not only to prevent compromise, but to understand where trust is created, amplified, or violated.
What we are actually protecting
Before identifying threats, it is essential to clarify what assets a CI/CD pipeline is responsible for protecting.
Common pipeline assets include:
- Source code integrity — ensuring code is not modified unexpectedly
- Build integrity — ensuring builds execute as intended
- Artifact integrity — ensuring outputs match inputs
- Secrets and credentials — tokens, keys, and identities used by automation
- Release authenticity — ensuring releases are legitimate and attributable
A successful pipeline attack does not always involve stealing data or crashing systems. Often, the attacker’s goal is much subtler:
Introduce malicious behavior while preserving the appearance of legitimacy.
Understanding trust boundaries in CI/CD
A trust boundary exists whenever data or control crosses from a less trusted context to a more trusted one.
In CI/CD pipelines, trust boundaries are everywhere—but they are rarely explicit.
Threat modeling begins by identifying these boundaries and asking a simple question:
What assumptions are we making about trust at this point?
1. Source code inputs
Pipelines consume source code from repositories, branches, tags, and pull requests. Not all of these inputs have the same trust level.
- Main branches may be restricted and reviewed
- Feature branches may be loosely controlled
- Pull requests may include untrusted contributions
Yet many pipelines treat all code inputs as equally trusted.
This creates an attack surface where untrusted code can influence trusted build and deployment processes.
2. Dependency resolution
Modern builds resolve dependencies dynamically from external ecosystems: package registries, container registries, and artifact repositories.
Each dependency resolution step crosses a trust boundary:
- From internal control to external infrastructure
- From verified inputs to third-party code
Threat modeling must account for:
- Dependency confusion
- Typosquatting
- Compromised upstream packages
Ignoring dependencies in threat modeling leaves a major attack path unexplored.
3. CI/CD runners and execution environments
Runners are where pipeline logic actually executes. They are one of the most critical—and most misunderstood—trust boundaries.
Runners execute:
- Source code
- Build scripts
- Third-party actions or plugins
If runners are treated as trusted infrastructure, but they execute untrusted inputs, the trust boundary collapses.
Threat modeling must explicitly consider:
- Runner isolation
- Persistence between jobs
- Network and filesystem access
- Access to secrets
4. Pipeline configuration and orchestration
CI/CD configuration files define what runs, when it runs, and with which permissions.
They are effectively control planes for the delivery process.
Any change to pipeline configuration can:
- Alter execution flow
- Expand privileges
- Introduce new attack paths
Threat modeling must treat configuration changes with the same rigor as production code changes.
5. Artifacts and handoff to deployment
The final trust boundary is the handoff from pipeline to production.
At this point, production environments often assume:
If it came from CI/CD, it is safe.
This assumption is precisely what attackers exploit.
Without integrity verification and provenance checks, production cannot distinguish legitimate artifacts from poisoned ones.
Identifying common CI/CD attack paths
Once trust boundaries are identified, the next step is to map realistic attack paths.
The goal is not to enumerate every theoretical threat, but to understand how attackers move through the system.
Attack path 1: Pull request to secret exfiltration
A common attack path involves:
- An attacker submits a pull request
- The pipeline executes PR code
- Secrets are exposed to the build environment
- The attacker exfiltrates credentials
This attack does not require exploiting a vulnerability— it exploits an implicit trust assumption.
Attack path 2: Dependency compromise to build poisoning
Another common path:
- A dependency is compromised upstream
- The pipeline resolves the dependency
- Malicious code executes during build
- Artifacts are modified before publication
Without integrity checks or provenance, the poisoned artifact may look completely legitimate.
Attack path 3: Pipeline configuration manipulation
Pipeline configuration files often receive less scrutiny than application code.
An attacker who can modify configuration can:
- Add hidden execution steps
- Expand permissions silently
- Redirect artifact outputs
This attack path is especially dangerous because it can persist across multiple builds.
Attack path 4: Runner compromise and lateral movement
If runners are shared, persistent, or poorly isolated, an attacker can:
- Persist across jobs
- Steal secrets from other pipelines
- Modify future builds
In some cases, runner compromise provides access to internal networks or cloud environments.
Mapping trust boundaries visually
Effective threat modeling benefits from visual representations.
For CI/CD pipelines, diagrams should focus on:
- Where untrusted inputs enter
- Where privilege increases
- Where artifacts are produced and consumed
Each arrow in the diagram represents a trust transition. Each transition is a candidate for control enforcement.
The key question at every boundary is:
What guarantees do we have at this point, and how are they enforced?
Prioritizing controls based on threat modeling
Threat modeling is only valuable if it informs action.
For CI/CD pipelines, the highest-impact controls usually include:
1. Reducing implicit trust
Explicitly distinguish between trusted and untrusted inputs. Do not expose secrets or privileged actions to untrusted contexts.
2. Enforcing least privilege
Pipeline identities should be scoped per job, per stage, and per environment. Avoid long-lived, broadly scoped tokens.
3. Isolating execution environments
Runners should be ephemeral or strongly isolated. Untrusted workloads should never share execution context with trusted ones.
4. Verifying artifact integrity
Artifacts should be signed, attested, and verified before deployment. Production should trust verification—not assumptions.
5. Treating pipeline configuration as high-risk code
Apply reviews, policies, and validation to CI/CD configuration changes. Prevent silent expansion of execution or privileges.
Common mistakes in CI/CD threat modeling
Even when organizations attempt to threat model pipelines, they often fall into predictable traps.
- Focusing only on tools, not trust relationships
- Assuming “internal” means “trusted”
- Ignoring third-party components
- Modeling idealized architectures instead of real pipelines
Effective threat modeling must reflect how pipelines actually operate, not how we wish they operated.
Conclusion
CI/CD pipelines are not peripheral systems. They are central to software integrity, security, and trust.
Threat modeling pipelines reveals attack paths that traditional application threat models miss, because the attacker’s goal is not to exploit runtime behavior, but to control what gets delivered in the first place.
By identifying trust boundaries, mapping realistic attack paths, and prioritizing enforceable controls, organizations can significantly reduce the risk of software supply chain attacks.
The most important shift is conceptual:
If you do not explicitly model trust in your pipeline, you are relying on assumptions—and attackers exploit assumptions.
