Most cloud breaches are not elegant. There is no novel exploit, no nation-state zero-day, no mystery attacker who outsmarted your team. The attacker found an S3 bucket with public read access or an IAM role with wildcard permissions and walked in through the front door.
The gap is not technical sophistication — it is timing. Misconfigurations often exist for days, weeks, or months before anyone notices. The typical discovery event is a vendor notification, a bug bounty report, or a breach disclosure — not a proactive scan. By that point, the damage is done.
This article covers the specific misconfiguration types that lead to real-world breaches, why they persist even in mature teams, and how to build a detection workflow that catches them before they become incidents.
The Most Common Misconfigurations That Lead to Breaches
AWS Misconfigurations
S3 bucket with public read/write ACL. The most common source of cloud data exposure incidents. An S3 bucket set to public-read makes every object accessible to anyone with the URL. A bucket set to public-read-write allows unauthenticated uploads — which attackers use to host phishing pages or malware from your domain. Most exposures happen because a developer set a bucket public for a quick test and never reverted it.
IAM role with wildcard (*) permissions. An IAM policy with "Action": "*" and "Resource": "*" grants full administrative control to whatever entity assumes that role. This is applied during initial setup for convenience and never tightened. If an attacker gains access to any service using that role — a Lambda function, an EC2 instance, a compromised CI/CD pipeline — they own your entire account.
Security group with 0.0.0.0/0 on port 22 or 3389. SSH and RDP open to the public internet invite brute-force and credential-stuffing attacks around the clock. Automated scanners probe the entire IPv4 address space continuously. An exposed RDP endpoint is typically scanned within minutes of provisioning.
RDS instance with a publicly accessible endpoint and no VPC restriction. A database should never be reachable from the public internet. When PubliclyAccessible is true and no VPC security group restricts inbound traffic, your database accepts connections from anywhere. Combined with a weak or default password, this is a complete data breach waiting to happen.
Lambda environment variables containing API keys. Lambda functions commonly store secrets as environment variables — database credentials, API tokens, signing keys. These are visible in plaintext in the AWS console, in CloudFormation exports, and in logs that print the environment. Any user or role with lambda:GetFunctionConfiguration can read them. Secrets should live in AWS Secrets Manager or Parameter Store.
CloudTrail disabled. CloudTrail is AWS's audit log for API calls. Without it, there is no record of who did what and when — no incident investigation trail, no detection of unusual API activity, no compliance evidence. Disabling CloudTrail is a common early step in an active attack sequence.
GCP Misconfigurations
Cloud Storage bucket with allUsers read access. The GCP equivalent of a public S3 bucket. Setting a bucket's IAM policy to include allUsers with roles/storage.objectViewer makes every object publicly accessible. Easy to set by accident through the GCP console and easy to miss across a large project.
Service account with Owner role at project level. Granting roles/owner at the project level gives a service account full control over every resource in the project. This is common in early-stage infrastructure where granular IAM felt like overhead. A compromised workload under this service account is a full project takeover.
Compute instance with serial port enabled. Enabling the serial port on a Compute Engine instance allows interactive access through GCP's infrastructure, bypassing normal network controls. Designed for emergency diagnostics — it should never be left enabled in production.
GKE cluster with legacy ABAC enabled or a public master endpoint. Legacy ABAC in GKE uses a static permissions file that does not integrate with modern Kubernetes RBAC. A GKE cluster with a public API server endpoint and weak authentication is accessible to anyone with valid credentials — and sometimes without them if anonymous access is misconfigured.
Kubernetes Misconfigurations
Container running as root in production. A container running as UID 0 has root-level access inside the container. If the container is compromised — through a dependency vulnerability, code injection, or a deserialization flaw — the attacker has root. Combined with a missing seccomp/AppArmor profile, this can mean a container escape to the host.
No resource limits set (CPU/memory). Containers without resource limits can consume unlimited node resources. A runaway process can starve other workloads — and an attacker who can execute code in a container can intentionally exhaust node resources to disrupt adjacent services.
Secrets stored as plain environment variables instead of Kubernetes Secrets. Hardcoding secrets in a pod spec or Deployment manifest stores them in plaintext in etcd and potentially in version control. Kubernetes Secrets are not encrypted by default either, but they enable RBAC-based access control and integrate with external secret stores like Vault or AWS Secrets Manager.
ClusterRoleBinding giving a service account cluster-admin. Binding cluster-admin to a service account gives it full read/write access to every resource in every namespace. Any workload compromise under that service account becomes a full cluster takeover.
Why Misconfigurations Slip Through
Infrastructure drift is the primary reason. A configuration correct at deploy time becomes dangerous after a single change: a developer opens port 22 "temporarily" to debug a connectivity issue, a rotation policy lapses and an old IAM role accumulates extra permissions, a new team member provisions a test environment with overly broad access and forgets to tear it down.
Human error in IAM is structurally guaranteed in complex accounts. AWS IAM policies involve condition keys, resource ARNs, permission boundaries, service control policies, and role chaining. Getting this right across dozens of roles and hundreds of policies is genuinely difficult.
Security reviews tend to happen at project kickoff and at compliance audit time — not in the space between, where most drift occurs. Changes made through the console or CLI, outside of Terraform or CloudFormation, are invisible to code review and version control. These out-of-band changes are the primary source of configuration drift.
Detection Approaches Compared
| Approach | Setup effort | Cost | Coverage | Plain-English output | Agent integration | Local/private results |
|---|---|---|---|---|---|---|
| Manual audit | None | Free | Limited, misses drift | No | No | Yes |
| AWS Config + Security Hub | Medium | Usage-based | AWS only | No — rule-based findings | No | No |
| GCP Security Command Center | Medium | Included / premium tier | GCP only | Partial | No | No |
| CSPM tools (Wiz, Prisma, Lacework) | High | $$ | Multi-cloud | Partial | Limited | No |
| Clanker Cloud | Low | Free–$20/mo | Multi-cloud + K8s | Yes | Yes (MCP) | Yes |
Manual audit works for a solo founder reviewing a single account, but does not scale and misses drift by definition.
Cloud-native tools (AWS Config, Security Hub, GCP Security Command Center) are powerful but require significant setup. AWS Security Hub has hundreds of controls; mapping them to your risk surface and building response workflows takes real engineering time. The output is rule-based — finding IDs and benchmark references, not plain-English explanations.
CSPM tools like Wiz, Prisma Cloud, and Lacework are enterprise-grade and priced accordingly. For startups and small teams, setup complexity and cost are often impractical. These tools also send your cloud configuration data to a third-party service.
Clanker Cloud approaches this differently. Rather than a dedicated CSPM platform, it is an AI workspace for infrastructure that includes security scanning as a built-in capability. Connect your cloud providers, ask it to scan for misconfigurations, and receive a plain-English report ranked by severity. No rules to write, no dashboards to configure. For teams that want AI-assisted DevOps workflows, it integrates directly into the tools you are already using.
How Clanker Cloud Detects Misconfigurations
Clanker Cloud connects to AWS, GCP, Azure, Kubernetes, Cloudflare, Hetzner, DigitalOcean, and GitHub. In security scanning mode, it reads the current state of your connected infrastructure and checks it against known misconfiguration patterns.
The interaction is direct. Ask: "Scan my infrastructure for security misconfigurations." Clanker Cloud reads your cloud state — IAM policies, security groups, storage bucket permissions, cluster configurations, secret handling patterns — and returns a prioritized report in plain English.
A finding looks like: "Your S3 bucket user-uploads-prod has public-read ACL enabled. Any object in this bucket is accessible to anyone with the URL. Recommended fix: remove the public ACL and enable Block Public Access at the bucket level."
Compare that to a Security Hub finding: [S3.2] S3 buckets should prohibit public read access. Both identify the same problem — but one requires you to decode the rule framework, the other tells you what is wrong and what to fix.
Clanker Cloud is local-first. Your scan results — IAM roles, security group rules, bucket permissions, cluster configurations — are processed on your machine and never sent to a third-party cloud. Clanker Cloud supports BYOK model configuration: Gemma 4 via Ollama, Claude, Codex, or Hermes. You choose the model; the analysis runs where you run it.
Automated Detection with AI Agents
A one-time scan beats no scan. A continuous cadence beats one-time.
Clanker Cloud supports AI agent workflows through its MCP integration. OpenClaw and Claude Code can trigger security scans programmatically, enabling two useful patterns.
Scheduled scanning with OpenClaw. Using a HEARTBEAT.md schedule file, configure OpenClaw to run a security scan via Clanker Cloud MCP on a daily or weekly cadence. The agent runs the scan and surfaces new or changed misconfigurations since the last run — catching drift without requiring anyone to remember to initiate it.
Pre-change scanning with Claude Code. Before any infrastructure change in a Claude Code maker mode session, the agent triggers a Clanker Cloud scan to establish a baseline. After the change is applied, a second scan diffs the findings. Any new misconfiguration introduced by the change is immediately visible before it reaches production.
Findings from agent-triggered scans feed back into the agent's context, so it can incorporate security posture into its reasoning when generating Terraform, Helm charts, or CloudFormation templates.
Remediation Workflow
Detection is the first half. The second half is what you do with a finding.
When Clanker Cloud surfaces a misconfiguration, it does not automatically fix it. It follows a read-first, act-second model: you see the finding, you see the recommended remediation, you review and approve. The agent generates a remediation plan — the specific policy change, security group rule update, or configuration fix — and presents it before anything is modified.
This is deliberate. Automated remediation of IAM policies and network rules is high-stakes. A bad "fix" to a security group rule can lock you out of your own instances. A modification to an IAM role used by a production workload can break that workload.
The workflow: finding surfaces → remediation plan generated → you review → you approve → agent applies the change → post-remediation scan confirms resolution. This loop closes the detection-to-fix cycle without removing the human from the decision.
FAQ
What are the most common cloud misconfigurations that lead to breaches?
The most frequently exploited misconfigurations are publicly accessible S3 buckets or GCP Cloud Storage buckets, IAM roles or service accounts with overly broad permissions (wildcard or Owner-level), security groups or firewall rules with ports 22 or 3389 open to 0.0.0.0/0, publicly accessible database instances, and secrets stored in environment variables or version control rather than a secrets manager. These account for the majority of cloud breach disclosures.
How do I scan AWS for security misconfigurations?
AWS Config and Security Hub provide native scanning but require setup and produce rule-based findings that take time to interpret. AWS Trusted Advisor covers a subset of common misconfigurations for free-tier accounts. CSPM tools like Wiz or Prisma Cloud provide comprehensive coverage at enterprise pricing. Clanker Cloud's security scanning mode connects to your AWS account and returns a plain-English prioritized findings report with no rule configuration required — start a scan at clankercloud.ai/account.
What is a CSPM tool and do I need one as a startup?
A Cloud Security Posture Management (CSPM) tool continuously monitors your cloud environment for policy violations, compliance gaps, and security misconfigurations. Enterprise CSPM platforms like Wiz, Prisma Cloud, and Lacework are comprehensive but carry significant cost and setup overhead — typically not practical for teams under 50 engineers or pre-Series B. For smaller teams, cloud-native tools (AWS Security Hub, GCP SCC) combined with an AI workspace like Clanker Cloud covers most of the same ground at a fraction of the cost. See our FAQ page for a longer comparison.
How often should I scan my cloud infrastructure for misconfigurations?
At minimum, once per week. Daily is better in active development environments where infrastructure changes frequently. The highest-value moments to scan are immediately after any infrastructure change and after any team membership change — new access grants are a common source of over-permissioning. With Clanker Cloud's MCP agent integration, you can automate daily scans without any manual steps.
Start Scanning Your Infrastructure
Misconfiguration breaches are preventable. The detection gap — between when a misconfiguration is introduced and when it is discovered — is what makes them dangerous. Closing that gap requires systematic, recurring scanning.
Clanker Cloud's security scanning mode connects to your cloud providers, checks your current configuration state against known misconfiguration patterns, and returns a prioritized plain-English findings report. No rules to write, no dashboards to configure. Local-first: your infrastructure data stays on your machine.
Create a free account to run your first scan, or read the documentation to see how security scanning integrates with AI agent workflows.
Run a local security and drift review
Use Clanker Cloud to inspect live cloud and Kubernetes state with local credentials, then review findings before any infrastructure change runs.