Every few months someone gives me read-only access to an AWS account I have never seen and asks a deceptively simple question: is this okay? Over the years I have settled on three open-source tools to answer it. None of them is enough alone. Together they get me to a defensible picture in an afternoon.

I want to be honest about what "audit" means here. This is not a penetration test and it is not a compliance certification. It is the first pass: the part where you find the public bucket, the root user without MFA, the security group open to the world, and the fifteen IAM users nobody remembers creating. That first pass is where most of the real risk lives, and it is the part most teams never do properly because it feels boring.

The dangerous account is rarely the one that was attacked. It is the one nobody looked at.

Step zero: get access the right way

Before any tool runs, I ask for a dedicated read-only role rather than someone's personal credentials. The AWS managed policies SecurityAudit and ViewOnlyAccess attached to a role I can assume are enough for everything below. This matters for two reasons. The findings are cleaner when nobody can argue the tool "did something", and the role itself becomes the first thing I check: if the account cannot produce a scoped role in ten minutes, that tells me a lot about how IAM is managed.

Prowler: the wide net

Prowler is where I start because it is the broadest. It runs hundreds of individual checks across IAM, S3, EC2, RDS, CloudTrail, KMS, Lambda and most other services, and it maps each finding to frameworks like CIS, ISO 27001 and the AWS Foundational Security Best Practices. One command, one coffee, and I have a JSON and HTML report. 

prowler aws --profile audit-role --output-formats json-ocsf html \
  --compliance cis_2.0_aws

What Prowler is good at: coverage and consistency. If a control exists in a common framework, Prowler probably checks it, and it checks it the same way every time. That makes it perfect for a baseline you can rerun next quarter and diff.

What it is bad at: telling a story. A raw Prowler run on a medium account produces thousands of lines, and a large share of them are true but unimportant. The first time I ran it for a client I sent the full report and got a polite reply asking which of the four hundred failures they should actually care about. I never made that mistake again. Now I filter to critical and high severity, group by service, and treat everything else as backlog.

ScoutSuite: the picture

ScoutSuite covers a lot of the same ground as Prowler, but its output is a single static HTML report you can open in a browser and click around. It organises findings by service, shows you the actual resource configuration next to the rule that flagged it, and colours things by severity. 

scout aws --profile audit-role --report-dir ./scout-report

I use ScoutSuite for the conversation, not the checklist. When I sit down with the team that owns the account, I do not open a JSON file. I open the ScoutSuite report, go to the IAM section, and we look at the policy together. People understand a wildcard in an inline policy much faster when they can see it than when they read a finding ID.

Its weakness is depth in a few areas and a slower release cadence than Prowler. When the two disagree, Prowler is usually more current. When they agree, I trust the finding without a second look.

Steampipe: the questions the tools did not think of

The first two tools answer questions somebody else wrote. Steampipe lets me ask my own. It exposes the AWS API as Postgres tables, so anything I can describe in SQL I can query across the whole account in seconds. 

select
  name,
  create_date,
  password_last_used,
  mfa_enabled
from aws_iam_user
where password_enabled
  and not mfa_enabled
order by password_last_used nulls first;

This is where the audit stops being generic. Every account has a few questions that only make sense in context. Which security groups reference a CIDR that belongs to an office the company closed? Which S3 buckets have no lifecycle rule and were last written to more than a year ago? Which Lambda functions run on a runtime that AWS deprecated? No scanner ships those checks, because they depend on knowing the business. Steampipe lets me write them in five minutes while I am sitting with the people who know.

Steampipe also has community benchmark mods that reproduce most of the standard frameworks, so in principle you could replace Prowler with it. I keep both. Prowler is the reproducible baseline; Steampipe is the notebook.

How I put the three together

The part the tools cannot do

Here is the uncomfortable lesson from doing this repeatedly. The scan is the easy part. What is hard is everything around it: deciding which findings matter for this business, attaching evidence that a control is actually met, keeping the picture current after the engineers fix things, and being able to show a reviewer six months later that you did all of this on purpose. Scanners produce findings. They do not produce proof, and they do not remember.

Most teams I meet solve that with a spreadsheet and one very tired person. If you are in that position, start with the three tools above; they are free and they will find the things that hurt. Then think seriously about where the findings go next, because the report you cannot rerun and cannot explain is the one that will let you down in the room where it counts.