The Question
Your CTEM program was designed around an on-premises infrastructure model. You have scan coverage across your data center assets, your network devices, your servers. Tenable or Qualys runs weekly scans. Asset inventory is reasonably current. The patching workflow connects to IT operations. It works.
Then the business migrated sixty percent of its workloads to AWS and Azure over the past two years. The cloud environment is something different. Developers are spinning up EC2 instances, EKS clusters, Lambda functions, and S3 buckets without routing through the IT provisioning process that feeds your asset inventory. A new microservice environment can go from code to production in a CI/CD pipeline in under an hour. Auto-scaling groups launch instances at peak load and terminate them before your weekly scan cycle runs.
Your CTEM program has a blind spot the size of your cloud estate.
The discovery mechanisms, the scanning tools, the remediation workflows, and the organizational model that make CTEM work in an on-premises environment do not translate to cloud without deliberate redesign. Assuming they do is how organizations end up with a mature CTEM program covering sixty percent of their attack surface.
CTEM for cloud requires rethinking every assumption from on-premises vulnerability management — the assets change too fast, the tooling is different, and the organizational model must include developers, not just security operations.
Why This Matters Now
In mid-2025, a global retail organization suffered a breach originating from a misconfigured AWS S3 bucket containing customer payment data. The bucket had been provisioned by a developer team building a data analytics prototype. It was not in the security team's asset inventory. The VM program had no visibility into it. The CTEM program's EASM coverage had identified the bucket as internet-accessible three weeks before the breach — but the finding had been routed to the security team's cloud findings queue, which was reviewed monthly. By the time the queue was reviewed, the breach had occurred.
The root cause was not absence of tooling. The organization had a CSPM solution deployed. The CSPM had flagged the bucket as publicly accessible. The finding had been correctly categorized. What failed was the operating model: the feedback loop between cloud security tooling and the developers who needed to act was too slow for the velocity of cloud deployment.
This pattern — correct tooling, miscalibrated operating model — is the dominant failure mode in enterprise cloud CTEM programs. A 2025 study by a major cloud security vendor found that the average time between a cloud misconfiguration being introduced and being detected was 4.2 days. The average time between detection and remediation was 23 days. The attacker dwell time for cloud-origin breaches averaged 6 days. The math does not work.
The cloud CTEM challenge is fundamentally a speed problem. The remediation model must match the deployment velocity — which means feedback loops measured in hours, not weeks.
What the CURVE™ Data Shows
The 2026 Stackcurve CTEM CURVE™ Report evaluated the cloud CTEM stack across four capability areas: agentless cloud asset discovery, CSPM coverage depth, container and serverless security, and developer workflow integration.
Wiz rated highest overall in cloud CTEM coverage — agentless architecture deploys across AWS, Azure, GCP, and OCI without agents, providing full asset discovery through cloud provider APIs within hours of deployment. Wiz's attack path analysis for cloud environments, including exposure paths through misconfigured IAM roles and public storage, rated highest in our assessment for depth and actionability.
Orca Security uses a similar agentless, side-scanning architecture and rated comparably to Wiz on discovery coverage, with slightly lower ratings on attack path visualization and developer integration depth.
Palo Alto Prisma Cloud rated highest among agent-based CSPM options for enterprises with strict compliance requirements that mandate agent-based telemetry. Prisma Cloud's IaC scanning and CI/CD pipeline integration also rated well for shift-left security coverage.
Aqua Security and Snyk Container rated highest specifically for container and Kubernetes security, particularly for organizations with mature DevSecOps practices that need deep image scanning and runtime protection.
For EASM coverage of cloud attack surface, Palo Alto Xpanse and Censys Attack Surface Management rated highest for internet-facing cloud asset discovery, including misconfigured storage, exposed APIs, and forgotten cloud endpoints.
The full vendor rankings are in the 2026 Stackcurve CTEM CURVE™ Report — free to download.
The Gap Most Buyers Miss
The gap most buyers miss is treating cloud security as a subset of their existing VM program rather than as a distinct CTEM capability domain with different discovery mechanisms, different tool requirements, and a fundamentally different operating model.
API-driven asset discovery is non-negotiable. Network-based scanning does not reliably discover cloud assets. EC2 instances behind load balancers, containers in private subnets, Lambda functions, and managed services like RDS or DynamoDB are not reachable by traditional network scan techniques — or are reachable but not attributable to the correct owner or business context. Cloud asset discovery must be performed through cloud provider APIs: AWS EC2 Describe, AWS Config, Azure Resource Graph, GCP Cloud Asset Inventory. CSPM tools operate this way natively. Extending your on-premises scanner's IP range to cover cloud subnets is not cloud asset discovery.
Serverless and container exposure requires purpose-built tooling. Lambda functions, ECS tasks, EKS pods, and API Gateway endpoints are not scannable by traditional vulnerability scanners. Serverless security requires static analysis of function code and dependencies (Snyk, Checkmarx), runtime behavior monitoring (Aqua, Sysdig), and configuration review of execution roles and API gateway settings. Container security requires image scanning in the registry (before deployment), runtime scanning of running containers, and Kubernetes configuration review. None of these are capabilities in traditional VM platforms.
Infrastructure as Code scanning shifts left — and must. The fastest way to prevent cloud misconfiguration exposure is to catch it before deployment. IaC security scanning tools — Checkov, tfsec, and the IaC scanning capabilities in Wiz and Prisma Cloud — analyze CloudFormation, Terraform, and Pulumi templates in the CI/CD pipeline and flag security misconfigurations before they reach production. A finding caught in a pull request review costs minutes to fix. The same finding in a production environment costs weeks to remediate with potential breach exposure in between.
Ephemeral compute breaks scan-cadence models. Auto-scaling groups launch and terminate instances within minutes during peak load events. Spot instances run for hours. These assets may never be present for a scheduled weekly scan. Agent-based deployment (deploying the security agent as part of the AMI or container base image) or API-based continuous scanning is required to maintain coverage over ephemeral compute. Any cloud CTEM program that relies on scheduled scans rather than continuous, event-driven discovery has coverage gaps proportional to its deployment velocity.
Developer integration is not optional. Cloud infrastructure is developer-controlled. Security teams that operate exclusively at the post-deployment layer — reviewing CSPM findings and creating tickets for developers to act on — are always reactive to deployment velocity. Effective cloud CTEM integrates security feedback into developer workflows: IDE plugins that surface misconfiguration as code is written, CI/CD pipeline checks that block deployments with critical misconfigurations, and Slack or Teams notifications that route cloud security findings directly to the responsible developer team. The remediation owner in cloud CTEM is not IT operations — it is the developer team that provisioned the resource.
Questions Your Buying Team Should Be Asking
1. Does our cloud CTEM tooling discover assets through cloud provider APIs rather than network-based scanning, and does discovery run continuously or on a scheduled cadence? This is the foundational question for cloud CTEM coverage. If the answer is network-based scheduled scanning, the program has structural coverage gaps by design. API-based continuous discovery is the minimum viable architecture for cloud asset inventory.
2. What is our current coverage for serverless functions, container workloads, and managed cloud services — and which tooling provides security assessment for assets that network scanners cannot reach? Many organizations discover when asked this question that their cloud CTEM coverage is limited to EC2 instances and misses a significant portion of their actual cloud attack surface. Lambda functions and containerized workloads may represent the majority of application logic in a modern cloud environment.
3. Have we integrated IaC security scanning into our CI/CD pipeline, and what percentage of our cloud deployments go through a pipeline that includes security policy checks before production deployment? The organization's answer to this question defines the proportion of cloud exposure that is being prevented versus detected post-deployment. A shift-left IaC scanning posture is the highest-leverage cloud security control available — finding misconfigurations before they reach production is categorically more effective than remediating them afterward.
4. When our CSPM identifies a critical cloud misconfiguration, what is the current mean time to notification for the responsible developer team, and what is the mean time to remediation? The target for critical cloud misconfigurations (publicly accessible storage, overprivileged IAM roles on internet-facing services, unencrypted sensitive data stores) is notification within hours and remediation within 24-48 hours. If the actual figures are measured in weeks, the operating model has a feedback loop problem that no additional tooling will solve.
5. Does our cloud security program have defined relationships with the developer teams responsible for cloud infrastructure, including a shared understanding of which misconfigurations require immediate action versus scheduled remediation? The developer-security relationship is the operational substrate of cloud CTEM. Without it, CSPM findings route to a security queue that has no organizational authority to compel developer action. With it, security and developers share ownership of cloud exposure outcomes.
The Stackcurve Take
Cloud CTEM is not a configuration exercise on top of your existing VM program. It is a distinct program with different discovery requirements, different tooling, different remediation owners, and a fundamentally different operating tempo. The organizations getting this right have made two decisions that the majority have not: they have committed to continuous API-based discovery as the architecture (not scheduled network scanning), and they have made developers co-owners of cloud security outcomes rather than recipients of security team ticket assignments.
Wiz and Orca Security have built the most complete agentless cloud CTEM stacks in the market. For organizations with strong DevSecOps practices, Prisma Cloud and Aqua provide deeper CI/CD integration. For organizations prioritizing cloud attack surface visibility from the outside in, Palo Alto Xpanse provides the strongest EASM coverage for cloud-origin exposure.
The technology decisions are consequential but secondary to the architectural and organizational decisions. Get the discovery model and the developer integration model right before evaluating specific platforms — the platform choice should follow from those architectural decisions, not precede them.
The 2026 Stackcurve CTEM CURVE™ Report covers the full cloud CTEM platform landscape, including agentless CSPM, container security, IaC scanning, and cloud EASM vendor ratings. Download it free →
Stackcurve Advisory Briefs are independent research. No vendor pays for placement, tier assignment, or editorial influence. The CURVE™ methodology is disclosed in full at stackcurve.net/research/methodology.