Security Group Sprawl
The accumulation of firewall and security group rules that nobody can safely remove, producing a permissive posture nobody chose.
Rules are added under pressure and removed never. Each addition is individually justified — a team needs connectivity, an incident requires a quick fix, a migration needs temporary access — and after three years the rule set permits far more than any current requirement, with no one able to say which rules are still needed.
The reason removal stalls is asymmetry of consequence: deleting a rule risks breaking production, while leaving it risks nothing visible. So the rational individual choice is always to leave it, and the aggregate outcome is a permissive network.
The practices that reverse it. Flow logging analysed against rules, so a rule with no matching traffic in ninety days is evidenced as removable rather than debated. Rules as code with review and ownership metadata, so every rule records who asked for it and why, which is the single most useful field and is almost never captured. Expiry by default for anything created for a migration or incident. And reference-based rules — allowing a source security group or workload identity rather than an IP range — which stay meaningful as infrastructure changes, unlike CIDR blocks that silently start covering different machines.
The architectural point underneath: a network posture maintained rule by rule tends towards permissiveness, so estates that want a tight posture achieve it by generating rules from service dependency declarations rather than by curating them.