Cloud security posture management (CSPM)

CSPM connects to a cloud account through its API, reads the configuration of the resources, and compares it against a set of rules: public storage, over-permissive roles, unencrypted volumes, missing logging, and similar. It runs continuously, so drift from the baseline is flagged as it happens, and it reports against compliance frameworks. It is worth placing next to its neighbours. CIEM focuses specifically on identities and entitlements, answering who can do what. CNAPP is the broader platform that typically bundles posture management, workload protection and entitlement analysis into one product. CSPM is the posture-and-misconfiguration layer of that stack, and it is often bought and used on its own.

The limitation is that posture tools report settings, not reachability. A CSPM produces a long list of findings, each technically true, and treats them as roughly equal because it cannot see how they chain. From the attacker’s side, most of that list is irrelevant and a handful of items combine into a real path: a modest cloud misconfiguration that only matters because of the identity relationship two findings away. Teams drown in the list, remediate the easy items, and miss the chain, which is the opposite of a risk-based approach. The tool is a good inventory of what is wrong; it is a poor guide to what is dangerous.

Clients frequently bring us a CSPM report and ask what actually matters in it. We validate the findings by attempting to exploit them, map which ones connect into an attack path, and re-prioritise the list against real reachability rather than the tool’s generic severity. Findings that hold up are written with the impact demonstrated; findings that do not are noted as low priority with the reason. Where the root cause is a template, we point the fix at infrastructure as code. This is part of how we validate posture findings against real impact.