CNAPP Guide: CSPM, CWPP, CIEM and CDR

Cloud estates generate more security findings than any team can fix, and most of the findings that matter only become dangerous in combination. A public virtual machine with a known vulnerability is a ticket; the same machine with an attached role that can read a production database is a breach path. Cloud-native application protection platforms (CNAPPs) bring posture management, workload protection, entitlement analysis, code scanning and runtime detection together so those combinations can be seen and ranked. This guide explains each CNAPP component, agent versus agentless scanning, attack path analysis, how to wire findings into CI/CD and ticketing, and when consolidation helps or hurts. It is written for cloud security engineers, platform teams and security architects, and it is vendor-neutral: cloud provider native tools are named only as documented examples.

Key takeaways

• A CNAPP is a convergence, not a single control: CSPM, CWPP, CIEM, KSPM, IaC scanning, DSPM and cloud detection and response (CDR) each answer a different question, and the value comes from correlating them on one asset graph.
• Posture and runtime are both needed: CSPM finds what could be exploited, CDR finds what is being exploited now. Posture without runtime misses stolen-key abuse; runtime without posture drowns in preventable incidents.
• Identity is usually the bridge in a cloud attack path: over-permissioned roles, long-lived access keys and service accounts attached to exposed workloads turn a single vulnerability into data access.
• Prioritise on reachability and blast radius, not severity: internet exposure, exploitable vulnerability, privileged identity and sensitive data together are a "toxic combination"; any one alone rarely is.
• Fixes belong in code and with owners: route findings to the team that owns the resource, fix the Terraform or template rather than the console, and measure time to remediate by severity.

What a CNAPP is and what it is not

Microsoft's documentation for Defender for Cloud describes a CNAPP as "a unified solution that combines multiple cloud security tools to protect applications across their entire lifecycle", grouped into posture management (CSPM), workload protection (CWPP) and DevSecOps. Other cloud providers document comparable building blocks: AWS Security Hub CSPM checks accounts against the AWS Foundational Security Best Practices (FSBP), CIS, PCI DSS and NIST standards, and Google Security Command Center combines misconfiguration findings, threat detection and posture management.

A CNAPP does not replace the provider's own logging, identity or network controls, and it does not own remediation. It is a detection, correlation and prioritisation layer whose findings other teams fix, with an inventory at its core.

• Scope: IaaS and PaaS configuration, compute (virtual machines, containers, serverless), Kubernetes, data stores, identities and entitlements, and the pipelines and templates that create them.
• Shared responsibility: NIST SP 800-210 treats IaaS, PaaS and SaaS access control as hierarchical, so controls at the infrastructure layer also apply to the same components higher up. A CNAPP covers your side of the shared responsibility model; it cannot see inside the provider's side.
• Not SaaS posture: SaaS settings and OAuth grants are usually out of scope. See the SaaS and OAuth App Governance Guide.

The components and what each finds

NIST SP 800-190 groups container risk into image, registry, orchestrator, container and host OS risks, which map to CWPP and KSPM. The CSA Cloud Controls Matrix v4.1 (197 control objectives in 17 domains) gives a provider-neutral control set, alongside CIS Benchmarks for each cloud and for AKS, EKS and GKE.

Agent versus agentless scanning

Agentless scanning reads configuration through APIs and inspects workloads by taking a snapshot of each disk and analysing it out of band. Microsoft's documentation, as one example, describes copying the root and data disk snapshots, analysing them in a "regional, volatile, isolated" scanning environment in the same region, and deleting them, "typically" within "a few minutes". The scan finds software inventory, vulnerabilities, EDR settings, malware and "plain text secrets", and "doesn't need any installed agents or network connectivity, and doesn't affect machine performance."

Decision guidance: start agentless for fast inventory and posture everywhere, then add runtime sensors where live detection justifies the overhead: internet-facing services, production Kubernetes nodes, and hosts holding sensitive data or privileged identities. Serverless and managed PaaS usually rely on audit-log based CDR. The scanner is itself a privileged NHI: Microsoft documents a scoped "VM scanner operator" role in Azure and a "VmScanner" role in AWS. Include such roles in entitlement reviews.

Where identity fits: CIEM and cloud non-human identities

Identity often decides whether a misconfiguration becomes a breach. Many cloud identities are non-human: instance roles, managed identities, service principals, service accounts, Kubernetes service accounts and access keys created for pipelines and integrations. An attacker inherits their permissions the moment they control the workload or steal the credential. The Capital One Breach 2019 is the textbook path: a server-side request forgery against a firewall returned the role credentials of the instance, and those credentials could list and read storage buckets.

