Eight open-source tools we run in every cloud posture review

A cloud posture review has a simple goal: find the things that would make an incident possible, rank them by how bad the incident would be, and hand over fixes that can be applied as code. The commercial CSPM products do this well. So do a handful of open-source tools, if you know what each one covers and what it misses. This is the set we run, in the order we run it, on every cloud security audit the client has authorised.

All of them need read-only access only. If a tool asks for more, that is a finding in itself.

1. Prowler: the broad first pass

Prowler runs several hundred checks against AWS, Google Cloud and Azure, mapped to CIS benchmarks, ENS, PCI DSS and other frameworks. It is the first thing we run because it produces the widest inventory of misconfigurations in the least time.

What it is good at: coverage and compliance mapping. If you need to say "we meet 84 percent of the ENS medium level controls that can be checked automatically", Prowler gives you the number and the evidence.

Where it misleads: volume. A fresh account produces a thousand findings, most of them low severity and many of them the same root cause repeated per resource. Do not hand the raw output to anyone. Group by check, then by root cause, then rank.

2. ScoutSuite: the second opinion

ScoutSuite covers the same providers with a different rule set and a report organised by service rather than by check. We run it after Prowler and compare. Findings that appear in both are almost always real; findings in only one deserve a look at the rule to see what the other missed.

The HTML report is also the best artefact to walk a team through their own account, because it shows the configuration next to the finding.

3. Steampipe: questions the scanners did not ask

Scanners answer their own questions. Steampipe lets you ask yours, in SQL, against the live API of the cloud. Typical queries in a review:

-- Security groups that allow 0.0.0.0/0 on anything other than 80 and 443
select group_id, from_port, to_port, cidr_ipv4
from aws_vpc_security_group_rule
where cidr_ipv4 = '0.0.0.0/0' and not is_egress
  and (from_port not in (80, 443) or to_port not in (80, 443));

Pair it with Powerpipe for the CIS and AWS Well-Architected mods when you want dashboards, but the real value is answering the specific question the client's architecture raises: which Lambda functions can reach the payments database, which buckets are replicated outside the EU, which IAM roles have not been assumed in a year.

4. Cloudsplaining: IAM at scale

IAM is where the serious findings are and where the generic scanners are weakest, because a policy's risk depends on what it can reach. Cloudsplaining downloads the account's authorization details and reports policies that allow privilege escalation, resource exposure, infrastructure modification or data exfiltration, with the exact statements.

Run it against every account in the organisation, not just production. The path into production usually starts from a developer account nobody audits.

5. Pacu: proving the path

Finding an over-permissive role is one thing. Showing that it leads from a compromised developer laptop to the production database is what changes priorities in a steering committee. Pacu is an AWS exploitation framework built for exactly this, with modules for enumeration, privilege escalation and persistence.

We use it only with written authorisation, only in the scope agreed, and only to demonstrate paths already identified by the analysis above. It is not a scanner and should not be run as one. The output we keep is the chain of steps, so the client can verify the fix closes every link.

6. Trivy: images and infrastructure as code

Trivy scans container images for known vulnerabilities and Terraform, CloudFormation and Kubernetes manifests for misconfigurations. Two uses in a review:

• Every image running in the cluster, pulled by digest, so the report matches what is actually deployed rather than what the pipeline built last week.
• The infrastructure repository, to catch the misconfiguration before it is applied. A public bucket found in Terraform is a pull request; the same bucket found live is an incident report.

7. Checkov: policy for the pipeline

Checkov overlaps with Trivy on infrastructure-as-code checks, but its strength is custom policies in YAML or Python and a clean integration in CI. The deliverable at the end of a review is not the list of findings but the pipeline step that stops them from coming back. Checkov, with a policy set derived from the review's findings, is that step.

8. kube-bench and kube-hunter: the cluster itself

If there is Kubernetes, the cloud account's posture is half the picture. kube-bench checks the nodes and control plane against the CIS Kubernetes benchmark; on managed services such as EKS or GKE it checks what the provider leaves in your hands. kube-hunter probes the cluster from inside a pod to show what a compromised workload could reach.

What the tools do not do

None of them rank by business impact. A public bucket of marketing images and a public bucket of invoices are the same finding to every scanner. The ranking is the part of a security review that needs a person who has asked what each system is for.

None of them fix anything. The value of a review is the set of pull requests against the infrastructure repository that closes the findings, in an order that starts with the ones that would matter at 3 a.m.

And none of them replace logging. Tools tell you what is exposed today. CloudTrail, audit logs and a detection service tell you whether anyone has used it. Turn those on before running any of the above, so you can see what the review itself did.