What Is a CNAPP? CSPM, CWPP and CIEM in One Platform

TL;DR: A cloud-native application protection platform (CNAPP) is a single product that checks cloud applications at three points: code before it ships, the configuration it runs on, and the workload while it runs. It combines cloud security posture management (CSPM), cloud workload protection platforms (CWPP) and cloud infrastructure entitlement management (CIEM) in one console. We think the real test is correlation: whether related findings on one asset show up as one prioritized item, not three tickets.

What is a CNAPP?

A cloud-native application protection platform (CNAPP) is a single product that checks a cloud application at three points: the code before it ships, the cloud configuration it runs on, and the workload while it runs. Gartner Peer Insights defines CNAPPs as "a unified and tightly integrated set of security and compliance capabilities, designed to protect cloud-native infrastructure and applications" (Gartner). Wiz, a vendor in the category, notes that Gartner coined the term.

For a skimming reader, CNAPP is a consolidation label. Tools that teams used to buy one at a time now sit behind one console and, more usefully, one shared model of risk.

What sits inside

Gartner lists the capabilities as artifact scanning, security guardrails, configuration and compliance management, risk detection and prioritization, and behavioral analytics, covering everything "from code creation to production runtime" (Gartner).

In our reading, most buyers map these onto three older product types. Cloud security posture management (CSPM) checks account settings. Cloud workload protection platforms (CWPP) protect running virtual machines, containers and serverless functions. Cloud infrastructure entitlement management (CIEM) covers identities and permissions.

How it connects to your estate

Gartner describes three integration routes: API connections to the major cloud providers, pipeline integrations for continuous integration and delivery (CI/CD), and "agent and agentless workload integration" (Gartner). Agentless scanning reads the environment through cloud APIs and snapshots. Agents sit on the workload and see what happens in real time. Many platforms offer both.

Why the integration matters

A single finding in isolation tells you little. Wiz gives the example that a vulnerability management tool can see that a machine is vulnerable, but "it doesn’t know if the machine is also exposed to the Internet or has high privileges" (Wiz). Wiz also quotes Gartner's market guide on separate tools: "This lack of integration results in fragmented views of risk with limited context, making it difficult to effectively prioritize overall business risk."

Gartner has also made a forecast, quoted by Wiz: by 2029, 60% of enterprises without a unified CNAPP "will lack extensive visibility into the cloud attack surface" (Wiz). That is a prediction, not a measurement.

We think correlation is the real test, more than the length of the feature list. When you assess a platform, check whether a code flaw, a loose permission and a runtime alert on the same asset show up as one prioritized item or as three tickets in three tabs. For related terms, see the glossary.

What CSPM, CWPP and CIEM each cover

A cloud-native application protection platform (CNAPP) is easier to judge once its three older parts are pulled apart. Each one looks at a different layer of the cloud, and each tends to hand its findings to a different person.

Cloud security posture management (CSPM) reads the configuration of your cloud accounts through the provider's control plane. It flags settings that break policy or a compliance baseline. Typical findings are a storage bucket open to the public, logging switched off, or a network rule that allows inbound traffic from anywhere.

Cloud workload protection platform (CWPP) looks inside the things that run: virtual machines, containers and serverless functions. It finds vulnerable packages, malware and suspicious behavior at runtime. How it reaches the workload matters. Wiz argues that agent-based tools leave blind spots, because cloud resources without the agent get no protection.

Cloud infrastructure entitlement management (CIEM) examines identities and what they are allowed to do. That covers human users, service accounts and roles in identity and access management (IAM). It finds permissions that are granted but never used, and chains where one identity can take on the rights of another.

In our reading, the owner column explains much of the pain of running these as separate tools. Wiz points out that developers are the ones spinning up resources in the cloud. A posture finding seen by security is often fixed by someone else, in a pipeline security does not run.

The three are not the full list. Wiz names other standalone tools that organizations use, such as vulnerability management and data security posture management (DSPM). Product listings still split the modules out: on Gartner Peer Insights, Sysdig describes its CNAPP as addressing vulnerability management, CSPM, CIEM and container security.

When you read a datasheet, check which module produced each finding and whether the platform joins them. A public bucket, a role with broad rights and a workload running a vulnerable library can be one problem. Wiz describes the goal as one risk engine covering vulnerabilities, network exposures, secrets, malware, identities and sensitive data. For the terms used here, see the glossary.

What else vendors fold into a CNAPP

Product sheets rarely stop at the three core modules. Five add-ons turn up again and again, and each one widens what a single console is expected to see.

The five add-ons