• Effective permissions, not policy text: CIEM calculates what an identity can actually do once group membership, role assumption, resource policies and permission boundaries are combined. Microsoft describes evaluating "effective permissions to identify identities that can reach sensitive or business-critical resources" across Entra ID service principals, AWS IAM roles and Google Cloud service accounts.
• Unused access: AWS IAM Access Analyzer documents unused access findings for unused roles, unused access keys, unused console passwords and unused services and actions on active roles. These are among the cheapest risk reductions available.
• Long-lived keys: static access keys in code, environment files and CI variables are a recurring initial access route. The 230 Million AWS Cloud Environments Campaign 2024 fed on exposed .env files. Prefer workload identity federation and short-lived tokens. See the Cloud Workload Identity Guide.
• Metadata service: workloads that can be made to fetch arbitrary URLs can leak instance credentials (ATT&CK T1552.005, Cloud Instance Metadata API). Require session-token based metadata access such as AWS IMDSv2 and flag instances that still allow the older version.
• Kubernetes service accounts: KSPM should flag cluster-admin bindings, automounted tokens on pods that do not call the API, and workload identity mappings to over-permissioned cloud roles. See the Kubernetes NHI Security Guide.
• Remediation ownership: right-size production roles with the service owner, using observed activity (for example policy generation from CloudTrail). See the Cloud PAM and CIEM Guide for entitlement programme design and just-in-time access for humans.

Attack path analysis and prioritisation

Attack path analysis models the estate as a graph of assets, network exposure, identities, permissions, vulnerabilities and data, then searches it for routes from an entry point to a valuable target. Microsoft describes an attack path as "a series of steps a potential attacker uses to breach your environment", starting at "an external entry point, such as an internet-exposed vulnerable resource" and moving laterally "using attached identities with permissions to other resources" until it reaches "databases containing sensitive data". Google's Security Command Center documentation uses the terms attack exposure scores, toxic combinations and chokepoints for the same idea.

Fix the chokepoint first: removing an over-permissioned role shared by twenty workloads usually beats patching twenty hosts. Graph engines infer reachability, so confirm before declaring an emergency, and use CVSS severity only as a tie-breaker: a critical CVE on an isolated build host with no identity attached matters less than a medium misconfiguration that exposes an admin role.

Posture versus runtime: CSPM and CDR together

CSPM and CDR are often presented as alternatives, but they cover different phases of an attack. Posture management reduces the paths available; runtime detection catches the attacker who uses a path still open, or valid credentials no posture check flags. Stolen keys are the clearest example: the Amazon AWS Crypto-Mining Campaign 2025 had miners running within minutes of compromised IAM credentials being used, and the Codefinger S3 Ransomware 2025 used stolen keys with the provider's own encryption. Neither is visible to a configuration scan.

Small organisations on one cloud usually get most value from the provider's native posture and threat detection services, enabled in every region and account. Larger, multi-cloud estates need cross-cloud correlation and consistent policy, which is where a third-party CNAPP earns its cost. Either way, send CDR alerts to the main security operations queue. See the SIEM Guide.

Integrating with CI/CD and ticketing

Misconfigurations created by templates come back on the next deployment if fixed only in the console. "Code to cloud" correlation links a finding to the repository and commit that created the resource, so the fix lands in code. Microsoft's DevOps security documentation, for example, covers Azure DevOps, GitHub and GitLab, with findings from "code, secrets, and open-source dependency vulnerability scans" and IaC, and describes "code-to-cloud contextual insights" and pull request annotations.

1. Scan IaC in pull requests: run policy checks on Terraform, CloudFormation, Bicep, Helm charts and Kubernetes manifests. Start in warn mode, then block merges only for a short list of high-confidence rules (public storage, wildcard IAM actions, privileged pods, disabled encryption).
2. Scan images in the registry and at admission: block images with known exploited vulnerabilities or no provenance from reaching production clusters, using an admission controller and Kubernetes Pod Security Admission (enforce, audit and warn modes against the Baseline and Restricted profiles).
3. Scan for secrets: in repositories, images and build logs. A detected cloud key must be revoked, not just deleted from the file. See the Secrets Management Guide.
4. Protect the pipeline's own identity: the deployment role can usually change everything the CNAPP is watching. Use short-lived federated credentials for pipelines. See the CI/CD Pipeline Identity Security Guide.
5. Route findings to owners automatically: map cloud accounts, subscriptions, projects and tags to teams. Microsoft's governance rules, as one documented example, assign an owner from a resource tag and a due date of 7, 14, 30 or 90 days, email owners weekly and escalate overdue items to managers. AWS Security Hub sends findings through EventBridge to "a ticketing system or to an automated remediation system".
6. Deduplicate and close the loop: one ticket per root cause (a module, an image, a role), verified closed on the next scan; record accepted risks with an expiry date.

Implementing a CNAPP programme

1. Inventory and connect: connect every cloud account, subscription and project, including sandboxes and acquired environments, using read-only roles. Enable posture checks in every region; AWS notes that full CIS AWS Foundations Benchmark compliance checking requires Security Hub CSPM in all supported Regions.
2. Baseline: pick one benchmark per cloud and one for Kubernetes, and record starting counts of critical findings, public resources, unused identities and long-lived keys.
3. Quick wins (low breakage risk): remove public access to data stores, delete unused keys and inactive identities, enforce metadata service v2, and enable audit logging everywhere.
4. Attack paths: turn on attack path analysis and fix chokepoints that reach sensitive data. Add DSPM classification so targets are known.
5. Shift left in pilot: enable IaC scanning in warn mode for two or three platform teams, measure noise, tune rules, then enforce a small blocking set.
6. Runtime: enable CDR and runtime sensors on production Kubernetes and internet-facing workloads first, testing response actions in a non-production account.
7. Automate remediation carefully: auto-remediate only reversible, low-impact changes (re-enabling logging, removing a public ACL on a bucket tagged non-public). Everything else goes to a ticket.
8. Rollback plan: every enforcement step (pipeline blocking rule, admission policy, auto-remediation) needs a documented bypass with approval and expiry, and should be switched back to audit mode if it blocks a critical release.

