CSPM and CNAPP: what each category actually does

When do you not need one of these platforms yet?

When the estate is small enough to enumerate by hand and the basics are still open. With two or three accounts, no organisation structure, root access unprotected and no central log destination, the findings a platform generates will be the findings you could have predicted, and the work it creates competes with the work that would have fixed them. Buy the structural controls first; they are cheaper and they reduce the finding count rather than counting it.

There is also a staffing threshold. A posture platform produces a continuous stream of items that require a decision, and that decision work is permanent. If no named person has time for a weekly hour on it, the tool will be installed, alert into a channel, and be muted within a quarter, which is the most common outcome in the category and has nothing to do with product quality.

The honest trigger for buying is scale or obligation: more accounts than one person can hold in their head, more than one provider, a compliance regime that requires continuous evidence, or a genuine need to know within hours rather than weeks that something changed. Any of those justifies it. The wish to feel covered does not.

What does CSPM actually do?

Cloud security posture management reads your configuration through the provider's own APIs and evaluates it against a rule set, then reports where the two disagree. There is no agent and no code execution: it enumerates resources, permissions, network rules and service settings on a schedule or from event streams, and compares them with benchmarks such as the CIS Benchmarks for that provider plus its own rules and your custom ones.

That gives it two real strengths. Coverage, because anything the provider's API exposes is visible including in accounts nobody remembers creating, and continuity, because it re-evaluates rather than snapshotting once a year. It also produces the inventory most organisations discover they never had, and mapping findings to control frameworks makes audit evidence collection much less painful.

Its limitation is definitional. Configuration is all it sees, so it cannot tell you whether a vulnerable process is running, whether an exposed path is reachable in practice, or whether a broad permission has ever been used. It will report a security group open to the world on an instance that is stopped with equal urgency to one on your payment service, which is why raw posture findings correlate poorly with actual risk.

What did CNAPP add on top of that?

Correlation, which is the part with real value. A cloud-native application protection platform bundles posture management with workload vulnerability scanning, entitlement analysis, infrastructure-as-code scanning and usually some runtime visibility, and then joins them into one graph. That join is what lets it say the thing no single layer can: this container has a known exploitable vulnerability, it is reachable from the internet, and the identity it holds can read your customer data store.

That statement is a work order. Compare it with the three findings it replaces, each of which is individually unactionable: a vulnerability among thousands, a network rule among hundreds, and a permission grant among tens of thousands. Attack path analysis is the feature to evaluate hardest, because it is the difference between a platform that reduces triage effort and one that multiplies it.

Runtime visibility is the other addition worth understanding, because it involves a deployment decision. Agentless approaches inspect disk snapshots, which is fast to roll out and sees vulnerabilities but not behaviour. Sensors, commonly using eBPF on Linux hosts, see process execution and network connections and can detect something happening now, at the cost of installing something on every node and owning its performance and upgrade story.

Which layer answers which question?

The acronyms describe data sources rather than outcomes, so the useful comparison is what each reads and what it structurally cannot know. Most disappointment with these platforms comes from expecting an answer from a layer that does not hold the input.

Why do these platforms end up unused?

Partial coverage that reads as a clean result. These tools need a read role in every account, and rollout typically stalls partway through, leaving the accounts created by teams outside the process, which are exactly the risky ones, invisible. A dashboard showing few findings across eleven of your nineteen accounts looks identical to a dashboard showing few findings across all of them. Check enrolment against the organisation's own account list, not against the tool's own count.

The second cause is suppression without expiry. Every estate has findings that are accepted for good reasons, and if accepting one is permanent then within a year the suppression list encodes decisions nobody can explain and quietly hides real regressions. Suppressions that expire force a cheap re-decision and keep the list honest, and their absence is a reasonable reason to reject a product.

The third is pricing that fights the deployment. Per-resource or per-workload pricing gives teams an incentive to exclude noisy environments, and the excluded environment is usually the one with the weakest hygiene. Understand the pricing basis before the pilot, because it will shape coverage more than any technical consideration.

What should you ask before buying?

Ask how a finding is dismissed and what happens to that dismissal in six months, because the lifecycle of a decision not to act is where the ongoing workload lives. Ask whether the platform computes reachability and privilege in combination, and make them demonstrate it on your estate during the trial rather than on a prepared demo account. Ask what happens when the provider ships a new service or you open a new region: does coverage extend automatically or wait for a release.

Then ask about writes. Automatic remediation sounds attractive and is the fastest route to an outage caused by security tooling, so establish precisely which actions it can take, whether they are reversible, and how they appear in your audit trail. A platform that changes production without a change record is trading one audit problem for another.

Run the trial with one measurable objective: reduce the findings your team must read to a number they can process weekly, while showing the paths to your most sensitive data store. If a product cannot demonstrate that in a fortnight on your own accounts, more time will not help, because the constraint is the correlation quality rather than the configuration effort.