Prowler vs ScoutSuite: Audit AWS Security Misconfigurations

Both Prowler and ScoutSuite inspect AWS configuration through AWS APIs rather than attacking hosts.

Prowler is currently the stronger choice for an actively maintained, broad AWS security and compliance assessment. ScoutSuite remains useful as a different point-in-time view of account configuration. Running both can expose different coverage, different assumptions, permission gaps, and different finding logic. Two tools reporting something still does not automatically prove the finding.

Prowler vs ScoutSuite: key differences

Start with a plain comparison. Do not invent an “accuracy score.”

On this page Prowler is the primary workflow. ScoutSuite is the independent second view you compare against the same identity and credentials.

ScoutSuite 5.14.0 is still the latest stable PyPI/GitHub release, published in May 2024. That is a much slower release cadence than Prowler, so treat ScoutSuite as a useful second viewpoint rather than the fresher primary AWS auditor.

Prepare the AWS audit identity

If one tool can call more APIs than the other, comparing findings becomes meaningless. The projects also document slightly different recommended read-only policy sets, so a “Prowler-only” identity is not a fair ScoutSuite baseline.

Required permissions

Create a dedicated auditor IAM user (or a role you can assume from a non-root principal). For this comparison, attach the union of the documented managed policies:

• arn:aws:iam::aws:policy/SecurityAudit (both tools)
• arn:aws:iam::aws:policy/job-function/ViewOnlyAccess (Prowler baseline)
• arn:aws:iam::aws:policy/ReadOnlyAccess (ScoutSuite baseline)

Prowler documents SecurityAudit + ViewOnlyAccess, plus an optional additions policy for full check coverage. ScoutSuite documents SecurityAudit + ReadOnlyAccess. This lab used the three-policy union so both scanners get the read visibility their own docs expect. I intentionally omitted Prowler’s optional additions policy, so some Prowler checks can still be incomplete. Do not attach AdministratorAccess just to make a demo easier.

This lab used IAM user glc-prowler-scoutsuite-auditor with those three managed policies, stored under AWS CLI profile glc-audit. Root access keys cannot assume roles (Roles may not be assumed by root accounts), so a non-root auditor identity is required for role-based designs too.

Verify caller identity

Wrong profile and wrong account are common. Confirm STS before either tool runs:

aws sts get-caller-identity --profile glc-audit

Account id values below are redacted for publishing:

{
    "UserId": "AIDAEXAMPLEAUDITOR",
    "Account": "111122223333",
    "Arn": "arn:aws:iam::111122223333:user/glc-prowler-scoutsuite-auditor"
}

Confirm three things:

• Account matches the engagement scope
• Arn is the auditor user (or assumed-role ARN shape), not an unexpected admin
• The profile name you will pass to both tools is the same (glc-audit here)

GetCallerIdentity does not require an explicit IAM permission grant, which makes it a safe first call even on tight identities.

Run Prowler on AWS

Install Prowler

Install Prowler in an isolated environment. On this Kali host, pipx worked with Python 3.13:

pipx install prowler

Confirm the version you will cite in the report:

prowler -v

Prowler 5.41.0 (You are running the latest version, yay!)

This article uses the CLI only. It does not deploy Prowler App or a self-hosted UI stack.

Targeted IAM/S3/EC2 scan

For a fair, fast comparison, limit region and services to the lab scope: IAM, S3, and EC2 in ap-south-1, and keep only FAIL rows in the summary view:

prowler aws --profile glc-audit --region ap-south-1 --service iam s3 ec2 \
  --status FAIL --output-directory ~/prowler-scoutsuite-aws-audit/prowler-out \
  --output-filename prowler-iam-s3-ec2 --ignore-exit-code-3 --no-banner

You rarely need every check while investigating one control family. The same flags scale down to --service iam, --service s3, or --service ec2. You can also pass --check / -c for a single check id once you know which rule matters.

Sample overview from the union-permission lab run (151 checks executed; filtered overview shows fails only):

Overview Results:
100.0% (47) Failed | 0.0% (0) Passed | 0.0% (0) Muted

Account … Scan Results (severity columns are for fails only):
Provider   Service   Status     Critical   High   Medium   Low
aws        ec2       FAIL (6)          0      2        2     2
aws        iam       FAIL (30)         4      6       12     8
aws        s3        FAIL (11)         0      2        5     4

Read findings as: status, severity, service, resource, region, and the extended status text. Do not paste hundreds of rows into a client report without triage.

The HTML report records version, parameters, caller identity, and the fail table in one place:

Crop account ids before you publish screenshots from your own runs.

Validate an IAM finding

This lab created user glc-prowler-scoutsuite-overbroad-user with an inline policy that allows Action: "*" on Resource: "*".

Prowler returned a critical fail:

Manually inspect the same object:

aws iam get-user-policy --user-name glc-prowler-scoutsuite-overbroad-user \
  --policy-name LabOverbroadInline --profile glc-audit

{
    "UserName": "glc-prowler-scoutsuite-overbroad-user",
    "PolicyName": "LabOverbroadInline",
    "PolicyDocument": {
        "Version": "2012-10-17",
        "Statement": [{
            "Sid": "LabOverbroad",
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        }]
    }
}