Consolidation trade-offs

• Benefit, correlation: a single graph, inventory and ownership model is what makes attack paths possible; separate tools cannot easily say that this CVE sits on the host with that role.
• Cost, depth: a converged platform may be weaker in one area (for example runtime response or code scanning) than a specialist tool. Check the components that matter most to your estate rather than the feature count.
• Cost, concentration: the CNAPP's own cross-account roles, API keys and console become a high-value target with read access to every account. Protect administrator access with phishing-resistant MFA and review the platform's integration roles as privileged NHIs.
• Cost, native overlap: provider native tools may already be licensed and integrate more deeply with their own cloud.

Detection and measurement

Feed control plane audit logs (CloudTrail, Azure Activity and Entra sign-in logs, Google Cloud Audit Logs) and Kubernetes audit logs into detection, and alert on changes to the CNAPP's own roles and connectors.

• Coverage: percentage of accounts, subscriptions and projects connected, and of production workloads with runtime coverage.
• Toxic combinations open: count of attack paths that reach sensitive data, trended weekly. This should fall steadily after the first quarter.
• Mean time to remediate by severity: measured from first detection to verified closure, with separate figures for code fixes and console fixes.
• Unused and long-lived credentials: number of access keys older than 90 days and identities unused for 90 days.
• Prevented misconfigurations: findings blocked or fixed in pull requests compared with findings first seen in runtime. A rising ratio shows shift-left is working.
• CDR alert quality: percentage of high-severity cloud alerts triaged within the SLA, and false positive rate.

Framework mapping

For threat coverage, test CDR content against the ATT&CK Cloud matrix (v20), in particular T1078.004 Valid Accounts: Cloud Accounts, T1190 Exploit Public-Facing Application, T1552.005 Cloud Instance Metadata API, T1528 Steal Application Access Token, T1098.003 Additional Cloud Roles, T1580 Cloud Infrastructure Discovery, T1530 Data from Cloud Storage, T1578 Modify Cloud Compute Infrastructure, T1535 Unused/Unsupported Cloud Regions and T1496 Resource Hijacking.

Common failure patterns

• Connecting only production: forgotten development and test accounts often hold trust relationships into production. Connect everything.
• Treating the CNAPP as a compliance dashboard: a high benchmark score with open paths to sensitive data is false comfort. Report toxic combinations, not just pass rates.
• Ignoring Kubernetes control planes: the Tesla Kubernetes Cryptojacking 2018 began with an exposed console that held cloud credentials. KSPM must check API server and dashboard exposure, not just pod settings.
• Deleting secrets without revoking them: secret scanning that removes a key from a file but leaves it valid only hides the evidence. Rotation and revocation must be part of the workflow.
• Over-permissive sharing links: storage access tokens and pre-signed URLs escape posture checks that only look at bucket policies, as the Microsoft SAS Token Exposure 2023 showed. Include token-based sharing in DSPM and CSPM scope.
• Per-resource tickets: thousands of identical, ownerless findings end up muted. Group by root cause and owner first.

Practitioner checklist

• Connect every cloud account, subscription, project and cluster, with posture checks enabled in all regions.
• Choose one benchmark per cloud and for Kubernetes, and record a baseline.
• Remove unused identities and access keys, and replace long-lived keys with federated workload identity.
• Enforce session-token metadata access and flag workloads with admin roles attached.
• Enable attack path analysis and DSPM, and fix chokepoints that reach sensitive data first.
• Scan IaC, images and secrets in pull requests; enforce a short blocking rule set after a warn-mode pilot.
• Deploy runtime detection to production Kubernetes and internet-facing workloads, and route CDR alerts to the SOC.
• Map findings to owners automatically, group by root cause, and track time to remediate by severity.
• Review the CNAPP's own integration roles, scanner roles and admin accounts as privileged NHIs.

Standards and references

• NIST: SP 800-190, Application Container Security Guide
• NIST: SP 800-210, General Access Control Guidance for Cloud Systems
• Cloud Security Alliance: Cloud Controls Matrix (CCM)
• CIS: CIS Benchmarks
• MITRE ATT&CK: Cloud Matrix
• Microsoft Learn: Attack path analysis in Defender for Cloud
• AWS: What is IAM Access Analyzer?
• AWS: Security Hub CSPM User Guide

Related NHI Mgmt Group resources: Cloud PAM and CIEM Guide · Cloud Workload Identity Guide · Kubernetes NHI Security Guide · Secrets Management Guide · CI/CD Pipeline Identity Security Guide