engineering
What is your CI job actually talking to?
We put a default-deny egress policy in audit mode across a sample of pipelines. Nobody predicted their own allowlist correctly.
Priya Raghavan · Infrastructure · 2026-05-13 · 7 min read
Ask a team to list the hosts their CI reaches and you get four or five: their registry, npm or PyPI, GitHub, maybe a cloud API. Turn on egress logging and the real list is consistently longer.
What turns up
- Telemetry endpoints in build tooling, phoning home on every invocation
- Analytics and version-check calls from CLIs nobody thought of as network clients
- Transitive dependencies fetching binaries at install time from personal domains
- Documentation and badge services hit by test suites that render markdown
Why it matters
Every one of those is a path out. A dependency-confusion attack or a compromised postinstall script does not need a clever exfiltration channel when the runner can reach the whole internet by default.
How to find out safely
- Run a default-deny egress policy in audit-only mode — it logs but does not block
- Leave it for a full week so weekly and nightly jobs are represented
- Build the allowlist from what actually appeared, not from what you expected
- Switch to enforce, and keep logging so additions are visible
Your next build could be twice as fast, at half the price
Start free. Migrating away is the same one line, and we publish that diff too.
Related
CI when your teammates are agentsAI coding agents push far more often than humans. Here is how that changes pipeline design and cost control.Why we publish instructions for leavingEvery migration page on this site includes the diff to migrate back off us. Here is the reasoning.What we learned running a million CI jobsQueue time, cache behaviour, right-sizing and the failure modes that only appear at scale.Stop retrying flaky testsAutomatic retries convert a real bug into an intermittent one, and train your team to distrust every failure.