Why Zero Trust Has to Reach the Pipeline, Not Just the Network

Zero trust as a network architecture principle is well understood at this point. You do not trust traffic because it originated inside the perimeter. You verify identity, validate posture, and enforce least-privilege access on every request regardless of where it comes from. The model is sound. The implementations have matured. Most platform teams have some version of this in place for their production infrastructure.

What those same teams typically have not done is apply the same thinking to their software delivery pipelines. This is the gap that motivated the SATHOS framework.

The pipeline's implicit trust problem

A CI/CD pipeline is a chain of automated steps that each trust the output of the previous step. A build job trusts that the source code it received is what was committed to the repository. A test job trusts that the artifact it received is what the build job produced. A deploy job trusts that the artifact it is pushing to production is the one that passed all the preceding gates.

None of these trust relationships are verified by default. They are assumed.

In a zero trust network, you would never say "this request is trustworthy because it came from inside the datacenter." But in most pipelines, teams say something equivalent every day: "this artifact is trustworthy because it came from our CI system." The question of whether that CI system, that artifact, or that delivery chain has been tampered with is not asked systematically. It is assumed to be fine because the pipeline ran successfully.

This assumption is exactly what supply chain attacks exploit. The SolarWinds compromise did not penetrate the network perimeter directly. It compromised the build system and let the delivery pipeline carry the malicious payload into production with full implicit trust. The network controls were irrelevant because the attack moved through a channel that was trusted by design.

What zero trust applied to a pipeline actually means

The principle is the same as zero trust networking: verify continuously, trust nothing implicitly, enforce least privilege at every boundary. What changes is what you are verifying and where the boundaries are.

Source integrity. The pipeline should verify that the code it is building matches a known, signed commit from an authorized contributor. This means commit signing enforced by policy, not encouraged by convention. A pipeline that will build any commit pushed to a branch is implicitly trusting every person and system with push access. That trust should be made explicit and enforced.

Artifact provenance. Every artifact produced by a build should carry a signed provenance record: what source it was built from, what build system produced it, what environment that build ran in, and what the resulting digest is. SLSA (Supply chain Levels for Software Artifacts) provides a framework for this. The point is that downstream steps do not just receive an artifact and assume it is valid. They verify the provenance attestation before proceeding.

Step identity and authorization. Pipeline steps should have scoped, ephemeral credentials rather than long-lived service accounts with broad access. A build step needs to pull from a container registry. It does not need write access to production infrastructure. A deploy step needs to push to a specific environment. It does not need access to every environment. This is least privilege applied to pipeline workloads, and it significantly limits the blast radius of a compromised step.

Continuous verification rather than gate-based checking. Traditional security in pipelines is checkpoint-based: a security scan runs at a specific stage, and if it passes, the artifact moves forward. Zero trust thinking pushes toward continuous verification: policy is evaluated at every step, anomalies trigger immediate interruption, and no step assumes that a previous step's security posture is still valid at the moment of execution.

How SATHOS approaches this

The SATHOS framework I published at IEEE ICAISET 2026 operationalizes these principles for enterprise CI/CD environments. The architecture has four layers.

The identity layer establishes cryptographic identity for every pipeline actor: the runner, the service account executing each step, the artifact being produced, and the policy evaluator making authorization decisions. Nothing in the pipeline is trusted based on its position in the workflow. Everything is trusted based on a verifiable identity claim.

The policy layer expresses authorization rules declaratively and evaluates them at runtime using an embedded policy engine. Rather than hardcoding security checks into pipeline scripts, policy is externalized and version-controlled separately from the pipeline definition. This means security teams can update policy without modifying pipeline code, and the policy evaluation is auditable independently of the pipeline execution.

The attestation layer produces a signed record at every significant pipeline transition: source checkout, build completion, test completion, security scan completion, and deployment. Each record is cryptographically bound to the previous one, creating a tamper-evident chain of custody for the artifact from source commit to production deployment.

The anomaly layer monitors pipeline execution against a behavioral baseline and interrupts execution when deviations occur. A build that takes three times longer than the historical baseline, a deploy step that makes API calls to systems it has never accessed before, a runner that downloads packages from domains outside the approved list: these are signals that something unexpected is happening. In a conventional pipeline, these anomalies produce logs that someone might review later. In SATHOS, they trigger policy evaluation in real time and can halt the pipeline before the unexpected action completes.

The organizational challenge

The technical architecture is the easier part. The harder part is the organizational shift that zero trust in the pipeline requires.

Security teams are accustomed to thinking about the pipeline as something that delivers software to the systems they protect, not as a system that itself requires zero trust controls. Platform teams are accustomed to thinking about pipeline security as vulnerability scanning and dependency auditing, not as identity, attestation, and continuous verification.

Closing this gap requires both teams to expand their mental model of where the trust boundary actually sits. In a cloud-native environment where pipelines have direct API access to production infrastructure, the pipeline is not outside the security perimeter. It is inside it, with elevated privileges, executing autonomously at high frequency. It deserves at least the same level of scrutiny as the infrastructure it deploys to.

A practical starting point

If you are building toward this and cannot implement the full model at once, the highest-leverage first step is artifact signing and provenance. Start producing and verifying signed attestations for your build artifacts before they reach any deployment step. This single change makes your supply chain materially more resilient to the class of attacks that pipeline zero trust is designed to address, and it builds the foundation that every other layer of the framework depends on.

The network is not the boundary anymore. The pipeline is. Treat it accordingly.