Fix cloud misconfiguration in the pull request, not the postmortem
The same handful of cloud mistakes cause most incidents, and every one of them is visible in the Terraform before it ever reaches production.
By KnightGrid Advisory
Cloud breaches are rarely a failure of the cloud provider. They are configuration — a storage bucket made public for a one-off migration, an over-broad IAM role copied from a tutorial, a security group opened to the world during a debugging session that nobody closed.
What makes these worth systematic attention is that they are all statically visible. The dangerous state exists in a text file, reviewed by a human, before it is ever applied.
The economics of when you catch it
A misconfiguration caught in a pull request costs a comment and a two-line change. The same misconfiguration caught by a posture scanner in production costs a ticket, a change window, an approval and a deployment. Caught by an attacker, it costs a disclosure.
This is why we push infrastructure-as-code scanning ahead of runtime posture management for teams that deploy through code. Runtime scanning still matters — it catches console changes and drift — but it is a second net, not the first.
Route findings to the owner, not to security
The most common reason posture management fails is that every finding lands in one security inbox, where it becomes a backlog nobody can clear. Findings should route to the team that owns the resource, in the tool they already work in, with the specific fix attached.
That requires resource ownership tagging to actually be enforced, which is unglamorous work. It is also the difference between a posture tool that reduces risk and one that produces a chart.
The five to check today
If you do nothing else this quarter, verify these:
- No storage bucket or blob container is publicly readable without a documented, reviewed reason.
- No security group or firewall rule allows 0.0.0.0/0 to an administrative port.
- Root and organisation-management accounts have hardware MFA and are not used for daily work.
- Every account and subscription ships logs to a central place the workload team cannot delete.
- No long-lived static access keys exist where a short-lived role could be used instead.