Prowler

Prowler is an open-source security-assessment CLI that connects to a live cloud account with read-only credentials, runs hundreds of individual checks against it, and tells you exactly where that account's actual configuration diverges from the CIS Benchmarks and a dozen other published standards — in minutes, from a laptop or a pipeline job, with no agent to install and nothing to enable in the account beforehand. It started as a single Bash script auditing one AWS account against one benchmark and has grown into a Python engine covering AWS, Azure, GCP, and Kubernetes from one command, one check library, and one compliance-mapping layer. By the end of this page you should know how a Prowler scan actually executes against an account, how to read a compliance-framework report rather than just a flat findings list, and precisely what it adds on top of — rather than instead of — AWS's own Security Hub.

What Prowler is, and the problem it solves

☺ Like you're 10: It began as one person's script for checking a single AWS rulebook, and grew into a proper multi-cloud tool that checks a dozen rulebooks at once.

Prowler was created by Toni de la Fuente and first released in 2015 as an AWS-focused command-line script built specifically to automate the CIS Amazon Web Services Foundations Benchmark — a from-scratch, checklist-by-checklist reimplementation of what had previously been a manual, spreadsheet-driven audit. It's since been rewritten from the ground up in Python (Prowler v3, then v4) as a proper multi-provider engine, and it now scans AWS, Azure, GCP, and Kubernetes from the same CLI, with each provider's checks organized the same way and reported through the same output pipeline. The project is open source under the Apache-2.0 license, hosted on GitHub under the prowler-cloud organization, and remains free to install and run with no account, license key, or network callback required for the CLI itself — a company built around the project (also named Prowler) additionally offers a hosted dashboard and a self-hostable web application layered on the same open-source scanning engine, the same open-core shape as several other tools on this course's tool shelf, but nothing in this page requires either.

The problem Prowler solves is running a genuinely comprehensive account audit without either writing the checks yourself or buying a platform to get them. A cloud account accumulates hundreds of independently-configurable resources — IAM roles, S3 buckets, security groups, KMS keys, CloudTrail trails, RDS instances — and a "does this look safe" review done by a person reading the console one page at a time is both slow and structurally incomplete, because nobody remembers to check all of it, every time, the same way. Prowler answers that by encoding the CIS Benchmark (and everything layered on top of it) as executable checks: point it at an account and every check runs against that account's live state, every time, identically.

Architecture: read-only API calls, checks-as-code, one report

☺ Like you're 10: Prowler asks the cloud provider a big list of "what is currently true" questions, checks each answer against a rule, and tags every answer with every rulebook that rule belongs to.

A Prowler scan has no server-side component and touches nothing but the provider's own read APIs. Given credentials — an AWS profile or assumed role, an Azure service principal, a GCP service account key, or a kubeconfig context — the engine authenticates once, then dispatches each check as a small, self-contained unit: a Python class that knows which read-only API calls it needs (for example, iam:GetAccountPasswordPolicy or s3:GetBucketPolicyStatus), what a passing configuration looks like, and which compliance frameworks that specific control belongs to. Checks run multi-threaded and are grouped by service, so a scan of a mid-sized account typically finishes in single-digit minutes rather than the hour a fully serial pass would take — thread count is tunable, which matters more than it sounds like the moment a large account starts tripping API rate limits.

The detail worth carrying forward from this diagram: compliance mapping isn't a separate reporting step bolted on after the scan — it's metadata attached to each check before it ever runs. A single check's metadata.json declares which frameworks and which specific requirement within each framework it satisfies, so the same PASS or FAIL result rolls up into as many framework reports as apply, computed once. That's the mechanism the next two sections build on directly.

Running a full-account audit from the CLI

☺ Like you're 10: One command scans a whole account by default; a handful of flags narrow it to specific checks, specific regions, or a whole organization's worth of accounts at once.

Prowler installs from PyPI (pip install prowler) or runs as a container image, which is the friendlier default for a CI job that shouldn't have to manage a Python environment — the image's namespace on Docker Hub has moved as the project changed hands, so confirm the current one against the project's own README rather than trusting an old blog post. Either way, the CLI authenticates using each provider's normal credential chain: for AWS, that's the same environment variables, shared credentials file, or instance/task role Prowler would find without any special configuration; for Azure and GCP, the equivalent service-principal or service-account patterns.

# install
$ pip install prowler
$ prowler --version

# the default: scan the whole AWS account reachable from your current credentials,
# every enabled region, every check, human-readable output plus a report file on disk
$ prowler aws

# other providers — same engine, same flag shapes
$ prowler azure --az-cli-auth
$ prowler gcp --credentials-file sa-key.json
$ prowler kubernetes --kubeconfig-file ~/.kube/config

# narrow a run: specific checks, specific services, specific regions
$ prowler aws --check s3_bucket_level_public_access_block,iam_root_hardware_mfa_enabled
$ prowler aws --service iam s3 ec2
$ prowler aws --region us-east-1 eu-west-1

# see what a given install actually knows before trusting a table on a page like this one
$ prowler aws --list-checks
$ prowler aws --list-services
$ prowler aws --list-compliance

