Why cloud-native CSPM finds 3x more exploitable misconfigurations than general compliance frameworks
Julian ThorneApril 29, 2026
TL;DR
In our assessments of 47 mid-market cloud environments between 2023 and 2025, cloud-native CSPM tools caught 3.1x more exploitable misconfigurations than general-framework-based approaches — but in 61% of those engagements, clients had both and neither team knew what the other tool was flagging.
The myth that broad security frameworks provide a compliance floor that cloud-native tools build on top of is backwards. General frameworks frequently produce false confidence: organizations pass framework assessments on documentation while running actively exploitable Kubernetes API servers.
The real CSPM gap is not between cloud-native and general tools. It is between what tools find and what teams act on. Average time from CSPM alert to remediation in the environments we assessed: 23 days. Average attacker dwell time after initial cloud access: 18 days.
Container escape vulnerabilities and overpermissioned workload identities are the two finding classes most likely to be present in organizations that believe they are cloud-compliant. Both are invisible to general framework audits.
There is a genuine unresolved argument in the practitioner community about whether CSPM tools create alert fatigue that is worse than the risk they mitigate. The data do not clearly resolve this. Organizations with dedicated cloud security engineering handle it. Organizations relying on generalist IT staff do not.
One concrete finding most clients find surprising: automated CSPM compliance scores are almost always lower than consultant-produced scores for the same environment, not because the tool is more thorough, but because consultants anchor on controls they can document and ignore implementation gaps they cannot easily evidence.
The audit passed. Then the pen tester found the open Kubernetes API server.
A 90-person fintech in Amsterdam. Two compliance frameworks on the wall: SOC 2 Type II, ISO 27001. A QSA had signed off six weeks earlier. The CISO's exact words when we started the engagement: 'We are probably the most assessed company our size in the Netherlands.' Their AWS environment had been CSPM-scanned by a general-framework-aligned tool that produced a 94% compliance score. They were proud of it. During the external attack surface assessment, before we had touched their internal environment, we found a Kubernetes API server with anonymous authentication enabled, exposed to the internet on a non-standard port. Unauthenticated. Full cluster-admin. The API server had been in that state for four months.
The general compliance tool had never looked at it. The tool's control library mapped to ISO 27001 Annex A and CIS Controls. It had no coverage for Kubernetes API server authentication defaults. The tool reported 94% compliance. The Kubernetes API server was not in scope for the ISO audit because the auditor had asked about 'server hardening procedures' and the client had produced a documented standard. The document was accurate. The implementation was not. This is not an isolated case. It is the modal outcome in our cloud assessments.
What the numbers actually look like
61%
Percentage of mid-market organizations in Vulnox cloud assessments (2023-2025, n=47) that had both a general-framework CSPM tool and a cloud-native tool deployed simultaneously, where neither security team had a clear owner for cross-tool alert triage. Both tools were running. Nobody was accountable for the overlap.
3.1x
Cloud-native CSPM tools found exploitable misconfigurations at 3.1x the rate of general-framework tools in the same environments. The general tools found more total findings. The cloud-native tools found more findings that an attacker could use within 48 hours. (Vulnox assessment data, 2023-2025)
23 days
Median time from CSPM alert generation to confirmed remediation in the environments we assessed. Compared to a median attacker cloud dwell time of 18 days reported by CrowdStrike Global Threat Report 2024. The math is not in defenders' favor.
78%
Percentage of cloud security incidents in 2024 that originated from misconfiguration rather than vulnerability exploitation. (Wiz State of Cloud Security 2024) This is why CSPM matters more than most organizations treat it.
4 months
How long the exposed Kubernetes API server in the Amsterdam fintech case had been accessible before we found it. It was present during their ISO 27001 surveillance audit. The auditor did not look at it.
The myth: general frameworks provide a security baseline that cloud tools build on top of
The myth
The reality
What the data showed — and what clients did not expect
Assessment base: 47 mid-market cloud environments assessed 2023-2025, primarily AWS with multi-cloud presence in 31 cases. Company sizes ranging from 40 to 800 employees. Industries: fintech (18), SaaS (14), logistics/OT (8), healthcare (7).
Shadow cloud resources are present in 71% of mid-market environments — and general CSPM tools do not see them
In 33 of our 47 assessments, we found AWS accounts, GCP projects, or Azure subscriptions that were not enrolled in the organization's primary CSPM tool. These were not rogue accounts. They were legitimate accounts created for dev/test, PoC work, or acquisitions that never got folded into the security program. General-framework tools were deployed on the 'production' account and produced clean scores. The shadow accounts contained production data in 14 of those 33 cases.
The 94% compliance score means 94% of the environment you have decided to look at is compliant. It says nothing about the environment you have not decided to look at. Cloud-native CSPM tools that integrate with cloud provider organization APIs surface these shadow accounts automatically. General-framework tools that require manual scope definition do not. This is not a technical limitation — it is a design philosophy difference.
Workload identity permissions are the most underassessed attack surface in cloud environments
IAM user permissions get reviewed. IAM role permissions attached to EC2 instances, Lambda functions, and Kubernetes service accounts mostly do not. In 42 of our 47 assessments, we found at least one workload with an attached policy that would allow lateral movement to a different AWS account or privilege escalation to AdministratorAccess. Most of these workloads had been running for more than a year. The permissions had been granted for a specific task, never revoked.
General compliance frameworks ask about 'access control' and 'least privilege.' They produce documentation reviews of IAM policies. What they do not produce is a graph of what each workload can actually do if compromised. Cloud-native CSPM tools that build IAM permission graphs find a median of 6 lateral movement paths per environment. General-framework tools find 0, because they do not build the graph.
Automated CSPM scores are consistently lower than consultant-produced scores for identical environments
This surprised clients every time. They expected the automated tool to be more demanding. It was not. The automated tool flags every deviation from a benchmark with equal weight, producing a long list of medium-severity findings. Consultants anchor on controls they can document satisfying and skip implementation details they cannot easily evidence. A consultant sees a documented encryption policy and marks the control green. The CSPM tool scans S3 buckets and finds unencrypted objects. Both are correct. They are answering different questions.
When clients tell us their CSPM score is 87%, the relevant question is not 'is 87% good?' It is 'what is in the remaining 13%, and can an attacker use it?' In our experience, the 13% contains at least one critical finding in 67% of cases.
The finding that looks safe and isn't: high CSPM scores in complex environments
Common belief
Organizations assume a high automated CSPM compliance score — say, above 90% — indicates that their cloud environment is well-secured. The logic is intuitive: more checks passing means more security. Mature organizations investing in cloud-native CSPM tooling treat their compliance dashboard as a health indicator.
What we found
In our 12 largest engagements (organizations with more than 200 EC2 instances), the median CSPM score was 91%. These same environments had a median of 3 critical misconfigurations that an attacker could use for initial access or privilege escalation. The high score was produced by the large number of correctly configured routine resources, not by the absence of critical gaps. The two organizations in this cohort that had experienced a cloud security incident in the prior 12 months both had CSPM scores above 89% at the time of the incident.
Complex environments with many accounts, many workloads, and many services have more total controls checked and more controls passing in absolute terms. The score is a ratio. A 92% score in a 500-control environment means 40 failing controls. A 92% score in a 50-control environment means 4 failing controls. The environments where a high score is most misleading are exactly the large, complex, multi-account environments where a breach would be most damaging. The CSPM score is a metric that rewards scale. Large environments have many passing controls by default — most of their S3 buckets are correctly configured, most of their IAM users have MFA. The few that don't are the ones that matter.
Why cloud-native CSPM and general frameworks find different things — the actual technical reason
General compliance frameworks produce control libraries mapped to human-auditable concepts: 'data classification policies exist,' 'access reviews are conducted quarterly,' 'incident response procedures are documented.' These controls were designed to be verifiable by a human reviewer with access to documentation and interview responses. They map cleanly to an audit checklist. Cloud-native CSPM tools work differently. They use cloud provider APIs to enumerate the actual current state of every resource — every security group rule, every IAM policy, every S3 bucket ACL, every Kubernetes admission controller configuration — and compare it against a continuously updated benchmark. They do not care what your policy document says. They care what your environment is doing right now. The technical divergence is most acute in four areas: container security, serverless function permissions, service mesh configurations, and cross-account trust relationships. None of these map cleanly to general framework controls because general frameworks were written before these abstractions existed. ISO 27001 was first published in 2005. Kubernetes was released in 2014. The control library is approximately a decade behind the attack surface.
Example
Take a concrete case: a Lambda function with an overpermissioned execution role. The function was written to access one specific DynamoDB table. The developer attached the AWS managed policy 'AmazonDynamoDBFullAccess' because it was the quickest path to getting the function working. The policy grants access to every DynamoDB table in the account, plus additional permissions for DynamoDB Streams, DynamoDB Accelerator, and DynamoDB global table management. A general compliance framework audit asks: 'Do you implement least privilege access?' The client answers yes, points to their IAM governance policy document, and the control passes. A cloud-native CSPM tool queries the Lambda execution role via the IAM API, evaluates the policy against the principle of least privilege, and flags it as a critical misconfiguration with a suggested remediation. The general audit produces a green check. The CSPM tool produces an actionable finding. Both are technically doing what they were designed to do.
The mechanism behind this is the distinction between prescriptive and descriptive controls. Prescriptive controls tell you what process to follow. Descriptive controls tell you what your environment currently is. General frameworks are prescriptive — they assess process. Cloud-native CSPM is descriptive — it assesses state. You cannot substitute one for the other. An organization that relies only on prescriptive controls will pass audits and get breached. An organization that relies only on descriptive controls will know their current state but may lack the governance processes to fix it systematically.
What clients say before the assessment — and what is actually happening
'We have continuous monitoring. Our CSPM tool sends alerts in real time.'
Root cause:Continuous monitoring and continuous remediation are different things. Across our assessments, organizations with 'real-time alerting' had median alert-to-remediation times of 23 days. The alerts were being received. They were going into a Slack channel that 14 people were in, nobody owned, and which had 340 unread messages. Continuous monitoring without a defined ownership and SLA structure produces a queue of unactioned findings, not security.
'We already did a cloud security assessment last year.'
Root cause:A point-in-time assessment documents the state of an environment at a specific moment. Cloud environments at mid-market companies add an average of 23 new resources per week (Vulnox assessment data, 2023-2025). An assessment 12 months ago documented an environment that no longer exists. The relevant question is not 'when did you last assess?' but 'what is the state of your environment right now, and how quickly do you know when it changes?'
'Our developers are security-aware. We have mandatory security training.'
Root cause:Security training reduces the frequency of specific known-bad behaviors. It does not prevent misconfiguration. The most common source of cloud misconfigurations in our assessments is not ignorance — it is time pressure. A developer opens a security group to debug a production issue, intending to close it after. They fix the issue, forget to close the group, and it stays open for six months. No amount of training prevents this. Automated drift detection does.
'We use infrastructure as code, so our configuration is always in a known state.'
Root cause:IaC describes the desired state. It does not guarantee that the running state matches it. In 29 of our assessments where clients claimed full IaC coverage, we found an average of 14 manually created resources per account that were not tracked in any IaC repository. These were created by developers for debugging, testing, or emergency response and never cleaned up. The IaC was accurate for its scope. Its scope did not cover everything that existed.
General framework tools vs cloud-native CSPM: what actually differs
General framework-aligned CSPM (examples: Tenable.io, Qualys, Rapid7)
Control libraries map to ISO 27001, NIST CSF, CIS Controls. Coverage is broad across the security program. Cloud-specific coverage relies on benchmarks that update slower than cloud provider API changes. Produces compliance reports that map directly to audit requirements. Does not build resource graphs or model blast radius.
Strong for organizations that need to demonstrate compliance to auditors, regulators, or enterprise customers. Produces findings that map to framework controls, which is what compliance teams and procurement questionnaires ask for. Produces a false sense of security if treated as a security tool rather than a compliance documentation tool.
Cloud-native CSPM (examples: Wiz, Lacework, Orca Security, Prisma Cloud)
Built on continuous cloud API enumeration. Coverage is deep within cloud environments — IAM graphs, workload permissions, container configurations, network exposure analysis. Does not map natively to audit frameworks without additional configuration. Produces findings that require cloud engineering knowledge to triage and remediate.
Strong for organizations that want to know what an attacker can actually do in their environment. The alert volume is higher and the findings require more technical judgment to prioritize. Organizations without dedicated cloud security engineers or a strong DevSecOps function will drown in findings and remediate nothing.
Open-source cloud security tooling (examples: ScoutSuite, CloudSploit, Prowler)
Free to run, community-maintained benchmark coverage, no ongoing licensing cost. Does not provide continuous monitoring without significant engineering investment to build pipelines. Finding quality varies by cloud provider — AWS coverage is strong, Azure and GCP coverage is thinner.
Appropriate for organizations with strong security engineering resources and low budgets. Not appropriate as a primary security control in environments with rapid change rates. We have seen organizations use Prowler as their primary CSPM and run it quarterly. That is approximately the same security value as doing nothing.
The four cloud attack surfaces that both tool categories mostly miss
Cross-account trust relationships
AWS allows accounts to trust each other via IAM role assumption. In multi-account environments, this creates an implicit graph of privilege escalation paths that crosses account boundaries. A compromised developer account in a sandbox environment can, through a chain of trusted role assumptions, reach production data. Both general-framework tools and most cloud-native CSPM tools assess accounts in isolation. They flag overpermissioned roles within an account. They do not model the cross-account graph. In our assessments, we found viable cross-account privilege escalation paths in 31 of our 47 environments. Wiz is the only commercial CSPM tool we have evaluated that models this graph natively.
Third-party SaaS integrations as cloud attack vectors
Organizations integrate Salesforce, Jira, GitHub, Slack, and dozens of other SaaS tools with their cloud environments, granting OAuth scopes or IAM permissions to external services. These integrations are invisible to cloud CSPM tools because they live in the SaaS layer, not the IaaS layer. A compromised Jira instance with an AWS integration that has S3 write permissions is an attack path. Neither general-framework tools nor cloud-native CSPM tools model it. This is a blind spot that will produce a named incident within the next 24 months.
CI/CD pipeline permissions
GitHub Actions workflows, GitLab CI pipelines, and CircleCI jobs run with AWS credentials that are often scoped to allow deployment to production. The credentials are stored as secrets in the CI/CD platform. The CI/CD platform is a third-party SaaS service outside the AWS trust boundary. Compromise of the CI/CD platform gives an attacker AWS credentials scoped for production deployment. In 19 of our 47 assessments, CI/CD credentials had more AWS permissions than the principle of least privilege would justify for their stated purpose.
Data exfiltration paths via legitimate AWS services
Attackers with S3 read access can exfiltrate data via S3 replication to an attacker-controlled bucket. Attackers with EC2 access can exfiltrate via DNS tunneling using Route 53. These are legitimate AWS services used for exfiltration, which means they do not trigger misconfiguration alerts. Detection requires behavioral analysis of API call patterns, not configuration assessment. Neither general-framework CSPM nor cloud-native CSPM addresses this well. It requires separate cloud detection and response tooling.
Two predictions worth fact-checking in three years
By 2027, SaaS-to-cloud attack paths will account for more than 20% of confirmed cloud breaches in mid-market organizations, and the incident will be attributed to 'cloud misconfiguration' rather than 'third-party compromise,' obscuring the actual attack vector.
The integration density between SaaS platforms and cloud environments is increasing faster than security tooling can model it. CSPM tools that assess cloud-native configurations have no visibility into OAuth grant scopes, SaaS API key permissions, or the security posture of the SaaS platforms themselves. The observable signal that this is arriving: insurance companies will begin requiring SaaS security assessments as a condition of cloud security coverage within 18 months.
Confidence: highIf by Q1 2027, major cloud CSPs have released native tooling to model SaaS-to-cloud permission graphs, and the breach rate via this vector has not increased, the prediction is wrong.Cloud-native CSPM tools will produce a class of organizations in the next 18 months that are technically over-alerted and practically under-secured — organizations where CSPM alert fatigue has led teams to suppress or deprioritize entire finding categories, including critical ones.
The trend is already visible in our current assessments. Organizations with mature cloud-native CSPM deployments have higher alert volumes than organizations with general-framework tools. In 8 of our most recent 15 assessments, we found suppression rules that had been applied to entire finding categories — including categories that contained exploitable misconfigurations. The suppression rules were created by engineers who were drowning in alerts. The observable signal: CSPM vendors will begin releasing 'alert fatigue' features — noise reduction, automatic triage, risk-prioritization — as core product differentiators rather than as optional add-ons.
Confidence: highIf alert-to-remediation times in cloud environments decrease below 7 days at industry median by 2027, the fatigue problem has been solved and this prediction is wrong.
My opinion: the CSPM tool selection debate is the wrong conversation
Organizations spend significant time and money evaluating cloud-native CSPM tools against each other, and against general-framework tools. Wiz vs Orca vs Prisma Cloud vs Lacework. The product comparisons are real. The differences matter at the margin. But in the majority of the mid-market environments I have assessed, the tool was not the problem. The problem was that nobody owned the alerts. A Wiz deployment with 800 unacknowledged findings and no clear remediation SLA does less security work than a Prowler scan that runs weekly and produces a 10-item report that a cloud engineer actually reviews. The conversation that needs to happen before any tool selection is: who is responsible for cloud security findings, what is the SLA for critical findings, and how will we know when something is being remediated? Organizations that cannot answer those three questions will not get better security outcomes from a more expensive CSPM tool.
Counterargument
The counterargument from practitioners I respect is that tool selection determines what you can see, and you cannot remediate what you cannot find. A general-framework tool will never find an overpermissioned Kubernetes service account because it does not know the concept exists. That is a real limitation. The tool ceiling matters. My position holds because in practice, the organizations that are breached via cloud misconfigurations are not breached because their tool could not find the finding — they are breached because the finding was in the queue and nobody acted on it. Tool capability is a necessary condition for good cloud security outcomes. It is not a sufficient one.
One thing to do this week
Pull your CSPM tool's alert queue right now — not the dashboard score, the actual queue. Sort by critical severity. Look at the oldest unacknowledged critical finding. Check when it was created. If it is more than 14 days old, you have a process problem that no tool upgrade will fix. Before evaluating a new CSPM tool, before scheduling a compliance assessment, go find who owns that finding and why it has not been remediated. The answer will tell you more about your cloud security posture than any compliance score.
Further Reading
Gap Analysis
framework gap analysisCIS
CIS compliance questionnaireNIST Cybersecurity Framework 2.0
NIST Cybersecurity FrameworkCIS Controls Framework
CIS Controls FrameworkCybersecurity Gap Assessments
gap assessment guide
Frequently Asked Questions
Why does my cloud environment have exploitable misconfigurations even though our CSPM compliance score is above 90%?
High CSPM scores in complex environments are misleading because the score is a ratio. A 92% score in a 500-control environment means 40 failing controls — enough to contain multiple critical misconfigurations. In Vulnox assessments, environments with scores above 90% still had a median of 3 exploitable misconfigurations. The score rewards the large volume of routine resources that are correctly configured, not the absence of critical gaps. Sort by severity and look at your oldest unacknowledged critical finding — that is your real security posture.
What is the difference between cloud-native CSPM and general framework-based cloud security tools?
General framework tools produce controls mapped to ISO 27001, NIST CSF, or CIS Controls — designed for human-auditable compliance documentation. Cloud-native CSPM tools use cloud provider APIs to enumerate actual current resource state: IAM policies, security group rules, S3 bucket ACLs, Kubernetes configurations. The key difference is prescriptive vs descriptive. General tools assess whether you have documented processes. Cloud-native tools assess whether your environment is exploitable right now. In 47 Vulnox assessments, cloud-native tools found exploitable misconfigurations at 3.1x the rate of general-framework tools in the same environments.
How long does it take for cloud environments to drift out of compliance after a clean audit?
In 38 of 47 Vulnox cloud assessments, critical misconfigurations post-dated the most recent compliance audit by fewer than 90 days. Cloud environments at mid-market companies add an average of 23 new resources per week. A point-in-time assessment documents an environment that no longer exists 30 days later. The only meaningful answer is continuous assessment with automated drift detection — not scheduled audits.
What cloud attack surfaces do CSPM tools commonly miss?
Four categories consistently appear in our assessments: cross-account trust relationships (most tools assess accounts in isolation and miss lateral movement paths that cross accounts); third-party SaaS integrations with AWS permissions (invisible to cloud CSPM because they exist at the SaaS layer); CI/CD pipeline credentials (GitHub Actions and similar tools hold AWS deployment credentials that are outside the AWS trust boundary); and data exfiltration via legitimate services like S3 replication to attacker-controlled buckets (requires behavioral detection, not configuration assessment). Of these, cross-account trust paths were present in 31 of 47 Vulnox assessments.
Should I use infrastructure as code to maintain cloud compliance?
IaC describes desired state — it does not guarantee that running state matches it. In 29 Vulnox assessments where clients claimed full IaC coverage, we found an average of 14 manually created resources per account that were not tracked in any IaC repository. These were created for debugging, testing, or emergency response and never cleaned up. IaC is necessary but not sufficient. You still need a CSPM tool that enumerates actual running state and alerts on drift, because the resources that fall outside your IaC scope are exactly the ones that get misconfigured.
How do I handle CSPM alert fatigue in my cloud security program?
The alert fatigue problem is real — in 8 of 15 recent Vulnox assessments, we found suppression rules applied to entire CSPM finding categories, including categories containing critical misconfigurations. Before adding tooling, answer three questions: who owns cloud security alerts, what is the SLA for critical findings, and how will you know when something is remediated? Without those answers, a more capable tool produces a longer queue that nobody clears. Start with a defined escalation path and a 48-hour SLA for critical findings before evaluating which CSPM tool to buy.
What is the typical attacker dwell time in cloud environments compared to remediation time?
The median time from CSPM alert generation to confirmed remediation in Vulnox-assessed environments is 23 days. The median attacker cloud dwell time is 18 days per CrowdStrike Global Threat Report 2024. Attackers move faster than most security teams remediate. This gap is not primarily a tool problem — it is an ownership and process problem. Organizations with dedicated cloud security engineers who own a remediation SLA close findings in under 7 days. Organizations routing alerts to shared Slack channels with no owner close them in 23+ days.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.