• Kubernetes security posture management (KSPM). This checks cluster configuration rather than cloud account settings. Typical findings include a cluster API server reachable from the internet, pods running privileged, or a workload's service account holding cluster-wide admin rights.
• Data security posture management (DSPM). This finds and classifies stores of sensitive data, then flags exposure. An example is a storage bucket of customer records that a broad role can read. In our reading, most DSPM works on data at rest. NIST IR 8505 instead extends data classification to data in transit.
• Cloud detection and response (CDR). This watches control-plane logs and workload activity for attacks in progress. An example is a new access key created and then used from an unfamiliar location. Wiz describes CNAPPs that blend posture management, exposure reduction and real-time threat detection.
• Pipeline scanning. This checks infrastructure as code (IaC) templates and container images before they deploy. An example is a template that opens remote administration to any address. Wiz frames this as integrating through continuous integration and continuous delivery (CI/CD) pipelines and IaC scanning so teams can shift left.
• API protection. This inventories application programming interface (API) endpoints and checks authentication and schema drift. NIST SP 800-228 sets out basic and advanced controls for both pre-runtime and runtime stages. That makes the stage a useful split for asking which half a product covers.

Some sheets add a sixth area. Wiz says the category has expanded to secure models, pipelines and the sensitive data behind AI applications.

Checking the claims in a demo

We think the test for any add-on is whether its findings join the same risk graph as posture and identity, or sit on a separate tab. A module that only produces its own list adds licence cost without adding context.

How a CNAPP gets its data

The first section listed the three ways a CNAPP (cloud-native application protection platform) collects data. This section covers what each one sees in practice. Each method answers a different question, so in our reading a platform's coverage depends on which methods are switched on.

Cloud provider API connections

This is usually the first connection a team sets up. The platform gets read access to each cloud account and queries the provider's application programming interfaces (APIs) for an inventory of resources, their settings and the identities and permissions tied to them.

That data supports posture checks and entitlement analysis. A storage bucket left open to the public, or a role with broader rights than its job needs, shows up here. One listing on Gartner Peer Insights describes a product that integrates with existing cloud platforms to offer visibility into cloud assets and activities.

The limit is that an API reports how a resource is configured. It does not report what software runs inside a machine or what a process does at runtime.

CI/CD pipeline hooks

The second method plugs into continuous integration and continuous delivery (CI/CD) pipelines. A misconfigured template can fail a build, so the problem never reaches a live account.

The limit runs the other way. A pipeline sees only what passes through it. A resource someone creates by hand in the console never enters the pipeline, and neither does a setting changed after deployment.

Agent and agentless workload scanning

The third method looks inside the workloads themselves. Agentless scanning typically reads a copy of a machine's disk through the cloud provider. It finds vulnerable packages, exposed secrets and malware without installing anything. It works from a snapshot, so it shows the state at the time of the scan, not what is running at the moment.

Agents run on the host or in the Kubernetes cluster and watch live activity: processes, network connections and file changes. That is the data runtime threat detection needs. Sysdig, for example, says on its listing: "We use intelligence from runtime to prioritize alerts so teams can focus on high-impact security events and improve efficiency." The earlier point about agents still applies: coverage stops wherever the agent is not installed.

When reviewing a platform, ask which of these four rows are active in your own accounts, not which ones the product supports. We think that list is a more honest measure of coverage than a feature sheet.

Where CNAPP platforms differ

In our reading, most products in this category claim the same headline capabilities, so the useful differences sit one layer down. The table sets out the dimensions where, in our reading, products part ways, and what a buyer can test on each.

What the product material shows

Listings describe coverage in different terms. One describes security for workloads, applications and containers across public, private, and hybrid cloud environments. Another names containers, Kubernetes, hosts/servers, and cloud services. Map each list against your own estate before a demo.

On agents, vendor arguments pull in different directions. Wiz argues that agentless products can protect an environment in minutes by using the cloud provider’s APIs, and that runtime visibility into ephemeral workloads may not outweigh the overhead of managing agents. Other listings lead with runtime, as the earlier section on data collection showed. We think most estates end up with a mix, so the useful trial question is which workloads justify an agent.

In our reading, prioritization is where marketing claims converge and products diverge. Wiz describes the shift as moving from long issue lists to understanding what's actively exploitable in production, and says modern platforms link misconfigurations, identities, vulnerabilities, data exposure and runtime activity into real attack paths. Ask each vendor to walk one attack path in your own accounts, end to end.

In our reading, the pricing unit is the dimension most worth getting in writing, because it decides whether growth in containers or accounts changes the cost of the same coverage. Vendor profiles on /vendors list the companies in this space without ranking them.

How to scope a CNAPP evaluation

The steps below are our method. Two NIST drafts on cloud-native access control and service mesh design inform it.

Step 1: Inventory what you run, by risk tier

List every cloud account, subscription and project. Then list the clusters, serverless functions, registries and pipelines inside them. Record an owner for each one, since an asset without an owner tends to sit in the backlog.

