Why Your CI Pipeline Needs Network Security (And How We Built It)

Most CI/CD pipelines have unlimited internet access. That's a problem.

When your GitHub Actions runners can connect to any external service, you're creating a massive attack surface. A compromised dependency, malicious script, or even an honest mistake can lead to data exfiltration or unauthorized access.

At Depot, we've been thinking about this problem while building our managed GitHub Actions runners. Today, we're sharing how we solved it with egress filtering — and why every CI pipeline should have network controls.

The Hidden Security Risk in CI/CD

Think about what your CI pipeline can access:

• Your source code and secrets
• Production deployment keys
• Internal APIs and databases
• Third-party services and registries

Now think about what it can connect to: everything on the internet.

That's the disconnect. Your CI has access to your most sensitive assets, but traditional runners operate with unlimited network access. One malicious npm package or compromised Docker image could exfiltrate your entire codebase.

What We Built: Egress Filtering for CI

Egress filtering gives you fine-grained control over which external services your CI runners can reach. Instead of unlimited internet access, you define exactly what your builds need.

How it works:

• Configure allow/deny rules for specific IPs, hostnames, or CIDR blocks
• Set a default policy (allow or deny all unlisted traffic)
• Automatic allowlisting for essential services (GitHub, your registries, etc.)
• Zero changes to your existing workflows

Example configuration:

The Technical Challenge: Making It Actually Work

Building network filtering for CI isn't straightforward. Here are the problems we had to solve:

Problem 1: Round-Robin DNS

Services like api.github.com return different IP addresses on each DNS lookup. You can't just allowlist one IP.

Our solution: After resolving hostnames in your rules, we write entries to /etc/hosts to ensure consistent IP resolution.

Problem 2: Dynamic Infrastructure

When you run depot build, our API spins up a new builder with a random AWS IP. We can't pre-allowlist every possible EC2 IP.

Our solution: A background process that listens for new builder IPs and dynamically adds them to the allowlist.

Problem 3: Essential Services

Runners need to connect to GitHub Actions services, AWS APIs, and other infrastructure. Breaking these would kill your builds.

Our solution: Automatic allowlisting for known essential services, with the ability to override if needed.

Implementation: iptables + Custom Chain

We implemented egress filtering using iptables on Linux runners:

1. Create custom chain: DEPOT_FILTER in the filter table
2. Route traffic: All outbound traffic goes through our custom chain
3. Process rules in order:
   • Allow loopback traffic (localhost services)
   • Apply deny rules first (explicit blocks take precedence)
   • Apply allow rules (explicit permits)
   • Apply default policy (allow or deny everything else)

Real-World Use Cases

Lock down production pipelines: Only allow connections to your specific registries, APIs, and deployment targets.

Prevent data exfiltration: Block connections to file-sharing services, social media, or unknown domains.

Meet compliance requirements: Many enterprises require network controls for CI/CD accessing sensitive data.

Secure open source projects: Prevent supply chain attacks from making unauthorized network connections.

What's Next

We're working on additional features:

Monitor mode: See which connections your runners are making without blocking them. Perfect for understanding what your builds actually need before locking things down.

Windows and macOS support: Currently Linux-only, but expanding to other platforms.

Advanced policies: Time-based rules, conditional access, and integration with external security tools.

Why This Matters

CI/CD security is often overlooked. Teams focus on securing their applications but leave their build pipelines wide open. As supply chain attacks become more common, network controls for CI aren't optional — they're essential.

Egress filtering gives you security without sacrificing the speed and flexibility that makes CI/CD valuable. Your builds run just as fast, but with dramatically reduced attack surface.

Try It Yourself

Egress filtering is available now for all Depot GitHub Actions runners. Head to your organization settings to configure rules for your team.

The future of CI/CD is fast and secure. You shouldn't have to choose.