--- key: "cloud-security-posture" title: "Choose cloud security posture tools and apply zero trust" url: "https://softwaresecurity.com/domains/runtime/cloud-posture/cloud-security-posture/" api: "https://softwaresecurity.com/api/v1/articles/cloud-security-posture.json" domain: "runtime" topic: "Runtime, cloud \u0026 APIs" type: "Guide" identifiers: ["CWE-1188","CWE-732","CWE-250","A02:2025","A01:2025"] tags: ["Cloud security","Security testing","Vulnerability management","AppSec programs","Compliance and assurance evidence"] stages: ["test","operate","respond","govern"] roles: ["platform-sre"] license: "CC-BY-4.0" license_url: "https://creativecommons.org/licenses/by/4.0/" code_license: "MIT" --- # Choose cloud security posture tools and apply zero trust What CSPM, CWPP, CIEM, CNAPP, DSPM and ASPM each find and miss, how they overlap, how to evaluate one on your own accounts, and how zero trust as defined in NIST SP 800-207 uses what they measure. Canonical URL: https://softwaresecurity.com/domains/runtime/cloud-posture/cloud-security-posture/ ## In short The acronyms name what a tool looks at. CSPM checks cloud configuration against best practices and benchmarks. CWPP protects running workloads from vulnerabilities, malware and runtime threats. CIEM works out who can actually do what across identities and policies. DSPM finds sensitive data and who can reach it. ASPM pulls application findings from SAST, SCA and other scanners together by owner and risk. A CNAPP combines CSPM and CWPP, usually with CIEM, Kubernetes and IaC scanning, and joins their findings into attack paths. Start with your provider's native services and an open-source scanner such as Prowler. Before you buy a platform, test it on a sandbox seeded with known problems and measure what it finds, what it misses and how long triage takes. Zero trust (NIST SP 800-207) is the architecture these signals feed: no trust from network location, and every request authenticated and authorized against policy that takes identity and asset posture into account. - Each category sees one layer: configuration (CSPM), workloads (CWPP), permissions (CIEM), data (DSPM) and application findings (ASPM). None of them sees all four layers of an attack path on its own. - A CNAPP's main value is correlation: an internet-facing instance with a critical CVE and a role that can read a sensitive bucket is one finding, not three. - Native services cover a lot: AWS Security Hub CSPM, Inspector, GuardDuty, Macie and IAM Access Analyzer; Microsoft Defender for Cloud with the free foundational CSPM and the paid Defender CSPM plan; Google Security Command Center. - Products change names and scope. AWS renamed the original Security Hub to Security Hub CSPM, Microsoft retired Entra Permissions Management on 1 November 2025, and Google deprecated DSPM in Security Command Center and is ending its Enterprise tier on 21 May 2027. - Evaluate on a seeded sandbox: known problems with safe twins, then count detections, false positives, time to first finding and minutes of triage per real issue. - Zero trust is an architecture, not a product: a policy engine and administrator decide each session, a policy enforcement point applies the decision, and posture data from these tools is one input. ## Recommended defaults | Setting | Value | Note | Source | | --- | --- | --- | --- | | AWS posture checks | Security Hub CSPM with AWS Foundational Security Best Practices, in every Region you use, aggregated to one Region | Most controls need AWS Config recording. | https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html | | AWS correlated exposure | AWS Security Hub exposure findings | Correlates Security Hub CSPM, Inspector, GuardDuty and Macie signals into attack paths. | https://docs.aws.amazon.com/securityhub/latest/userguide/exposure-findings.html | | AWS unused permissions | IAM Access Analyzer unused access analyzer for the organization, 90-day tracking period | Charged per IAM role and user analyzed. | https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-create-unused.html | | Azure | Defender for Cloud foundational CSPM (free); Defender CSPM plan for attack path analysis, CIEM, agentless scanning and sensitive data discovery | — | https://learn.microsoft.com/en-us/azure/defender-for-cloud/concept-cloud-security-posture-management | | Google Cloud | Security Command Center Premium for Security Health Analytics, CIEM, attack path simulation and threat detection | The Standard tier has limited posture checks. | https://docs.cloud.google.com/security-command-center/docs/service-tiers | | Open-source scanner | Prowler with the CIS benchmark for each provider, output as OCSF JSON | — | https://github.com/prowler-cloud/prowler/tree/5.44.0/prowler/compliance | ## Verify it 1. List every account, subscription and project from your organization root and confirm each one is enrolled in the posture tool; unenrolled accounts are the usual blind spot. 2. Deploy the seeded sandbox and confirm each planted problem produces a finding within the time the vendor claims, and that the safe twins produce none. 3. Remediate one seeded finding and confirm the tool closes it, and that reverting the fix reopens it. 4. Pick one attack path the tool reports and check each link by hand: exposure, vulnerability, permission and data. 5. Export findings through the API in OCSF or ASFF and confirm your ticketing or SIEM receives them with owner and account fields. ## What you will learn - Explain what CSPM, CWPP, CIEM, DSPM, ASPM and a CNAPP each look at and what each misses. - Start with native services and an open-source scanner, and measure what they find. - Evaluate a commercial platform with a seeded sandbox and a triage-cost estimate. - Map the tenets and components of NIST SP 800-207 to concrete engineering controls. Audience: Cloud security and platform engineers choosing, deploying or tuning posture tools, and architects asked what zero trust means for their systems Before you start: - Know your cloud accounts, subscriptions or projects and who owns them. - Read IAM policies and basic network rules on at least one provider. Time: About 31 minutes: 8 to read and 23 for the exercise ## What each category looks at The names come from analyst firms and vendors, not from a standards body, so products labeled the same way can differ a lot. Judge a tool by its data sources: cloud APIs and configuration, an agent or disk snapshot on the workload, identity policies with activity logs, data store contents, or scanner output. That determines what it can see. | Category | Finds | Reads | Misses | Native and open-source examples | | --- | --- | --- | --- | --- | | CSPM, cloud security posture management | Public storage, open admin ports, logging off, unencrypted resources, benchmark failures | Cloud control-plane APIs and configuration | What runs inside workloads; whether a permission is ever used | AWS Security Hub CSPM, Defender for Cloud CSPM, Security Command Center Security Health Analytics; Prowler, Cloud Custodian | | CWPP, cloud workload protection | Vulnerable packages, malware, runtime attacks on VMs, containers and functions | Agent, eBPF sensor or snapshots of disks and images | Cloud configuration outside the workload | Amazon Inspector, GuardDuty Runtime Monitoring, Defender for Servers and Containers; Trivy, Falco | | CIEM, cloud infrastructure entitlement management | Unused and excessive permissions, risky trust relationships, privilege escalation paths | IAM policies, role trust and activity logs | Permissions granted inside applications and databases | IAM Access Analyzer, CIEM in the Defender CSPM plan, Security Command Center CIEM; Cartography | | DSPM, data security posture management | Where sensitive data lives, how it is classified and who can reach it | Samples of data in storage and databases | Data in transit or inside SaaS it cannot read | Amazon Macie, Microsoft Purview and Defender CSPM data discovery, Google Sensitive Data Protection | | ASPM, application security posture management | Deduplicated SAST, SCA, secrets, IaC and DAST findings by owner and risk | Scanner results, repositories and pipelines | Anything its scanners miss; it adds no detection of its own | OWASP DefectDojo, OWASP Dependency-Track for components, code scanning dashboards | | CNAPP, cloud-native application protection platform | The above combined, with attack paths across them | All of the above | Coverage gaps of each component; application logic | Defender for Cloud, Security Command Center Premium, AWS Security Hub exposure findings | ## Where they overlap, and why correlation matters Real attacks cross the layers. Take a virtual machine reachable from the internet on SSH, running a package with a known remote code execution flaw, whose role can read every bucket, one of which holds customer records. A CSPM reports the open port, a CWPP the vulnerable package, a CIEM the broad role, and a DSPM the sensitive bucket: four medium findings in four queues. Joined, they are one critical path from the internet to customer data, and fixing any single link breaks it. That join is what CNAPPs and the cloud providers' exposure features sell. AWS Security Hub builds exposure findings from Security Hub CSPM, Inspector, GuardDuty and Macie signals, and shows unused permissions from IAM Access Analyzer as context. AWS's example is an instance with a vulnerability whose role has 47 unused permissions across 5 services. Correlation is only as good as the inventory beneath it, so check that every account and Region is enrolled before trusting a quiet dashboard. ASPM does the same for application findings: one vulnerable library reported by three scanners and in twenty repositories should become a few tickets with owners, not sixty alerts. The application security tool guide at /domains/appsec/testing/appsec-tool-categories-and-evaluation/ covers what each scanner category finds. ## Start with native services and one open-source scanner Turn on the provider's posture service in every account first, because it needs no procurement and covers the provider's own services as they change. Add an open-source scanner as a second opinion and for multi-cloud reports in one format. Prowler 5.44 supports CIS benchmarks for AWS (up to 7.0), Azure (up to 6.0), Google Cloud (up to 5.0) and Kubernetes (up to 2.0.1), among many other frameworks, and writes CSV, HTML, OCSF JSON and ASFF JSON; SARIF output is for its infrastructure-as-code scans only. Expect disagreement between tools. Rule sets lag service changes, and scanners can be wrong about provider defaults, as the cloud provider baselines guide at /domains/runtime/cloud-posture/cloud-provider-baselines/ shows for Checkov and Azure. Treat each disagreement as a question to settle against the provider's documentation, not a vote. ```bash # AWS: posture checks, unused access and a second opinion from an open-source scanner. aws securityhub enable-security-hub --enable-default-standards # Security Hub CSPM, per Region aws accessanalyzer create-analyzer --analyzer-name org-unused-access \ --type ORGANIZATION_UNUSED_ACCESS \ --configuration '{"unusedAccess":{"unusedAccessAge":90}}' # Prowler 5.44 with a read-only role; exit code 3 means at least one unmuted check failed. docker run --rm -v "$HOME/.aws:/home/prowler/.aws:ro" -v "$PWD/out:/home/prowler/output" \ prowlercloud/prowler:5.44.0@sha256:9dbcc3c9abd71ec6d37610e6a5a2c45279bc6488caf8aaa948a9e8e368622d30 \ aws --compliance cis_7.0_aws --status FAIL --output-formats csv json-ocsf html # The same scanner for the other providers and Kubernetes. # prowler azure --compliance cis_6.0_azure # prowler gcp --compliance cis_5.0_gcp # prowler kubernetes --compliance cis_2.0.1_kubernetes ``` ## Evaluate a platform on a seeded sandbox Demos run on the vendor's data. Run yours on a sandbox you control, seeded with problems whose answers you know, and with safe twins that should produce no finding. Write the expected results down before the trial starts. Then measure the tool rather than the brochure. Weight triage cost heavily. Count how many alerts an engineer must open to confirm each real issue, and time a sample: a tool that reports twice as many findings is worse if half of them are noise. Check that a finding names the exact resource, account and owner, and that suppressions carry a reason and an expiry. ```hcl # seeded.tf: a sandbox account with known problems and their safe twins. # Each resource is tagged with the finding a posture tool should raise (or not). resource "aws_s3_bucket" "p1_public_reports" { # P1: public bucket with test PII bucket = "eval-p1-public-reports-${var.suffix}" tags = { expected = "public-bucket" } } resource "aws_s3_bucket_public_access_block" "p1" { bucket = aws_s3_bucket.p1_public_reports.id block_public_policy = false restrict_public_buckets = false } resource "aws_security_group" "p2_ssh_world" { # P2: SSH from anywhere name = "eval-p2-ssh-world" ingress { from_port = 22 to_port = 22 protocol = "tcp" cidr_blocks = ["0.0.0.0/0"] } tags = { expected = "open-admin-port" } } resource "aws_security_group" "n2_ssh_bastion" { # N2: SSH only from the VPN range name = "eval-n2-ssh-vpn" ingress { from_port = 22 to_port = 22 protocol = "tcp" cidr_blocks = ["10.20.0.0/16"] } tags = { expected = "none" } } resource "aws_iam_role_policy_attachment" "p3_app_s3_full" { # P3: app role with s3:* on every bucket role = aws_iam_role.app.name policy_arn = "arn:aws:iam::aws:policy/AmazonS3FullAccess" } # P4: an EC2 instance from an old AMI with a known critical CVE, in P2's group, using the app role. # Expected: CSPM flags P2, CWPP flags the CVE, CIEM flags P3, and an attack path joins them to P1. ``` ## Selection criteria | Criterion | What to measure in the trial | | --- | --- | | Coverage | Share of your accounts, Regions, services, clusters and data stores it can see, including new accounts joining automatically | | Detection | Seeded problems found, by layer, and time from deployment to first finding | | Precision | Findings on safe twins, and duplicates per real issue | | Correlation | Whether the seeded attack path appears as one finding with every link correct | | Agent and access model | Agentless snapshot scanning, agents or both; the permissions its role needs in your accounts | | Code-to-cloud | Whether a finding maps back to the Terraform or manifest that created the resource | | Workflow | Ownership, ticketing, suppressions with expiry, and API export in OCSF or ASFF | | Data handling | Where scan data and samples are stored, and for how long | | Cost model | Price per resource, workload or account, and the cost at next year's size | ## Zero trust as NIST SP 800-207 defines it NIST SP 800-207 (August 2020) defines zero trust as granting no implicit trust based on network location or asset ownership, and treating authentication and authorization of the subject and device as discrete steps before each session to a resource. Its seven tenets: every data source and computing service is a resource; all communication is secured regardless of network location; access is granted per session; access is decided by dynamic policy that includes the client's identity, the application and the requesting asset's state; the enterprise monitors the integrity and security posture of all assets; authentication and authorization are dynamic and strictly enforced before access; and the enterprise collects as much information as it can about assets, network and communications to improve its posture. The architecture has three logical components. The policy engine makes and logs each decision, the policy administrator sets up or tears down the session, and together they form the policy decision point. The policy enforcement point sits in the data path and enables, monitors and ends connections. Inputs include continuous diagnostics and mitigation data, threat intelligence, activity logs and identity management, which is where posture and workload tools feed in. The document describes three approaches: enhanced identity governance, micro-segmentation, and network infrastructure with software-defined perimeters. For engineers, that means checking every service-to-service call against the caller's workload identity instead of its subnet, with mTLS and authorization policy as in the workload mTLS guide at /domains/runtime/service-security/workload-mtls-serverless/. Use short-lived credentials from federation instead of keys. Make device and workload posture an input to access decisions for administrative paths, and log every decision. SP 800-207A (September 2023) applies this to cloud-native applications with service identities and proxies, and SP 1800-35 (June 2025) documents 19 example implementations built with 24 collaborators. CISA's Zero Trust Maturity Model 2.0 grades progress in five pillars (identity, devices, networks, applications and workloads, data) through four stages: traditional, initial, advanced and optimal. ## Pitfalls - Buying by category name: two CNAPPs can cover very different services and layers. - Measuring success by findings closed rather than attack paths broken. - Leaving accounts, Regions or clusters unenrolled, so dashboards look clean because they cannot see. - Suppressing a noisy check everywhere instead of per resource with a reason and an expiry. - Calling a network segmentation project zero trust while services still trust any caller on the network. - Giving the posture tool's role more access than it needs; it reads your whole estate and is a target. ## Guided practice Two posture platforms ran for two weeks on the same seeded sandbox. Use the results to recommend one, or neither. ### Supplied material ```text Seeded problems (P) and safe twins (N) P1 public S3 bucket with test PII N1 private bucket with the same data P2 SSH open to 0.0.0.0/0 N2 SSH open to the VPN range only P3 app role with s3:* on all buckets N3 app role scoped to one bucket P4 EC2 instance with a critical RCE CVE, using P2 and P3 P5 IAM user with an access key unused for 200 days P6 CloudTrail stopped in one Region Expected attack path: internet -> P2 -> P4 -> P3 -> P1 Platform A: found P1, P2, P3, P4, P6; missed P5; flagged N2 ("SSH open"); attack path shown with all links 1,240 findings in total in the sandbox; median 4 min to triage a finding Platform B: found P1, P2, P3, P4, P5, P6; no findings on N1-N3; attack path missing P3 310 findings in total; median 6 min to triage; findings in one AWS Region only until a setting was changed ``` ### 1. Score detection Compute each platform's detection rate and false positives on the seeded set. Worked answer: A: 5 of 6 problems, 1 false positive (N2). B: 6 of 6, no false positives on the twins. Both found the internet-facing and vulnerability links. ### 2. Weigh correlation How much should the attack path result count? Worked answer: A lot: A showed the full path, so fixing any link is prioritized correctly; B missed the permission link and would rank the path lower. Ask B whether that is a data gap (CIEM coverage) or a configuration issue. ### 3. Estimate triage cost Compare the effort of running each in production. Worked answer: A: 1,240 findings at 4 minutes is about 83 hours; B: 310 at 6 minutes is about 31 hours. B's lower noise outweighs its slower per-finding time, unless A's extra findings are real issues the seeded set did not cover. ### 4. Check coverage What does B's one-Region behavior tell you? Worked answer: Coverage depends on configuration. Verify that both platforms see every account and Region before comparing numbers, and repeat the trial after fixing B's setting. ### 5. Recommend Write the recommendation and the condition that would change it. Worked answer: Prefer B for precision and coverage of identity hygiene (P5), conditional on fixing its Region setting and demonstrating the P3 link in attack paths; choose A only if its extra findings prove to be real issues. Deliverable: A one-page recommendation with detection, false positives, correlation quality and estimated triage hours for each platform, and the follow-up tests you would require before signing. Scope: The trial results are invented for the exercise; the evaluation method applies to any posture tool. Prowler options on this page were checked against Prowler 5.44.0; the native service descriptions come from provider documentation as of October 2026. Articles and teaching material: CC BY 4.0. Original executable code: MIT. Attribution: Software Security. ## Sources - [NIST SP 800-207: Zero Trust Architecture](https://csrc.nist.gov/pubs/sp/800/207/final). August 2020. - [NIST SP 800-207A: zero trust for cloud-native applications in multi-cloud environments](https://csrc.nist.gov/pubs/sp/800/207/a/final). September 2023. - [NIST SP 1800-35: Implementing a Zero Trust Architecture](https://csrc.nist.gov/pubs/sp/1800/35/final). June 2025. - [CISA Zero Trust Maturity Model](https://www.cisa.gov/zero-trust-maturity-model). Version 2.0 (April 2023). - [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) - [AWS Security Hub: exposure findings](https://docs.aws.amazon.com/securityhub/latest/userguide/exposure-findings.html) - [IAM Access Analyzer: unused access analyzers](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-create-unused.html) - [Microsoft Defender for Cloud: cloud security posture management](https://learn.microsoft.com/en-us/azure/defender-for-cloud/concept-cloud-security-posture-management) - [Microsoft Entra Permissions Management: end of sale and retirement notice](https://learn.microsoft.com/en-us/previous-versions/entra/permissions-management/whats-new-in-permissions-management) - [Microsoft Defender for Cloud: cloud infrastructure entitlement management](https://learn.microsoft.com/en-us/azure/defender-for-cloud/permissions-management) - [Google Security Command Center service tiers](https://docs.cloud.google.com/security-command-center/docs/service-tiers) - [Google Security Command Center: deprecations (DSPM and the Enterprise tier)](https://docs.cloud.google.com/security-command-center/docs/deprecations) - [Prowler 5.44.0: compliance frameworks by provider](https://github.com/prowler-cloud/prowler/tree/5.44.0/prowler/compliance) - [Prowler: reporting and output formats](https://docs.prowler.com/user-guide/cli/tutorials/reporting) - [OWASP DefectDojo](https://owasp.org/projects/defectdojo)