Skip to main content
Several Prowler’s checks have user configurable variables that can be modified in a common configuration file. This file can be found in the following path:
Additionally, you can input a custom configuration file using the --config-file argument.
Numeric thresholds enforce hard limits. A value outside the accepted range is dropped with a warning and the check falls back to its built-in default. See Configuration Value Limits for the exact range of every bounded option (max-days caps, percentages, counts, etc.).

AWS

Configurable Checks

The following list includes all the AWS checks with configurable variables that can be changed in the configuration yaml file:

Resource Scan Limit

Some AWS services accumulate large numbers of resources (EBS snapshots, backup recovery points, CloudWatch log groups, Lambda functions, ECS task definitions, and CodeArtifact packages). Scanning every resource increases scan time, cost, API throttling, and finding volume. By default, Prowler scans every resource. Configure a positive resource scan limit to cap how many resources Prowler analyzes for these high-volume AWS resource paths. The global default applies to the supported resources below and is overridable per resource. The default global value is 0, which disables the limit and scans every resource. A global null value is also unlimited. For per-resource values, null means inherit the global default; set 0 or a negative value to disable that resource limit explicitly. Positive values enable limits.
When positive resource scan limits are configured, compliance results are based only on the selected resources, not on the full set of matching resources in the account. Treat compliance summaries and percentages as partial evidence, because unselected resources are not analyzed and can change the real compliance posture.

Global Behavior

Resource scan limits select resources for analysis. They do not cap, prioritize, or reorder findings.
  • 0, negative, or global null values: Disable the limit and keep the legacy behavior for that resource path. Prowler analyzes every discovered matching resource.
  • Positive values: Select at most that many resources for the affected resource path. A selected resource can produce zero, one, or many findings.
  • No PASS/FAIL prioritization: Prowler does not inspect the compliance result before selecting resources. Limits do not prefer failed resources, passed resources, or resources with more findings.
  • Latest-first where possible: When AWS exposes timestamps or useful ordering, Prowler selects the newest resources first. When AWS only exposes API order, Prowler preserves that API order and documents the behavior as best effort.
  • Findings are downstream: Checks only evaluate the resources exposed by the service client after selection. Findings from unselected resources are not produced because those resources are not analyzed.
Exact list API call reduction depends on each AWS API’s ordering and pagination capabilities. When Prowler must enumerate candidates locally to select the latest resources, list calls may still read candidates, but expensive per-resource enrichment calls are bounded to the selected resources for the supported paths below.

Full Collections Versus Limited Analysis Sets

Some checks need lightweight evidence from a complete resource collection to avoid incorrect cross-service conclusions, while other checks perform primary analysis on a limited resource set. Prowler keeps full lightweight collections where they are needed for cross-service evidence. For example:
  • Lambda security groups and regions: Prowler records security groups used by all discovered Lambda functions and the regions where functions exist before it limits Lambda functions for primary Lambda checks. This helps Amazon EC2 and Amazon Inspector checks avoid false positives such as treating Lambda security groups as unused or assuming a region has no Lambda functions.
  • CloudWatch all_log_groups: Prowler records all discovered CloudWatch log groups in all_log_groups before limiting the primary log_groups analysis set. Other services can still resolve log group evidence, while CloudWatch log group checks only analyze the selected log groups.
This split is intentional. It reduces expensive per-resource analysis calls without discarding lightweight context that other services need for accurate results.

Supported AWS Resource Limits

Resource Limit Behavior By Resource Path

Use limits when scan duration, API throttling, or cost are more important than exhaustive coverage for these high-volume resources. Keep limits disabled when you need complete evidence for every resource in the affected checks.

Validating Discovered Secrets

By default, the secret-scanning checks run fully offline: secrets are detected but never sent anywhere. Setting secrets_validate to True additionally confirms whether each discovered secret is live by authenticating with it against the corresponding provider API. The discovered secret itself serves as the credential, so Prowler requires no additional permissions to validate it. secrets_validate applies to every AWS secret-scanning check listed above (those that accept secrets_ignore_patterns). The --scan-secrets-validate CLI flag is provider-wide: it also enables validation for the secret-scanning checks of other providers, such as the OpenStack metadata checks. To enable validation through the configuration file, set the value under the aws section:
To enable validation for a single scan (any provider), use Prowler CLI:
Secret validation makes outbound network calls that authenticate with each discovered secret. The credential is exercised against the provider, so the call appears in the audited account’s logs and can trigger its monitoring (for example, AWS CloudTrail records the validation request). Validation stays disabled by default so that scans remain fully offline.

Azure

Configurable Checks

The following list includes all the Azure checks with configurable variables that can be changed in the configuration yaml file:

GCP

Configurable Checks

The following list includes all the GCP checks with configurable variables that can be changed in the configuration yaml file:

Kubernetes

Configurable Checks

The following list includes all the Kubernetes checks with configurable variables that can be changed in the configuration yaml file:

M365

Configurable Checks

The following list includes all the Microsoft 365 checks with configurable variables that can be changed in the configuration yaml file:

GitHub

Configurable Checks

The following list includes all the GitHub checks with configurable variables that can be changed in the configuration yaml file:

Vercel

Configurable Checks

The following list includes all the Vercel checks with configurable variables that can be changed in the configuration YAML file:

Okta

Configurable Checks

The following list includes all the Okta checks with configurable variables that can be changed in the configuration YAML file:

Alibaba Cloud

Configurable Checks

The following list includes all the Alibaba Cloud checks with configurable variables that can be changed in the configuration YAML file:

MongoDB Atlas

Configurable Checks

The following list includes all the MongoDB Atlas checks with configurable variables that can be changed in the configuration YAML file:

OpenStack

Configurable Checks

The following list includes all the OpenStack checks with configurable variables that can be changed in the configuration YAML file:

Config YAML File Structure

This is the new Prowler configuration file format. The old one without provider keys is still compatible just for the AWS provider.
config.yaml