Continuously monitor and enforce cloud security configuration across AWS, GCP, and Azure. Covers CSPM tools, misconfiguration detection, automated remediation, multi-cloud policies, and the compliance frameworks that CSPM maps to.
Cloud Security Posture Management (CSPM) is the class of continuous, automated assessment of cloud‑wide configurations against declared security, compliance, and operational baselines. It matters when an organization spans multiple accounts, regions, or providers and needs to detect drift, misconfiguration, or excessive permission surfaces before they become breach vectors. Unlike point‑in‑time audits, CSPM runs on a schedule or in response to events, correlates findings across services, and feeds remediation workflows. This reference page focuses on the practical workflows a practitioner uses to discover, evaluate, and fix posture gaps, organized by the reader’s immediate goal.
The first step in any CSPM practice is to establish what the cloud layer currently looks like relative to a control set. Most teams start by pulling a registry of evaluated rules and then querying the compliance state of resources.
A typical CSPM scanner contacts the cloud control plane to retrieve the set of rules it will evaluate. In AWS, this is done through the Security Hub CLI:
aws securityhub list-enablement-status --region us-east-1The command returns a JSON array of SecurityHubId and Status for each standard (e.g., CIS, PCI-DSS). A generic parsing step extracts the enabled standards; the same pattern applies in Azure via az policy list --query "[].name" and in GCP via gcloud compliance regrets list.
When working with a multi‑account setup, the scanner typically iterates over a control tower or organization root ID. A real‑world script might look like:
for account in $(aws organizations list-accounts --query "Accounts[].Id" --output text); do
aws securityhub batch-enable-security-hub --account-id $account --region us-east-1
doneThe scanner then records which standards are active per account, producing a baseline inventory that downstream steps compare against live resources.
Once the rule set is known, the next goal is to ask “which resources are non‑compliant?” Cloud providers expose this via a state‑query API. Azure’s equivalent is:
az policy state list --filter "status eq 'NonCompliant'" --output jsoncThis returns one entry per non‑compliant resource, showing the policy definition, resource ID, and deviation details. A CSPM engine will typically paginate through results (Azure limits to 1000 per call) and normalize the output into a unified finding format: resource type, violated rule, severity, and remediation hint.
In environments where a native CSPM agent is not deployed, the same information can be reached through the provider’s configuration API. For example, listing all S3 buckets and their block‑public‑access settings can be done with a single curl call against the AWS S3 control plane:
curl -s "https://s3-control.amazonaws.com/v20180831/accounts/AWS_ACCOUNT_ID/accesspoints?region=us-east-1" \
-H "X-Amz-Algorithm: AWS4-HMAC-SHA256" \
-H "X-Amz-Credential: AKIA.../us-east-1/s3/aws4_request" \
-H "X-Amz-Date: 20250831T120000Z" \
-H "X-Amz-SignedHeaders: host;x-amz-target" \
-d '{"nextToken": null}'The response includes BlockPublicAcls, BlockPublicPolicy, IgnorePublicAcls, and RestrictPublicBuckets flags for each bucket. A CSPM rule then flags any bucket where all four are not explicitly true.
With the current posture mapped, the next goal is to enforce a desired baseline and surface deviations in real time. This is where policy‑as‑code and native cloud policy engines intersect.
Open Policy Agent (OPA) is a widely adopted generic engine for evaluating JSON/YAML configurations against Rego rules. A typical CSPM pipeline stores the organization’s control baseline as Rego files and runs OPA against a snapshot of the current cloud state exported by the mapping step above:
opa eval --input s3_state.json 'data.buckets.violations'The s3_state.json file is produced by the earlier curl/aws extraction step. A Rego rule might read:
default allow = false
allow {
not input.buckets[_].block_public_acls
not input.buckets[_].block_public_policy
not input.buckets[_].ignore_public_acls
not input.buckets[_].restrict_public_buckets
}OPA returns a list of bucket IDs that violate the rule, which the CSPM dashboard consumes as a finding. The same pattern works against Terraform state, Kubernetes manifests, or Azure Resource Manager JSON exports.
Most clouds ship with a built‑in policy engine that can be queried without an external tool. AWS Config rules, for instance, are defined in the console or via CLI and evaluated continuously:
aws configservice start-config-rules --rule-names S3BucketPublicReadProhibitedThe rule runs on every configuration change and pushes a ConfigRuleEvaluation event. To list current evaluations:
aws configservice describe-configuration-recorder-status | jq '.ConfigurationRecorders[0].ConfigurationRecorderStatus'Azure Policy uses “initiatives” – collections of policy definitions each with an effect (Audit, Deny, DeployIfNotExists). To list non‑compliant resources under a specific initiative:
az policy state list --initiative-definition-name "required-tagging" --query "[].{resource: resourceId, reason: reason}" --output tableGCP Forseti Policy Engine operates similarly, loading a ruleset and running it against a GCP inventory API dump. The mechanics—fetch inventory, evaluate rules, emit findings—are identical across providers; the CLI flags and API endpoints differ, but the workflow is the same.
Finding gaps is useless without a remediation path. CSPM workflows typically automate fixes through one of two patterns: native cloud remediation actions or API‑driven resource replacement.
Azure Policy’s DeployIfNotExists effect automatically provisions missing resources or tags when a non‑compliant state is detected. To enable it:
az policy assignment create --name add‑tag‑policy \
--policy "policy-id" \
--scope "/subscriptions/xxxxx" \
--mode DeployIfNotExistsWhen a resource lacks the required tag, Azure’s engine creates it on the next evaluation cycle (typically within 30 minutes). The CSPM consumer sees the compliance state flip from NonCompliant to Compliant without manual intervention.
AWS Config Rules can trigger AWS Systems Manager Automation Documents. A rule definition might reference a pre‑written SSM document that resets S3 block‑public‑access settings:
{
"Source": "AWS-ConfigureS3BucketPublicAccess",
"MaximumAutomaticExecutionCount": 1
}When the rule evaluates NON_COMPLIANT, SSM executes the document against the affected bucket, applying the requested ACL and policy settings. The rule then re‑evaluates and reports COMPLIANT if the settings persist.
When a native effect is unavailable, the CSPM pipeline issues targeted API calls. A generic Python snippet using boto3 might look like:
import boto3, json
client = boto3.client('s3')
bucket = 'example-bucket'
client.put_public_access_block(
Bucket=bucket,
PublicAccessBlockConfiguration={
'BlockPublicAcls': True,
'BlockPublicPolicy': True,
'IgnorePublicAcls': True,
'RestrictPublicBuckets': True
}
)The same pattern applies to IAM role boundary attachment, KMS key rotation enforcement, or GCP bucket IAM redaction. The key is that the remediation step is idempotent: re‑running it produces the same result, and the CSPM scanner re‑evaluates immediately after to confirm the state change.
Posture checks should not live only in the operational layer; they must block or warn before code reaches production. Modern CI/CD pipelines integrate CSPM checks as gate steps.
tfsec and checkov are two openly maintained tools that scan Terraform, CloudFormation, and Bicep templates for known misconfigurations before apply. A GitHub Actions workflow snippet:
- name: Run tfsec
uses: aquasecurity/tfsec-action@v2
with:
args: --soft-fail
- name: Run checkov
uses: checkov/cli-action@main
with:
directory: .
framework: terraform
soft_fail: trueBoth tools read the template, parse provider‑specific blocks, and exit with a non‑zero status if any rule fails. The soft-fail flag ensures the pipeline continues if the team wants to review findings in a separate step, but the exit code can be flipped to hard for mandatory compliance.
For containerized workloads, trivy is a real, widely used scanner that evaluates base image CVEs and misconfigurations:
trivy image --exit-code 1 --severity HIGH,CRITICAL my-registry/my-app:latestThe --exit-code 1 flag makes the CI job fail if any HIGH or CRITICAL vulnerability is found, effectively gate‑keeping the image from deployment. The same command can be run against a Kubernetes manifest file to check RBAC over‑privilegment, privileged container usage, and host‑path volume mounts.
Even a well‑designed CSPM practice breaks down in certain scenarios. Knowing these edges prevents wasted effort and blind spots.
Cloud policy engines do not always evaluate changes instantaneously. AWS Config rules have a typical evaluation latency of 2–5 minutes after a configuration change, but during high‑velocity change windows (auto‑scaling groups, blue‑green deployments) the rule may miss the transient state entirely. The finding appears hours later, creating a gap where a resource is non‑compliant but the dashboard still shows COMPLIANT. Teams often mitigate this by coupling Config rules with CloudTrail event‑based triggers, but that adds operational complexity.
Many CSPM scanners are configured per‑region or per‑account. If a multi‑account org enables a new account automatically via Organizations SCP propagation, the scanner may not have ingested the new account’s configuration registry yet. The result is a “missing account” finding that resolves only after the next scanner sweep (often daily). A practical workaround is to hook account creation into the scanner’s onboarding script, but this requires a custom integration layer.
Permission‑based rules (e.g., “no IAM user should have admin access”) frequently flag service‑linked roles or assumed roles that legitimately require broad privileges for a bounded task. A CSPM engine that does not distinguish between principal type (user vs. role vs. federated) will produce noise that erodes trust in the system. The sharp edge here is that the scanner’s output must be enriched with role‑usage metadata (last accessed timestamp, session context) before a human makes a remediation decision.
CSPM pipelines that poll cloud control planes at high frequency can hit service quotas. AWS Security Hub, for example, enforces a limit on BatchEnableSecurityHub calls per account per region. Exceeding the limit returns ThrottlingException, and the scanner may silently skip enabling standards for newly discovered accounts. Implementing exponential back‑off and respecting Retry-After headers is essential; otherwise the pipeline reports partial posture coverage without indicating why.
Automated remediation (SSM documents, Azure DeployIfNotExists) is idempotent only if the underlying desired state does not change. If a downstream process (e.g., a CI pipeline applying a Terraform module) re‑creates a resource with the original misconfigured attributes, the CSPM scanner will flag the gap again on the next cycle. The sharp edge is that remediation without a “guardrail” in the provisioning pipeline creates a whack‑a‑mole dynamic. The recommended pattern is to enforce the same policy at the IaC level so that the desired state and the runtime state are always in sync.
Many CSPM scanners rely on exported resource state (Terraform state, cloud configuration snapshots). If the export step is misconfigured—for instance, Terraform state stored in S3 with versioning disabled but version history pruned—the scanner may miss resources that were created and deleted between exports. The finding appears as “no data” rather than “non‑compliant,” which can be misleading during compliance audits. Verifying export completeness (checking state version hashes, confirming all resource addresses are present) should be a pre‑run checklist item.
CSPM is not a single tool or a one‑time scan; it is a recurring workflow that maps live configuration, evaluates it against a control set, surfaces gaps, and drives automated or manual remediation. The concrete steps above—using real CLI commands, policy‑as‑code evaluation, CI/CD gate checks, and an awareness of the failure modes that appear in production—provide a practical pattern that can be mapped to any cloud provider or hybrid setup. The mechanics (HTTP API calls, JSON configuration schemas, Rego/Rego‑like rule evaluation, paginated state queries) are portable; the specific flags and endpoints will vary, but the overall shape of the practice remains the same.
This page was rewritten on 16 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.
We use cookies for analytics (Google Analytics) and advertising (Google AdSense) to improve your experience and support free content. Privacy Policy