27. 01. 2026
Automation, Development, DevOps, Offensive Security, Red Team, SEC4U
21. 07. 2026
Patrick Di Fazio
Offensive Cloud Security, Offensive Security, Red Team, SEC4U
What Cloud Security Posture Management Actually Checks, and What It Doesn’t
Cloud Security Posture Management describes a category of tools that inspect cloud environments for configuration problems like public storage, overly broad IAM permissions, disabled logging, and missing encryption. The category includes open-source projects like Prowler and ScoutSuite, and commercial platforms. Despite different pricing models and interfaces, they solve the same underlying problem in similar ways, and they share the same structural limits. In this article it is shown how at Würth IT Italy we use CSPM to strengthen cloud security and surface weaknesses in cloud configurations.
A check is a small, specific piece of logic
People sometimes describe CSPM as running a checklist against a cloud account. That’s roughly right, but a “check” is more precise than the word suggests. Each one queries a specific API, evaluates the response against a defined condition, and returns a pass or fail result.
Take the common check for public S3 buckets in AWS. There’s no single field that says “this bucket is public.” A tool has to look at the bucket ACL, the bucket policy, and the account-level Block Public Access setting, because any one of the three can override the others. A bucket can have a locked-down policy and still be exposed if Block Public Access is turned off at the account level.
That reconciliation work is where CSPM tools differ from each other. A tool that reads one API field and reports it as a security finding will generate false positives and miss real ones. A tool that models how a provider’s permission layers actually interact will produce fewer, more trustworthy findings. This holds across most check categories, including IAM policy evaluation, network access rules, encryption settings, and audit logging configuration. The logic behind the check matters more than the label attached to it.
Prowler is a useful reference point here because its check counts are public. It currently ships several hundred checks for AWS covering dozens of services, with smaller but growing sets for Azure, GCP, Kubernetes, and other platforms including GitHub, Microsoft 365, and Oracle Cloud. The Prowler GitHub repository documents this coverage directly, and it’s a reasonable way to see what a mature open-source CSPM check set actually looks like in practice, including how AWS coverage tends to lead other providers simply because it’s been supported the longest. In the image below we can see our Prowler instance run against a cloud infrastructure highlighting findings and misconfigurations.
Compliance frameworks are a layer on top of checks, not a separate scanning method
Most CSPM tools map their checks to compliance frameworks such as CIS Benchmarks, NIST 800-53, PCI-DSS, ISO 27001, and SOC2. It’s worth being precise about what that mapping actually means. A framework requirement such as “enforce MFA for privileged users” corresponds to a check that combines IAM user metadata, MFA device status, and a separate determination of what counts as privileged access, which itself requires evaluating attached policies for administrative scope.
Framework compliance and actual risk measure different things. A finding can pass a benchmark’s minimum requirement while still leaving meaningful risk in place, because benchmarks are written to apply broadly across many organizations and have to generalize. Treating a clean CIS report as proof that an environment is secure is a common misreading of what the report is telling you. It confirms the environment meets a baseline. Real risk can still remain underneath it.
Configuration checks and runtime detection answer different questions
CSPM tools evaluate configuration state, the settings currently in place. Whether those settings are actively being exploited is a separate question, and it’s one these tools structurally can’t answer. A check can correctly confirm that a permission boundary is configured properly while completely missing that the permission is being actively misused through a valid, technically compliant API call. That’s a structural limit. Better checks won’t close it.
Kubernetes tooling makes this boundary easy to see because the ecosystem splits it across separate tools rather than one product. kube-bench runs the CIS Kubernetes Benchmark against cluster and node configuration, covering things like kubelet flags, API server settings, and etcd configuration. That’s the same kind of static check a cloud CSPM tool runs, just scoped to the cluster instead of the cloud account. Trivy moves earlier in the lifecycle, scanning container images for known vulnerable packages and checking Terraform, CloudFormation, or Kubernetes manifests before anything is deployed. Falco sits on the other side entirely, watching live system calls and Kubernetes audit events for behavior like a shell spawned inside a container or an unexpected outbound connection. This is exactly the category of activity that configuration scanning has no visibility into. Below we can see the output of a kube-bench scan that could help blue team operators or system administrators enforce cluster security.
A well-configured RBAC policy and a compromised pod abusing valid credentials can exist in the same cluster at the same time. Only a runtime tool is positioned to catch the second half of that. Pre-deployment scanning, configuration drift detection, and runtime behavior detection cover three different phases of the same lifecycle, and each one covers ground the other two miss.
Because these tools evaluate state at a point in time, a resource created five minutes after a scan finishes has no coverage until the next scan runs. How often you scan directly determines how large that gap gets. Running scans more frequently narrows the window but increases API call volume against provider rate limits, a real tradeoff worth planning for ahead of an incident review.
Multi-cloud coverage isn’t symmetric
Running an equivalent check across AWS, Azure, and GCP sounds like it should produce directly comparable results, but the underlying access models differ enough that comparison needs care. AWS’s public-access model for storage involves bucket and object ACLs, bucket policy, and account-level Block Public Access. Azure Blob Storage handles public access at the storage account level with container-level overrides, plus shared access signatures as an entirely separate exposure path. GCP Cloud Storage relies on IAM bindings and, separately, ACLs if uniform bucket-level access isn’t enforced. Below there is an example of ScoutSuite run against an AWS infrastructure.
A tool has to encode each of these models independently to claim real coverage. That’s part of why check counts across providers in most CSPM tools aren’t equal. A higher finding count in one cloud often just reflects how many overlapping mechanisms that provider offers for the same underlying risk.
How we use Prowler and CSPM findings in red team scenarios at Würth IT Italy
We at Würth IT Italy run Prowler across AWS, Azure, and GCP accounts on both Red Team and CSPM activities. Scans feed a shared dashboard that we review and refine, and every finding gets triaged against internal severity criteria before it lands on a remediation backlog.
The goal is for that output to go beyond the report. The idea we work toward is having Prowler findings feed directly into Red Team planning, because a configuration finding and an attack path are often the same thing viewed from two different angles. This is the part of our CSPM practice we’re focusing on: findings get handed to the Red Team as a starting point for validation, which shortens the distance between “this looks risky” and “here’s what it would actually let someone do.”
Take a Prowler finding that would look routine on any dashboard, an EC2 instance with an attached IAM role carrying broader permissions than the workload needs, sitting on a security group that allows inbound access from a wider network range than intended. On its own, that’s a medium severity misconfiguration. Treated as a starting point for a red team exercise, it’s a potential foothold, and it’s the kind of finding worth validating instead of leaving at its default severity.
A validation exercise built around that finding starts where the CSPM report leaves off. It confirms the network path is actually reachable, since overlapping rules and peering configurations sometimes narrow exposure that a single rule suggests is open. Once reachability is confirmed, the next step is the instance itself. The attached IAM role, the one flagged as overly permissive, becomes the pivot point to test. From a foothold on the instance, the role’s credentials are reachable through the instance metadata service, and the attached permissions are broad enough to enumerate other resources in the account or attempt privilege escalation, including reaching roles whose trust relationships shouldn’t be assumable from a workload of that kind.
None of the individual steps require anything exotic, which is exactly why this kind of validation is worth running as standard practice. It walks the exact path a real attacker would take, starting from a finding that already exists in a Prowler scan, using no new technique. The scan already proves the misconfiguration exists. The exercise is what shows how far it actually reaches, what it makes reachable, what it makes assumable, and what it would expose if left sitting at “medium severity, address when convenient.”
This is the model we’ve built for prioritizing CSPM findings across our own environment, and it’s become one of the more distinctive parts of how we maintain, enforce, and report a solid level of cloud security at Würth IT Italy. A permission or network finding gets escalated faster once a quick validation shows it chains into something with real reach, past whatever severity a generic benchmark assigned it. CSPM tells us what’s misconfigured across our accounts. Validating those same findings against a real attack path tells us which misconfigurations are actually worth fixing first. We run that loop, scan, triage, validate, remediate, on every cycle.
However, what CSPM tells you still needs a human call. A CSPM scan is a well-defined snapshot of configuration state at a point in time. Turning that into an accurate picture of risk takes context about the environment, ongoing tuning, and enough visibility into pre-deployment and runtime behavior, sometimes backed by direct validation through red teaming, to cover the ground configuration scanning alone leaves open.
Did you learn from this article? Perhaps you’re already familiar with some of the techniques above? If you find cybersecurity issues interesting, maybe you could start in a cybersecurity or similar position here at Würth IT Italy.
Patrick Di Fazio
Red Team & Offensive Security Specialist | Würth IT Italy
Author
