How to Evaluate CNAPP Tools for AWS, Azure and GCP

Cloud-native application protection platforms (CNAPPs) promise one view of misconfigurations, identities, workloads and code across every cloud you run.

In practice, CNAPP tools differ a lot in how deeply they understand each provider, how they connect findings into attack paths, and how much noise they generate.

This guide gives you vendor-neutral evaluation criteria, a proof-of-concept plan you can run in two to four weeks, and a balanced comparison of the main architectural approaches for multi-cloud security across AWS, Azure and GCP.

What CNAPP tools are supposed to cover

A CNAPP combines capabilities that used to be bought separately. The core components are cloud security posture management (CSPM), cloud infrastructure entitlement management (CIEM), cloud workload protection (CWPP), infrastructure-as-code (IaC) scanning, and container and Kubernetes security. Many also add data security posture management (DSPM) and API discovery.

The value is not the checklist but the correlation. A public storage bucket is a finding; a public bucket readable by a role that an internet-facing VM with a critical CVE can assume is an attack path.

That correlation is what separates a CNAPP from a bundle of point tools sold under one contract.

The problem it solves is real. Flexera’s 2025 State of the Cloud survey found organisations use an average of 2.4 public cloud providers (Flexera via SoftwareONE, 2025).

Each provider has its own IAM model, logging format and policy language, and few teams have deep expertise in all three.

Evaluation criterion 1: depth of CSPM per cloud

Every vendor claims AWS, Azure and GCP support. The useful question is how deep that support goes on each one, because coverage often lags on the second and third clouds.

What to test

• Service coverage: ask for the list of supported resource types per provider and compare it with the services you actually run, including newer AI and data services.
• Organisation-level onboarding: AWS Organizations, Azure management groups and GCP organisation/folder hierarchies should onboard automatically, including new accounts and subscriptions.
• Benchmark mapping: CIS Benchmarks for each provider, plus frameworks you report against, such as NIST CSF 2.0 or CIS Controls v8.
• Time to detect: how long between a misconfiguration being created and it appearing in the console. Event-driven ingestion usually beats scheduled polling.

Our coverage of detecting and remediating cloud misconfigurations explains why detection speed matters as much as rule count.

Evaluation criterion 2: identity and entitlement analysis

Identity is where most cloud breaches actually turn. Datadog’s 2025 State of Cloud Security research found that 59% of AWS IAM users and 55% of Google Cloud service accounts had active keys more than a year old (Datadog via SC Media, 2025).

Long-lived keys map to MITRE ATT&CK T1078.004 (Valid Accounts: Cloud Accounts) when they leak.

What a strong CIEM capability shows

• Effective permissions after evaluating identity policies, resource policies, permission boundaries, SCPs and Azure role inheritance, not just attached policies.
• Unused permissions over a 90-day window, with a generated least-privilege policy.
• Cross-account and cross-cloud trust: for example, a GCP workload identity federated into AWS.
• Non-human identities: service principals, managed identities, and keys embedded in CI/CD.

Also test how the tool treats instance metadata. Attacks that abuse the instance metadata service to steal credentials rely on IMDSv1 being enabled and on overly broad instance roles, so a CNAPP should flag both together.

Evaluation criterion 3: attack path analysis quality

Cloud attack path analysis is the feature most vendors demo and the one most worth testing on your own estate. Good attack path analysis reduces thousands of findings to a short list of chains that lead somewhere valuable.

Practitioner example: a test attack path to seed

Build this illustrative chain in a sandbox account before the proof of concept, then see which tools find it and how they rank it:

1. An EC2 instance or Azure VM with a public IP and a web service exposing a known critical CVE.
2. IMDSv1 enabled (AWS) or a managed identity with broad scope (Azure).
3. The instance role can call sts:AssumeRole into a second role.
4. The second role has s3:GetObject on a bucket tagged as containing customer data, or equivalent Storage Blob Data Reader rights.

A capable tool should show this as one critical path, not four medium findings. Ask it to explain which single fix breaks the chain at the lowest cost, which is usually enforcing IMDSv2 or removing the trust relationship.

Questions to ask about the graph

• Does the graph include network reachability (security groups, NSGs, firewall rules), or only IAM?
• Does it use runtime data to confirm a vulnerable package is actually loaded?
• Can analysts query the graph directly, and export it to the SIEM?

Evaluation criterion 4: workload and runtime coverage

CNAPPs take two broad approaches to workloads. Agentless tools snapshot disks through cloud APIs and analyse them out of band. Agent-based tools run a sensor (often eBPF-based on Linux) inside the workload.

