Documentation

The Prowler Registry works like PyPI but is purpose-built for Prowler security artifacts. It implements the PEP 503 Simple Repository API, which means you can use standard Python tools like pip to install packages.

The registry hosts artifacts — Python wheel packages that contain one or more checks. Each check is a security rule that Prowler can execute against a cloud provider (AWS, Azure, GCP, M365, Kubernetes, and more).

The typical workflow is:

1. Browse — find checks relevant to your cloud environment using the Checks page, filtered by provider, service, severity, or organization.
2. Install — use pip install with the registry as an extra index URL to install the artifact packages.
3. Run — execute checks with the Prowler CLI. Installed artifacts are automatically discovered.

The Checks page is the main entry point for discovering security checks. Every individual check from every published artifact is listed as its own card.

Search

The search bar searches by check_id — the unique identifier for each check (e.g. s3_bucket_public_access). The header search bar also searches checks globally.

Filters

The left sidebar provides multi-select filters. You can combine multiple values within each filter (OR logic) and combine filters across categories (AND logic):

• Organization — filter by the publisher
• Provider — filter by cloud provider (AWS, Azure, GCP, etc.)
• Severity — filter by criticality level (Critical, High, Medium, Low, Informational)
• Service — filter by cloud service (S3, EC2, IAM, etc.)

The top filter bar provides mutually exclusive type filters and an independent Verified toggle.

Check Detail

Click on a check to view its full detail page. The detail page shows:

• Full description and risk assessment
• Severity, service, categories, and resource type
• CLI install and run commands with copy buttons
• Recommendation text with links
• Remediation instructions — CLI, Terraform, and step-by-step guides
• Reference URLs to vendor documentation

Interactive Filters

On each check card, the provider logo, service badge, and severity badge are clickable — clicking them toggles the corresponding filter.

Providers represent cloud platforms and technologies that checks can target. Examples include AWS, Azure, GCP, Kubernetes, M365, Docker Desktop, and more. Browse all providers at /providers.

Each provider card shows the number of checks and packages available for that platform. Click on a provider to see all checks filtered by that provider.

Artifacts are standard Python wheel packages. Install them using pip with the registry as an extra index URL:

pip install --extra-index-url https://registry.prowler.com/simple/ "<package-name>[runtime]"

To avoid typing the URL every time, configure it permanently in your pip.conf (Linux/macOS: ~/.config/pip/pip.conf, Windows: %APPDATA%\\pip\\pip.ini):

[global]
extra-index-url = https://registry.prowler.com/simple/

Then simply:

pip install "<package-name>[runtime]"

Private Artifacts

Public artifacts are available without authentication. Private artifacts require an API key with download scope:

pip install --extra-index-url https://__token__:YOUR_API_KEY@registry.prowler.com/simple/ "<package-name>[runtime]"

Version Pinning

You can pin to specific versions like any pip package:

pip install "<package-name>[runtime]==1.2.0"
pip install "<package-name>[runtime]>=1.0,<2.0"

Once artifacts are installed, Prowler automatically discovers them via Python entry points. Run specific checks by their check_id:

# Run a single check
prowler aws --checks s3_bucket_public_access

# Run multiple checks
prowler aws --checks s3_bucket_public_access,ec2_instance_public_ip

# Run all checks for a service
prowler aws --services s3

To publish artifacts you need an API key with upload scope. Upload Python wheel files (.whl) using twine or uv:

# Using twine
twine upload --repository-url https://registry.prowler.com/simple/ \
  -u __token__ -p YOUR_API_KEY dist/*

# Using uv
uv publish --publish-url https://registry.prowler.com/simple/ \
  --token YOUR_API_KEY

Processing Pipeline

After upload, packages are processed asynchronously:

1. File is stored in S3 and the version is created with pending status
2. A background worker extracts PEP 658 metadata from the wheel
3. The worker validates the artifact scaffolding and metadata inside the wheel
4. If valid, the version moves to processed and checks become visible
5. If invalid, the version moves to invalid with a rejection_reason

New Providers

If your package references a provider that does not exist in the registry, the provider is automatically created with pending status. The package will be rejected until the registry owner reviews and accepts the new provider. Once accepted, re-upload the package and it will be processed normally.

Re-uploading

If a version is rejected, you can fix the issue and re-upload the same version. The old rejected version is replaced. If a version is already processed, re-uploading the same version returns a 409 Conflict.

The registry uses API keys for authentication. All authenticated requests use HTTP Basic Auth with __token__ as the username and the API key as the password.

# Using curl
curl -u __token__:prr_YOUR_KEY https://registry.prowler.com/api/v1/whoami/

# Using pip (for private packages)
pip install --extra-index-url https://__token__:prr_YOUR_KEY@registry.prowler.com/simple/ "<package-name>[runtime]"

# Using twine (for uploads)
twine upload --repository-url https://registry.prowler.com/simple/ \
  -u __token__ -p prr_YOUR_KEY dist/*

Key Types

When creating an API key, you choose between Upload or Download type.

Package Types

Every package in the registry has a type based on the organization that published it:

• Official — published by the registry owner

Additionally, package versions can be marked as Verified, indicating they have passed additional quality checks. This creates sub-types like “Official Verified” that download keys can target specifically.

Upload Keys

Upload keys allow publishing artifacts to the registry. You select the visibility of the packages you want to publish:

• upload:public — publish public artifacts visible to everyone
• upload:private — publish private artifacts restricted to authorized users

Download Keys

Download keys grant access to private artifacts. You select which package types the key can download:

• download:official — download private official artifacts
• download:official-verified — download only verified official artifacts
• download:all — download all private artifacts regardless of type

Key Management

Manage your API keys at Settings > API Keys. You can create keys with specific scopes, set expiration dates, and revoke them. All API keys start with the prefix prr_.

Organizations are the publishers on the registry. Every package belongs to an organization, and each organization has a type that determines its trust level and capabilities.

Organization Types

• Official — the registry owner. Official checks carry the highest trust level and are shown with a primary-colored badge.

Verified Packages

Package versions can be marked as Verified, indicating they have passed additional quality checks. The organization card shows the ratio of verified packages to total packages.

Browse all organizations at /orgs. Each org profile shows its packages, total checks, download statistics, and all published artifacts.

Customers are enterprise users who create accounts to download private artifacts from the registry. The customers feature enables self-service sign-up and download key management.

Customer Sign Up

1. Register — go to /register/customer and create an account with name, email, password, and optional company name.
2. Login — sign in at /login with email and password.
3. Create download keys — from the customer dashboard, create API keys selecting which package types to access (Official, and their Verified variants).
4. Install private artifacts — use the download key with pip:

   pip install --extra-index-url https://__token__:YOUR_KEY@registry.prowler.com/simple/ "<package-name>[runtime]"

Customer Dashboard

At /customer, customers can:

• Create new download API keys with specific scope selections
• View all existing keys with their scopes and last usage
• Revoke keys that are no longer needed

Administration

The registry owner manages customers from Settings > Customers. From there the owner can view all registered customers, activate or deactivate accounts, and revoke individual keys.

Bundles are curated collections of private packages grouped together for convenient distribution. They allow organizations to offer sets of checks as a single logical unit — for example, a “CIS AWS Benchmark” bundle containing all the checks needed for that compliance framework.

Bundle Lifecycle

1. Draft — the organization creates a bundle from Settings > Bundles, selecting which private packages to include. Draft bundles are not publicly visible.
2. Deployed — the organization deploys the bundle, making it visible on the public /bundles page. Customers can browse and request access.
3. Archived — the organization can archive a bundle to remove it from active listings while preserving its history.

Browsing Bundles

The /bundles page lists all deployed bundles. Each bundle card shows the publishing organization, number of included packages, and a description. Click on a bundle to see its full detail including the list of included packages.

Requesting Access

Customers can request access to a bundle from its detail page. The request goes to the bundle's organization for approval. Once approved, the customer's download keys gain access to all packages in the bundle.

Access request status is shown on the bundle card: Pending, Approved, or Denied.

Managing Bundles

Owner and partner organizations manage bundles from Settings > Bundles:

• Create — give the bundle a name, description, and select which private packages to include
• Deploy — publish the bundle so it appears on the public /bundles page
• Archive — remove a deployed bundle from active listings

Approving Access Requests

When a customer requests access to a deployed bundle, the request appears in the bundle's detail page under Settings > Bundles. The organization can:

• Approve — the customer's download keys gain access to all packages in the bundle
• Deny — the request is rejected and the customer is notified

Pending requests are highlighted with a badge count in the navigation bar for quick visibility.

The registry exposes a JSON:API-compliant REST API. All endpoints accept and return application/vnd.api+json content type.

Public Endpoints

Authenticated Endpoints

Full interactive API documentation with request/response examples is available at API Docs.

The registry implements the PEP 503 Simple Repository API for full compatibility with pip and twine:

Downloads of public packages use presigned S3 URLs (302 redirect) for efficient direct-from-storage delivery. Private package downloads require HTTP Basic Auth with an API key.

Package names follow PEP 503 normalization — names are lowercased with hyphens, dots, and underscores normalized to hyphens.

All list endpoints follow the JSON:API filtering convention. Filters use the filter[field] query parameter syntax, pagination uses page[number] and page[size], and sorting uses the sort parameter with - prefix for descending order.

Common Parameters

Available Filters by Endpoint

Response Metadata

List responses include a meta object with pagination info and, for some endpoints, aggregated filter counts (e.g. available_providers, available_severities) that can be used to build dynamic filter UIs.

Example

# Filter checks by provider and severity
curl "https://registry.prowler.com:8000/api/v1/checks/?filter[provider]=aws&filter[severity]=critical&sort=check_id&page[size]=10" \
  -H "Accept: application/vnd.api+json"