CSPM: Cloud Security Posture Management
What CSPM does
A CSPM scans the control plane of every cloud account you connect: APIs that describe how resources are configured. It does not look inside workloads (that's vulnerability scanning), and it does not watch live activity (that's CDR).
Typical questions a CSPM answers:
- Are any S3 / Object Storage buckets public?
- Do any RDS / Cloud SQL / Database instances allow connections from
0.0.0.0/0? - Are MFA / 2FA enforced on every IAM identity?
- Are KMS keys rotated within the policy window?
- Is CloudTrail / Cloud Audit Logs / Activity Log enabled and not sampled?
Each question is encoded as a rule. Each rule produces zero or more findings when evaluated against a cloud account.
How CSPM differs from KSPM and DSPM
| Scope | Telemetry | Typical findings | |
|---|---|---|---|
| CSPM | Cloud control plane | Cloud APIs (read-only) | Public bucket, weak IAM, missing encryption |
| KSPM | Kubernetes API | Cluster API server | Privileged pod, host network, missing PSS |
| DSPM | Data inside resources | Object samples, DB queries | PII in object storage, customer phone numbers in a public bucket |
The three are complementary. A typical environment surfaces ~70% CSPM findings, ~20% KSPM, ~10% DSPM by volume, but DSPM findings are usually the most consequential per item.
How Ctadel implements CSPM
- A curated rule library at launch, growing release by release.
- Rules run as queries against the security graph. A single configuration change can fire or silence multiple rules at once, consistently.
- Scan cadence is daily. Resource changes are picked up and re-evaluated on the next scan.
- Drift status is reported alongside each finding:
code_and_cloud(the IaC repo and the cloud both have the misconfig),drift(the cloud diverged from IaC),code_only(the IaC has it but the cloud doesn't yet).
What ends up in a CSPM finding
Every CSPM finding has:
| Field | What it is |
|---|---|
| Rule key | Stable identifier, e.g. AWS-S3-PUBLIC |
| Rule name | Human-readable, e.g. Public S3 bucket |
| Severity | CRITICAL, HIGH, MEDIUM, LOW |
| Resource ID | The cloud resource the rule matched on |
| Region / Project | For grouping |
| Frameworks | Compliance frameworks the rule maps to (SOC 2, PCI-DSS, …) |
| Drift status | See above |
| Remediation | Step-by-step fix |
| References | Vendor docs, CIS benchmarks, MITRE techniques |
Where to use CSPM in Ctadel
- The CSPM module page (
/cspm) shows only configuration findings, with cloud / category / region filters. - The Findings unified page shows CSPM findings alongside everything else.
- The Toxic Combinations page surfaces CSPM findings that participate in attack paths , usually the most actionable angle.
Common pitfalls
- Volume. A fresh tenant with a large AWS account often surfaces hundreds of CSPM findings. Don't try to fix them all. Sort by severity, then by toxic-combo participation, then close the top of the list.
- False urgency on
LOW. ManyLOWfindings are best-practice nudges (e.g. Bucket versioning not enabled). Filter them out of your default view if your team is small. - Compliance-only rules. Some rules exist purely for SOC 2 / ISO 27001 mapping. They don't represent active risk; they exist because an auditor needs them ticked.
What's next
- The security graph, what CSPM rules query against
- Toxic combinations & attack paths
- The CSPM module