Your build runners now deny all outbound traffic - what belongs on the egress allow-list?

## Why the list is the hard part Flipping build runners to deny-all outbound takes an afternoon. Keeping four hundred pipelines green afterwards is the actual project, and the allow-list is where a well-intentioned control goes to die: every broken build produces a ticket, every ticket produces an entry, and within a quarter the list is the union of everywhere anyone ever went. ## The categories a real list has to carry - **Dependency sources.** Ideally exactly one host: the internal proxy or index that fronts the public ecosystems. If jobs still reach several public indexes directly, you have an allow-list of the whole internet's package hosting. - **Container and base-image pulls.** The registry the runner pulls job images and base layers from, which is often a different host from the one you publish to. - **The CI control plane itself.** Job status callbacks, log streaming, artifact upload, cache service. Forgetting these is memorable because the build appears to *work* and then hangs or fails at the very end when it tries to upload. - **Source hosts.** Clone, submodules, and any dependency declared as a revision on a source host rather than a package version. - **Identity and secret endpoints.** The OIDC token issuer, the cloud STS endpoint, the secret store. Note these are exactly what you want the untrusted install stage *not* to reach - which is the argument for a per-stage list rather than one global list. - **Service APIs used by tests and deploys.** Integration tests hitting a sandbox, the deploy step hitting a control plane. - **Telemetry and observability.** Where build metrics and logs are shipped. - **Plumbing that nobody lists until it breaks.** The DNS resolver, time sync, certificate revocation endpoints that a TLS client fetches, and keyservers used to verify package signatures. ## How you discover it without guessing Run the policy in **log-only / audit mode** first and collect observed destinations across a full cycle of pipelines, then enforce. Two cautions. First, an audit window captures what builds happened to do that week - the quarterly release job, the yearly certificate renewal path and the rarely-run migration pipeline will not appear, so keep a fast exception path for the first few months. Second, audit mode records what builds *do*, which includes destinations you would rather not bless; the list you enforce is a curated subset, not the raw capture. ## Naming destinations: hostname versus address This is the operational trap. Package indexes and artifact stores generally sit behind content delivery networks, so their addresses **rotate and are shared with unrelated tenants**. An IP or CIDR allow-list therefore either breaks on a schedule nobody controls, or gets widened to a whole provider's ranges - at which point it allows an attacker's bucket on that same provider. Address-based rules are honest only for a destination you operate and pin yourself. Hostname rules need a chokepoint that can see the name: - An **explicit forward proxy**, where the client sends the host in the connect request. Reliable, but every build tool has to honour the proxy configuration, and the ones that do not will fail in confusing ways. - **SNI-based filtering** at the network layer, which reads the name from the TLS handshake. This assumes the name is visible in the handshake and that the client is not doing anything clever to hide it. - A **TLS-terminating proxy**, which sees full URLs and payloads, at the cost of installing a trusted certificate authority into every build image and breaking any tool that pins certificates. Wildcards are the other slow leak: one entry covering an entire domain can quietly authorise user-controlled content hosted under it. ## Scoping beats length The fix for list sprawl is not discipline about additions, it is **scope**. Attach the narrow list to the stage that needs it: the install stage gets the package proxy and nothing else; the deploy stage gets the cloud control plane; the test stage gets the sandbox. Entries then get reviewed by the pipeline that owns them, and no single stage inherits the union. ## The answer that lands Name the categories, mention the ones that fail late (control plane, plumbing), say that you would audit before enforcing, and be clear that you would express the rules by hostname through a proxy because CDN-fronted package indexes make address rules either brittle or meaninglessly wide. Then say the list is per-stage, because a single global list is how default-deny becomes default-allow with extra steps.