Cloud Security Posture Management

The headline cloud breaches of the past decade were not won by nation-state exploit chains or novel zero-days. They were won by attackers who found an S3 bucket with acl: public-read, an IAM role with Action: "*", or a security group with 0.0.0.0/0 on port 22 — and walked right in. Misconfiguration is the dominant attack vector in cloud environments. One 2025 study pegged it as responsible for 99% of cloud security failures, with organizations averaging over 3,000 misconfigured assets at any given time and a mean detection time of 241 days. The cloud’s shared-responsibility model makes this entirely your problem: AWS, Azure, and GCP handle the security of the cloud. You handle security in the cloud — meaning every IAM policy, every storage ACL, every network rule, and every logging switch you leave in its default state is your liability.

Cloud Security Posture Management is the practice of continuously inventorying and evaluating those configurations against a defined security baseline, finding gaps, and tracking remediation. It does not protect you from runtime threats — it does not detect a cryptominer that just executed on your EC2 instance or a container that escaped its sandbox. What it does is eliminate the low-hanging fruit that makes your environment an easy target: the open bucket, the wildcard policy, the CloudTrail that was never turned on. Get the posture clean and you’ve removed the attacks that work at scale. What remains requires much harder, targeted exploitation.

The Agentless Scanning Model

CSPM tools operate differently from traditional endpoint security. There are no agents to deploy, no kernel modules to load, and nothing to patch on your hosts. A CSPM scanner authenticates to the cloud provider’s control plane APIs — the same APIs the console uses — with read-only credentials and walks the resource graph.

  Cloud Control Plane APIs
  ┌────────────────────────────────────────┐
  │  IAM  │  S3   │  EC2  │  RDS  │  VPC  │
  │  API  │  API  │  API  │  API  │  API  │
  └────────────────────────────────────────┘
              │ read-only credentials
              ▼
  ┌─────────────────────────┐
  │      CSPM Scanner       │
  │  (Prowler / ScoutSuite  │
  │   / Steampipe)          │
  │                         │
  │  1. Enumerate resources │
  │  2. Fetch config        │
  │  3. Evaluate checks     │
  │  4. Map to frameworks   │
  └─────────────────────────┘
              │
              ▼
  ┌─────────────────────────┐
  │  Findings / Compliance  │
  │  Report                 │
  │  CSV / JSON / HTML /    │
  │  SARIF / ASFF           │
  └─────────────────────────┘
              │
     ┌────────┴────────┐
     ▼                 ▼
  SIEM / Slack    Ticketing /
  Alerting        Dashboard

The strength of this model is universal coverage with minimal operational overhead. You don’t need the cloud provider’s consent to deploy an agent on every VM, there’s no performance impact on workloads, and you can stand up a full assessment of a new account in minutes by handing the scanner a role ARN. A single scanner can cover hundreds of accounts across multiple cloud providers with the same codebase.

The blind spot is equally fundamental: the scanner sees configuration, not behavior. It can tell you that an EC2 instance has IMDSv1 enabled (a known attack vector) but it cannot tell you whether an attacker is currently exploiting that fact by querying the metadata service from inside the instance. It can verify that S3 server-side encryption is enabled, but it cannot detect whether someone exfiltrated data through a legitimate IAM role five minutes ago. For runtime behavioral coverage you need a separate layer — Cloud Workload Protection Platform (CWPP) capabilities, which is why the industry has been consolidating CSPM into larger Cloud-Native Application Protection Platform (CNAPP) suites. Gartner projected that 75% of new CSPM purchases would come from CNAPP bundles by 2025, and in 2026 that transition is largely complete among enterprise buyers. But the CSPM layer itself — the configuration audit — remains the foundation, and it’s available entirely in open source.

Open-Source Tools in Depth

Three tools cover the practical space for teams doing this themselves. They are complementary, not competitive.

Prowler

Prowler is the most operationally complete open-source CSPM available. Written in Python, it runs hundreds of checks across AWS, Azure, GCP, Kubernetes, GitHub, Microsoft 365, OCI, and Alibaba Cloud. Version 5.x introduced a full self-hosted application (multi-container docker-compose deployment with RBAC and a web dashboard), but the CLI remains the workhorse and what you’ll run in automation.

