Cloud breaches still start more often with a setting someone forgot than with an exploit, and most teams cannot say how many of their accounts, subscriptions and projects fail the CIS Benchmark today. Prowler is an open source cloud security tool, licensed under Apache 2.0, that runs read-only posture checks against AWS, Azure, Google Cloud and other platforms and maps the results to frameworks such as the CIS Benchmarks, NIST SP 800-53 and ISO 27001. This guide explains what Prowler does, how defenders use it, how to deploy it safely with a least-privilege scanning identity, how to handle its output and how it compares with other posture scanning options. It is written for cloud security engineers, platform teams and auditors. It covers defensive and authorised use only; for the wider posture management market, see the CNAPP Guide.
Key takeaways
- Prowler reads configuration, it does not attack. It calls cloud provider APIs with a read-only identity and evaluates the returned configuration against its checks, so it is a posture scanner, not a penetration testing tool.
- The scanning identity is a privileged non-human identity. SecurityAudit and ViewOnlyAccess on AWS, Reader on Azure and Viewer on Google Cloud expose the configuration of the whole estate, so the scan role needs a trust policy, an External ID and monitoring.
- One scan, many frameworks. Each check maps to compliance frameworks, so the same run produces CIS Benchmark, NIST and ISO evidence without separate tooling.
- Mutelists decide whether output is trusted. Accepted exceptions belong in a reviewed, version-controlled mutelist with owners and descriptions, not in someone's memory.
- Treat fixers with caution. The optional --fixer flag changes cloud resources and needs write permissions, so keep it out of routine scanning and run it only under change control.
What the tool does
Prowler is maintained by Prowler (the company) on GitHub as prowler-cloud/prowler. It ships in three forms that share the same check engine:
- Prowler CLI: a Python package (pip install prowler, Python 3.10 to 3.12 at the time of writing) and container images, run as prowler <provider>, for example prowler aws, prowler azure or prowler gcp.
- Prowler Local Server: the self-hosted open source web application, made up of a Next.js UI, a Django REST Framework API, Celery workers and scheduler, PostgreSQL and Valkey, with an optional Neo4j graph for AWS attack path analysis. It is deployed with Docker Compose.
- Prowler Cloud: the vendor's hosted service. Its documentation states it is hosted in the EU (Ireland); the self-managed options can run anywhere, including air-gapped environments.
The project README publishes per-provider counts that change with each release. At the time of writing it listed 662 checks across 86 services for AWS, 191 checks for Azure and 110 for Google Cloud, plus Kubernetes, Microsoft 365, GitHub, Oracle Cloud, Google Workspace and others. Infrastructure as code scanning is delegated to Trivy, so for IaC coverage see the Trivy Guide.
| Check family | Example check IDs | What it catches |
|---|---|---|
| Identity hygiene (AWS) | iam_no_root_access_key, iam_root_hardware_mfa_enabled, iam_user_accesskey_unused, iam_rotate_access_key_90_days | Root keys, missing MFA, stale and long-lived access keys |
| Privilege escalation (AWS) | iam_policy_allows_privilege_escalation, iam_inline_policy_allows_privilege_escalation | Policies that let a principal grant itself more access |
| Entra ID (Azure) | entra_privileged_user_has_mfa, entra_global_admin_in_less_than_five_users | Unprotected or excessive privileged roles |
| Service accounts (Google Cloud) | iam_sa_no_user_managed_keys, iam_sa_user_managed_key_rotate_90_days, iam_sa_no_administrative_privileges | Downloadable keys and over-privileged service accounts |
| Data exposure | s3_account_level_public_access_blocks, s3_bucket_public_access | Publicly readable or writable storage |
| Workload credentials | ec2_instance_imdsv2_enabled, ec2_instance_account_imdsv2_enabled | Instance metadata exposed to request forgery |
| Logging | cloudtrail_multi_region_enabled | Gaps in audit trail coverage |
Results are written by default as CSV and JSON-OCSF (Open Cybersecurity Schema Framework), with HTML, JSON-ASFF for AWS Security Hub and SARIF for IaC available through -M/--output-formats. Compliance reports are written to a separate compliance output directory on every run. Each finding carries a status of PASS, FAIL or MANUAL, a severity, the check ID, the resource identifier and a muted flag.
Defender use cases
- Baseline assessment: a first full scan of every account, subscription and project gives an inventory of misconfigurations and a starting score per framework. Run prowler <provider> --list-compliance to see which frameworks apply, then --compliance with a framework name such as cis_2.0_gcp for a framework-specific summary.
- Audit evidence: the compliance outputs show requirement-by-requirement status for CIS Benchmarks, NIST SP 800-53, NIST CSF, ISO 27001, PCI DSS, SOC 2 and others, which supports CIS Control 4 (secure configuration) evidence. See the CIS Control 4 Secure Configuration of Enterprise Assets and Software Guide.
- Continuous posture monitoring: scheduled scans from Prowler Local Server, or the CLI in a scheduled job, show drift between runs. Filtering with --severity critical high or --status FAIL keeps daily reports actionable.
- Non-human identity review: the IAM, Entra and service account checks surface unused keys, keys older than 90 days, user-managed service account keys and administrative policies, which feed directly into a non-human identity clean-up. See the Multi-Cloud Identity Guide.
- Pipeline gating: Prowler exits with code 3 when checks fail (disable with -z/--ignore-exit-code-3), and the official GitHub Action can upload SARIF, so a pipeline can block on new critical findings.
- Pre-test hygiene: running posture scans before a cloud penetration test removes the obvious findings so testers spend their time on chained paths. See the Cloud Penetration Testing Guide.
Deployment and safe use
Scanning identity by provider
| Provider | Permissions the documentation requires | Recommended authentication | Hardening notes |
|---|---|---|---|
| AWS | AWS managed policies SecurityAudit and job-function/ViewOnlyAccess, plus the read-only prowler-additions-policy for some checks | A dedicated ProwlerScan role assumed with -R/--role (session default 3,600 seconds), provisioned from the project's CloudFormation or Terraform template | Require an External ID (-I/--external-id) to prevent the confused deputy problem; restrict the trust policy to the scanner principal ARN |
| Azure | Reader per subscription plus the custom ProwlerRole for some checks; Microsoft Graph application permissions AuditLog.Read.All, Directory.Read.All and Policy.Read.All for Entra checks | Service principal (recommended), or managed identity where the scanner runs in Azure | Domain.Read.All can replace Directory.Read.All at the cost of some Entra checks; grant admin consent deliberately |
| Google Cloud | Viewer (roles/viewer) at project, folder or organisation level, Service Usage Consumer, and a custom ProwlerRole with storage.buckets.getIamPolicy | Service account impersonation or application default credentials; key files are supported but are long-lived secrets | Prefer impersonation over downloaded keys; set a quota project |
Rollout steps
- Pick the form factor. The CLI is enough for a single team or for pipelines; Local Server suits central teams that need scheduling, a UI and history. Decide early whether findings may leave your environment, which rules Prowler Cloud in or out.
- Create the scan identities. Use the published role templates, keep them read-only, and put them under the same ownership and review as any other privileged non-human identity.
- Pilot on one non-production account. Run a full scan, review the volume of findings and check that no permission errors leave checks unexecuted.
- Build the mutelist. Record intended exceptions (a public website bucket, a security group open for a specific service) in YAML with a Description per entry, store it in version control and require review for changes.
- Expand across the organisation. For AWS, use role assumption into each member account or the documented AWS Organizations support; for Azure, assign Reader per subscription or at management group level; for Google Cloud, grant Viewer at folder or organisation level.
- Integrate outputs. Send findings to a SIEM, Security Hub (--security-hub with --send-sh-only-fails), S3 or ticketing, using OCSF where the destination supports it.
- Roll back cleanly. Because scanning is read-only, rollback means removing the scan role assignments and stopping the schedule; nothing in the scanned estate changes unless fixers were used.
Protecting the scanner and its data
- Output is sensitive: a findings file is a map of every weakness in your cloud estate. Store it encrypted, restrict access and set a retention period.
- Local Server secrets: the documentation warns not to use default .env values in production, to treat the .env file as a secret and to never reuse static token signing keys. Change default Neo4j credentials if attack paths are enabled.
- Prefer short-lived credentials: run the scanner on a host with an attached role, managed identity or workload identity rather than static keys in a .env file.
- Keep fixers separate: the --fixer flag needs write permissions (for example ec2:EnableEbsEncryptionByDefault or s3:PutAccountPublicAccessBlock) and can break workloads, such as public buckets that are meant to be public, or incur charges. Never give the routine scan role those permissions.
- Pin versions: the latest container tag tracks the development branch and is not stable; use a release tag or stable.
The licence is Apache 2.0, so commercial and internal use, modification and redistribution are permitted under its notice terms. Some features of Prowler Cloud are subscription features; check the current documentation before relying on them.
Detection and hardening value
Prowler maps posture to the attacker behaviours it makes harder. The mapping below is by outcome and is NHI Mgmt Group's own, not a vendor claim.
| Finding area | Attacker behaviour it reduces (MITRE ATT&CK) | Control framework link |
|---|---|---|
| Unused or old access keys, missing MFA on privileged users | T1078.004 Cloud Accounts | NIST SP 800-53 AC-2; CIS Control 5 |
| Public storage and object access | T1530 Data from Cloud Storage | NIST SP 800-53 CM-6; CIS Control 3 |
| Privilege escalation in IAM policies | T1098.001 Additional Cloud Credentials | NIST SP 800-53 AC-6; CIS Control 6 |
| IMDSv1 allowed on instances | T1552.005 Cloud Instance Metadata API | NIST SP 800-53 CM-6; CIS Control 4 |
| Audit logging gaps | Reduced visibility of T1580 Cloud Infrastructure Discovery | NIST SP 800-53 AU-2; CIS Control 8 |
The Capital One Breach 2019 combines two of these rows: credentials for a firewall's cloud role were obtained, widely attributed to request forgery against the instance metadata service, and that role could list and read customer data in S3. Checks for IMDSv2 enforcement and for over-broad role permissions would both have flagged parts of that path, although posture scanning alone does not catch the application flaw.
In NIST CSF 2.0 terms, regular posture scanning supports ID.RA-01 (vulnerabilities identified, validated and recorded), PR.PS-01 (configuration management practices) and DE.CM-09 (monitoring of computing hardware, software and runtime environments). In NIST SP 800-53 it supports CA-7 (Continuous Monitoring), CM-6 (Configuration Settings) and RA-5 (Vulnerability Monitoring and Scanning).
Metrics
- Coverage: accounts, subscriptions and projects scanned in the last seven days as a share of the inventory.
- Critical and high FAIL count: trend per business unit, excluding muted findings.
- Mean time to remediate: days from first FAIL to PASS for critical findings.
- Mutelist health: entries without an owner, a description or a review in the last twelve months.
- Stale credentials: count of iam_user_accesskey_unused and iam_sa_user_managed_key_unused failures, which should fall to zero.
Alternatives
| Option | Type | Licence | When it fits |
|---|---|---|---|
| Prowler | Multi-cloud posture scanner with compliance mapping | Apache 2.0 | Broad multi-cloud checks and framework evidence from one tool |
| ScoutSuite (NCC Group) | Multi-cloud point-in-time auditing tool | GPL-2.0 | Consultant-style assessments where data is gathered once and reviewed offline |
| Cloud Custodian | Policy-as-code rules engine for AWS, Azure and Google Cloud | Apache 2.0 | Teams that want to write their own policies and take automated actions |
| Checkov and Trivy | Infrastructure as code and image scanners | Apache 2.0 | Shift-left checks before resources are deployed |
| Provider-native services (AWS Security Hub, Microsoft Defender for Cloud, Google Security Command Center) | Built-in posture management | Commercial, priced per provider | Single-cloud estates that want integration with native alerting |
| Commercial CSPM or CNAPP platforms | Agentless posture plus workload, identity and data risk | Commercial | Large estates needing correlation, attack paths and support |
Choose an open source scanner when you need transparency over checks, data kept in your own environment and no licence cost, and accept that you own the operation. Choose a commercial platform when you need correlation across workloads, identities and data at scale. Many organisations run both, using Prowler as an independent second opinion on a commercial tool. See the CNAPP Buyer's Guide and the Cloud Misconfiguration Guide.
Practitioner checklist
- Create a dedicated, read-only scan identity per provider from the published templates, with an External ID on AWS.
- Register the scan identities as privileged non-human identities with an owner and review date.
- Pilot on a non-production account and fix permission errors before expanding.
- Keep the mutelist in version control with a description and owner for every entry.
- Pin a release version and update on a schedule.
- Store findings encrypted with restricted access and a retention period.
- Keep fixers out of scheduled scans and run them only under change control.
- Track coverage, critical FAIL trends and stale credential counts monthly.
Standards and references
- Prowler: prowler-cloud/prowler repository and README
- Prowler: Documentation (authentication, reporting, mutelist, fixers, compliance)
- NCC Group: ScoutSuite repository
- Cloud Custodian: project repository
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- MITRE ATT&CK: Cloud Accounts
- OCSF: Open Cybersecurity Schema Framework
Related NHI Mgmt Group resources: CNAPP Guide · Cloud Security Guide · Trivy Guide · AWS IAM Policies and Roles Guide · Google Cloud IAM and Service Accounts Guide