CI/CD Pipeline Security: Human Error Is Inevitable. Lateral Movement Isn't.

The incident report always reads “human error": a misconfigured runner, a committed token, an overpermissioned service account attached to a build job that didn’t need it. These mistakes happen at every company, regardless of maturity level, so the question isn’t whether they’ll happen to your team. The question is how your architecture lets those errors compound.

Image by kjpargeter on Freepik

A Compromised Runner Is a Beachhead

When attackers gain access to a CI/CD pipeline runner through a leaked token, a poisoned dependency, or a misconfigured environment variable, they don’t stop there. They enumerate everything reachable from that position, including artifact stores, secrets managers, container registries, staging environments, and sometimes even production databases. They look for credentials baked into the source code, its comments, and the documentation markup. They probe the subnet for services the runner was never supposed to touch but can, because no one restricted the network paths when it was originally provisioned.

That’s the blast radius problem in software delivery pipelines. A typical GitLab runner sitting on a shared subnet can reach the artifact store, the secrets vault, adjacent runners, and internal APIs all in the same network breath. The misconfiguration is the entry point, but the open network is the damage multiplier.

Why Least Privilege Alone Doesn’t Contain the Damage

The standard DevSecOps response to blast radius is least-privilege configuration: tighten IAM policies, scope tokens to the minimum needed permissions, and rotate secrets on a schedule. While these are necessary controls, none of them solve the lateral movement problem.

Least privilege governs what a process is authorized to do. However, it has no effect on what’s network-reachable to a compromised process. A misconfigured IAM role is one mistake, but the runner can still attempt connections to adjacent services, scan for open ports, and exploit trust relationships baked into the subnet’s routing table. Authorization policy and network reachability operate on different layers, and closing the gap at the authorization layer leaves the network layer wide open.

Terniion Removes the Paths, Not Just the Permissions

Terniion approaches CI/CD pipeline security from a different premise: instead of configuring what’s allowed to reach what, make every pipeline component non-addressable by default and grant reachability only where it’s explicitly required.

Terniion deploys lightweight STLink agents alongside protected pipeline components. Each STLink establishes outbound-only, process-to-process connections with triple-layer, quantum-resistant encryption. No inbound ports open. No public IPs. No routable addresses exposed on the subnet. A runner authorized to pull artifacts from a specific store does exactly that and nothing else. The network path to the secrets vault, to adjacent runners, and to staging simply doesn’t exist from that runner’s position. Probing the subnet returns nothing because there’s nothing addressable to probe.

This is the distinction between restricting what a compromised process can do versus eliminating what it can reach. The first approach relies on the perimeter holding. The second doesn’t need that assumption.

Blast Radius as a Design Parameter

Because Terniion works at the process level rather than the network level, the blast radius shrinks to whatever a specific process was authorized to reach—and nothing else. A build runner connected to the artifact store has exactly that: one tunnel, one destination, one authorized process on each end. There is no tunnel to the secrets manager, no tunnel to staging, no tunnel to production, because SealedTunnel never establishes connections that weren't explicitly configured. An attacker who compromises that runner can't pivot to other systems because the paths to those systems were never created in the first place.

Layered with Aclave credential-less authentication, which removes stored usernames, passwords, and long-lived certificates from the pipeline entirely, the architecture eliminates both the movement path and the credential that a compromised runner could carry to another system.

Error Prevention and Error Containment Are Different Problems 

Most pipeline security investment goes into preventing mistakes. Examples of this are secret scanning, pre-commit hooks, tighter code review, or security training. All of it matters, but none of it is a substitute for an architecture that limits what a mistake can become.

When the inevitable misconfiguration happens, the architecture either gives attackers a subnet to pivot across or it doesn’t. Terniion’s process-to-process tunneling and Zone-enforced segmentation make pipeline components non-addressable to anything outside their authorized communication scope. Your engineers don’t become less human. The blast just has nowhere left to go.