Then tier each application. NIST's service mesh draft set out to analyze the capabilities required for each class of cloud-native applications by risk profile, using low, medium and high classes. We think the same three tiers are a practical way to decide where a cloud-native application protection platform (CNAPP) must prove itself first. That draft was obsoleted by the final SP 800-233 in October 2024, so check the final text before you adopt its classes.

Step 2: Name the three findings you most need closed

In our reading, a leader gets more from a short, named list than from a feature checklist. Our suggested three:

1. Identity paths to sensitive data. NIST's zero trust draft describes a shift in focus from network segmentation to identities. A test should show how well cloud infrastructure entitlement management (CIEM) traces who can reach what.
2. Public exposure from misconfiguration, the core job of cloud security posture management (CSPM).
3. Exploitable vulnerabilities on running workloads, the territory of cloud workload protection (CWPP).

Step 3: Plan the PoC accounts yourself

Do not let a vendor pick the demo environment. Choose one account that resembles production, one with containers or a service mesh, and one sandbox where you plant known issues, such as an over-permissioned role or an open storage bucket. Grant read-only access, and write down what each tool should find before it connects.

If you run a mesh, include it. The service mesh draft notes that it runs runtime functions such as access control through proxies. A tool that cannot see that layer will miss part of your access picture.

Step 4: Put these questions to each vendor in writing

The zero trust draft says enforcement needs API gateways, sidecar proxies, and application identity infrastructures across on-premises and multi-cloud estates. A slide is not enough.

For how this fits a new leader's early agenda, see our CISO first 90 days plan.

What NIST cloud-native guidance asks you to check

Four National Institute of Standards and Technology (NIST) publications describe the parts of a cloud-native stack that a CNAPP says it can see. None of them is a buying standard for a CNAPP. Each one describes an architecture or a set of controls, and that description gives you a fair way to frame questions for a vendor.

Check the status before you quote a document. Three of the four started as initial public drafts. Those draft pages are still online and are now labeled withdrawn.

In plain terms, east-west traffic moves between services, and north-south traffic enters or leaves the environment.

One question set for vendors

These questions are our reading of the four documents. Ask each vendor to answer them with a live demonstration in your own environment, not with slides.

1. Service identities. Show the workload and service identities in our accounts next to the human identities, along with what each one is allowed to call.
2. Mesh visibility. Identify which proxy model we run, which services have no proxy in front of them, and which mesh settings weaken access control.
3. API gateways. Read our gateway and schema configuration, and connect each exposed endpoint to the workload behind it.
4. Data in transit. Show whether sensitive data is classified as it moves between services, or only where it sits in storage.

All four documents are guidance. They describe what NIST examined and recommends. They do not set out what a product must do. Before you put one into a request for proposal (RFP), open its document history page and confirm you are citing the current version.

Who owns a CNAPP once it is bought

Buying a cloud-native application protection platform (CNAPP) settles the tooling question. It does not settle who acts on what the tool finds. In our reading, ownership in most organizations splits three ways, and that split shapes results more than the license does.

How the work usually divides

The finding type tends to decide the fixer. Cloud security posture management (CSPM) findings on shared accounts usually land with platform engineering. Cloud workload protection platform (CWPP) findings, such as a vulnerable package in a container, usually land with the team that owns the service. Cloud infrastructure entitlement management (CIEM) findings are the hardest to place, because an over-permissioned role can belong to an identity team, a platform team or an application team.

In our reading, scale is the reason a central team cannot do the fixing itself. NIST describes cloud-native applications as involving the governance of thousands of services with as many calls between them. We think the security team's realistic job is to set the rules and chase the backlog, while the people who own each service do the repair.

Reporting lines shape who fixes

Where the CISO and the head of platform engineering share a boss, findings tend to compete inside one set of priorities. Where security sits outside engineering, a finding becomes a request to another department, and it waits behind feature work. That is our reading, not a measured result. Our guide to CISO reporting structure and reporting lines report cover how those lines are drawn.

The practical test is simple. Pick an open critical finding and trace who has the authority to make someone fix it this week. If the answer is nobody below the CISO, the tool will produce reports rather than repairs.

What to settle early

• Name an owner for each finding type, and for each cloud account or cluster, before alerts start flowing.
• Route findings into the ticketing and code review tools engineers already use, not a separate console they never open.
• Agree an exception process with an expiry date and a named approver.
• Decide who may change policies and severity rules, so tuning does not happen quietly in one team.
• Give each engineering leader a view of their own open findings, so the backlog has a visible owner outside security.

What this guide does not cover

This guide does not rank, grade or recommend any vendor, and it does not cover pricing. The NIST publications it cites are guidance, not buying standards, and nothing here is legal or financial advice. Check the current version of any document before you cite it in a request for proposal. For the rules and the record behind it, see What Does a CISO Do? Responsibilities, Reporting Lines and Required Skills.