Zero Trust for CI/CD means applying the principle of “never trust, always verify” to the software build pipeline. Instead of automatically trusting packages, credentials, scripts, and network connections because they originate from an approved source, teams establish security policies and, during the build, automated controls check build activity against those policies and enforce them in real time. Most security teams already apply zero trust to users and devices. Fewer have extended the same scrutiny to the systems that assemble their software, even though those systems pull in third-party code, hold live secrets, and make frequent outbound network calls during a build.
That gap matters because attackers have noticed it. The build stage has become one of the most active targets in software supply chain attacks, and the tools most teams rely on were designed to inspect code before a build starts or scan artifacts after it finishes. The moment the build is actually running gets very little attention. Closing the gap is the job of a newer category of tooling, the Build Application Firewall (BAF), which brings zero-trust enforcement into the build itself.
What Is Zero Trust?
Zero Trust is a security model that removes automatic trust from anyone and anything, regardless of whether they sit inside or outside the network perimeter. Every request to access a resource has to be authenticated, authorized, and validated before it is granted, and that decision is made fresh each time rather than assumed from a previous login or network location.
The model was formalized by the National Institute of Standards and Technology (NIST) in NIST SP 800-207, published in 2020. The older perimeter approach assumed that once a user or system was inside the corporate network, it could be trusted. Zero trust throws that assumption out. It treats the network as already compromised and asks every actor to prove itself continuously.
Three ideas sit underneath most zero-trust programs: verify explicitly, enforce least privilege, and assume breach. They apply just as cleanly to a build pipeline as they do to employees logging in from a coffee shop.
What Does Zero Trust Mean for CI/CD Pipeline Security?
Applied to CI/CD, zero trust means no build step, dependency, script, or outbound connection is trusted by default, even when it originates from your own pipeline. The build environment is treated as a place where an attacker might already be operating, so each action it takes is checked against policy instead of being waved through because it came from a trusted runner.
How CI/CD Pipelines Operate on Implicit Trust Today
Many (if not most) CI/CD pipelines implicitly trust code executing inside the build environment, often granting it broad network access and access to credentials needed by the pipeline. A workflow triggers, checks out code, pulls dependencies from public registries, runs install scripts, fetches container images, and reaches out to whatever network endpoints those steps request. Each of those actions usually happens with broad permissions and little inspection. The runner trusts the package manager, the package manager trusts the registry, and the build trusts every script that executes along the way. Yet few controls monitor or enforce policy on what the build actually does while it runs.
Why Implicit Trust is the Attack Surface
That implicit trust is exactly what attackers exploit. The Cybersecurity & Infrastructure Security Agency (CISA) and the National Security Agency (NSA) describe the pipeline as a distinct and separate attack surface from the rest of the software supply chain in their guidance on defending CI/CD environments, and they lay out how a single compromise can spread to every system a build touches. Stolen developer credentials, a poisoned dependency, or a malicious install script can turn a routine build into a delivery mechanism for malware, and because the pipeline is trusted downstream, the compromised artifact usually sails straight into production. A recent example, GitHub Actions “pwn request” vulnerabilities, illustrates the danger: a misconfigured workflow can allow code from an untrusted pull request to execute with elevated permissions, potentially exposing repository secrets or enabling unauthorized actions.
The Three Zero Trust Principles Applied to CI/CD Pipeline Security
The three core zero-trust principles map directly onto pipeline security, and together they describe what “never trust, always verify” looks like during a build.
Verify Explicitly: Validate Dependencies, Actions, and Connections
Verifying explicitly means checking, rather than assuming, the identity and integrity of what a build pulls in. Rather than trusting a package because it came from a well-known registry, a zero-trust pipeline confirms where each dependency, action, and container image actually comes from before it is allowed into the build. That means validating signatures, pinning actions to a specific commit rather than a mutable tag, and rejecting artifacts whose provenance does not check out, no matter how reputable the source looks on paper.
Enforce Least Privilege: Scope Permissions Tightly Across the Pipeline
Least privilege means giving each build step only the access it needs, and nothing more. CISA and NSA specifically recommend least-privilege policies and short-lived credentials for CI/CD access, because pipelines so frequently run with standing admin rights and long-lived tokens. A build that only needs to pull two dependencies and publish one artifact should not have open network access to the entire internet or the ability to push code back to the main branch.
Assume Breach: Treat Every Build as a Potential Attack Vector
Assuming breach means designing the pipeline as if an attacker is already inside it. Instead of asking whether a build could be compromised, you plan for the possibility that it is and contain the damage. In practice, that means monitoring build-time behavior in real time, blocking suspicious actions as they happen, and keeping a tamper-resistant record of what each build did, helping teams detect and investigate compromises that might otherwise go unnoticed.
Where Most DevSecOps Teams Leave Zero Trust Gaps
Most DevSecOps teams apply zero trust to who can access the pipeline, then stop short of what the pipeline does once it runs. The result is three recurring gaps.
Identity Verification Stops at the Workflow Trigger
Identity checks usually cover who can start a build, not what the build talks to afterward. Teams invest in strong authentication, branch protection, and reviewer approvals for the humans involved, which is good practice. Once the workflow fires, though, the machine identity of the build takes over, and the packages, actions, and endpoints it contacts rarely face the same scrutiny. Verification that ends at the trigger leaves the entire execution phase unchecked.
Network Connections Are Largely Unmonitored During Builds
Few teams watch the network traffic a build generates while it runs. A pipeline may contact package registries, mirrors, container repositories, and any number of other endpoints during a single job, and most tooling has no visibility into those connections. That blind spot is where secrets get exfiltrated and where malicious dependencies phone home. Without inspection at the network layer during execution, a build can send credentials to an attacker’s server and leave almost no trace in the tools teams normally check.
Build Attestation Is Not Real-Time Enforcement
Generating a Software Bill of Materials (SBOM) or an attestation after the build is useful for compliance, but it documents what happened rather than stopping it. By the time a post-build report lists a suspicious component, the artifact already exists and may already be moving downstream. Attestation describes the past. Enforcement has to happen while the build runs, the moment a policy is violated, which is a different capability than reporting on it afterward. The distinction matters wherever the build record has to serve as evidence, as in healthcare software supply chain security, where it needs to reflect what truly went into the build rather than what a manifest claims.
How a Build Application Firewall Brings Zero Trust to DevSecOps
A Build Application Firewall enforces zero trust by sitting inline in the pipeline and applying policy to build-time behavior in real time. Just as a Web Application Firewall (WAF) protects web applications, a Build Application Firewall (BAF) protects CI/CD pipelines while software is being built. It operates as a proxy for CI/CD communication and performs deep packet inspection of the traffic a build generates, so it can validate components as they are pulled in and control where the build is allowed to connect.
That inline position is what turns principles into enforcement. The firewall supports explicit verification by inspecting dependency retrieval and network connections against policy. It reinforces least privilege by restricting which destinations and network-based actions a build may access. And it supports an assume-breach approach by monitoring build-time communication in real time and blocking activity that violates policy. Policies can be written as code, which keeps enforcement consistent and reviewable rather than dependent on tribal knowledge.
When a build tries to reach an untrusted domain, pull a disallowed package, or leak a secret, the firewall can block the action, stop the build, and record exactly what occurred. It covers the build-time layer that SAST, SCA, and runtime scanning leave open, and it does so without asking developers to change how they work.
Move From Zero Trust as a Goal to Zero Trust as a Policy with InvisiRisk
A pipeline’s biggest blind spot is the build itself, where code executes with real privileges and little oversight. InvisiRisk’s Build Application Firewall works alongside your existing CI/CD pipelines and security tools, applying zero-trust policy to live build traffic. It verifies dependency retrieval, controls where builds can connect, and blocks unauthorized outbound activity and attempts to exfiltrate secrets. Instead of relying only on pre-build scans and post-build reports, you gain visibility into build-time activity, the ability to stop unauthorized behavior, and verifiable evidence of what occurred.
FAQs
Does Zero Trust for CI/CD replace SCA and other security scanners?
No. Zero Trust for CI/CD complements traditional security tools rather than replacing them. Software Composition Analysis (SCA) identifies known vulnerabilities and malicious components, while tools like SAST detect coding flaws. These tools provide important protection, but generally do not control what dependencies and scripts do while a build is running. Build-time enforcement adds that missing layer by monitoring activity and blocking unauthorized behavior in real time.
How does a Build Application Firewall support Zero Trust?
A Build Application Firewall (BAF) applies Zero Trust principles directly inside the CI/CD pipeline. Rather than automatically trusting code and dependencies because they run in an approved build environment, the BAF inspects build-time network traffic and enforces security policies in real time. It can block unauthorized outbound connections, suspicious dependency behavior, and attempts to exfiltrate secrets, even when an attack involves a previously unknown vulnerability.
Book a demo today to see how our Build Application Firewall protects your CI/CD pipeline against software supply chain attacks.
