Cloud Security Posture Management (CSPM): A Practical Guide

Cloud Security Posture Management (CSPM) continuously reads the configuration of your cloud accounts through the provider APIs and compares it against a baseline: CIS Benchmarks, provider best-practice standards and your own rules. It flags public storage, open management ports, disabled audit logs, identities without MFA and roles with far more access than they use. It finds misconfiguration, not software vulnerabilities. The tool is the easy part; the value comes from routing each finding to an owner, fixing the infrastructure code that created it, and adding a guardrail so it cannot come back.

Key takeaways

• CSPM answers one question continuously: is the cloud configured the way we intended? Turn it on from the first production account, at the organization level, so new accounts are covered automatically.
• Native tools (AWS Security Hub CSPM, Microsoft Defender for Cloud, Google Security Command Center) are enough for many single-cloud teams. Multi-cloud estates and attack-path context are where commercial platforms earn their cost.
• Prioritize by exposure, privilege and data together. A public bucket of marketing images and a public database snapshot are not the same severity, whatever the rule says.
• Fix findings in infrastructure as code, not in the console, or the next deploy reverts your fix.
• Use preventive guardrails (SCPs, Azure Policy, GCP organization policies) for anything you never want to see again, and keep auto-remediation to fixes that cannot cause an outage.
• Measure recurrence, not the open finding count. A finding that keeps coming back is a missing guardrail.

How CSPM works

Every CSPM tool, native or commercial, runs the same loop. It assumes a read-only role in each account, enumerates resources through the provider APIs, evaluates them against rules, and emits findings. Modern tools add a graph on top so they can say "this VM is internet-facing, has a critical CVE and can assume an admin role", which is far more useful than three separate findings.

The read-only part matters more than it sounds. The scanner's role can see every resource in your estate, and depending on which policy you attach, it can read data too. On AWS, the managed ReadOnlyAccess policy includes s3:GetObject; SecurityAudit and ViewOnlyAccess stay at the metadata level. Give the scanner the narrowest policy its documentation supports, and treat its credentials as high-value.

CSPM versus the other acronyms

Vendors blur these categories, so it helps to know what each one actually inspects.

IaC scanning and CSPM are complements, not alternatives. IaC scanning stops a bad change before it ships. CSPM catches everything that never went through IaC: console changes, resources created by managed services, accounts someone opened on a credit card, and drift.

What CSPM catches

These are the misconfiguration classes that matter most, with the check and why it matters.

Identity findings deserve their own program; our cloud IAM guide covers least privilege, workload identity and guardrails across all three providers in depth.

Choosing a tool

Our default for a single-cloud startup is the native tool plus Prowler in CI. The native tool covers continuous detection inside the provider's organization model. Prowler gives you a portable, scriptable second opinion and a way to check accounts that are not yet in the organization. If you run several clouds, the case for one platform gets stronger; see our multi-cloud strategy guide for when that complexity is worth having at all.

Rolling it out without drowning

Step 1: Turn it on at the organization level

Enable the tool from a dedicated security account, not account by account. On AWS, delegate Security Hub CSPM administration from the management account:

aws securityhub enable-organization-admin-account --admin-account-id 111122223333

Then turn on auto-enable for new accounts and the standards you want from the delegated admin account, and make sure AWS Config is recording in every region you use. In Azure, enable Defender for Cloud at the management group. In GCP, activate Security Command Center at the organization. The point is that a new account or subscription is covered the moment it exists, with nobody needing to remember.

For an independent check, run Prowler from a workstation or CI job with a read-only role:

pipx install prowler
prowler aws --severity critical high -M csv html

Step 2: Triage the first scan by exposure

The first scan of any real estate produces a long list. Do not try to clear it. Sort it by three questions:

1. Is it reachable? Internet-facing beats internal. Cross-account access beats same-account.
2. What can it touch? A resource with an admin role or production data beats a sandbox.
3. Is it sensitive? Customer data, credentials and audit logs beat everything else.

A reasonable starting policy, which you should adjust to your own risk appetite:

Pull the critical list through the API so it lands somewhere people look:

aws securityhub get-findings --max-items 50 --filters '{
  "SeverityLabel": [{"Value": "CRITICAL", "Comparison": "EQUALS"}],
  "RecordState":   [{"Value": "ACTIVE",   "Comparison": "EQUALS"}],
  "WorkflowStatus":[{"Value": "NEW",      "Comparison": "EQUALS"}]
}' --query 'Findings[].[Title, Resources[0].Id, AwsAccountId]' --output table

Step 3: Route findings to owners

A finding without an owner is a finding nobody fixes. Make ownership a tag (owner, env, data-class) enforced at creation time, then route findings by tag into the owning team's tracker. Anything untagged goes to the platform team, which has a strong incentive to get tagging enforced.

Send findings to issue trackers, not chat channels. A channel full of posture alerts gets muted within a week.

Step 4: Fix it where it was created

If a resource is managed by Terraform and you fix it in the console, the next terraform apply reverts your fix, or the plan shows drift that someone "corrects" back. Find the module, fix it there, and add a check so the same mistake fails in review:

checkov -d infra/ --framework terraform --compact
trivy config infra/

Trivy's config scanner absorbed tfsec, so if you are still running tfsec it is worth moving over. The Terraform production guide covers module structure and CI for this.

Step 5: Add guardrails for what must never happen

Detection tells you about a problem after it exists. Guardrails make it impossible. Use them for the short list of things you never want, not as a substitute for review.

Account-wide S3 Block Public Access (new buckets have had Block Public Access on by default since April 2023, but older buckets and account settings may not):

