The most damaging cloud breaches of the past five years share a common root cause, and it is not sophisticated zero-day exploits or advanced persistent threats. It is misconfiguration. Public S3 buckets exposing millions of customer records. IAM policies granting admin access to every developer. Security groups allowing unrestricted inbound access to database ports. These are not exotic attack vectors. They are configuration mistakes that persist in production because nobody is systematically checking for them.
Cloud Security Posture Management (CSPM) emerged as a category specifically to address this problem. But understanding what CSPM can and cannot do, and where it fits alongside manual cloud security assessments, is critical to building a cloud security program that actually protects your infrastructure.
The shared responsibility model: where breaches actually happen
Every major cloud provider operates under a shared responsibility model. AWS, Azure, and GCP are responsible for securing the infrastructure: the physical data centers, the hypervisors, the network fabric, and the managed service platforms. You are responsible for everything you deploy on that infrastructure: your IAM policies, your network configurations, your data encryption, your application code, and your access controls.
Almost every cloud breach exploits the customer's side of this model. Cloud providers invest billions in infrastructure security. Their side of the shared responsibility line is, for practical purposes, solid. What fails is the customer's configuration: the storage bucket someone made public for a demo and never locked down, the IAM role with wildcard permissions that was supposed to be temporary, the security group that allows SSH from 0.0.0.0/0 because a developer needed quick access during a deployment.
The shared responsibility model means that your cloud provider will not protect you from your own configuration mistakes. That is your job. CSPM tools help automate that job, but they have significant limitations that organizations need to understand.
The top cloud misconfigurations attackers exploit
Based on what we see in cloud security assessments, these are the misconfigurations that lead to the most severe outcomes.
Public storage buckets
S3 buckets, Azure Blob containers, and GCS buckets that are publicly accessible remain one of the most common and most damaging misconfigurations. Attackers actively scan for public buckets using automated tools, and the data they find, customer records, application backups, database dumps, API keys, is immediately exploitable. Cloud providers have added guardrails (AWS S3 Block Public Access, for example), but these protections must be enabled at the account or bucket level, and legacy configurations often predate them.
Overly permissive IAM policies
The principle of least privilege is the most violated security principle in cloud environments. Developers need to move fast, and writing granular IAM policies for every service and action takes time. The result is IAM policies with "Action": "*" and "Resource": "*" that grant unrestricted access to everything in the account. When an attacker compromises a single credential with this level of access, they own the entire environment.
The compounding problem: Overly permissive policies are not just a risk at the human user level. Service accounts, Lambda execution roles, EC2 instance profiles, and cross-account roles all carry IAM policies. A compromised web application running on an EC2 instance with an overpermissioned instance profile gives the attacker the same broad access as a compromised admin credential.
Unencrypted data at rest and in transit
Cloud providers offer encryption for virtually every storage and database service, but it is not always enabled by default, and many organizations have not enabled it retroactively on resources created before encryption defaults changed. Unencrypted EBS volumes, RDS instances without encryption, and S3 buckets without server-side encryption leave data exposed if an attacker gains access to the underlying storage or intercepts data in transit between services.
Exposed management ports
Security groups and network ACLs that allow inbound SSH (port 22), RDP (port 3389), or database ports (3306, 5432, 27017) from any source IP address are an open invitation. Attackers run continuous port scans across cloud IP ranges looking for exactly these exposures. Combined with weak or default credentials, an exposed management port is a direct path to compromise.
Disabled logging and monitoring
CloudTrail disabled. VPC Flow Logs not enabled. GuardDuty not activated. Access logging turned off on S3 buckets. When logging is disabled, there is no audit trail. When an incident occurs, you cannot determine what happened, when it happened, or what data was affected. This is not just a security failure; it is a compliance failure under virtually every framework that requires audit logging.
Real-world pattern: The most common cloud attack chain we see in assessments starts with an exposed service (public bucket, open management port, or leaked credential), escalates through overpermissioned IAM to broader access, and succeeds in exfiltrating data precisely because logging was disabled and nobody detected the activity. Every link in this chain is a misconfiguration, not a vulnerability in the cloud provider's infrastructure.
What CSPM tools actually do
CSPM tools connect to your cloud provider APIs and continuously scan your infrastructure configuration against security benchmarks. They check whether your actual configuration matches your desired security state. When a deviation is found, an alert is generated.
Effective CSPM covers several key areas:
- Configuration benchmarking: Comparing your settings against CIS Benchmarks, AWS Well-Architected Framework, Azure Security Benchmark, or custom organizational policies.
- Compliance mapping: Mapping configuration findings to compliance requirements (SOC 2, PCI DSS, ISO 27001, HIPAA) to identify compliance gaps.
- Drift detection: Alerting when configurations change from a known-good state, which may indicate unauthorized modifications or accidental changes during deployments.
- Multi-cloud visibility: Providing a unified view across AWS, Azure, and GCP environments so security teams do not need to context-switch between provider-native tools.
- Automated remediation: Some CSPM tools can automatically fix certain misconfigurations, like re-enabling encryption or closing overly permissive security groups, though automated remediation requires careful tuning to avoid breaking production services.
Where CSPM falls short
CSPM is an essential layer of cloud security, but it has fundamental limitations that organizations must account for.
- No exploitation context. CSPM tells you that a security group allows inbound SSH from any IP. It does not tell you whether an attacker can chain that exposure with a weak SSH key, a compromised credential, and a overpermissioned IAM role to achieve full account compromise. Understanding exploitability requires manual assessment.
- Configuration-only view. CSPM checks configuration settings but does not test whether those settings are actually enforced in practice. A network ACL might deny traffic on paper, but a misconfigured route table might bypass it entirely. Only active testing reveals whether controls work as intended.
- Alert fatigue. A typical CSPM deployment generates hundreds or thousands of findings. Without context about which findings are actually exploitable and which represent theoretical risk, security teams waste time on low-impact issues while critical chains of misconfiguration go unaddressed.
- No application-layer testing. CSPM operates at the infrastructure level. It does not test your applications, APIs, or custom code for vulnerabilities. A perfectly configured cloud environment can still host a critically vulnerable application.
CSPM vs cloud penetration testing: complementary, not competing
CSPM and cloud penetration testing answer different questions. CSPM asks: "Is our configuration correct?" Cloud penetration testing asks: "Can an attacker exploit our configuration to compromise our environment?"
| Capability | CSPM | Cloud Pentest |
|---|---|---|
| Configuration scanning | Continuous, automated | Point-in-time, manual |
| Exploitation testing | Not performed | Core capability |
| Attack chain analysis | Limited | Primary focus |
| Compliance mapping | Automated against frameworks | Validates control effectiveness |
| Coverage | Broad, all resources | Deep, focused on critical paths |
| Frequency | Continuous | Annually or semi-annually |
| False positives | High volume | Validated findings only |
The most effective cloud security programs use both. CSPM provides continuous visibility into configuration state and compliance posture. Cloud penetration testing, conducted annually or after significant infrastructure changes, validates whether the most critical CSPM findings are actually exploitable and identifies attack chains that configuration scanning alone cannot reveal.
Lorikeet Security's cloud penetration tests start at $9,500 and include infrastructure configuration review, IAM policy analysis, privilege escalation testing, network segmentation validation, and exploitation of identified misconfigurations to demonstrate real-world impact. The output prioritizes findings by actual exploitability, not theoretical risk, so your team can focus remediation effort where it matters most.
Continuous monitoring with attack surface management
Between annual cloud penetration tests, your cloud attack surface changes constantly. New services are deployed, configurations are modified during deployments, developers create temporary resources that become permanent, and third-party integrations introduce new exposure. CSPM addresses internal configuration drift, but it does not monitor your external attack surface the way an attacker would see it.
Attack surface management (ASM) fills this gap by continuously discovering and monitoring your externally visible cloud assets: public-facing services, exposed ports, DNS records, SSL certificates, and cloud resources that are reachable from the internet. When a developer accidentally exposes a staging environment or a misconfigured load balancer makes an internal service publicly accessible, ASM detects it.
Lorikeet's ASM platform starts at $29.99 per month for personal use and $299 per month for professional environments. It provides continuous external monitoring of your cloud infrastructure alongside your traditional web and network assets, alerting you to new exposures before attackers find them.
Building a cloud security program that works
A mature cloud security program layers multiple controls. No single tool or assessment covers everything. Here is the practical framework for organizations at any stage of cloud adoption.
- Implement least-privilege IAM from day one. Use service-specific policies with explicit resource ARNs. Audit IAM policies quarterly. Remove unused credentials and access keys. Enable MFA for all human users, especially those with console access.
- Enable logging everywhere. CloudTrail for API activity, VPC Flow Logs for network traffic, S3 access logging for storage, and GuardDuty or equivalent for threat detection. Centralize logs in a dedicated security account that application teams cannot modify.
- Deploy CSPM for continuous configuration monitoring. Choose a tool that supports your cloud providers, maps to your compliance frameworks, and integrates with your alerting workflows. Tune alerting thresholds to reduce noise.
- Encrypt everything. Enable encryption at rest for all storage services, databases, and EBS volumes. Enforce TLS for all data in transit. Use customer-managed keys where compliance requires it.
- Conduct annual cloud penetration testing. Validate that your configurations are not just compliant on paper but resistant to real-world attack techniques. Cloud pentests at $9,500+ provide the exploitation context that CSPM cannot.
- Monitor your external attack surface continuously. Use ASM to detect publicly exposed cloud resources, new services, and configuration changes that create external exposure between penetration test cycles.
For organizations that need comprehensive coverage, Lorikeet's Offensive Security Bundle at $37,500 per year includes recurring penetration testing, vulnerability scanning, and ASM, providing both the point-in-time depth of manual assessment and the continuous monitoring needed to catch new exposures as they appear.
Validate Your Cloud Security Posture
CSPM tells you what might be wrong. A cloud penetration test tells you what an attacker can actually exploit. Cloud assessments starting at $9,500.
