How should security teams segment CI pipelines that depend on many internal and external services?

Why CI pipeline segmentation needs to be stricter than ordinary network zoning

A CI pipeline is not just another internal service path. It is an execution environment that often touches source code, build systems, artifact registries, package managers, cloud APIs, and deployment credentials, so broad connectivity turns it into a high-impact bridge between many trust domains. Segmentation works best when it is designed around the pipeline’s exact functional dependencies, not around convenience or shared network location.

The practical implication is that segmentation should be policy-driven, not topology-driven. A pipeline job may run in one subnet, but its real exposure is defined by what it can reach, what it can authenticate to, and what it can exfiltrate if compromised. That is why allowlisting specific repositories, package endpoints, artifact stores, and required internal services is more defensible than “internal-only” access.

In practice, this also means treating internet access as an exception path, not a default. If build steps must fetch external dependencies, the destination set should be narrowly approved and observable, because unrestricted outbound connectivity is one of the fastest ways for a compromised runner, malicious dependency, or poisoned build step to expand the blast radius. The Shai Hulud npm malware campaign and the Reviewdog GitHub Action supply chain attack both show how CI-adjacent trust can be abused to reach secrets and downstream systems.

What to segment, and what to leave tightly coupled

The right segmentation boundary is usually the CI worker or runner, plus its control plane dependencies, not the broader developer network. Keep source checkout, dependency retrieval, artifact publication, signing, and deployment permissions separated so that compromise of one function does not automatically grant access to all others. That separation matters most when pipelines can read secrets, impersonate service accounts, or trigger production deployments.

Where a dependency is unavoidable, define it explicitly and minimize its scope. For example, a pipeline that needs a package registry does not also need broad database access, general intranet browsing, or unrestricted access to every cloud endpoint. If a shared service must be reachable, segment by protocol and destination rather than by a coarse trust label. The guiding principle is that every additional reachable service becomes part of the pipeline’s effective attack surface.

Segmentation should also account for the supply-chain path the pipeline consumes. Build systems are frequently targeted through dependencies, action reuse, and compromised tooling, which means the pipeline’s trust graph can be broader than the visible network graph. SLSA is useful here because it anchors the broader idea of build integrity and provenance, while NIST AI Risk Management Framework is not relevant here, so there is no need to force adjacent governance concepts into a pipeline-segmentation question.

How to operationalize allowlist-based pipeline segmentation

Start with a dependency inventory at the level of exact systems, repositories, domains, and protocols. Then decide which calls are mandatory for each pipeline stage, which are stage-specific, and which are forbidden. That inventory should be reviewed as part of change management, because new packages, new deployment targets, and new build steps often expand connectivity quietly.

From there, enforce segmentation in the network layer, the identity layer, and the build configuration layer. Network controls restrict where runners can connect; identity controls restrict what those connections can do; and build configuration controls reduce the chance that a job can self-modify its trust boundaries. A runner that can reach an endpoint but cannot authenticate usefully to it is still safer than a runner that can both reach and fully use every service it sees.

Verification should be continuous. Security teams should be able to prove which destinations are reachable from each stage, what egress is permitted, and whether unexpected connections are blocked or alerted. That visibility is especially valuable during incident response, because segmentation is only meaningful if abnormal traffic stands out quickly enough to contain the event.

Risk and Threat Considerations

CI pipelines are attractive compromise targets because they often sit close to source code, secrets, package trust, and deployment authority. If segmentation is too broad, an attacker who gains runner execution can pivot into artifact stores, credentialed services, or external exfiltration paths with very little friction.

Failure mechanism: Overbroad egress and shared trust paths let malicious code, poisoned dependencies, or stolen runner credentials reach more systems than the build actually needs, which increases the chance of secret theft and lateral movement.

Impact: A single pipeline compromise can become a supply-chain event, causing code tampering, credential exposure, unauthorized deployments, or hidden exfiltration that is harder to detect after the fact.

Practitioner Guidance

What to verify: Confirm that each pipeline stage has a documented destination list and that the list matches observed traffic, not just intended design. Any destination outside that list should be treated as a control failure until explained.

Common mistake: Teams often segment by subnet or environment label and assume the problem is solved. In CI, the real question is whether a compromised job can talk to anything it does not strictly need and whether that path can be used to recover secrets or publish artifacts.

What good looks like: Build jobs can complete with minimal, stage-specific access, outbound traffic is sparse and expected, and an exception path for internet access is visible enough to review quickly during an incident.

Practitioner takeaway: The goal is not to make CI isolated in the abstract, but to make every permitted dependency explicit, bounded, and easy to audit when a build runner is suspected to be compromised.

Related resources from NHI Mgmt Group

• How should security teams decide whether JIT access is safe for non-human identities?
• How should security teams govern credentials used by CI/CD pipelines?
• How should security teams handle Dependabot-style automation in CI pipelines?
• How should security teams govern AI applications that span notebooks, pipelines, and runtime services?