Prowler: the open source cloud security platform behind the CLI

What Prowler scans and who actually needs it

Prowler is a Python security scanner for cloud accounts. The README describes it as an open source cloud security platform that automates security and compliance across any cloud environment, and the repository topics list AWS, Azure, GCP, IAM, hardening and forensics alongside CIS benchmark and CSPM. The intended user is a cloud or security engineer who has read-only credentials in one or more cloud accounts and needs to answer two different questions: what is misconfigured right now, and which control in a named framework does that misconfiguration break.

The second question is where most scanners get thin. Prowler ships hundreds of built-in controls mapped to standards the README lists explicitly: CIS, NIST 800, NIST CSF, CISA, MITRE ATT&CK, RBI, FedRAMP, PCI-DSS, NIS2, GDPR, HIPAA, FFIEC, SOC2, GXP, ISO 27001, AWS Foundational Technical Review, the AWS Well-Architected Framework, BSI C5, ENS and KISA ISMS-P. It also supports custom frameworks. That mapping is the product. A raw list of failed checks is easy to produce; a list an auditor will accept is not.

The README also markets a Prowler ThreatScore, described as weighted risk prioritisation scoring that puts the most critical findings first. Treat that ordering as a starting point for triage rather than a substitute for reading the finding. Nothing in the repository material documents how the weights are derived, so if you need to justify the ranking to someone outside your team, that work is on you.

Three ways to run Prowler and what each one is for

The repository contains three distinct surfaces, and confusing them is the most common setup mistake.

The first is the CLI. The README gives a single command shape: `prowler <provider>`. This runs checks against a provider and writes results. It is the piece you put in CI or run from a bastion host. It has no database and no persistent state of its own.

The second is the local dashboard, started with `prowler dashboard`. The README shows this as a separate command, which implies the CLI produces output that the dashboard then reads. It is a local viewer, not a service you expose.

The third is Prowler Local Server, the self-hosted version of the Prowler Cloud web application. This is a multi-container stack: `docker-compose.yml` defines an `api` service, a `ui` service, `postgres`, `valkey`, `neo4j` and `mcp-server`, with health checks on each. The API listens on `${DJANGO_PORT:-8080}` and the UI on `${UI_PORT:-3000}`. This is the surface that stores scans, schedules them and runs the post-scan Attack Paths job. If you only want a report, you do not need any of it.

One detail worth noting: the production compose file pulls pre-built images tagged `${PROWLER_API_VERSION:-stable}` and `${PROWLER_UI_VERSION:-stable}` from Docker Hub under the `prowlercloud` namespace. The `stable` default means an unattended `docker compose up` can move you between releases without a commit. Pin those variables if you care about reproducibility.

Installing the Prowler CLI and running a first AWS scan

The README points at PyPI for the package, and the repository ships a Dockerfile and a Docker Hub image (`toniblyx/prowler`) as alternatives. The PyPI route is the shortest path for a first run.

Install it into an isolated environment. The project's `pyproject.toml` declares support for Python 3.10 through 3.13, and the Dockerfile builds on `python:3.12.13-slim-trixie`, so 3.12 is a safe choice.

pip install prowler

After installation the `prowler` entry point should be on your PATH. The README shows the general invocation as `prowler <provider>`, so an AWS run is the provider name with no extra flags.

prowler aws

Expect a progress display during the run (the dependency list includes `alive-progress`) followed by findings, each carrying a severity and the compliance frameworks it maps to. If you want the local viewer instead of terminal output, the README lists a separate command for it.

prowler dashboard

Authentication is not documented in the README excerpt. Prowler is a Python program that uses the standard cloud SDKs, so the usual credential chain applies, but the repository material does not spell out the credential precedence. Confirm which profile or identity the scanner is using before you trust a clean result.

For the container route, the repository also publishes to the AWS ECR public gallery under `prowler-cloud/prowler`, which the README links. That path avoids installing Python dependencies on the scanning host, at the cost of mounting your cloud credentials into the container.

Attack Paths, Neo4j and the constraint the README is explicit about

Attack Paths is the newest piece and the one with the sharpest operational edges. According to the README, it extends every completed AWS scan with a graph that combines Cartography's cloud inventory with Prowler findings, and it runs in the API worker after each scan. Two consequences follow immediately.

First, it is AWS-only. The README says every completed AWS scan. Azure and GCP scans are not described as feeding the graph.

Second, it is not a CLI feature. Because the job runs in the API worker, you need Prowler Local Server or Prowler Cloud to get it at all. A team running `prowler aws` from a CI runner will never see an attack path.

The sink is selected with `ATTACK_PATHS_SINK_DATABASE`, which accepts `neo4j` or `neptune` and defaults to `neo4j`. The bundled Docker Compose files already include a `neo4j` service, so the default path needs no extra infrastructure.

The constraint that will surprise people is stated plainly in the README: Cartography ingestion always uses a temporary Neo4j database, regardless of the configured sink, and the `NEO4J_*` variables must remain set even when `ATTACK_PATHS_SINK_DATABASE=neptune`. Choosing the cloud-managed backend does not remove Neo4j from your deployment. It adds Neptune alongside it. If the reason you picked Neptune was to avoid operating a graph database, the README does not support that plan.

