Many cloud-native application protection platform (CNAPP) evaluations are won in a demo tenant full of tidy findings, then the real estate produces thousands of alerts nobody owns. Almost every platform now claims posture management, workload protection, entitlement analysis, Kubernetes, code scanning, data security and runtime detection, so the module list no longer separates them. What does is depth in the modules you need, the quality of attack paths, how accurately findings are ranked, how fixes reach the right team, and what the platform's own access to your accounts looks like. This vendor-neutral guide is for cloud security leads, platform engineers and procurement teams writing requirements, running an RFP or replacing a CSPM tool. Our CNAPP Guide explains the components and how to run the programme; this page is about choosing the platform.
Key takeaways
- Buy for your estate, not the feature grid. A serverless-heavy single-cloud estate and a multi-cloud Kubernetes estate need different strengths.
- Test prioritisation on your own data. The core promise is a short, correct list of what to fix first, so measure it against findings you already know about.
- Agentless first, runtime where it pays. Snapshot and API scanning gives fast coverage; runtime sensors add live detection on internet-facing and production Kubernetes workloads.
- The platform is a privileged non-human identity. It holds read, snapshot and sometimes write access across every account. Score its connector design as hard as its features.
- Know the pricing unit before you scale. Resources, events, vCPUs, data scanned and tokens grow at different rates, and the wrong unit makes full coverage unaffordable.
Define requirements
- Estate shape: clouds and their share of spend, the number of accounts, subscriptions and projects, how they are organised (AWS Organizations, Azure management groups, Google Cloud folders), and how many are sandboxes or acquisitions without a clear owner. See the AWS Security Guide, the Microsoft Azure Security Guide and the Google Cloud Security Guide.
- Workload mix: virtual machines, managed Kubernetes clusters and nodes, serverless functions, registry images, databases and storage accounts. This drives coverage and price.
- Module priorities: rank CSPM, CWPP, CIEM, KSPM, infrastructure as code (IaC) scanning, DSPM, cloud detection and response (CDR) and AI security posture management (AI-SPM) as must-have, useful or not needed, and be honest about what existing tools already do well.
- Benchmarks: the CIS Foundations Benchmark for each cloud, CIS benchmarks for EKS, AKS or GKE, and any regulatory or customer frameworks you report against. Ask for the benchmark version each rule pack implements and how quickly new versions are adopted. See the Kubernetes Security Guide.
- Control obligations: map the platform to what you report against: NIST CSF 2.0 ID.AM-02 (inventories of software, services and systems), PR.PS-01 ("Configuration management practices are established and applied"), ID.RA-01 (vulnerabilities identified, validated and recorded), PR.AA-05 (access permissions and entitlements) and DE.CM-09 (runtime environments monitored for adverse events); NIST SP 800-53 CM-6, CM-8, RA-5, AC-6 and SI-4; CIS Controls v8.1 Safeguards 4.1 (secure configuration process), 6.8 (role-based access control) and 7.5 and 7.6 (automated vulnerability scans); ISO/IEC 27001:2022 Annex A 5.23 (information security for use of cloud services), 8.8 (management of technical vulnerabilities), 8.9 (configuration management) and 8.16 (monitoring activities). Ask each vendor which reports evidence these, rather than accepting a logo list of frameworks.
- Remediation and detection model: who fixes findings and where the work lives (pull requests, tickets), whether any automated remediation is allowed, and which SOC and SIEM receive CDR alerts. See the SIEM Guide.
Be clear which problem you are buying for, because CNAPP is a bundle of categories that are still sold separately.
| Category | Primary question | A standalone or native tool may be enough when |
|---|---|---|
| CSPM | Are cloud resources configured to policy and benchmark? | One cloud, few accounts, and the provider's posture service is enabled everywhere |
| KSPM | Are clusters, workloads and RBAC configured safely? | A handful of managed clusters with admission policies already enforced |
| CWPP | Are hosts, containers and functions vulnerable or compromised? | An existing endpoint or container tool already covers your workload types |
| CIEM | Which human and non-human identities hold excess or unused permissions? | Provider access analysers cover your clouds and someone acts on their findings |
| CNAPP | Which combinations of exposure, vulnerability, identity and data create a real path to harm? | Rarely replaced by point tools in multi-cloud estates; the joined graph is the reason to buy |
Size changes the answer. A single-cloud organisation with a small team often gets most of the value from the provider's native posture and threat detection services, enabled in every account and region, plus a good IaC scanner. A multi-cloud enterprise with hundreds of accounts needs one inventory, one policy model and cross-cloud attack paths, which is where a third-party platform earns its cost.
| Pricing unit | Documented example | What makes cost grow |
|---|---|---|
| Resource unit | AWS Security Hub Essentials bills per "Resource unit / mo": an EC2 instance is one unit, with Lambda functions, ECR images and IAM users or roles at lower ratios. Microsoft Defender CSPM counts servers, storage accounts and databases, and "8 functions and/or web apps = 1 billable resource" | Autoscaling fleets, image sprawl, many small functions |
| Events | AWS prices threat analytics on CloudTrail management events "Per one million events/month" | Busy automation, enabling data events |
| vCPU | AWS measures runtime monitoring in vCPUs | Kubernetes node count and size |
| Data scanned | Microsoft prices storage malware scanning per GB scanned | Upload-heavy buckets, data lakes |
| Tokens | Microsoft prices AI services protection per 1K tokens per month | Production AI applications and agents |
Ask every vendor which unit it counts and how autoscaling and serverless are measured, model three years of growth, and price coverage of every account, including development and test: forgotten accounts are where trust paths into production hide.
Evaluation criteria
Weight to your requirements. An illustrative split is 25% prioritisation and attack paths, 20% module depth, 15% remediation workflow, 15% coverage and deployment, 15% platform security and identity, 10% the rest.
| Criterion | What good looks like | Weak signs |
|---|---|---|
| Module completeness | CSPM, CWPP, CIEM, KSPM, IaC, DSPM, CDR and AI-SPM share one inventory and graph; your must-have modules hold up against specialist tools | Acquired modules in separate consoles; roadmap slides; thin rule packs |
| Agentless versus agent | Agentless API and disk snapshot scanning everywhere; optional runtime sensor for process, file and network visibility; a clear support matrix for kernels, managed Kubernetes and serverless containers. Native sensors have gaps too: AWS documents that its runtime agent sees "file access, process execution, command line arguments, and network connections", but "GuardDuty doesn't support Amazon EKS clusters running on AWS Fargate" | Agent needed for basic vulnerability data; no answer for short-lived nodes |
| Multi-cloud coverage | Similar service and check depth on each of your clouds; organisation-level onboarding that auto-connects new accounts | Deep on one cloud, shallow elsewhere; manual per-account onboarding |
| Attack path quality | Paths join exposure, exploitable vulnerability, identity permissions and sensitive data, with evidence per hop, chokepoints and cross-account role assumption | Pairs of unrelated findings; inferred reachability presented as fact |
| Prioritisation accuracy | Uses exploitation signals (CISA Known Exploited Vulnerabilities; EPSS, the probability a CVE "will be exploited in the wild in the next 30 days"), runtime evidence that a package is loaded, reachability, data sensitivity and blast radius | CVSS-only ranking; thousands of "critical" findings; scores nobody can explain |
| Remediation workflow | Owner mapping from tags, accounts and repositories; one ticket per root cause; tracing to the Terraform module or image that created the resource; pull request fixes; verified closure; exceptions with expiry | One ticket per resource; console-only fixes; no due dates |
| Noise and tuning | Suppressions as code with reason and expiry; readable custom policies; an audit trail of who suppressed what | All-or-nothing muting; tuning lost on upgrade |
| Detection and response | CDR on audit logs and runtime, mapped to ATT&CK Cloud techniques; scoped, approved response actions; SIEM export in an open schema | Alerts only in the console; response actions needing broad write access |
| Data and AI posture | DSPM classification feeds attack path targets and covers token-based sharing; AI-SPM inventories AI services, model endpoints and their identities. See the DSPM Buyer's Guide | Data classification not linked to paths; AI coverage is a service list |
| Platform security | SSO with phishing-resistant MFA, roles inside the tool, customer-visible audit logs, stated data residency, current independent assurance (for example a CSA STAR Level 2 entry or a completed CSA Consensus Assessment Initiative Questionnaire) | Shared admin accounts; no log of connector or policy changes |
Where identity fits
- CIEM depth: ask whether effective permissions are calculated across identity and resource policies, permission boundaries, organisation guardrails and role chaining, with last-used data driving right-sizing. Depth varies even among native tools: Google documents that on its Standard tiers "CIEM provides recommendations for Google Cloud basic roles only". See the Cloud PAM and CIEM Guide.
- NHI and workload identities: most cloud identities are roles, managed identities, service principals, service accounts and access keys. The platform should show each one's owner, last use, key age and reach, and flag long-lived keys and admin roles on exposed workloads. The Capital One breach turned a firewall's role credentials into bucket access, and the 230 Million AWS Cloud Environments campaign fed on keys in exposed .env files. See the Cloud Workload Identity Guide and the Kubernetes NHI Security Guide.
- The platform's own cross-account roles: require federated, short-lived access. Microsoft, as one documented example, says its AWS connector "authenticates to AWS using federated trust and short-lived credentials, without storing long-lived secrets", and its Google Cloud connector uses workload identity federation. Where a third party assumes AWS roles, require an external ID in the trust policy; AWS says its "primary function" is "to address and prevent the confused deputy problem", and the value must be unique per customer and controlled by the vendor, "not its customers".
- Least privilege for the connector: some products offer "Default access", which "Grants permissions required for current and future capabilities", or "Least privilege access", which "Grants only the permissions required today" (Microsoft's wording). Choose least privilege, list every permission, and treat snapshot, key decryption and remediation rights as privileged. See the Third-Party Access Guide.
Questions to ask vendors
- Which modules share one inventory and graph today, and which were acquired and are still integrating? Show it on our data.
- What does agentless scanning read, where are disk snapshots analysed and how fast are they deleted, and which workloads need a runtime sensor for live detection? See the Container Security Guide.
- Walk one attack path hop by hop: which hops are confirmed and which inferred? How are cross-account roles and Kubernetes service accounts mapped to cloud roles modelled?
- Which signals rank a finding, and can we see why one outranks another?
- How are findings routed to owners, grouped by root cause and fixed as pull requests against the template that created them?
- Exactly which permissions do your connectors need in each cloud, including snapshot, key decryption and remediation rights? Are credentials federated and short-lived, with an external ID per customer?
- Which AI services, model endpoints and agent identities does AI-SPM discover in our clouds? See the AI Security Posture Management (AI-SPM) Guide.
- What will covering every account cost in three years, and what can we export at contract end?
Red flags
- A proof of concept limited to the vendor's demo environment or a hand-picked account.
- Connectors that need administrator or owner rights, long-lived access keys or uploaded service account keys.
- Attack paths without evidence per hop, or "critical" counts that barely move after tuning.
- Automated remediation on by default, without approval, scope limits or rollback.
- Blind spots for token-based sharing: storage tokens and pre-signed links escape checks that only read bucket policies, as the Microsoft SAS Token Exposure showed.
- Pricing that makes development, test and sandbox coverage unaffordable.
Proof of concept
- Scope and score first: two or three production-like accounts across your main clouds, one managed Kubernetes cluster, one serverless application, a registry and two IaC repositories. Agree weights and pass criteria before connecting anything.
- Connect with least privilege: onboard through the organisation or management account using the least-privilege option, record every role, trust policy and external ID created, and set an expiry on PoC access.
- Seed known issues: a public bucket, an access key unused for 90 days, an admin role on a workload behind an internet-facing load balancer, a privileged pod with a cluster-admin binding, a plaintext key in an image and a vulnerable package. Score detection, time to detect and whether the attack path joins them. See the Cloud Misconfiguration Guide.
- Measure noise: count findings by severity in week one, tune for a week, count again, and have engineers judge what share of the top 50 ranked findings are real and actionable. That share is the most honest prioritisation test.
- Test remediation: route findings to two teams, raise one fix as a pull request against a Terraform module, confirm closure on rescan, and check that suppressions carry a reason and expiry.
- Test detection: in a non-production account, use a test key from an unusual location (ATT&CK T1078.004 Valid Accounts: Cloud Accounts), run discovery calls (T1580 Cloud Infrastructure Discovery) and launch unexpected compute. Confirm alerts reach your SIEM and a scoped response (disable the key) works. Stolen-key abuse such as the Codefinger S3 ransomware is invisible to configuration scans.
- Exit and roll back: get a quote priced on the discovered inventory, export findings and exceptions, then remove every role, trust policy and federation setting the vendor created, confirm access stops, and remove every seeded test issue.
After go-live, track accounts and clusters connected, open attack paths to sensitive data, mean time to remediate by severity, long-lived keys and unused identities, and the false positive rate of high-severity CDR alerts. See the Vulnerability Management Guide.
How NHI Mgmt Group can help
We provide independent market analysis, requirements definition and RFP support for cloud security programmes, including how CNAPP connectors and the cloud identities they analyse are governed as non-human identities. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: CNAPP Guide · Cloud PAM and CIEM Guide · Secrets Management Guide · AI Security Platform Buyer's Guide · NHI Security Platform Buyer's Guide