The thing that makes Prowler stand apart from point tools is its compliance framework mapping. Every check is tagged to one or more framework controls: CIS Benchmarks, NIST 800-53, NIST CSF, PCI-DSS, SOC 2, HIPAA, GDPR, FedRAMP, ISO 27001, MITRE ATT&CK, and more. When you run it with --compliance, you don’t get a pile of unrelated findings — you get a compliance report showing your pass/fail rate against every control in the specified framework, which is the artifact your auditor or security team actually needs.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

# Install
pip install prowler

# List available compliance frameworks for AWS
prowler aws --list-compliance

# Full AWS scan against CIS Foundations Benchmark v5.0
prowler aws \
  --compliance cis_5.0_aws \
  --severity medium high critical \
  --output-formats json csv sarif \
  --output-directory ./prowler-output

# Scope to IAM checks only, output ASFF for Security Hub
prowler aws --service iam --severity high critical --output-formats json-asff

# Azure CIS and GCP PCI-DSS
prowler azure --compliance cis_2.0_azure
prowler gcp --compliance pci_4.0_gcp

Output formats matter for downstream integration. json-asff (Amazon Security Finding Format) feeds directly into AWS Security Hub. sarif enables findings to appear as inline annotations in GitHub pull requests. csv drops into a SIEM or spreadsheet for tracking. The compliance/ subdirectory Prowler creates alongside scan output contains per-framework CSV reports covering every requirement, every check, and every finding — suitable for handing to an auditor.

Prowler v5 also introduced ThreatScore, a risk-weighted prioritization system that accounts for severity, exposure, and exploitability rather than treating all high-severity findings as equally urgent. The Attack Paths feature (currently AWS-only) integrates with Neo4j to build a graph of exploitable chains — for example, an internet-facing EC2 instance with an overpermissive IAM role that can read S3 buckets containing credentials is a higher-priority finding than either issue in isolation.

ScoutSuite

ScoutSuite (maintained by NCC Group) takes a different approach. Rather than a stream of individual check results, it collects all the configuration data from the cloud provider APIs into a local JSON structure and then renders a single self-contained HTML report. That report is interactive: you click into a service (say, S3), see all buckets and their properties, and drill into flagged findings. The whole thing runs offline once the data is collected.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# Install
pip install scoutsuite

# AWS assessment (uses your configured AWS credentials)
scout aws

# Azure assessment
scout azure --cli

# GCP assessment
scout gcp --project my-project-id

# AWS with specific profile and region
scout aws --profile prod-readonly --regions us-east-1 us-west-2

The generated report lives in scoutsuite-report/scoutsuite-results.html and can be opened in any browser without a server. This makes ScoutSuite the tool of choice for consultants and auditors doing a point-in-time assessment of an environment they don’t own: collect the data, generate the report, hand it to the client. The HTML report’s service-by-service breakdown is more readable for non-engineers than Prowler’s raw CSV output, and the configuration dump is useful for forensic analysis.

ScoutSuite’s limitation is that it lacks Prowler’s framework mapping depth and is harder to integrate into a continuous pipeline. It’s a manual audit tool. Use it for initial assessments, penetration testing engagements, and when you need a human-readable deliverable. Use Prowler for scheduled automation.

Steampipe and Powerpipe

Steampipe takes a fundamentally different approach: it exposes cloud APIs as SQL tables. Install the AWS plugin and you can run queries like SELECT instance_id, instance_type, public_ip_address FROM aws_ec2_instance WHERE state = 'running' AND public_ip_address IS NOT NULL. The embedded PostgreSQL instance translates each query into live API calls — no ETL pipeline, no data warehouse, results in seconds.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

# Install Steampipe and the AWS plugin
brew install turbot/tap/steampipe
steampipe plugin install aws

# S3 buckets without server-side encryption
steampipe query "
  SELECT name, region
  FROM aws_s3_bucket
  WHERE server_side_encryption_configuration IS NULL
"

# IAM access keys older than 90 days (unrotated)
steampipe query "
  SELECT u.name, k.access_key_id,
    DATE_PART('day', NOW() - k.create_date) AS key_age_days
  FROM aws_iam_user u
  JOIN aws_iam_access_key k ON u.name = k.user_name
  WHERE k.status = 'Active'
    AND DATE_PART('day', NOW() - k.create_date) > 90
  ORDER BY key_age_days DESC
"