Approach	Strengths	Limitations
Agentless snapshot scanning	Fast deployment, full coverage, no performance impact	Periodic, not real time; cannot block; limited visibility into running processes
Runtime agent / eBPF sensor	Real-time detection, process and network telemetry, can prevent	Deployment effort, kernel compatibility, coverage gaps on unmanaged hosts
Hybrid	Agentless for breadth, agents on critical workloads	Two data models to reconcile; licensing can be complex

Vendors such as Orca security popularised the agentless model, while others started from runtime sensors and added agentless scanning later. Neither is strictly better; match the approach to whether your priority is coverage or real-time prevention.

Evaluation criterion 5: operations, integration and cost

A CNAPP that produces accurate findings but cannot route them to the right team will be shelved within a year. Operational fit deserves as much scoring weight as detection quality.

• Ownership routing: can findings be assigned by account, tag, or repository owner automatically?
• Developer workflow: pull-request comments for IaC, ticket creation in Jira or ServiceNow, and suppression with expiry dates.
• SIEM and SOAR: native connectors, plus raw event export for detection engineering.
• Pricing model: per workload, per resource or per account. Model your cost at 2x current scale, because autoscaling and serverless can change billing units sharply.
• Data residency: where snapshots and metadata are processed, which matters for regulated workloads.

Concentration of providers is also a live risk to plan for. Large outages at hyperscalers such as AWS are a reminder that your security tooling should keep working, or at least degrade gracefully, when one provider has problems.

A balanced comparison of CNAPP sourcing options

Rather than rank individual products, the table below compares the main ways organisations source CNAPP capability.

Specific vendors change ownership and features quickly; for example, Google completed its $32 billion acquisition of Wiz in 2026, and buyers should check the roadmap commitments of any vendor going through a merger.

Option	Best fit	Multi-cloud depth	Main trade-off
Cloud-native tools (AWS Security Hub, Microsoft Defender for Cloud, Google Security Command Center)	Single-cloud or one dominant cloud	Deepest on own cloud, partial on others	Separate consoles and policy models per cloud
Independent CNAPP specialist	Two or more clouds with a central security team	Generally consistent across providers	Another vendor and data copy; acquisition risk
CNAPP module of a broad security platform (XDR/SIEM vendor)	Organisations consolidating vendors	Varies widely; test carefully	Cloud features may lag specialist tools
Open-source stack (e.g., Prowler, Trivy, Falco, Cloud Custodian)	Strong engineering teams, tight budgets	Good rule coverage, little correlation	You build and maintain the graph and workflow

For product shortlists, see our reviews of CSPM tools and Google Cloud security tools, and validate any shortlist against the criteria above.

Running a two-to-four-week proof of concept

1. Week 0: seed the test attack path above and three known misconfigurations per cloud. Record ground truth.
2. Week 1: onboard one production organisation per cloud in read-only mode. Measure onboarding time and permissions requested.
3. Week 2: compare findings with ground truth. Score detection rate, false positives on a 100-finding sample, and attack path ranking.
4. Week 3: test workflow: route ten findings to owners, push two IaC fixes, export to SIEM.
5. Week 4: cost model at 2x scale and a reference call with a customer of similar size and cloud mix.

Key takeaways

• Test CNAPP tools on depth per cloud, not just on whether AWS, Azure and GCP logos appear on the datasheet.
• Identity analysis and effective permissions matter more than raw misconfiguration counts.
• Seed a known attack path and judge tools on whether they find it, rank it critical and suggest the cheapest fix.
• Choose agentless, agent-based or hybrid workload coverage based on whether you need breadth or real-time prevention.
• Weight operational fit and pricing model as heavily as detection quality.

FAQ

What is the difference between CNAPP and CSPM?

CSPM checks cloud configurations against policies and benchmarks. A CNAPP includes CSPM but adds identity entitlement analysis, workload protection, IaC scanning and correlation of findings into attack paths.

Do I need a CNAPP if I only use one cloud?

Not necessarily. The provider’s native tools may cover a single-cloud estate well. A CNAPP becomes more valuable when you run two or more clouds, Kubernetes at scale, or need one prioritised view across teams.

Are agentless CNAPP tools enough?

Agentless scanning gives broad coverage quickly but works from periodic snapshots and cannot block activity. Most mature programmes add runtime sensors on internet-facing and business-critical workloads.

What is cloud attack path analysis?

It is a graph-based technique that links exposure, vulnerabilities, identities and data stores to show how an attacker could move from an entry point to a sensitive asset, so teams can fix the step that breaks the chain.

How long should a CNAPP proof of concept take?

Two to four weeks is usually enough to onboard each cloud, compare findings against seeded ground truth, test workflows and model cost at scale.