A single account is the easy case. A real organization audit means every member account, which Prowler handles by assuming a role into each one rather than running once per account by hand:

# assume a role in one target account from a management or audit account
$ prowler aws --role arn:aws:iam::222233334444:role/ProwlerAudit \
    --role-session-name prowler-audit

# a common real-world wrapper: pull every active account ID from AWS Organizations,
# then loop the assumed-role scan across all of them into one combined output directory
$ for acct in $(aws organizations list-accounts \
      --query "Accounts[?Status=='ACTIVE'].Id" --output text); do
    prowler aws --role "arn:aws:iam::${acct}:role/ProwlerAudit" \
      --output-directory "reports/${acct}"
  done

The identity running Prowler needs read access across the account, not just the resource types you expect to matter — a check you didn't anticipate still needs to see the resource it's checking. AWS publishes exactly this pairing for the purpose: attach the SecurityAudit managed policy for the bulk of read access Prowler's checks need, plus ViewOnlyAccess to cover the handful of additional read calls SecurityAudit alone doesn't grant. Both are read-only by AWS's own definition, but "read access to nearly everything in the account" is still a credential worth protecting — assume it through a role with a short session duration rather than handing out a long-lived access key with that policy attached.

Not every finding should stay actionable forever. A bucket that's intentionally public because it hosts a static site, a legacy security group mid-decommission, a check that structurally can't apply to a workload your team doesn't run — Prowler's mutelist suppresses exactly these, scoped as precisely as you want:

# mutelist.yaml
Accounts:
  "111122223333":
    Checks:
      s3_bucket_level_public_access_block:
        Regions: ["us-east-1"]
        Resources: ["acme-marketing-site"]
        Tags: []
        Reason: "Static site behind CloudFront with an OAI — see runbook RB-114"

$ prowler aws --mutelist-file mutelist.yaml

Treat a mutelist entry with no Reason the same way Checkov's inline skip comments get treated in code review: technically allowed, practically worthless. A muted finding with a real reason and a runbook link is an accepted risk on record; a muted finding with none is a scanner someone quietly turned off for one resource, with no trace of why.

Reading compliance-framework-mapped output

☺ Like you're 10: Instead of one long list of "this is wrong," you can ask Prowler to sort the exact same findings by which rulebook they break — and one broken setting usually shows up under several rulebooks at once.

The flat findings list — every check, every resource, PASS or FAIL — is the ground truth, but it's rarely what a compliance conversation actually needs. The --compliance flag re-groups that same run's results around a specific published framework instead, mapping each requirement in that framework to the underlying checks that satisfy it:

# run the full scan, but report it through the lens of one specific framework
$ prowler aws --compliance cis_2.0_aws
$ prowler aws --compliance pci_4.0_aws
$ prowler aws --compliance hipaa_aws
$ prowler aws --compliance soc2_aws

# every framework identifier a given install ships — treat the list above as illustrative;
# exact identifiers shift release to release, this is the authoritative source
$ prowler aws --list-compliance

A compliance-mode report reads by requirement, not by check: CIS Benchmark section 1.5 ("ensure hardware MFA is enabled for the root user") shows as PASS or FAIL, backed by whichever underlying check(s) evaluate it, and a requirement can legitimately come back MANUAL rather than PASS or FAIL — some controls (an organizational policy document existing, a process being followed) simply can't be verified by an API call, and Prowler is explicit about that distinction rather than silently marking everything it can't check as passing. The CIS Benchmarks themselves are published in two profile levels worth knowing by name — Level 1 is a baseline every account should clear with minimal operational friction; Level 2 is stricter and assumes a security-conscious environment willing to accept the operational trade-offs — and Prowler's CIS-mode reports carry that level distinction through into the output.

Treat these IDs and mappings as illustrative rather than a table to memorize — Prowler ships new checks and adjusts framework mappings every release, and check IDs plus their exact requirement mappings for your installed version are always one command away via --list-checks and --list-compliance. What's stable is the mechanism, not the specific list: metadata attached once, reported many ways.

Prowler and AWS Security Hub: complements, not competitors

☺ Like you're 10: One is a very thorough inspector you call in for a deep walkthrough; the other is a permanent night-watchman who's always on duty but trusts fewer rulebooks by default. You generally want both, and you can point the inspector's report straight at the watchman's desk.

AWS Security Hub is AWS's own native aggregation service: it ingests findings continuously from AWS's other detection services — GuardDuty, Inspector, Macie, IAM Access Analyzer — plus its own configuration checks against a handful of built-in standards (the AWS Foundational Security Best Practices standard, and an AWS-maintained CIS Benchmark implementation among them), and gives an account or an entire AWS Organization one correlated console and one finding format (ASFF, the AWS Security Finding Format) that every contributing service writes into. Its defining property is that it's always running, wired directly into CloudTrail and Config change events, so drift shows up close to real time rather than at the next scheduled scan.

Prowler is not a replacement for that — it's a second, independent source of findings written in the same format, and the two are designed to interoperate directly:

# push this run's findings straight into Security Hub as ASFF,
# on top of whatever CLI/HTML/CSV/JSON-OCSF output you also asked for
$ prowler aws --security-hub

# only send failing findings — keep passes out of the Security Hub finding count entirely
$ prowler aws --security-hub --send-sh-only-fails

What Prowler adds on top of Security Hub's own checks is depth and portability, not a competing console. Security Hub's built-in CIS coverage is real but narrower than Prowler's dedicated CIS implementation, which tracks the full published benchmark — including checks Security Hub's own standard doesn't implement — and Prowler additionally covers a stack of other frameworks (PCI-DSS, HIPAA, GDPR, SOC 2, ISO 27001, NIST 800-53, and more) that Security Hub has no native standard for at all. Prowler also runs anywhere: from a laptop, a CI job, an air-gapped environment, or an account where Security Hub was never enabled in the first place, and identically across AWS, Azure, GCP, and Kubernetes — Security Hub, by contrast, is an AWS-only service that has to be explicitly enabled (and paid for, per finding ingested and evaluated) before it does anything.

The honest framing: Security Hub is the natural single pane of glass for continuous, native, cross-service AWS monitoring once your other AWS security services are already running — GuardDuty's threat detection, Inspector's vulnerability findings, Macie's data-classification findings all land there automatically, and Prowler's ASFF push means its own findings can join them in that same queue rather than living in a separate report nobody checks. Prowler is the deeper, portable, scheduled or on-demand audit layer — the tool you'd point at a brand-new account on day one before Security Hub is even configured, run from a pipeline gate that has to work identically across three cloud providers, or reach for when an auditor asks specifically for CIS or PCI-DSS coverage that Security Hub's own standards don't provide. Most mature AWS environments run both: Security Hub as the always-on aggregation point, Prowler as a deeper, portable, and multi-cloud audit that feeds into it rather than sitting beside it unread.

Gotchas and failure modes

☺ Like you're 10: Most surprises come from the inspector not being let into every room, being let into too many rooms without a good enough safety chain on the door, or a report that looks scary until you realize what "not enabled" actually means.

• Read-only doesn't mean low-value if leaked. A credential carrying SecurityAudit plus ViewOnlyAccess can enumerate nearly everything in an account — every IAM policy document, every resource name, every security group rule. That's an attacker's reconnaissance phase handed to them for free if the credential leaks. Assume the role for the duration of a scan rather than issuing a standing access key with that policy pair attached, and see workload identity & pipeline IAM for how a CI job should hold a credential like this one at all.
• Region scope is opt-in in practice, even when the flag looks like it defaults to everything. Global services (IAM, Route 53, CloudFront) evaluate once regardless of region, but region-scoped resources only get checked in regions Prowler actually reaches — an account with resources sitting in an opt-in region (several AWS regions require explicit account-level enablement before they're even queryable) can look clean simply because nothing was ever asked about that region. Confirm which regions are enabled on the account before trusting a "clean" result as complete.
• Large accounts hit API throttling, and a rate-limited call can read as a false negative. Multi-threading is what keeps a full-account scan fast, but it's also what triggers provider-side rate limiting on accounts with a large resource count. A throttled API call that Prowler can't retry past can surface as a check silently not running rather than a loud failure — tune thread count down on very large accounts and check the run's own error output, not just its pass/fail summary.
• A FAIL can mean "not configured the way the check expects," not "misconfigured." A check tied to GuardDuty, Config, or another optional AWS service returns FAIL in an account where that service was never turned on at all — which is a real gap worth fixing, but a different kind of gap than a resource that was configured and configured wrong. Reading every FAIL as "someone made a mistake" instead of "this control isn't in place yet" leads to the wrong remediation conversation.
• Exit codes trip up a pipeline that assumed a scanner exits 0 by default. A CI job wired to fail the build on Prowler's own exit behavior needs that behavior read deliberately — confirm the current default and the flag that changes it against prowler aws --help for your installed version before wiring it as a merge-blocking gate, the same due diligence vulnerability management & triage asks for with every other scanner feeding a pipeline.
• Mutelist debt is suppression debt. Exactly like Checkov's suppression comments, a mutelist that only grows and is never reviewed stops meaning "accepted risk" and starts meaning "forgotten." Review it on the same cadence compliance & governance already expects for any other tracked exception.

Alternatives and when to reach for something else

☺ Like you're 10: Other tools ask the cloud provider similar questions — they just hand you the answers in a different shape, or bundle in a lot more than just "is this configured safely."

A pipeline already gating on Prowler rarely needs a second open-source CSPM tool running the same job — the built-in check library and compliance mapping cover more ground than most teams write custom rules for in their first year. Findings from a Prowler run, like findings from every other scanner this course covers, are usually worth deduplicating into one queue rather than living in their own separate report; DefectDojo ingests Prowler's output alongside everything else in the pipeline for exactly that reason. See the tooling landscape for where CSPM sits among the other seven scanner categories, and cloud security posture for the shared-responsibility and least-privilege context a CSPM finding usually sits inside.