# Security groups with SSH open to the world
steampipe query "
  SELECT group_id, group_name, vpc_id
  FROM aws_vpc_security_group
  WHERE ip_permissions @> '[{\"FromPort\": 22, \"IpRanges\": [{\"CidrIp\": \"0.0.0.0/0\"}]}]'
"

The power multiplier is Powerpipe, which is Turbot’s dashboards-as-code layer that sits on top of Steampipe and runs pre-built benchmark mods. The benchmark mods are HCL files that encode an entire compliance framework as a tree of SQL-backed controls. Install the aws-compliance mod and you can run the full CIS AWS Foundations Benchmark v5.0 with a single command.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# Install Powerpipe and the AWS compliance mod
brew install turbot/tap/powerpipe
powerpipe mod install github.com/turbot/steampipe-mod-aws-compliance

# Full CIS v5.0 benchmark run (interactive dashboard)
powerpipe benchmark run aws_compliance.benchmark.cis_v500

# JSON output for pipeline consumption — filter to alarm state
powerpipe benchmark run aws_compliance.benchmark.cis_v500 \
  --output json | jq '.[] | select(.status == "alarm")'

# Export HTML report for sharing
powerpipe benchmark run aws_compliance.benchmark.cis_v500 \
  --export html --output-dir ./reports

# GCP CIS v3.0
powerpipe benchmark run gcp_compliance.benchmark.cis_v300

The Powerpipe Hub at hub.powerpipe.io catalogs mods for AWS, Azure, GCP, M365, Kubernetes, Terraform, and more. The steampipe-mod-aws-compliance mod alone covers CIS v1.4 through v5.0, PCI DSS v3.2.1 and v4.0, NIST 800-53, HIPAA, SOC 2, FedRAMP, and the AWS Foundational Security Best Practices. Because the benchmarks are SQL-backed, you can fork a mod and add custom controls against your organization’s specific policy requirements — something neither Prowler nor ScoutSuite makes as easy.

Tool Comparison

Mapping to Frameworks: Why It Matters

A raw finding — “security group sg-0abc123 has port 22 open to 0.0.0.0/0” — is actionable by an experienced engineer but useless to a compliance program. When that same finding is tagged to CIS AWS Foundations Benchmark v5.0 control 5.2, NIST 800-53 SC-7, and PCI-DSS Requirement 1.3.2, it becomes evidence in an audit trail.

The CIS Benchmarks are the de-facto baseline for cloud security configuration. The CIS AWS Foundations Benchmark v5.0 (released late 2025, now supported by AWS Security Hub) covers 40 automated controls across IAM, storage, logging, monitoring, and networking. The CIS Azure Foundations Benchmark v3.0.0 (released February 2025) covers over 100 controls across nine sections. CIS GCP Foundations Benchmark v4.0 parallels the same structure for Google Cloud. These benchmarks are consensus-built, versioned, and widely recognized — passing a CIS Level 1 scan is a defensible security baseline, not a marketing checkbox.

For regulated environments, PCI-DSS scope requires demonstrating that cardholder data environment resources meet specific configuration requirements. SOC 2 Type II auditors increasingly expect to see evidence of continuous configuration monitoring rather than point-in-time reports. NIST 800-53 controls map to specific cloud configuration requirements at every impact level. Prowler’s compliance CSV outputs and Powerpipe benchmark reports are designed to produce exactly these artifacts.

The practical value of framework mapping is prioritization, not completeness. A 500-finding scan result is overwhelming. A report that says “you pass 87% of CIS Level 1, fail 13%, and here are the 19 specific controls causing failures” is a work plan. Controls tied to specific audit frameworks tell your team which findings have regulatory consequences and which are advisory.

The Usual Suspects: Misconfiguration Classes

These are the finding categories that appear repeatedly across every cloud environment. They are not exotic. They persist because cloud services default to convenience over security, engineers move fast, and there is no compiler error for a misconfigured IAM policy.

The IAM category deserves particular attention. Every AWS environment accumulates IAM debt. Roles are created for a one-time migration and never deleted. Policies are copied from Stack Overflow with wildcards intact. Lambda functions get AdministratorAccess because it was easier. Cross-account trust policies get broad principals. The result is a web of implicit privilege that nobody has a clear picture of — and attackers who pivot to any single credential can traverse it. IAM least privilege with permission boundaries and SCPs is a force multiplier for CSPM findings: if your IAM posture is clean, the blast radius of every other misconfiguration shrinks dramatically.

