Most organizations running workloads across AWS, Azure and Google Cloud have accumulated a cloud security toolbox piece by piece: a posture management product here, a container scanner there, a separate tool for identity entitlements, another for runtime threats and yet another for infrastructure-as-code checks in pipelines. Each tool produces its own alerts, its own risk scores and its own dashboards. The result is alert fatigue, duplicated findings and blind spots where tools do not connect. Cloud-native application protection platforms (CNAPPs) promise to fix this by unifying those capabilities around a single view of risk from code to runtime. In 2026, consolidation is accelerating, the market leaders are being reshaped by acquisitions, and AI workloads are adding new requirements. This guide explains what is changing, how to evaluate a CNAPP and how to roll one out effectively.
What Changed in 2025–2026
Three developments have moved CNAPP from a category label to a strategic platform decision.
Hyperscaler Consolidation
Google completed its $32 billion acquisition of Wiz on March 11, 2026, after announcing the deal in March 2025. Google stated that Wiz products will continue to work across AWS, Azure, Google Cloud and Oracle Cloud, will remain available through partners and marketplaces, and will keep the Wiz brand, while the two companies build a unified platform applying consistent controls from source code through cloud infrastructure to runtime. Analysts quoted by SDxCentral framed the deal as part of a broader trend of platform players seeking tighter control over the security stack, and noted that the key question for buyers is how fully Wiz’s multicloud neutrality is preserved over time. Dell’Oro Group’s Mauricio Sanchez projected the CNAPP market will reach $12.9 billion by 2030.
Analyst Guidance Points to Convergence
Gartner’s 2025 Market Guide for CNAPP, published in August 2025, emphasized convergence. As quoted by vendors summarizing the report, Gartner observed that CNAPP and application security offerings are increasingly converging, and that CNAPPs help bridge development, security architecture and security operations through a consistent view of risk. Gartner also predicted that by 2029, 40% of enterprises implementing zero trust in cloud environments will rely on CNAPP visibility and control features. Vendor summaries of the guide consistently highlight runtime context, attack-path analysis, code-to-cloud correlation and developer-friendly workflows as differentiators.
AI Workloads Expand the Attack Surface
Organizations are deploying model endpoints, vector databases, GPU clusters, AI agents and MCP servers across their clouds, often faster than security teams can inventory them. CNAPP vendors have responded with AI security posture management (AI-SPM): discovering AI services and models in use, flagging exposed endpoints or over-permissive service identities and mapping sensitive data that flows into training or retrieval pipelines.
What a Modern CNAPP Should Cover
The acronyms are confusing, but the capability set is reasonably stable. A complete CNAPP brings together:
- Cloud security posture management (CSPM): continuous detection of misconfigurations and compliance drift across cloud accounts, with benchmarks such as CIS and mappings to frameworks like NIST, PCI DSS and ISO 27001.
- Cloud infrastructure entitlement management (CIEM): analysis of effective permissions for human and non-human identities, highlighting unused and excessive privileges.
- Cloud workload protection (CWPP): vulnerability management and runtime protection for VMs, containers and serverless functions, using agentless scanning, lightweight sensors or both.
- Kubernetes security (KSPM): cluster configuration, admission control and workload policy.
- Shift-left scanning: infrastructure-as-code, container image, secrets and dependency scanning in repositories and pipelines.
- Data security posture management (DSPM): discovery and classification of sensitive data in cloud stores and the exposure paths to it.
- AI security posture management: inventory and posture of AI services, models and agent infrastructure.
- Cloud detection and response (CDR): real-time threat detection from cloud logs and runtime signals, integrated with the security operations center.
The point of a CNAPP is not to have every box ticked; it is to correlate these signals in a security graph so that a vulnerable container image, running with an over-privileged identity, reachable from the internet and able to read a bucket of customer data, is recognized as one critical attack path rather than four medium-severity findings in four tools.
Platform or Best of Breed?
The consolidation trend does not mean every organization should buy a single platform for everything. The trade-offs are real:
- Single platform advantages: one inventory, one risk model, correlated attack paths, fewer integrations to maintain, simpler procurement and training.
- Single platform risks: weaker depth in some modules, vendor lock-in, and dependence on one vendor’s roadmap, which matters more as hyperscalers acquire independent vendors.
- Best-of-breed advantages: deeper capability in specialized areas such as runtime protection or application security testing.
- Best-of-breed risks: fragmented risk views, duplicated alerts and integration effort that never ends.
Hyperscaler-native tools add another dimension. Each major cloud offers its own posture and threat detection services, and they are often the fastest way to get baseline coverage inside a single cloud. Their limitation is the multicloud view: a team running significant workloads in two or three clouds usually needs a layer that normalizes inventory, identity and risk across all of them. Many organizations therefore keep native services enabled for the signals only the provider can generate, and use a CNAPP to correlate everything into one model.
A pragmatic middle ground is a CNAPP as the system of record for cloud risk, with a small number of specialist tools integrated into its graph or into the SIEM where depth genuinely matters.
Selection Criteria That Actually Differentiate
Feature checklists make most CNAPPs look similar. The following criteria separate them in practice:
- Coverage of your real estate: every cloud you use (including Oracle Cloud or regional providers), Kubernetes distributions, serverless, PaaS and on-premises extensions.
- Quality of prioritization: during a proof of value, compare how many findings each product flags as critical and how many of those your team agrees are genuinely exploitable.
- Runtime context: whether the platform knows which vulnerable packages are actually loaded and which workloads are internet-exposed, using agentless techniques, sensors or both.
- Identity depth: effective permission analysis across clouds, including non-human identities and AI agents.
- Developer experience: findings delivered in pull requests and IDEs with clear fixes, and ownership mapped to the right teams.
- Remediation workflow: integration with ticketing, auto-remediation options with safe guardrails, and exception management with expiry dates.
- Operations integration: high-quality detections that flow into your SIEM or SOAR, with enough context for analysts to act.
- Multicloud neutrality and roadmap: contractual and roadmap assurances about support for clouds other than the vendor’s parent company, where relevant.
- Data handling: where scan data and snapshots are processed and stored, which matters for regulated and sovereignty-sensitive environments.
Running a Proof of Value That Means Something
Vendor demos run on curated environments. A useful evaluation runs on yours. Structure a proof of value over three to four weeks:
- Pick representative scope: a production-like account in each major cloud, at least one Kubernetes cluster, a serverless application and a repository with infrastructure code.
- Seed known issues: ask your red team or cloud engineers to plant a few realistic weaknesses, such as an over-privileged role attached to an exposed workload, so you can test whether each product connects the dots.
- Compare top findings: have the same engineers review each product’s top twenty critical items and score them as exploitable, theoretical or false positive.
- Test the workflow: route a handful of findings to real owning teams through tickets or pull requests and observe whether the context is enough to fix them without a security engineer translating.
- Check operational fit: deployment effort, permissions requested, scan latency, API quality and how detections appear in your SIEM.
- Model total cost: licensing metrics vary widely (workloads, accounts, resources, developers), so price your expected growth, not just today’s footprint.
Document the scoring so the decision can be explained to leadership and revisited at renewal.
A Phased CNAPP Rollout Plan
Phase 1: Connect and Baseline (Weeks 1–4)
Connect all cloud accounts and subscriptions in read-only mode, including the forgotten ones. Build the asset inventory, run benchmark assessments and establish a baseline of findings. Resist the temptation to send everything to engineering teams on day one; thousands of unprioritized tickets will destroy goodwill before the platform has proven its value.
Phase 2: Prioritize Attack Paths (Weeks 4–10)
Focus on the small number of toxic combinations: internet exposure plus critical vulnerability plus excessive privilege plus sensitive data access. Fix these first, and use them to demonstrate value to leadership. Map asset ownership using tags, account structure and repository metadata so findings reach the right teams.
Phase 3: Shift Left (Months 2–6)
Enable infrastructure-as-code and image scanning in pipelines, initially in warn-only mode, then block on a narrow set of high-confidence policies. Feed findings into the tools developers already use. Align policies with your landing zone guardrails so preventive controls and detective controls tell the same story.
Phase 4: Runtime and Response (Months 3–9)
Deploy runtime sensors where needed, enable cloud detection and response, and integrate alerts with the SOC. Build playbooks for common scenarios such as exposed credentials, crypto-mining and suspicious privilege escalation.
During this phase, tune detections aggressively. Cloud detection rules that fire on every administrative action will be muted by analysts within weeks, so start with high-fidelity scenarios and add coverage as the team builds confidence.
Phase 5: Extend to Data and AI (Months 6–12)
Turn on DSPM for sensitive data stores and AI-SPM for model endpoints, agent infrastructure and AI pipelines. Add policies for AI-specific risks, such as public model endpoints, over-privileged agent identities and unapproved MCP servers.
Operating Model and Metrics
Technology alone does not close attack paths. Assign a platform owner for the CNAPP, define severity-based remediation targets agreed with engineering leadership, and give each product team a simple dashboard of its own open risks. Useful metrics include the number of critical attack paths open, mean time to remediate by severity, percentage of cloud accounts connected, share of findings with a mapped owner, and the proportion of new infrastructure deployed through pipelines with policy checks. Review these monthly with engineering leads so security becomes part of normal delivery conversations rather than a separate stream of complaints.
A Worked Example: Consolidating Five Tools Into One Risk View
Consider a hypothetical fintech with workloads on AWS and Google Cloud, using five separate security tools. Its security team of six spends most of its time deduplicating findings and arguing with engineering teams about priorities.
After a structured proof of value with two CNAPP vendors, measured on prioritization accuracy against a sample of real environments, the team selects one platform. In the first month, read-only connections reveal several unknown accounts created for experiments, two of them hosting public storage buckets. The attack-path view identifies a handful of critical paths, including an internet-facing container running with an identity that could read the production customer database. These are fixed within weeks.
Over the next two quarters, pipeline scanning moves from warn to block for a short list of policies, findings are routed to owning teams through the developer portal and ticketing system, and three of the legacy tools are retired. The SOC receives fewer, better-contextualized cloud alerts. Six months later, the team extends coverage to its new AI features, discovering an unauthenticated model endpoint created by a data science team and an agent identity with write access it did not need.
Pitfalls to Avoid
- Measuring success by findings volume: more alerts is not more security. Measure critical attack paths closed and mean time to remediate.
- Skipping ownership mapping: findings without owners are never fixed.
- Blocking pipelines too early: aggressive gates without developer buy-in lead to bypasses.
- Ignoring identities: misconfigurations get attention, but excessive permissions, especially for non-human identities, often create the most dangerous paths.
- Assuming vendor neutrality is permanent: after acquisitions, review roadmaps and contract terms for multicloud support.
The value of a CNAPP is not the number of modules it offers, but its ability to connect code, configuration, identity, data and runtime into a short list of real attack paths that the right teams can fix quickly.
Conclusion: Consolidate Around Risk, Not Around Logos
The cloud security market is consolidating fast, and Google’s acquisition of Wiz is the clearest signal yet that cloud providers see unified security platforms as strategic. For buyers, the opportunity is to replace fragmented tools with a single, correlated view of risk that spans development, cloud configuration, identity, data, AI and runtime. Choose based on prioritization quality, coverage of your actual estate, developer experience and roadmap neutrality, then roll out in phases that build trust with engineering teams. Done well, a CNAPP shifts security from counting findings to closing the attack paths that matter.
How Hanoi Technology Can Help
Hanoi Technology helps teams evaluate, deploy and operationalize CNAPP platforms across AWS, Azure and Google Cloud, from attack-path remediation to pipeline guardrails and SOC integration.