Software Buyer Brief
Cloud Native Application Protection Platform Checklist Before Buying
Short answer: buy a CNAPP only if it can connect cloud posture, workload risk, container security, infrastructure-as-code policy, identity permissions, runtime alerts, ownership, remediation workflow, and evidence export into one prioritized cloud-native risk view.
CNAPP is a broad category. Some products started as CSPM, some as workload protection, some as container security, and some as code scanning. The buying question is whether the tool truly connects those domains.
CISA cloud guidance, NIST container guidance, Kubernetes hardening guidance, and the NIST SSDF all point to the same operating reality: cloud-native risk spans configuration, identity, code, containers, runtime, and response. A CNAPP demo should show the full path from risky code or configuration to exposed running workload.
Start With The Cloud Asset Graph
The product should build a graph of cloud accounts, projects, subscriptions, networks, identities, storage, databases, clusters, containers, serverless functions, workloads, and exposed paths. It should show ownership and business context, not only asset counts.
Ask whether the graph updates fast enough to track ephemeral workloads and short-lived infrastructure.
Test Correlation Across Modules
A CNAPP should correlate findings: misconfigured storage plus sensitive data, vulnerable image plus internet-exposed workload, excessive identity permission plus production resource, or risky IaC change plus deployed cloud drift.
If every module has a separate dashboard and separate ticket queue, the platform may be a bundle rather than an integrated CNAPP.
Review Runtime And Workload Protection
Ask how the product detects suspicious process activity, network behavior, privilege escalation, container escape indicators, secrets exposure, and workload drift. Runtime signals should map back to image, repository, deployment, owner, and cloud resource.
Runtime protection should be tested in your environment because agent, sensor, and permissions models vary widely.
Require Developer And Cloud Team Workflow
Cloud-native findings often require multiple owners: developers, platform engineers, cloud security, identity teams, and data owners. The CNAPP should route fixes by resource owner and provide enough context to prevent ticket ping-pong.
Reports should show risk reduction by application, cloud account, cluster, owner, and control area.
CNAPP Review Table
| Requirement | Demo question | Buying signal |
|---|---|---|
| Asset graph | Can it map cloud assets, workloads, identities, code, and owners? | Findings have relationship context. |
| Correlation | Can it combine posture, vulnerability, identity, data, and runtime risk? | Prioritization is more than severity counts. |
| Runtime | Can it detect risky behavior in running workloads? | Production risk is visible after deployment. |
| IaC and code | Can it catch risky changes before deployment and compare drift? | Prevention and detection are connected. |
| Workflow | Can it route fixes to owners and export evidence? | Cloud risk turns into accountable work. |
Questions To Ask Before Buying
- Which clouds, clusters, container registries, CI/CD systems, and IaC tools are supported?
- Can the product map findings from code to deployed workload?
- Can it combine excessive permissions with vulnerable or exposed resources?
- How quickly does the asset graph update?
- Does runtime protection require agents, sensors, or privileged cloud roles?
- Can policies run in monitor mode before enforcement?
- How are exceptions scoped and expired?
- Can findings be routed to application and cloud owners?
- Can evidence be exported by app, account, cluster, and control area?
Red Flags In A CNAPP Demo
- The platform is a set of renamed dashboards with no correlation.
- Cloud identity risk is not included in prioritization.
- Runtime alerts do not map back to code, image, or owner.
- IaC findings cannot be tied to deployed drift.
- Agents require broad privileges with unclear controls.
- Reports cannot show risk reduction by application or owner.
Demo move: ask the vendor to trace one risky IaC change into a deployed workload, add identity context, show runtime visibility, open a ticket, and export evidence.
Source Links
- CISA: Cloud Security Technical Reference Architecture
- NIST SP 800-190: Application Container Security Guide
- CISA: Updated Kubernetes Hardening Guide
- NIST SP 800-218: Secure Software Development Framework
- CISA: Secure by Design
FAQ
Is CNAPP the same as CSPM?
No. CSPM focuses on cloud configuration posture. CNAPP should also include workload, identity, code, container, and runtime context.
Does CNAPP replace container security?
Not necessarily. It may include container security features, but buyers should verify image scanning, admission policy, runtime detection, and ownership workflows.
Why does identity context matter?
Cloud risk often depends on who or what can reach a resource. Excessive permissions can turn a medium configuration issue into a major exposure.
Should CNAPP include IaC scanning?
Yes, if the team wants to catch risky cloud changes before deployment and compare planned policy with actual cloud drift.
What evidence should CNAPP export?
Asset graph, findings, policy decisions, runtime alerts, owner routing, exceptions, remediation tickets, and before-and-after risk summaries.