Egress Filtering
Restricting what a workload may connect out to, which is the control that turns a compromise into a contained one.
Inbound filtering receives nearly all the attention, and outbound is where the damage is done. An attacker who has compromised a workload needs to reach a command-and-control endpoint and to exfiltrate data, and in the default cloud configuration — unrestricted outbound to the internet — both are trivial.
Egress filtering constrains it: workloads may reach a defined set of destinations and nothing else. This blocks command and control, blocks exfiltration to arbitrary endpoints, and additionally stops a compromised build step from pulling a malicious payload.
The reason it is not universal is that it is genuinely awkward. Modern applications reach many external services, dependency resolution pulls from registries, and cloud service endpoints are numerous and change. Maintaining an allowlist is real work, and a broken egress rule presents as a mysterious application failure rather than as a security event, which makes teams resistant.
What makes it tractable: private endpoints for cloud services so that traffic never traverses the internet, an internal proxy or artifact mirror as the single permitted path for package downloads, DNS-based policy rather than IP for services with changing addresses, and — importantly for adoption — running in log-only mode first to discover the real destination set before enforcing.
The tier where it is non-negotiable regardless of effort: anything handling regulated data, and CI runners, which execute untrusted third-party code by design.