5 Signs Your AWS Security Posture Needs a Review

Security debt in AWS accounts doesn't usually announce itself. It accumulates quietly through normal, reasonable-seeming decisions made under deadline pressure — until something forces the issue. Here are the five signs we see most often before that happens.

1. GuardDuty is on, but nobody's looked at a finding in months

Enabling GuardDuty satisfies a checkbox. It does nothing for your actual security posture if findings pile up unreviewed in a console nobody opens. If you can't answer "what did GuardDuty flag last week," that's the first sign worth acting on.

2. IAM policies use wildcards because scoping them down "felt risky"

"Action": "*" and "Resource": "*" policies are almost always a shortcut taken under time pressure, with the intention of "tightening it later." Later rarely comes, because tightening a policy that's already in production feels riskier than leaving it broad — even though the broad policy is the actual risk. This is exactly the kind of thing that's cheap to fix proactively and expensive to untangle after an incident.

3. Long-lived access keys exist instead of roles

If there are IAM users with access keys that have been active for over 90 days, especially ones used by automation or CI/CD pipelines, that's a standing liability — a leaked key doesn't expire on its own, and rotating keys that are deeply embedded in scripts and pipelines is exactly the kind of unglamorous work that keeps getting deprioritized until it's forced.

4. Nobody can produce a clean access review on request

If a client questionnaire, an insurance renewal, or a compliance audit asked "who has access to production, and why" tomorrow, could you answer confidently in an hour? If the honest answer involves several people cross-referencing spreadsheets and Slack history, that's a sign the access model has drifted further than anyone's tracking.

5. No Web Application Firewall in front of anything public-facing

Public-facing applications without a WAF are relying entirely on application-layer code being bug-free against common attack patterns — SQL injection, cross-site scripting, and the like. A WAF isn't a replacement for secure code, but it's a cheap, fast layer of protection that catches a meaningful share of automated attack traffic before it ever reaches the application.

The short version

If more than one of these five signs sounds familiar, it's worth a focused review before an audit, a client, or an incident forces the timeline. None of these are difficult to fix individually — they're just easy to keep deprioritizing until something makes that impossible.