The relevant variables are `NEO4J_HOST` (default `neo4j`), `NEO4J_PORT` (default `7687`, the Bolt port), and `NEO4J_USER` / `NEO4J_PASSWORD` for credentials with rights to create per-scan data. The README excerpt truncates that last description mid-sentence, so the exact permission set required is not fully specified.

Where Prowler is the wrong tool

Prowler is a configuration and posture scanner. It reads cloud APIs and compares what it finds to a control definition. It does not instrument running workloads.

If your question is whether a process on a production host just spawned a reverse shell, Prowler will not answer it. There is no runtime agent, no eBPF probe and no syscall visibility anywhere in the repository layout. The topics list includes forensics, and the Dockerfile installs Trivy and Zizmor, but those are image, dependency and workflow scanners that run at scan time, not continuous runtime sensors. Teams that need detection and response should not expect Prowler to replace that layer.

The second mismatch is infrastructure appetite. The CLI is genuinely lightweight. Prowler Local Server is not: Postgres, Valkey, Neo4j, an API container, a UI container and an MCP server container, each with its own health check and start period. The API health check alone allows a 60-second start period and 12 retries. A small team that wants a weekly compliance report is better served by the CLI and a scheduled job than by operating that stack.

The third is scope creep in the other direction. Attack Paths suggests the project is moving toward graph-based analysis of exposure. That is a different discipline from benchmark checking, and the README does not describe how the graph handles Azure or GCP, or how findings age out of it.

How Prowler compares to a managed CSPM service

The obvious alternative is a commercial cloud security posture management service, which is also what Prowler Cloud, the vendor-hosted product linked in the README, is. The difference in approach is where the checks live and who owns the mapping.

With a managed CSPM, the vendor maintains the check library, the framework mappings and the console. You get a UI on day one and someone else's on-call rotation when a cloud API changes. You also get the vendor's opinion about which frameworks matter, and your findings sit in their tenancy.

With Prowler, the checks are Python in a repository you can read, the framework mappings are in that same repository, and everything runs under credentials you control. The trade-off is that you own the upgrade cadence. Releases are frequent (5.42.0 on 2026-09-11, 5.41.0 on 2026-09-02, 5.40.0 on 2026-08-28), which is good for coverage of new cloud services and means there is always a newer version than the one you pinned.

The hybrid is the self-hosted server: the vendor's application, running in your infrastructure. That is a real middle ground, and it is the option to evaluate if you want the Attack Paths graph without sending findings to a third party.

A narrower alternative for AWS-only shops is to assemble the same coverage from individual open source scanners. You would get comparable raw findings and lose the unified framework mapping, which is the part that takes the most maintenance to reproduce.

Licence, maintenance and what upgrading actually costs

Prowler is Apache-2.0. That permits commercial use, modification and redistribution, and it includes an explicit patent grant. It does not give you the Prowler name or logo, and it does not make the vendor-hosted Prowler Cloud service part of the open source grant. If you plan to redistribute a modified Prowler inside a product, read the NOTICE and attribution requirements rather than assuming the licence text covers everything. This is a description of the licence, not legal advice.

The repository is not archived, and the last push was on 2026-09-21, the same day as the most recent release activity. That is a fast cadence, and it cuts both ways. Security checks need to track cloud API changes, so frequent releases are the point. They also mean your pinned version drifts from the check library quickly, and a check that passed last month may be rewritten.

The dependency list explains a large part of the upgrade cost. `pyproject.toml` pins Azure SDK packages to exact versions across dozens of `azure-mgmt-*` modules, plus `azure-identity` and `azure-keyvault-keys`. Those pins move when Microsoft ships new API versions. Upgrading Prowler is not a one-line version bump if you have your own code importing Prowler modules; the SDK surface underneath can shift too.

The Dockerfile shows the project takes supply chain seriously in a specific way: Trivy, PowerShell and Zizmor binaries are pinned by SHA256 in build arguments, with a comment noting the checksums are pinned in the file rather than fetched with the artefact, because a compromised release would ship its own checksum. It also applies targeted `--only-upgrade` patches for named CVEs in the Debian base rather than moving the base digest. That is a deliberate, defensible choice, and it means the image is not simply the stock base image plus Python.

For the server stack, the upgrade surface is larger. The compose file pulls `prowlercloud/prowler-api` and `prowlercloud/prowler-ui` at `stable` by default, runs database migrations through the API entrypoint, and depends on Postgres, Valkey and Neo4j. Pin `PROWLER_API_VERSION` and `PROWLER_UI_VERSION`, and check the release notes before moving them.

Editorial conclusion

Prowler fits teams that already hold read-only credentials in more than one cloud and need framework-mapped evidence, and engineers who want a CLI they can run from a pipeline. It does not fit anyone expecting the CLI alone to produce Attack Paths, since that graph is built by the API worker after a scan, nor anyone unwilling to run a Neo4j instance even when the sink is set to Neptune. Before adopting it, verify which compliance frameworks your auditor actually accepts and confirm the version of the CIS benchmark each check maps to.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. prowler-cloud/prowler on GitHub
4. README
5. Releases