Continuous Assessment: Posture Degrades Immediately

A one-time CSPM scan is better than nothing. It is not a security posture. The day after your clean scan, an engineer deploys a new Lambda with a broad execution role, a developer enables public access on a bucket for “just testing,” and a CI pipeline creates a service account with owner permissions “temporarily.” Cloud environments drift constantly, and drift toward misconfiguration is the default direction of least resistance.

Continuous assessment means scheduled scans on a cadence short enough to catch drift before an attacker does. For most environments, daily is the practical minimum. High-sensitivity environments warrant hourly scans of critical services. The scan results must be persisted and compared over time so new findings — things that were passing yesterday and failing today — surface immediately rather than being buried in a stable list of known issues.

This is directly analogous to the drift detection discussed in Terraform at scale with modules, remote state, and drift: infrastructure state and configuration state both decay relative to what you declared, and the discipline of continuous comparison keeps reality aligned with intent. IaC gives you version-controlled intent; CSPM gives you continuous verification that deployed reality matches it.

Alerting strategy matters here. Alerting on every finding from every scan generates instant alert fatigue — security teams stop reading the alerts, which defeats the purpose entirely. The right model is alerting on regressions: findings that are new since the last scan. A finding tracked in a ticket for 30 days does not need another Slack notification. A finding that appeared in the last four hours on a production account does.

Wiring CSPM Into CI and Alerting

The highest-value CSPM integration is running a scan in your deployment pipeline so that a new configuration change that introduces a high-severity finding blocks or warns before it reaches production. This is shift-left for cloud configuration: catch the open security group in the pull request, not after the attacker finds it.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

# .github/workflows/cspm-scan.yml
name: CSPM Security Scan

on:
  schedule:
    # Daily scan at 06:00 UTC
    - cron: '0 6 * * *'
  pull_request:
    # Also run on PRs that touch IaC
    paths:
      - 'terraform/**'
      - 'cloudformation/**'

permissions:
  contents: read
  security-events: write
  id-token: write   # for OIDC auth to AWS

jobs:
  prowler-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # Authenticate to AWS using OIDC (no long-lived keys)
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/ProwlerReadOnly
          aws-region: us-east-1

      - name: Run Prowler
        uses: prowler-cloud/prowler-cloud-github-action@v5
        with:
          provider: aws
          output-formats: sarif json csv
          compliance: cis_5.0_aws
          severity: high critical

      # Upload SARIF so findings appear in Security tab and as PR annotations
      - name: Upload SARIF findings
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: prowler-output/prowler.sarif
        if: always()

      # Fail the pipeline on new critical findings (optional, strict mode)
      - name: Check for critical findings
        run: |
          CRITICALS=$(jq '[.[] | select(.status == "FAIL" and .severity == "critical")] | length' \
            prowler-output/prowler-results.json)
          echo "Critical findings: $CRITICALS"
          if [ "$CRITICALS" -gt 0 ]; then
            echo "Pipeline failed: $CRITICALS critical CSPM findings"
            exit 1
          fi

A few design decisions in this workflow are worth calling out. First, the AWS authentication uses OIDC with a role assumption rather than long-lived IAM access keys stored as secrets — this is itself a CSPM-recommended practice. Second, the read-only role for Prowler (SecurityAudit + ViewOnlyAccess managed policies at minimum) limits the blast radius if the pipeline is ever compromised. Third, uploading SARIF to GitHub’s code scanning feature surfaces findings directly in pull request review, which is where engineers can act on them.

The complementary shift-left tool here is Trivy for container and IaC vulnerability scanning, which scans Terraform files, Kubernetes manifests, and Helm charts for misconfigurations before they’re deployed. CSPM catches what slips through post-deploy; Trivy IaC scanning catches it pre-deploy. Run both and you cover the full lifecycle.

For routing findings to alerting and SIEM, the json-asff output from Prowler imports directly into AWS Security Hub — centralizing findings from multiple accounts and fanning out via EventBridge to Lambda for Slack notifications, auto-remediation, or ticketing. Push findings with prowler aws --output-formats json-asff --send-sh-findings. For non-AWS SIEM, the JSON output parses cleanly into Elasticsearch, Splunk, or any log ingest pipeline.

Limits and Honest Assessment

