Cloud security posture management, or CSPM, evaluates cloud control-plane configuration against intended security requirements. In AWS, Azure, and Google Cloud, CSPM helps us identify whether resources, identities, and account-level settings currently match a defined posture. It does not inspect application packet payloads or replace runtime detection of an active attack.
CSPM tools typically work agentlessly. They use read-only credentials to call each provider’s APIs, build an inventory of resources, and evaluate rules against it. Examples include AWS Config and Security Hub, Microsoft Defender for Cloud, Google Security Command Center, and open-source scanners such as Prowler and Steampipe. When a resource fails one of those rules, the tool reports the result as a finding.
A finding is a statement about observable configuration state, such as a storage resource’s access setting or an identity’s assigned permission. Its value depends on the evidence the CSPM process can read and on the rule used to interpret that evidence.
We can now trace the provider boundaries and evidence sources a CSPM assessment uses.
Configuration evidence describes what the provider control plane reports at the time of collection. Activity logs add a historical record of management actions, such as a principal changing a policy or creating a resource. In AWS these are AWS Config and CloudTrail, in Azure the Azure Resource Graph and the Activity Log, and in Google Cloud the Cloud Asset Inventory and Cloud Audit Logs. Together, these sources can show that a setting exists and may indicate who changed it, but neither proves that an application request succeeded, that data was accessed, or that a network packet was safe.
Configuration drift is a difference between the approved or expected configuration and the current observed configuration. Drift can result from a manual change, an automation error, a deployment rollback that restored an older value, or a resource created outside the intended delivery process. CSPM detects the difference only when the resource is within its inventory and its evidence is available.
Evidence boundary A CSPM finding establishes a configuration condition within a provider boundary. It does not, by itself, establish exploitability, business impact, or successful access.
A finding can be a false positive when the evaluated rule reports a problem even though the applicable requirement permits the observed state. For example, a broadly written rule may flag an internet-facing endpoint that is deliberately public and protected by controls the rule does not evaluate. The safe response is to validate the requirement, resource purpose, exposure path, and compensating controls before changing production configuration.
Missing read permissions create the opposite problem. If the CSPM identity cannot list a resource, retrieve a policy, or inspect a relevant setting, the assessment may have incomplete coverage rather than a clean result. An unmanaged resource has the same practical effect when it sits outside the accounts, subscriptions, projects, or inventory scope being assessed.
Shared responsibility also sets a limit. The cloud provider operates the underlying service, while the customer remains responsible for choices such as identity assignment, network exposure, resource policy, and data-access configuration. A passing posture check does not transfer that responsibility or demonstrate that every customer-managed control is effective.
Decision rule Treat an absence of findings as useful only after confirming scope, collection permissions, rule applicability, and the evidence time window.
We will use one deliberately small workload called orders-api. It represents an application service listening on port 8080 and storing order data in a provider-native object storage resource. Each version stays inside its own provider boundary, so no identity, storage permission, or finding is assumed to cross from one cloud to another.
In AWS, orders-api uses the role orders-api-role and the bucket orders-data-s3. In Azure, it uses the managed identity orders-api-mi and the storage account ordersdatast. In Google Cloud, it uses the service account orders-api-sa and the bucket orders-data-gcs. These identifiers are fictional, but the boundary they demonstrate is reusable.
We can inspect how each workload identity remains scoped to its own provider resources.