Egress Filtering

Inbound filtering is universal; outbound is frequently left open, on the reasoning that traffic originating inside is trusted. That reasoning fails against exactly the scenarios that matter, because an attacker who has achieved code execution needs an outbound path to be useful.

What restricting egress prevents: exfiltration of data to attacker infrastructure, command and control callbacks, SSRF reaching internal services or the metadata endpoint, and dependency confusion attacks that phone home during a build.

The implementation problem is that applications legitimately call many external services, and an allow-list must be complete or things break. The workable approach mirrors microsegmentation: observe first with flow logs, build the list from what actually communicates, then enforce — with DNS-based allow-listing at an egress proxy for services whose addresses change.

Two details worth getting right. Private endpoints for cloud services remove a large share of legitimate egress from the internet path entirely, which shrinks the list and reduces cost. And the build environment deserves stricter egress control than production, because it has credentials, network access and executes third-party code by design.

The general point: it is a control that limits the impact of bugs you have not found yet, which makes it worth more than most controls that address specific known issues.