What is CNAPP?

CNAPP is a bundle, not one technique. The vendor connects to your cloud accounts, gathers several kinds of information and correlates them into one list of risks. The parts differ by vendor, but Microsoft's description of Defender for Cloud is a typical example: it names three core components.

• Posture management (CSPM): checks and improves the security posture of cloud resources, for instance a storage account that allows public access.
• Workload protection (CWPP): defends virtual machines, containers, storage, databases and serverless functions from threats while they run.
• DevSecOps: looks at code and pipelines, such as infrastructure-as-code misconfigurations and exposed secrets, before anything is deployed.

Examples per platform

• Azure: Microsoft Defender for Cloud calls itself a CNAPP and also connects AWS and Google Cloud accounts.
• Google Cloud: Security Command Center covers vulnerability and misconfiguration detection, threat detection and posture policies.
• AWS: there is no single product with the name. Services such as Security Hub CSPM and GuardDuty are used together, and Amazon Detective helps investigate.

The correlation is the selling point. A finding that a virtual machine is reachable from the internet carries more weight when the same tool also sees that it holds a powerful identity.

Cloud environments change quickly and are managed by several teams. When posture, vulnerabilities, identities and runtime alerts sit in different tools, someone has to combine them by hand, and the combinations are where real attack paths appear.

Cloud providers describe a split of duties in their shared responsibility models: the provider secures the platform, and the customer is responsible for configuration, identities and data. The NSA and CISA advisory AA23-278a lists default configurations and weak privilege separation among the problems found in many organizations. A CNAPP is one way to cover those customer-side duties in a single place.

Be careful with the label. Because it is a marketing category rather than a standard, two products called CNAPP can cover very different things. Judge a product by the specific capabilities listed, not by the acronym.

A team can reasonably start with one component, such as posture, and add others later. A CNAPP is not a prerequisite for any of them.

A practical test when reading a vendor page: ask which of the capabilities above the product actually delivers, in which of your clouds, and whether they are included in the plan you would buy. Defender for Cloud, for example, lists separate plans for servers, containers, storage and databases, so coverage depends on what you enable.

1. Write down what you must protect: which clouds, whether you run containers or serverless code, and who writes the code and templates.
2. Check what your providers already include. Defender for Cloud has free foundational posture capabilities, Security Command Center has tiers, and AWS offers separate services that you can enable per account.
3. Compare candidate products by capability, not by name. Ask for the exact checks, the clouds covered and what access they need.
4. Prefer read-only connection methods for the posture part, and review what any agent or scanner can change before you accept it.
5. Start with the findings that reach the internet or hold admin rights, and add other capabilities when you have capacity to act on their output.
6. Name an owner for each kind of finding, so that a posture issue, a workload alert and a code issue each have someone who will act on it.