CSPM is not a complete security program. Four limits deserve clear articulation.

Config-only blindness. The scanner sees what the API returns. It cannot see what runs inside your EC2 instance, what process executed inside a container, or whether credentials were exfiltrated through an authorized API call. A perfectly clean CSPM posture does not mean you haven’t been breached. Runtime threat detection requires CWPP tooling (GuardDuty, Sysdig Secure, Falco) as a separate layer. This is the core technical reason CSPM is being absorbed into CNAPP platforms that bundle both.

Alert fatigue and false positives. A fresh Prowler scan of an average AWS account produces hundreds to thousands of findings, many of which are accepted risks, exceptions, or out of scope. Without disciplined suppression, allowlisting, and severity routing, the output overwhelms the team that is supposed to act on it. The findings are technically accurate; the problem is that accuracy and actionability are different properties. Getting from raw output to a managed queue of findings tied to owners, SLAs, and ticket numbers is significant operational work that the tools themselves don’t do for you.

Finding-to-fix gap. CSPM identifies problems; it does not fix them. Some findings are trivial to remediate (enable encryption on an EBS volume). Others require careful architectural changes (decompose a wildcard IAM policy that services actually depend on). Others require policy decisions (is this S3 bucket intentionally public?). Organizations with mature security programs treat CSPM findings as inputs to their risk management process. Organizations without that process accumulate findings in perpetuity. The tool is not the program.

Multi-account and multi-cloud scale. Running a single Prowler scan against a single AWS account is trivial. Running it continuously against 50 AWS accounts, 3 Azure subscriptions, and 2 GCP projects, aggregating results, suppressing exceptions, tracking remediation trends, and reporting to leadership requires infrastructure. Open-source tools handle the scanning; the orchestration, storage, and reporting layer is what you build or buy. This is where managed commercial CNAPP platforms — Wiz, Orca, Lacework, Prisma Cloud — earn their cost. They provide the aggregation, suppression workflows, asset inventory, and business context that turn 10,000 raw findings into a managed security program. For organizations running at that scale without the engineering bandwidth to build the surrounding infrastructure, the commercial platforms are worth the evaluation.

Broader program context. CSPM is one layer. Zero Trust Architecture in practice removes the implicit trust that makes misconfiguration exploitable in the first place. Supply chain security addresses the risk that your clean cloud environment deploys compromised workloads. Posture management, identity controls, workload protection, and software supply chain security are not competing priorities — they are sequential layers of a defense-in-depth program.

Verdict

The posture scanning tools are mature, free, and effective. Prowler covers the continuous monitoring and compliance reporting use case comprehensively; ScoutSuite generates the human-readable point-in-time assessment deliverable; Steampipe with Powerpipe benchmark mods gives you the SQL-based flexibility for custom investigation and framework benchmarking with interactive dashboards. There is no technical reason not to have continuous CSPM in place from the first day you have cloud accounts.

The harder problem is operational. Raw findings without a triage process, a suppression workflow, remediation owners, and SLA tracking deliver marginal security value. The tools surface what is broken. Whether your organization has the process to fix it, track it, and prevent regression is a different question — one that tooling alone cannot answer.

Start with Prowler on a scheduled daily basis against your production accounts, send findings to Security Hub or directly to your SIEM, alert only on new high and critical findings, and build the suppression and ticketing workflow from there. The first scan will be humbling. The 30th scan, if you’ve been working the queue, will be a credible security posture. The 365th scan, compared against the first, is the artifact you bring to an auditor.

Sources

• What’s New in Prowler v5
• Prowler Documentation — Compliance
• Prowler GitHub Repository
• Prowler Security Scan — GitHub Marketplace
• ScoutSuite — NCC Group GitHub
• Steampipe — select * from cloud
• Steampipe AWS Plugin
• Powerpipe Documentation — Run Benchmarks
• steampipe-mod-aws-compliance
• Powerpipe Hub — AWS CIS v5.0.0
• AWS Security Hub — CIS AWS Foundations Benchmark v5.0
• CNAPP vs. CSPM — Wiz Academy
• Cloud Security Posture Management in 2026 — Security Boulevard
• 50 Cloud Misconfiguration Statistics For 2025-2026
• Misconfigured, exposed, forgotten: why S3 is still a problem in 2025
• Compliance auditing with Steampipe and SQL — AWS Open Source Blog