Cloud Security Posture Management (CSPM)

Cloud Security Posture Management (CSPM) refers to tools that continuously monitor cloud environments for security misconfigurations, compliance violations, and risks. CSPM automates what would otherwise be manual security audits, and it exists because the overwhelming majority of cloud incidents start with a misconfiguration rather than an exotic exploit: a bucket made public, a security group opened to the world, a role trusted too broadly.

AWS CSPM Capabilities

• Security Hub: automated compliance checks, security scoring, finding aggregation, historical trends
• AWS Config: continuous configuration monitoring with hundreds of managed rules
• IAM Access Analyzer: identifies resources shared with external entities
• Inspector: vulnerability scanning (CVEs, SAST, SCA, IaC)

How CSPM Actually Works

The mechanics are consistent across tools. First, an inventory layer records the configuration of every resource; on AWS this is the AWS Config recorder producing configuration items on every change. Second, a rules layer evaluates that inventory against expected state, either individual Config rules or whole standards in Security Hub such as the AWS Foundational Security Best Practices and the CIS AWS Foundations Benchmark. Third, a findings layer surfaces failures with severity labels, tracks them over time, and computes a posture score. The value is less in any single check and more in the loop: a resource that was compliant yesterday and is not today is a change worth explaining, whether it came from a rushed hotfix or an attacker.

How It Goes Wrong in Practice

The most common failure is partial coverage that everyone believes is total. Security Hub and Config are regional services: a team enables them carefully in its two main Regions, then someone deploys a proof of concept in an unmonitored Region and the posture dashboard simply cannot see it. Attackers who gain credentials deliberately favor unused Regions for exactly this reason. A related pattern is the quietly disabled Config recorder: someone stops it in one account to save cost during an experiment, every rule in that account silently stops evaluating, and the stale green findings sit unchanged for months. The third failure is organizational rather than technical: findings accumulate with no owner, the count climbs into the thousands, and the tool becomes wallpaper. CSPM without a triage routine and suppression discipline is a compliance artifact, not a control. Enable the tooling organization-wide through delegated administration, cover all Regions, alarm on the recorder itself being stopped, and give critical findings a routing path to a human who must act.

A Practical Check: Pulling Critical Findings

To see what your posture tooling is actually flagging, query Security Hub for active critical findings:

aws securityhub get-findings --filters '{"SeverityLabel":[{"Value":"CRITICAL","Comparison":"EQUALS"}],"WorkflowStatus":[{"Value":"NEW","Comparison":"EQUALS"}]}' --max-items 20

The --filters structure accepts up to 10 finding attributes with up to 20 values each, so you can slice by resource type, account, or compliance standard. Note that WorkflowStatus is the current field for triage state; WorkflowState is deprecated. If this command returns pages of long-ignored criticals, that is your real posture, whatever the dashboard score says.

Frequently Asked Questions

What is the difference between Security Hub and AWS Config for CSPM?

Config is the raw machinery: it records resource configurations and evaluates individual rules. Security Hub consumes those evaluations plus findings from GuardDuty, Inspector, Macie, and third-party tools, packages checks into named standards, scores them, and gives you one aggregation point across accounts and Regions. In practice you run both; most Security Hub controls are implemented on top of Config under the hood.

Does CSPM fix the problems it finds?

Not by itself. CSPM detects and reports. Remediation is a separate layer you build: Security Hub findings can trigger EventBridge rules that invoke Lambda functions or SSM runbooks, and Config supports remediation actions on non-compliant resources. Auto-remediation is worth having for unambiguous cases like public S3 access, but keep humans in the loop for anything that could break production.

Do I still need a third-party CSPM product?

Depends on scope. The native stack covers AWS deeply and cheaply. Third-party platforms earn their cost mainly in multi-cloud environments, where you need one policy language and one dashboard across AWS, Azure, and GCP, or when you want richer attack-path analysis than native scoring provides.

Where does CSPM stop and workload protection begin?

CSPM evaluates configuration: what your resources are set to. It does not watch what is running inside them. Runtime threats on instances and containers, malware, suspicious processes, active exploitation, belong to workload protection and threat detection tooling such as GuardDuty and Inspector. A healthy posture program pairs the two, since a perfectly configured environment can still be running compromised code.