aws s3control put-public-access-block --account-id 111122223333 \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

An SCP that stops anyone, including account admins, from switching off the tools that watch them:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ProtectSecurityTooling",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail",
        "config:StopConfigurationRecorder",
        "config:DeleteConfigurationRecorder",
        "guardduty:DeleteDetector",
        "securityhub:DisableSecurityHub"
      ],
      "Resource": "*",
      "Condition": {
        "ArnNotLike": { "aws:PrincipalArn": "arn:aws:iam::*:role/SecurityBreakGlass" }
      }
    }
  ]
}

The Azure equivalent is an Azure Policy assignment with a deny effect at the management group; in GCP, organization policy constraints such as disabling service account key creation and restricting public IPs on VMs.

Step 6: Automate remediation narrowly

Auto-remediation is safe when the fix cannot reduce availability: enabling encryption on new resources, turning on logging, blocking public access on buckets that are not meant to serve public content. It is dangerous for network and identity changes, because the rule cannot know that the "open" security group fronts your public load balancer.

Cloud Custodian expresses remediation as policy. Run it with --dryrun first and read what it would touch:

policies:
  - name: sg-remove-world-ssh
    resource: aws.security-group
    filters:
      - type: ingress
        Ports: [22]
        Cidr:
          value: "0.0.0.0/0"
    actions:
      - type: remove-permissions
        ingress: matched

custodian run --dryrun -s out/ sg-remove-world-ssh.yml

Measuring whether it works

Count fewer things, and pick ones that drive behavior:

• Time to remediate by priority. Track the critical and high targets you set, per owning team.
• Recurrence. The same rule failing on new resources means a module or a habit is wrong. Each recurring finding should produce a code fix or a guardrail.
• Untagged and unowned resources. These are where findings go to die.
• Coverage. Accounts, subscriptions, projects and regions not reporting into the tool. A posture dashboard that misses one account is worse than none, because it looks complete.

A compliance score going up is pleasant but weak evidence. It moves when you suppress findings, too.

What goes wrong in production

• Day-one flood, day-seven mute. Every rule turned on, findings piped into chat, and the channel muted within a week. Start with critical and high, route to trackers, and add rule packs as the backlog shrinks.
• Auto-remediation takes down production. A rule removes 0.0.0.0/0 from a security group that fronts a public load balancer on 443, and the site goes dark. Scope network remediation to management ports and test every rule in dry-run first.
• Remediation fights Terraform. The CSPM bot fixes a resource, the next apply reverts it, the bot fixes it again. The loop is visible in the change history and invisible on the dashboard. Fix the module.
• Suppressions with no expiry. "Accepted risk" gets used for anything inconvenient and never revisited. Every suppression needs an owner, a reason and an expiry date.
• Coverage gaps. A new account created outside the landing zone, a region where Config was never enabled, a service the tool does not support yet. Alert on accounts and regions that stop reporting, not only on findings.
• The scanner becomes the target. A third-party CSPM with read access to every account is a high-value credential. Use external IDs on the trust policy, the narrowest read policy that works, and alert on the role being used from anywhere unexpected.
• Config costs surprise the finance team. Continuous recording in accounts with heavy resource churn (autoscaling, ephemeral CI environments) produces a lot of configuration items. Use periodic recording for noisy resource types where continuous detection is not needed.
• Score theater before an audit. A sprint spent closing low-value findings to lift a percentage, while a critical exposure waits. Auditors for SOC 2 care about the process for handling findings, not a perfect score.

Frequently Asked Questions

What is CSPM in cloud security?

Cloud Security Posture Management (CSPM) is tooling that continuously reads the configuration of your cloud accounts through provider APIs and compares it with a security baseline such as the CIS Benchmarks. It flags misconfigurations like public storage buckets, open management ports, disabled audit logs and over-privileged identities. It does not scan software for vulnerabilities; it checks how your cloud services are set up.

What is the difference between CSPM and CNAPP?

CSPM checks cloud configuration. A Cloud-Native Application Protection Platform (CNAPP) bundles CSPM with workload protection, identity entitlement analysis, Kubernetes posture and often IaC scanning in one product. CNAPPs can correlate findings across those layers, for example a public VM that runs a vulnerable package and holds an admin role. If you only need configuration checks, native CSPM or an open-source scanner is often enough.

Are native cloud tools enough for CSPM?

For a single cloud and a small number of accounts, usually yes. AWS Security Hub CSPM, Microsoft Defender for Cloud and Google Security Command Center all run benchmark checks and integrate with their own organization structures. Third-party tools earn their cost when you run several clouds, need cross-layer context such as attack paths, or need one place to route findings to owners.

Can CSPM fix misconfigurations automatically?

Yes, but only for a short list of fixes that cannot break production, such as enabling encryption on new resources or turning on logging. Removing network rules or changing IAM automatically can take down a service, and if the resource is managed by Terraform the next apply will undo the fix. Start in report-only mode and fix most findings in infrastructure as code.

Does CSPM help with SOC 2 and ISO 27001 compliance?

It helps with the evidence. CSPM tools map checks to frameworks such as SOC 2, ISO 27001, PCI DSS and HIPAA, and their history shows auditors that controls operate continuously rather than on audit day. A compliance score is not proof of security, though, and auditors also look at how findings are triaged and fixed.

Need help with cloud security posture?

We design cloud estates and then operate them, so we care less about the score and more about whether the critical findings get fixed at the source and stay fixed. Senior engineers set up the tooling, the guardrails and the routing, and if we built it, we're on the pager for it.

• Cybersecurity and compliance
• Cloud architecture and infrastructure
• Talk to an engineer