The CLI confirms the scanner: this is a true positive for an administrative inline policy on a user. Related Prowler rows (iam_inline_policy_allows_privilege_escalation, CloudTrail/KMS full-access style checks) are derivatives of the same *:* document, not separate root causes.

Validate an S3 finding

The lab bucket glc-prowler-scoutsuite-02920 intentionally disabled Block Public Access:

Verify with the API:

aws s3api get-public-access-block --bucket glc-prowler-scoutsuite-02920 --profile glc-audit

{
    "PublicAccessBlockConfiguration": {
        "BlockPublicAcls": false,
        "IgnorePublicAcls": false,
        "BlockPublicPolicy": false,
        "RestrictPublicBuckets": false
    }
}

All four settings are false. That matches Prowler. The bucket held no production data; it existed only to create a controlled finding.

Run ScoutSuite on the same AWS account

Install ScoutSuite

ScoutSuite 5.14.0 is still the latest stable PyPI/GitHub release (May 2024). Install it in a dedicated venv:

python3 -m venv ~/prowler-scoutsuite-aws-audit/venv-scout

Activate the venv, then install the pinned release:

pip install 'scoutsuite==5.14.0'

Confirm the ScoutSuite version before you scan:

scout --version

Scout Suite 5.14.0

Same services and scope

Run against the same profile, region, and services:

scout aws -p glc-audit -r ap-south-1 --services iam s3 ec2 \
  --report-dir ~/prowler-scoutsuite-aws-audit/scout-out \
  --report-name scout-glc-audit --no-browser -f

INFO Launching Scout
INFO Authenticating to cloud provider
INFO Gathering data from APIs
INFO Fetching resources for the EC2 service
INFO Fetching resources for the IAM service
INFO Fetching resources for the S3 service
INFO Running rule engine
INFO Creating …/scout-glc-audit.html

Open the HTML file locally in a browser. ScoutSuite’s strength is navigating services and flagged rules from that dashboard.

If the page shows a loading modal, wait for the embedded results JavaScript to finish, then expand EC2, IAM, and S3.

Compare Prowler and ScoutSuite findings

Same identity (glc-audit), same three-policy read-only union, same region (ap-south-1), same three services. Ground truth from AWS CLI, not from finding counts. After adding ScoutSuite’s documented ReadOnlyAccess alongside Prowler’s baseline, the three controlled disagreements below still tracked rule logic rather than missing API visibility.

Do not treat “47 Prowler fails vs a handful of ScoutSuite flagged rules” as a quality score. Check scope and rule logic differ on purpose.

Why the tools disagree

Common reasons:

• Different checks and rule libraries
• Different severity mappings
• Different assumptions about unused resources
• Region / service filters you passed on the CLI
• Scanner version (Prowler 5.41 vs ScoutSuite 5.14 here)
• Detection logic for policy documents and condition keys
• Missing or incomplete API responses
• AWS service behavior changing faster than older rulesets

Disagreement is a signal to verify, not a reason to average severities.

How missing permissions affect results

Before you trust PASS or FAIL, inspect:

• Scanner errors and stderr
• AccessDenied / unauthorized API calls
• Skipped checks
• Empty services that should contain resources you know exist

ScoutSuite has a long history of incomplete reads producing odd defaults when permissions are missing. Prowler also has check-specific false positives and open issues. A green PASS with half the APIs denied is not evidence of safety.

If one tool “sees” a bucket property and the other does not, compare IAM allow lists and CloudTrail for AccessDenied before arguing about tool quality. That is why this lab used a common read-only union instead of only one project’s recommended pair.

Validate findings before reporting

Use the same discipline you would for host vulnerability scanners (validate scan results):

1. Identify the resource.
2. Read the scanner evidence and check id.
3. Verify the AWS setting with CLI or Console.
4. Read the tool’s check description / reference URL.
5. Read AWS documentation for the control.
6. Decide true positive, false positive, or incomplete evidence.
7. Record proof (CLI output, policy document, screenshot crop).

Prioritize validated findings with business impact next (vulnerability prioritization).

A CIS or other compliance fail means configuration does not meet that benchmark. It does not automatically mean an attacker can own the account today. A PASS means that check’s logic did not fail under the permissions and scope you used. It does not mean the account is secure. Keep compliance rows and exploitable attack paths in separate mental buckets when you write the report.

After you validate a misconfiguration, remediate configuration first. Only then consider authorized offensive validation (for example Pacu or manual IAM abuse testing) where the RoE allows it. This page stops at posture evidence.

Which should you use: Prowler or ScoutSuite?

Use Prowler when you need:

• A current broad AWS audit
• Compliance mappings
• Automation / frequent rescans
• An actively updated check ecosystem

Use ScoutSuite when you want:

• An independent configuration view
• HTML exploration of services and rules
• A second perspective on the same account

Use both when you plan to investigate differences, not when you only want a larger finding count.

Troubleshooting

References

• Prowler CLI installation
• Prowler AWS authentication and required permissions
• Prowler on PyPI
• ScoutSuite GitHub (NCC Group)
• ScoutSuite Setup wiki
• ScoutSuite Amazon Web Services wiki
• AWS SecurityAudit managed policy
• AWS ReadOnlyAccess managed policy
• AWS Customer Support Policy for Penetration Testing