Merge master
No files matched your search
@@ -78,11 +78,25 @@ b. National security is of the utmost concern nowadays.
|
||||
|
||||
Prowler Features are considered proper nouns. They are to be referenced without articles in all pieces of writing.
|
||||
|
||||
This is a list of Prowler Features:
|
||||
Prowler ships two product families. Use these names exactly; the former names Prowler App (now Prowler Local Server) and Prowler Enterprise (now Prowler Private Cloud) must not appear in new writing. The only allowed former-name notes are on the Prowler Product Families page (`getting-started/products/index.mdx`) and in the site-wide banner, which document the mapping.
|
||||
|
||||
Prowler Products:
|
||||
|
||||
* **Prowler Cloud**
|
||||
* **Prowler Private Cloud** (formerly Prowler Enterprise)
|
||||
* **Prowler Hub**
|
||||
* **Prowler Lighthouse AI**
|
||||
* **Prowler MCP**
|
||||
|
||||
Open Source projects:
|
||||
|
||||
* **Prowler App**
|
||||
* **Prowler CLI**
|
||||
* **Prowler Local Server** (formerly Prowler App)
|
||||
* **Prowler Local Dashboard** (the Prowler CLI dashboard)
|
||||
* **Prowler SDK**
|
||||
|
||||
Other Prowler Features:
|
||||
|
||||
* **Built-in Compliance Checks**
|
||||
* **Multi-cloud Security Scanning**
|
||||
* **Autonomous Cloud Security Analyst (AI)**
|
||||
@@ -97,8 +111,6 @@ This is a list of Prowler Features:
|
||||
* **AI-Generated Detections & Remediations**
|
||||
* **Prowler Studio**
|
||||
* **Custom Security Policies**
|
||||
* **Prowler Cloud**
|
||||
* **Prowler Registry**
|
||||
* **Open Source & Full APIs**
|
||||
|
||||
---
|
||||
@@ -137,10 +149,10 @@ Explicit use of second-person pronouns (you) and possessives (your) should be mi
|
||||
### Example of Improvement Through Avoiding Second Person Pronouns
|
||||
|
||||
**Original:**
|
||||
Prowler App can be installed in different ways, depending on your environment:
|
||||
Prowler Local Server can be installed in different ways, depending on your environment:
|
||||
|
||||
**Improved Version:**
|
||||
Prowler App offers flexible installation methods tailored to various environments:
|
||||
Prowler Local Server offers flexible installation methods tailored to various environments:
|
||||
|
||||
---
|
||||
|
||||
@@ -262,7 +274,7 @@ There are several options for punctuating bullet points. Regardless of the style
|
||||
|
||||
* **No punctuation (minimalistic):** This strategy is suitable when no verbs are involved and is best used to highlight products or features in isolation. For example:
|
||||
|
||||
Prowler App is composed of three key components:
|
||||
Prowler Local Server is composed of three key components:
|
||||
* Prowler UI
|
||||
* Prowler API
|
||||
* Prowler SDK
|
||||
@@ -271,7 +283,7 @@ There are several options for punctuating bullet points. Regardless of the style
|
||||
|
||||
* **Periods for full sentences:** This approach works best when each bullet point forms a full sentence or includes verbs. For example:
|
||||
|
||||
Prowler App is composed of three key components:
|
||||
Prowler Local Server is composed of three key components:
|
||||
* Prowler UI, a web-based interface, built with Next.js, providing a user-friendly experience for executing Prowler scans and visualizing results.
|
||||
* Prowler API, a backend service, developed with Django REST Framework, responsible for running Prowler scans and storing the generated results.
|
||||
* Prowler SDK, a Python SDK designed to extend the functionality of the Prowler CLI for advanced capabilities.
|
||||
@@ -539,6 +551,43 @@ Tag-Based Scanning allows filtering resources by AWS tags during security assess
|
||||
|
||||
---
|
||||
|
||||
## AppliesTo Banner for Product Scope
|
||||
|
||||
The AppliesTo component states which products a guide covers and links to the product families page. It is located at `docs/snippets/applies-to.mdx`.
|
||||
|
||||
### When to Use the AppliesTo Banner
|
||||
|
||||
Use it on web UI tutorial pages that apply to more than one product (for example, a guide written for Prowler Cloud whose steps also work on Prowler Local Server). Do not combine it with the SubscriptionBanner: pages carrying the SubscriptionBanner already state their availability.
|
||||
|
||||
### How to Use the AppliesTo Banner
|
||||
|
||||
```mdx
|
||||
import { AppliesTo } from "/snippets/applies-to.mdx"
|
||||
|
||||
<AppliesTo />
|
||||
```
|
||||
|
||||
The default covers Prowler Cloud, Prowler Private Cloud, and Prowler Local Server. Pass the `products` prop to narrow the scope:
|
||||
|
||||
```mdx
|
||||
<AppliesTo products={["Prowler Cloud", "Prowler Private Cloud"]} />
|
||||
```
|
||||
|
||||
Place it on its own line below the Version Badge when one is present, otherwise directly after the imports.
|
||||
|
||||
### Cloud Marker for Subscription Content
|
||||
|
||||
The custom green cloud glyph (`docs/images/icons/cloud-bold.svg`) marks content that requires a Prowler Cloud or Prowler Private Cloud subscription. It renders as a trailing `::after` element through the "Cloud marker" rules in `docs/style.css`, so sidebar labels stay left-aligned.
|
||||
|
||||
* Pages: add a `li[id="<page path>"] a span::after` selector to the Cloud marker rule in `docs/style.css` for every page whose content is subscription-gated. The `li` id equals the page URL path. Pages where only one section is gated (for example the Support page, where only the Support Desk carries the SubscriptionBanner) get no marker.
|
||||
* Navigation groups: add a selector only when every page in the group is subscription-gated. One sanctioned exception: the Prowler MCP group is marked because the hosted server at `mcp.prowler.com` includes tools for Prowler Cloud-specific features, and its overview page explains the free local alternative. Nested groups render as `li[data-title="<group name>"]` with a button toggle, so use `li[data-title="<group name>"] > button span:first-child::after`. Top-level groups render as `h3` headings without `data-title`, which means name collisions with top-level groups resolve themselves; a gated top-level group (always expanded) is selected through its sibling list with `:has()`, like the Security tab group. Do not use `:has()` on child links of nested groups: collapsed groups do not render their children.
|
||||
|
||||
Do not use the `icon` field for this marker (icons render before the label and misalign the sidebar), and do not use `"tag"` on navigation groups (group-level tags crash `mint broken-links` with a stack overflow, verified with mint 4.2.689). The SVG stroke uses the fixed brand green `#10B981` on purpose: it must be visible on both themes without `currentColor` support.
|
||||
|
||||
The marker meaning is explained on the Prowler Product Families page at `getting-started/products/index.mdx`: keep that note in place.
|
||||
|
||||
---
|
||||
|
||||
## Avoid Assumptions Regarding Audience’s Expertise
|
||||
|
||||
### Understand Your Audience’s Expertise
|
||||
|
||||
@@ -5,7 +5,7 @@ This repository contains the Prowler Open Source documentation powered by [Mintl
|
||||
## Documentation Structure
|
||||
|
||||
- **Getting Started**: Overview, installation, and basic usage guides
|
||||
- **User Guide**: Comprehensive guides for Prowler App, CLI, providers, and compliance
|
||||
- **User Guide**: Comprehensive guides for Prowler Cloud, Prowler Local Server, Prowler CLI, providers, and compliance
|
||||
- **Developer Guide**: Technical documentation for developers contributing to Prowler
|
||||
|
||||
## Local Development
|
||||
@@ -13,7 +13,7 @@ This repository contains the Prowler Open Source documentation powered by [Mintl
|
||||
Install a reviewed version of the [Mintlify CLI](https://www.npmjs.com/package/mint) to preview documentation changes locally:
|
||||
|
||||
```bash
|
||||
npm install --global mint@4.2.560
|
||||
npm install --global mint@4.2.689
|
||||
```
|
||||
|
||||
Run the following command at the root of your documentation (where `mint.json` is located):
|
||||
|
||||
@@ -0,0 +1,878 @@
|
||||
---
|
||||
title: "Changelog"
|
||||
description: "New features and improvements in each Prowler release"
|
||||
rss: true
|
||||
---
|
||||
|
||||
<Update label="v5.38.0" description="August 6, 2026">
|
||||
### 📌 Compliance Watchlist
|
||||
|
||||
<Note>
|
||||
This feature is available exclusively in **Prowler Cloud** and **Prowler Private Cloud** with a [subscription](https://prowler.com/pricing).
|
||||
</Note>
|
||||
|
||||
Compliance Watchlist keeps the frameworks an organization tracks in one shared list. Pin frameworks from any compliance view, manage several at once through a searchable catalog, and filter the Compliance section to show only the pinned frameworks.
|
||||
|
||||
The Overview page now reports the latest score for every pinned framework, while finding details highlight the watched frameworks associated with each check. Universal frameworks remain a single watchlist entry across provider views, keeping the organization's priorities consistent everywhere.
|
||||
|
||||

|
||||
|
||||
Read more in the [Compliance Watchlist documentation](https://docs.prowler.com/user-guide/compliance/tutorials/compliance#tracking-frameworks-with-the-compliance-watchlist).
|
||||
|
||||
### 🔐 SAML SSO - Multiple Email Domains
|
||||
|
||||
<Note>
|
||||
This feature is available exclusively in **Prowler Cloud** and **Prowler Private Cloud** with a [subscription](https://prowler.com/pricing).
|
||||
</Note>
|
||||
|
||||
One SAML configuration can now authorize a primary email domain and up to 19 additional domains through the same Identity Provider. Every domain shares one stable Assertion Consumer Service (ACS) URL based on the primary domain, so subsidiaries, acquired companies, regional domains, and multiple brands no longer require separate tenants or duplicated SAML applications.
|
||||
|
||||
Domain ownership remains tenant-bound throughout the authentication flow. During service provider-initiated sign-in, the discovery domain and the domain asserted by the Identity Provider must resolve to the same tenant before provisioning continues.
|
||||
|
||||

|
||||
|
||||
Read more in the [SAML SSO documentation](https://docs.prowler.com/user-guide/tutorials/prowler-app-sso#add-multiple-saml-domains).
|
||||
|
||||
### 👥 User Sign-In Methods
|
||||
|
||||
<Note>
|
||||
This feature is available exclusively in **Prowler Cloud** and **Prowler Private Cloud** with a [subscription](https://prowler.com/pricing).
|
||||
</Note>
|
||||
|
||||
The Users table now shows each account's sign-in methods as tags, including email/password, Google, GitHub, SAML with linked domains, and Partner SSO. Accounts without a reported method display a placeholder.
|
||||
|
||||

|
||||
|
||||
### 🕸️ Attack Paths - Expanded AWS Privilege-Escalation Coverage
|
||||
|
||||
Attack Paths adds 20 AWS privilege-escalation queries from [pathfinding.cloud](https://pathfinding.cloud), while `iam_policy_allows_privilege_escalation` gains 22 additional escalation combinations.
|
||||
|
||||
The new coverage includes service `iam:PassRole` paths across AWS Batch, Braket, Cognito Identity, ECS, EMR, EMR Serverless, GameLift, Glue, EC2 Image Builder, Kinesis Analytics, HealthOmics, EventBridge Scheduler, Systems Manager, and Step Functions. It also covers existing-resource abuse, permissions-boundary removal, role assumption, and IAM Identity Center permission-set policy injection.
|
||||
|
||||
The query catalog now exposes each AWS query's outcome category, distinguishing code execution, privilege escalation, public exposure, and resource inventory.
|
||||
|
||||
Explore the full Attack Paths query catalog at [Prowler Hub](https://hub.prowler.com/attack-paths).
|
||||
|
||||
Read more in the [Attack Paths documentation](https://docs.prowler.com/user-guide/tutorials/prowler-app-attack-paths).
|
||||
|
||||
### 🔍 Checks
|
||||
|
||||
#### Microsoft 365
|
||||
|
||||
Twelve new checks expand the coverage of CIS Microsoft 365 Foundations Benchmark v7.0.0:
|
||||
|
||||
- **Admin Center:** Shared Bookings is disabled.
|
||||
- **Defender:** Priority account protection and strict preset security policies are enabled.
|
||||
- **Entra ID:** Six checks cover device registration restrictions, local administrator behavior, device limits, LAPS, and BitLocker key visibility.
|
||||
- **Exchange Online:** Personal accounts in Outlook on the web are disabled and Direct Send is rejected.
|
||||
- **Microsoft Teams:** External access from trial-only tenants is blocked.
|
||||
|
||||
Explore all Microsoft 365 checks at [Prowler Hub](https://hub.prowler.com/check?provider=m365).
|
||||
|
||||
### 🔐 Security
|
||||
|
||||
- Prowler API, UI, SDK, and MCP container images now publish per-architecture Software Bills of Materials (SBOMs) and build-provenance attestations. Prowler Cloud production and Prowler Private Cloud images carry the same attestations.
|
||||
- SDK and API container builds verify the checksums of downloaded PowerShell, Trivy, and zizmor binaries before installation.
|
||||
- Grype now complements Trivy across the container-image security gates, detecting components and vulnerabilities that manifest-based scanners can miss and blocking fixable high and critical findings.
|
||||
- `aiohttp` was upgraded to 3.14.3 to address CVE-2026-69244. `cryptography` was upgraded to 50.0.0 to address CVE-2026-69247 and CVE-2026-69249.
|
||||
|
||||
See the [full release notes on GitHub](https://github.com/prowler-cloud/prowler/releases/tag/5.38.0) for the complete list of changes.
|
||||
</Update>
|
||||
|
||||
<Update label="v5.37.0" description="August 3, 2026">
|
||||
### 💬 Lighthouse AI — Context-Aware Chat and a Bigger Toolbox
|
||||
|
||||
<Note>
|
||||
This feature is available exclusively in **Prowler Cloud** and **Prowler Private Cloud** with a [subscription](https://prowler.com/pricing).
|
||||
</Note>
|
||||
|
||||
Lighthouse AI is now aware of your working context when in Prowler Cloud. Messages carry page-aware context — the page you are on, the finding or resource open in the side panel, and its metadata — so "explain this" just works, and each page offers concise contextual suggestions to start from.
|
||||
|
||||

|
||||
|
||||
Lighthouse also gained access to every tool family the Prowler MCP server advertises: scan configurations, scan scheduling, finding triage, alert rules and recipients, integrations, users, and roles. Every action remains gated by RBAC: Lighthouse AI can only do what the user asking could do themselves.
|
||||
|
||||
Read more in the [Lighthouse AI documentation](/getting-started/products/prowler-cloud-lighthouse).
|
||||
|
||||
### 🔌 Prowler MCP — Integrations, Users, and Roles
|
||||
|
||||
Prowler MCP gained three tool families, available on both the Cloud and the self-hosted Local MCP Server:
|
||||
|
||||
- **[Integrations](/getting-started/basic-usage/prowler-mcp-tools#integrations-management)** — manage where Prowler sends its results, with the full lifecycle for Amazon S3, AWS Security Hub, and Jira: create them, update credentials, configuration and attached providers, re-check connections, and delete them — plus turning findings into Jira work items directly from a conversation.
|
||||
- **[Users](/getting-started/basic-usage/prowler-mcp-tools#user-management)** — read-only tools to list the tenant users with their emails and identify the authenticated user.
|
||||
- **[Roles](/getting-started/basic-usage/prowler-mcp-tools#role-management)** — browse the RBAC roles defined in the tenant, inspect the capabilities each one grants, and set the role a user holds.
|
||||
|
||||
### ☁️ Prowler MCP — Cloud-Only Tools
|
||||
|
||||
<Note>
|
||||
This feature is available exclusively in **Prowler Cloud** and **Prowler Private Cloud** with a [subscription](https://prowler.com/pricing). These tools are exposed only by the Cloud MCP Server at `https://mcp.prowler.com/mcp`; the self-hosted Local MCP Server **does not** include them.
|
||||
</Note>
|
||||
|
||||
A new `prowler_cloud_*` namespace adds 32 tools so your AI assistant can run Prowler Cloud workflows end to end instead of only reading from them:
|
||||
|
||||
- **[Alerts](/getting-started/basic-usage/prowler-mcp-tools#alerts)** — create and manage alert rules and email recipients, and browse the fired-alert history. Rule conditions can be dry-run before saving, so you can see what a rule would match without persisting anything.
|
||||
- **[Findings Triage](/getting-started/basic-usage/prowler-mcp-tools#findings-triage)** — set a finding's triage status and attach notes documenting the decision. Unlike muting, the finding stays visible.
|
||||
- **[Scan Scheduling](/getting-started/basic-usage/prowler-mcp-tools#scan-scheduling)** — configure daily, interval, weekly, or monthly recurring scans, one provider at a time or applied across many at once.
|
||||
- **[Scan Configurations](/getting-started/basic-usage/prowler-mcp-tools#scan-configurations)** — build reusable check and compliance selections and attach them to providers.
|
||||
|
||||
Read more in the [Prowler MCP tools reference](/getting-started/basic-usage/prowler-mcp-tools#prowler-cloud-tools).
|
||||
|
||||
### 🧭 Compliance — Grouped by provider of the same type
|
||||
|
||||
<Note>
|
||||
This feature is available exclusively in **Prowler Cloud** and **Prowler Private Cloud** with a [subscription](https://prowler.com/pricing).
|
||||
</Note>
|
||||
|
||||
One framework, every provider, a single answer. Building on the cross-provider-type roll-up, the Compliance section now groups compliance for all providers of the same type: a **single-provider framework** — CIS AWS, CIS GCP, ENS for Azure — is aggregated across the latest completed scan of every provider of that type. Each framework card rolls up into a consolidated posture with a per-provider breakdown, a findings drill-down, and a combined executive PDF report. Requirement status follows the same strict precedence (FAIL over PASS over MANUAL), so one failing provider flags the requirement for the whole estate.
|
||||
|
||||

|
||||
|
||||
The Compliance tabs were also renamed to say what they aggregate: "Per Scan" is now **Single Scan**, "Cross-Provider" is now **Multiple Scans**, and Compliance lands on Multiple Scans by default.
|
||||
|
||||

|
||||
|
||||
Read more in the [Cross-Provider Compliance documentation](/user-guide/compliance/tutorials/cross-provider-compliance).
|
||||
|
||||
### ☁️ GCP Organization Onboarding
|
||||
|
||||
<Note>
|
||||
This feature is available exclusively in **Prowler Cloud** and **Prowler Private Cloud** with a [subscription](https://prowler.com/pricing).
|
||||
</Note>
|
||||
|
||||
Onboarding an entire Google Cloud organization is now a single guided flow. Provide an organization-level credential and Prowler discovers the full hierarchy, every folder and project. Pick the folders and projects to onboard from a selection tree, set custom aliases, test the connection, and launch: each selected project is registered as a provider, with no need to add them one by one. Post-onboarding management is covered too, including credential replacement and organization-wide deletion.
|
||||
|
||||
Read more in the [GCP Organizations documentation](/user-guide/tutorials/prowler-cloud-gcp-organizations).
|
||||
|
||||
### 🕸️ Attack Paths — More Privilege Escalation Queries
|
||||
|
||||
Attack Paths adds four AWS privilege-escalation detection queries from [pathfinding.cloud](https://pathfinding.cloud). Thanks to @paramanandmallik!
|
||||
|
||||
- **[STS-002](https://hub.prowler.com/attack-paths/aws-sts-privesc-cross-account-trust)** — cross-account role trust
|
||||
- **[STS-003](https://hub.prowler.com/attack-paths/aws-sts-privesc-wildcard-trust)** — wildcard role trust
|
||||
- **[IAM-022](https://hub.prowler.com/attack-paths/aws-iam-privesc-delete-user-permissions-boundary)** — user permissions-boundary removal
|
||||
- **[SSO-001](https://hub.prowler.com/attack-paths/aws-sso-privesc-permission-set-escalation)** — IAM Identity Center permission-set escalation
|
||||
|
||||
The query info panel now links every query to its page on [Prowler Hub](https://hub.prowler.com), and the IAM privilege-escalation queries were reworked to run efficiently on accounts with many IAM roles, users, or groups, fixing runtime errors and timeouts on large graphs.
|
||||
|
||||
Read more in the [Attack Paths documentation](/user-guide/tutorials/prowler-app-attack-paths).
|
||||
|
||||
### 🛡️ AWS Confidential Computing — Nitro Enclaves Checks
|
||||
|
||||
Prowler adds the first CSPM coverage for confidential computing workloads on AWS, with **11 new checks** for [Nitro Enclaves](https://aws.amazon.com/ec2/nitro/nitro-enclaves/), developed together with [Guillermo Ruiz](https://www.linkedin.com/in/gruizesteban/) from AWS.
|
||||
|
||||
- **Workload host environment (EC2)** — five `ec2_confidential_workload_host_*` checks for the parent instance: IMDSv2 not enforced, public IP exposure, unrestricted ingress, exposed vsock proxy ports, and hosts not running.
|
||||
- **KMS attestation policy** — six `kms_key_enclave_*` checks for the key policies gating enclave secrets: attestation not enforced or bypassable, missing deployment binding, debug-mode attestations, PCR mismatches, and unknown enclave images.
|
||||
|
||||
All checks are fully passive, using AWS APIs and CloudTrail with no instance access or SSM agent required, and are mapped across 23 compliance frameworks, including NIST 800-53 Rev 5, PCI-DSS v4.0, ISO 27001:2022, SOC 2, HIPAA, and MITRE ATT&CK.
|
||||
|
||||
Read more about it this [blog post](https://prowler.com/blog/your-llm-runs-in-a-nitro-enclave-who-is-checking-the-enclave).
|
||||
|
||||
Try them out now at [cloud.prowler.com](https://cloud.prowler.com/sign-up)!
|
||||
|
||||
### 🏢 New Provider — Huawei Cloud
|
||||
|
||||
Prowler now scans [**Huawei Cloud**](https://www.huaweicloud.com/), with **25 checks** across ten services: CTS, ECS, ELB, EVS, IAM, KMS, OBS, RDS, VPC, and WAF, plus the CIS Huawei Cloud Foundations Benchmark 1.0 compliance framework. Thanks to @tomitobio for their 1st provider in Prowler!
|
||||
|
||||
To scan a Huawei Cloud account, export the IAM user's access key credentials and run Prowler CLI:
|
||||
|
||||
```bash
|
||||
export HUAWEICLOUD_ACCESS_KEY_ID="your-access-key-id"
|
||||
export HUAWEICLOUD_SECRET_ACCESS_KEY="your-secret-access-key"
|
||||
|
||||
prowler huaweicloud
|
||||
```
|
||||
|
||||
Read more in the [Huawei Cloud documentation](/user-guide/providers/huaweicloud/getting-started-huaweicloud). Explore all Huawei Cloud checks at [Prowler Hub](https://hub.prowler.com/check?provider=huaweicloud).
|
||||
|
||||
### 🔍 Checks
|
||||
|
||||
#### AWS
|
||||
|
||||
- `codecommit_repository_no_secrets`, alongside the new `codecommit` service, scans files tracked at the tip of each repository's default branch for hardcoded secrets. Thanks to @Sid-0602!
|
||||
- `glue_catalog_connection_no_secrets` detects secrets in Glue Data Catalog connection properties. Thanks to @l46983284-cpu, @Rishi943, and @UTKARSH698!
|
||||
- `ec2_instance_stopped_older_than_specific_days` detects EC2 instances stopped longer than a configurable number of days (default 30). Thanks to @Nithin078!
|
||||
- `sagemaker_endpoint_config_kms_encryption_enabled` verifies SageMaker endpoint configurations use a KMS key for storage volume encryption. Thanks to @Nithin078 and @l46983284-cpu!
|
||||
|
||||
Read more in the [AWS documentation](/user-guide/providers/aws/getting-started-aws). Explore all AWS checks at [Prowler Hub](https://hub.prowler.com/check?provider=aws).
|
||||
|
||||
### 📤 OCSF Output — MITRE ATT&CK Enrichment
|
||||
|
||||
OCSF detection finding output now populates `finding_info.analytic` with the Prowler check rule and `finding_info.attacks` with MITRE ATT&CK technique and tactic objects for findings with MITRE ATT&CK compliance metadata. Thanks to @AlexanderSanin!
|
||||
|
||||
### 🐞 Fixed
|
||||
|
||||
- AWS Security Hub integrations now persist successful recovery checks during finding delivery, keeping connection status and the last-checked time accurate.
|
||||
- Social sign-up now creates authentication, tenant, and membership records in a single transaction, fully rolling back failed provisioning to prevent incomplete accounts.
|
||||
- The SAML configuration form keeps the ACS URL field stable while generating the callback URL and exposes the copy action only after a valid URL is available.
|
||||
- SAML users without a `userType` attribute and without an existing role now receive a least-privilege `read_only` fallback role, so role-dependent operations continue to work without granting management permissions.
|
||||
|
||||
### 🔐 Security
|
||||
|
||||
- Provider deletion, connection checks, scan creation, provider secrets, provider groups, and daily schedules now respect role provider-group visibility.
|
||||
- HTML reports escape provider-originated finding fields, preventing stored cross-site scripting through malicious cloud resource tags. https://github.com/prowler-cloud/prowler/security/advisories/GHSA-c2jg-2778-ggm4
|
||||
- Authentication with an API key whose owning user was deleted now returns `401`, and user deletion revokes the user's API keys across all their tenants.
|
||||
|
||||
### 🙌 External Contributors
|
||||
|
||||
Thank you to our community contributors for this release!
|
||||
|
||||
- @tomitobio: Huawei Cloud provider with CIS 1.0 benchmark ([#11950](https://github.com/prowler-cloud/prowler/pull/11950))
|
||||
- @paramanandmallik: four AWS privilege-escalation Attack Paths queries ([#11460](https://github.com/prowler-cloud/prowler/pull/11460))
|
||||
- @Sid-0602: AWS `codecommit` service and `codecommit_repository_no_secrets` check ([#11846](https://github.com/prowler-cloud/prowler/pull/11846))
|
||||
- @l46983284-cpu, @Rishi943, and @UTKARSH698: AWS `glue_catalog_connection_no_secrets` check ([#11963](https://github.com/prowler-cloud/prowler/pull/11963))
|
||||
- @Nithin078: AWS `ec2_instance_stopped_older_than_specific_days` ([#12076](https://github.com/prowler-cloud/prowler/pull/12076)) and `sagemaker_endpoint_config_kms_encryption_enabled` ([#12118](https://github.com/prowler-cloud/prowler/pull/12118), co-authored with @l46983284-cpu) checks
|
||||
- @AlexanderSanin: MITRE ATT&CK enrichment in OCSF detection finding output ([#11492](https://github.com/prowler-cloud/prowler/pull/11492))
|
||||
- @stefanobaldo: GCP gen2 Cloud Functions IAM policy retrieval is now thread-safe ([#12107](https://github.com/prowler-cloud/prowler/pull/12107))
|
||||
- @rayair250-droid: GCP SSH and RDP firewall checks now detect exposed ports in any position within multi-port rules ([#12115](https://github.com/prowler-cloud/prowler/pull/12115))
|
||||
- @jbchief-dev: secret ignore patterns now use Kingfisher-compatible LF line indexing ([#12141](https://github.com/prowler-cloud/prowler/pull/12141))
|
||||
- @bmbferreira: Helm chart improvements — immutable chart versions on release ([#12056](https://github.com/prowler-cloud/prowler/pull/12056)) and capped Celery worker concurrency ([#12054](https://github.com/prowler-cloud/prowler/pull/12054))
|
||||
|
||||
See the [full release notes on GitHub](https://github.com/prowler-cloud/prowler/releases/tag/5.37.0) for the complete list of changes.
|
||||
</Update>
|
||||
|
||||
<Update label="v5.36.0" description="July 24, 2026">
|
||||
### 🎫 Finding Groups - Jira
|
||||
|
||||
<Note>
|
||||
This feature is available exclusively in **Prowler Cloud** and **Prowler Private Cloud** with a [subscription](https://prowler.com/pricing).
|
||||
</Note>
|
||||
|
||||
Selected Findings, Finding Groups, and mixed selections can now be sent to Jira. When you select multiple findings, choose between one grouped issue or separate issues. Generated issues keep their Prowler context with deep links and filter details, while the UI provides clear dispatch and failure feedback.
|
||||
|
||||

|
||||
|
||||
Read more in the [Jira integration documentation](/user-guide/tutorials/prowler-app-jira-integration).
|
||||
|
||||
### 🕸️ Attack Paths - Queries
|
||||
|
||||
<Note>
|
||||
This feature is available exclusively in **Prowler Cloud** and **Prowler Private Cloud** with a [subscription](https://prowler.com/pricing).
|
||||
</Note>
|
||||
|
||||
Prowler Cloud now records which built-in Attack Paths queries returned data at the end of each scan. The query selector hides confirmed-empty queries for the selected scan, so you can focus on paths that exist without opening blank graph views. Errored, unknown, and parameterized queries remain available when they still require investigation or input.
|
||||
|
||||
All Attack Paths queries are now published on [Prowler Hub](https://hub.prowler.com), where you can browse the full catalog.
|
||||
|
||||

|
||||
|
||||
Read more in the [Attack Paths documentation](/user-guide/tutorials/prowler-app-attack-paths).
|
||||
|
||||
### 🧑🏫 New Tutorials: Connect Your AI Agents to Prowler Cloud
|
||||
|
||||
<Note>
|
||||
This feature needs a Prowler Cloud API key, so it is available exclusively in **Prowler Cloud** and **Prowler Private Cloud** with a [subscription](https://prowler.com/pricing).
|
||||
</Note>
|
||||
|
||||
New tutorials walk you through connecting your own AI agents to Prowler Cloud, so they can query your security posture and act on it programmatically.
|
||||
|
||||
Read more in the [AI agents documentation](/user-guide/ai-agents/index).
|
||||
|
||||
### ☁️ Region-less Oracle Cloud Infrastructure Setup
|
||||
|
||||
Oracle Cloud Infrastructure (OCI) provider credentials no longer require a region. Existing clients can still send the legacy `region` field for compatibility, but the API ignores it before storing credentials or starting a scan. This removes an unnecessary step from OCI onboarding.
|
||||
|
||||
Read more in the [OCI documentation](/user-guide/providers/oci/getting-started-oci).
|
||||
|
||||
### 🔍 Checks
|
||||
|
||||
#### AWS
|
||||
|
||||
- `sagemaker_notebook_instance_no_secrets` scans the `OnCreate` and `OnStart` lifecycle scripts of SageMaker notebook instances for hardcoded API keys, passwords, tokens, connection strings, and other secrets. Thanks to @kiranrajsg!
|
||||
|
||||
Read more in the [AWS documentation](/user-guide/providers/aws/getting-started-aws). Explore all AWS checks at [Prowler Hub](https://hub.prowler.com/check?provider=aws).
|
||||
|
||||
### 🔐 Security
|
||||
|
||||
- Integration responses and operations now respect provider visibility, preventing hidden-provider disclosure and blocking unauthorized attachment, connection checks, Jira dispatches, edits, and deletion.
|
||||
- Next.js was updated from 16.2.9 to 16.2.11, patching four high-severity and five medium-severity vulnerabilities.
|
||||
- The unused `npm` CLI was removed from the UI container image, eliminating the bundled `node-tar` CVE-2026-59873 and reducing exposure to future bundled npm vulnerabilities.
|
||||
- Vitest and its browser packages were updated from 4.1.8 to 4.1.10, resolving the critical `@vitest/browser` file-access permission bypass. These are development dependencies and have no runtime impact.
|
||||
- Kubernetes kubeconfig validation now blocks legacy `auth-provider.config.cmd-path` command authentication, closing a command-execution bypass.
|
||||
- `next-auth` was updated from 5.0.0-beta.30 to 5.0.0-beta.32, patching two critical Auth.js advisories: existence-based authorization checks that could fail open when a provider is misconfigured, and a homoglyph `@` bypass in email address normalization. The bump also pulls in the patched `@auth/core` 0.41.3 transitively.
|
||||
|
||||
### 🙌 External Contributors
|
||||
|
||||
Thank you to our community contributors for this release!
|
||||
|
||||
- @kiranrajsg: AWS `sagemaker_notebook_instance_no_secrets` check ([#11843](https://github.com/prowler-cloud/prowler/pull/11843))
|
||||
- @owenchenxy: Alibaba Cloud SSH and RDP security group checks now handle capitalized `Policy="Accept"` values correctly ([#12049](https://github.com/prowler-cloud/prowler/pull/12049))
|
||||
- @rsaladra: S3 bucket name validation no longer raises an invalid escape sequence `SyntaxWarning` at startup ([#12041](https://github.com/prowler-cloud/prowler/pull/12041))
|
||||
- @SujayKulkarni-2211: Updated the AWS check count in the README ([#12011](https://github.com/prowler-cloud/prowler/pull/12011))
|
||||
|
||||
See the [full release notes on GitHub](https://github.com/prowler-cloud/prowler/releases/tag/5.36.0) for the complete list of changes.
|
||||
</Update>
|
||||
|
||||
<Update label="v5.35.0" description="July 17, 2026">
|
||||
### 💬 Lighthouse AI - Side Chat
|
||||
|
||||
<Note>
|
||||
This feature is available exclusively in **Prowler Cloud** and **Prowler Private Cloud** with a [subscription](https://prowler.com/pricing).
|
||||
</Note>
|
||||
|
||||
Lighthouse AI now lives in a side panel you can open from anywhere in the app. Ask about the findings you are looking at without leaving the page, and expand to the full-page chat at any time: your draft, messages, and streaming response come along. Finding and resource details share the same panel, with tabs to switch between Details and Lighthouse AI.
|
||||
|
||||

|
||||
|
||||
Read more in the [Lighthouse AI documentation](/getting-started/products/prowler-cloud-lighthouse#side-panel).
|
||||
|
||||
### 🤖 Lighthouse AI - Take Action
|
||||
|
||||
<Note>
|
||||
This feature is available exclusively in **Prowler Cloud** and **Prowler Private Cloud** with a [subscription](https://prowler.com/pricing).
|
||||
</Note>
|
||||
|
||||
Lighthouse AI is no longer read-only. Ask it to do things and it will: connect or remove providers, trigger a scan, schedule daily scans, update scan settings, and manage your mutelist and mute rules, straight from the chat. Every action is gated by RBAC: Lighthouse can only do what the user asking could do themselves.
|
||||
|
||||
Read more in the [Lighthouse AI capabilities](/getting-started/products/prowler-cloud-lighthouse#capabilities).
|
||||
|
||||
### ☁️ One-step AWS Organizations onboarding
|
||||
|
||||
<Note>
|
||||
This feature is available exclusively in **Prowler Cloud** and **Prowler Private Cloud** with a [subscription](https://prowler.com/pricing).
|
||||
</Note>
|
||||
|
||||
Onboarding an entire AWS Organization is now a single step. One CloudFormation quick-create link deploys the management account role and a service-managed StackSet that rolls the role out to every member account, replacing the manual StackSet console setup. Target the whole organization or a specific Organizational Unit or Root ID, and deploy from the management account or a delegated administrator. The S3 integration quick-create link also pre-fills the bucket owner account ID, preventing a stack validation error.
|
||||
|
||||

|
||||
|
||||
Built on the full-organization CloudFormation template contributed by @jchrisfarris — thanks!
|
||||
|
||||
Read more in the [AWS Organizations documentation](/user-guide/tutorials/prowler-cloud-aws-organizations).
|
||||
|
||||
### 🎯 Scan configurations: exclude checks and services
|
||||
|
||||
<Note>
|
||||
This feature is available exclusively in **Prowler Cloud** and **Prowler Private Cloud** with a [subscription](https://prowler.com/pricing).
|
||||
</Note>
|
||||
|
||||
Scan configurations now accept `excluded_checks` and `excluded_services` to narrow the execution scope. Skip individual checks or entire services per provider, and the scan does not run them at all: less noise, faster scans, and no findings you would mute anyway.
|
||||
|
||||
Read more in the [Scan Configuration documentation](/user-guide/tutorials/prowler-app-scan-configuration#limiting-the-scan-scope).
|
||||
|
||||
### 🧭 Redesigned sidebar navigation
|
||||
|
||||
The sidebar was redesigned around how you actually work: grouped sections for security, settings, and help, a Home/Chat switch at the top, collapsible configuration entries, clearer active states, and a responsive mobile overlay.
|
||||
|
||||

|
||||
|
||||
### 🔌 Prowler MCP tools renamed to `prowler_*`
|
||||
|
||||
Core Prowler tools in Prowler MCP moved from the `prowler_app_*` prefix to the shorter `prowler_*` namespace, and the MCP documentation was restructured around it. Legacy `prowler_app_*` names keep working in Lighthouse AI, so existing setups are not broken.
|
||||
|
||||
Read more in the [Prowler MCP tools reference](/getting-started/basic-usage/prowler-mcp-tools).
|
||||
|
||||
### 🔐 Security
|
||||
|
||||
- Jira integration credentials now only accept bare Atlassian site names (letters, numbers, and hyphens), and Jira tenant information requests validate site names and no longer follow redirects.
|
||||
- Social account linking now requires a verified matching email from both the identity provider and the existing user account, and account connection notification emails are disabled.
|
||||
- 13 advisories reported by `pnpm audit` on the UI (3 high, 9 moderate, 1 low) are resolved with patched versions of `hono`, `ws`, `vite`, `dompurify`, `js-yaml`, `@opentelemetry/core`, and `@babel/core`, including `hono` CVE-2026-59896.
|
||||
|
||||
### 🙌 External Contributors
|
||||
|
||||
No external contributors in this release.
|
||||
|
||||
Special mention to @jchrisfarris, whose full-organization CloudFormation template from v5.34.0 powers the new one-step AWS Organizations onboarding ([#10403](https://github.com/prowler-cloud/prowler/pull/10403)).
|
||||
|
||||
See the [full release notes on GitHub](https://github.com/prowler-cloud/prowler/releases/tag/5.35.0) for the complete list of changes.
|
||||
</Update>
|
||||
|
||||
<Update label="v5.34.0" description="July 15, 2026">
|
||||
### 🏷️ New product names
|
||||
|
||||
The Prowler family has grown, and the names now say what each product is. Same products, clearer names:
|
||||
|
||||
**Prowler products:**
|
||||
|
||||
- **Prowler Cloud** — the managed cloud security platform operated by the Prowler team.
|
||||
- **Prowler Private Cloud** (formerly *Prowler Enterprise*) — the self-hosted deployment of Prowler Cloud in your own environment.
|
||||
- **Prowler Hub** — the free public library of versioned checks, cloud service artifacts, and compliance frameworks.
|
||||
- **Prowler Lighthouse AI** — The Agentic Cloud Defender in Prowler Cloud and Prowler Private Cloud.
|
||||
- **Prowler MCP** — the MCP server that connects AI assistants and agents to Prowler, including the IDE plugins.
|
||||
|
||||
**Open source projects:**
|
||||
|
||||
- **Prowler CLI** — the command-line scanner for all supported providers.
|
||||
- **Prowler Local Server** (formerly *Prowler App*) — the self-hosted web application and API to run scans, visualize findings, and manage providers.
|
||||
- **Prowler Local Dashboard** — the web dashboard for visualizing Prowler CLI scan results, distributed with the CLI.
|
||||
- **Prowler SDK** — the Python library behind Prowler CLI and Prowler Local Server.
|
||||
|
||||
See the full family in the [Prowler products documentation](/getting-started/products).
|
||||
|
||||
### 🧭 Cross-Provider Compliance
|
||||
|
||||
<Note>
|
||||
This feature is available exclusively in **Prowler Cloud** and **Prowler Private Cloud** with a [subscription](https://prowler.com/pricing).
|
||||
</Note>
|
||||
|
||||
One framework, every cloud, a single answer. The new **Cross-provider** tab in Compliance takes the most recent completed scan of every compatible provider and rolls them up into a single compliance posture per framework, with a per-provider breakdown and a combined executive PDF report. Requirement status follows strict precedence (FAIL over PASS over MANUAL), so one failing provider is enough to flag a requirement across your whole estate.
|
||||
|
||||

|
||||
|
||||
Three universal frameworks support it today:
|
||||
|
||||
- **CIS Controls 8.1** — AWS, Azure, Google Cloud, Microsoft 365, Kubernetes, GitHub, Google Workspace, Okta, Oracle Cloud, Alibaba Cloud, Cloudflare, MongoDB Atlas, OpenStack, and Vercel.
|
||||
- **CSA CCM 4.0** — AWS, Azure, Google Cloud, Alibaba Cloud, and Oracle Cloud.
|
||||
- **DORA 2022/2554** — AWS, Azure, Google Cloud, Alibaba Cloud, and Cloudflare.
|
||||
|
||||
Filter by provider type, account, or provider group, drill into each framework's requirements, and export the combined PDF.
|
||||
|
||||

|
||||
|
||||
Read more in the [Cross-Provider Compliance documentation](/user-guide/compliance/tutorials/cross-provider-compliance).
|
||||
|
||||
### 🏢 New Provider — E2E Networks
|
||||
|
||||
Prowler now scans [**E2E Networks**](https://www.e2enetworks.com/), with **27 checks** spanning compute nodes, networking, security groups, load balancers, block and file storage, and managed databases. Thanks to @deepak7093 for their 1st provider in Prowler!
|
||||
|
||||
Available in the Prowler CLI:
|
||||
|
||||
```bash
|
||||
export E2E_NETWORKS_API_KEY="your-api-key"
|
||||
export E2E_NETWORKS_AUTH_TOKEN="your-auth-token"
|
||||
export E2E_NETWORKS_PROJECT_ID="your-project-id"
|
||||
prowler e2enetworks
|
||||
```
|
||||
|
||||
Read more in the [E2E Networks documentation](/user-guide/providers/e2enetworks/getting-started-e2enetworks). Explore all E2E Networks checks at [Prowler Hub](https://hub.prowler.com/check?provider=e2enetworks).
|
||||
|
||||
### 🔐 Security
|
||||
|
||||
User role relationship updates in the API are now limited to the active tenant, preserving the role assignments the same user holds in other tenants.
|
||||
|
||||
### 🔍 Checks
|
||||
|
||||
#### AWS
|
||||
|
||||
- `ec2_ami_account_block_public_access` — verifies AMI block public access is enabled at the account level in each Region, so AMIs cannot be shared publicly. Thanks to @goutham-hari!
|
||||
- `datapipeline_pipeline_no_secrets_in_definition` — scans Data Pipeline object fields, parameter objects, and parameter values for hardcoded secrets with Kingfisher. Thanks to @YinkaMetrics!
|
||||
- `elbv2_listener_pqc_tls_enabled` — verifies ELBv2 HTTPS/TLS listeners use post-quantum TLS security policies with TLS 1.2 or higher, helping reduce harvest-now-decrypt-later exposure.
|
||||
- `amplify_app_no_secrets_in_environment` — scans Amplify app and branch environment variables and build settings (buildSpec) for hardcoded secrets with Kingfisher. Thanks to @Deep070203!
|
||||
|
||||
#### Azure
|
||||
|
||||
- `app_function_ensure_http_is_redirected_to_https` — verifies that Function Apps enforce HTTPS-only traffic. Thanks to @amandalal007!
|
||||
|
||||
#### Kubernetes
|
||||
|
||||
- `core_minimize_hostpath_volume_mounts` — detects Pods that use `hostPath` volumes. Thanks to @0xTaoZ!
|
||||
- `core_readonly_root_filesystem_enabled` — verifies that every container in each Pod explicitly sets `readOnlyRootFilesystem: true` in its security context. Thanks to @Weedle02!
|
||||
|
||||
#### STACKIT
|
||||
|
||||
- `iaas_server_public_ip_attached` — flags IaaS servers that have a public IP address directly attached to a network interface. Thanks to @johannes-engler-mw!
|
||||
|
||||
Explore all checks at [Prowler Hub](https://hub.prowler.com/check).
|
||||
|
||||
### 🙌 External Contributors
|
||||
|
||||
Thank you to our community contributors for this release!
|
||||
|
||||
- @jchrisfarris — Deploy AWS Organizations with the CloudFormation template in one step ([#10403](https://github.com/prowler-cloud/prowler/pull/10403))
|
||||
- @deepak7093 — New E2E Networks provider: 27 checks across compute nodes, networking, security groups, load balancers, block/file storage, and managed databases ([#11654](https://github.com/prowler-cloud/prowler/pull/11654))
|
||||
- @goutham-hari — AWS `ec2_ami_account_block_public_access` check ([#11828](https://github.com/prowler-cloud/prowler/pull/11828))
|
||||
- @YinkaMetrics — AWS `datapipeline_pipeline_no_secrets_in_definition` check ([#11821](https://github.com/prowler-cloud/prowler/pull/11821))
|
||||
- @amandalal007 — Azure `app_function_ensure_http_is_redirected_to_https` check ([#11929](https://github.com/prowler-cloud/prowler/pull/11929))
|
||||
- @0xTaoZ — Kubernetes `core_minimize_hostpath_volume_mounts` check ([#11837](https://github.com/prowler-cloud/prowler/pull/11837))
|
||||
- @Weedle02 — Kubernetes `core_readonly_root_filesystem_enabled` check ([#11835](https://github.com/prowler-cloud/prowler/pull/11835))
|
||||
- @johannes-engler-mw — STACKIT `iaas_server_public_ip_attached` check ([#11549](https://github.com/prowler-cloud/prowler/pull/11549))
|
||||
- @janderik — Trailing newlines added to compliance, region, and fixture data files for POSIX compliance ([#11765](https://github.com/prowler-cloud/prowler/pull/11765))
|
||||
- @Deep070203 — AWS `amplify_app_no_secrets_in_environment` check ([#11825](https://github.com/prowler-cloud/prowler/pull/11825))
|
||||
|
||||
See the [full release notes on GitHub](https://github.com/prowler-cloud/prowler/releases/tag/5.34.0) for the complete list of changes.
|
||||
</Update>
|
||||
|
||||
<Update label="v5.33.0" description="July 7, 2026">
|
||||
### 🤖 Lighthouse AI — The Agentic Cloud Defender
|
||||
|
||||
<Note>
|
||||
This feature is available exclusively in **Prowler Cloud** and **Prowler Private Cloud** with a [subscription](https://prowler.com/pricing).
|
||||
</Note>
|
||||
|
||||
Lighthouse AI is now a full agentic assistant wired to the Prowler Cloud backend. Ask it about your findings, your compliance posture, or your riskiest resources, and watch it work: the agent discovers and runs the Prowler tools it needs to answer, with every tool call visible in the new agentic view. It reads your security data through read-only tools, so it can never touch secrets or modify your tenant.
|
||||
|
||||

|
||||
|
||||
The chat experience is rebuilt around **persistent sessions**: conversations stream in real time, stay in your session history, can be archived, and a **sidebar chat mode** lets you ask questions from any page in the app without losing your place.
|
||||
|
||||

|
||||
|
||||
You control the brain behind it. Configure one or more LLM providers — **OpenAI**, **Amazon Bedrock**, or any **OpenAI-compatible** endpoint (OpenRouter, Ollama) — with connection testing built into the setup and per-provider model selection. Add a shared **business context** (your security goals, compliance needs, organizational priorities) and every session uses it to give answers that fit your environment.
|
||||
|
||||

|
||||
|
||||
Read more in the [Lighthouse AI documentation](/getting-started/products/prowler-cloud-lighthouse) and the [multiple LLM providers guide](/user-guide/tutorials/prowler-cloud-lighthouse-multi-llm).
|
||||
|
||||
### 📄 Compliance PDF Reports Without Credentials
|
||||
|
||||
Compliance PDF reports no longer require the provider's credentials to be present. Findings are now enriched from the provider metadata stored in the database, so a report still generates even after the provider secret has been deleted or its credentials have become invalid.
|
||||
|
||||
Read more in the [compliance documentation](/user-guide/compliance/tutorials/compliance).
|
||||
|
||||
### ⏳ Scan Queueing
|
||||
|
||||
Overlapping scans for the same provider now queue behind the active one instead of dispatching concurrent scan workers. Launch a manual scan while a scheduled one is running and it waits its turn. No more duplicated work or racing scans.
|
||||
|
||||
### 🔐 Security
|
||||
|
||||
The Kubernetes provider credentials now reject kubeconfigs using `exec` authentication in Prowler Cloud, at the API and in the credential form, preventing user-supplied commands from running on Cloud workers.
|
||||
|
||||
Read more in the [Kubernetes provider authentication documentation](/user-guide/providers/kubernetes/getting-started-k8s#step-2-configure-kubernetes-authentication).
|
||||
|
||||
### 🙌 External Contributors
|
||||
|
||||
Thank you to our community contributors for this release!
|
||||
|
||||
- @kratos0718 — Azure `postgresql_flexible_server_log_retention_days_greater_3` Flexible Server log retention fix ([#11761](https://github.com/prowler-cloud/prowler/pull/11761))
|
||||
- @Sanjays2402 — `KeyError: 'MANUAL'` crash fix in the compliance summary table, shipped early in v5.32.1 ([#11823](https://github.com/prowler-cloud/prowler/pull/11823))
|
||||
|
||||
See the [full release notes on GitHub](https://github.com/prowler-cloud/prowler/releases/tag/5.33.0) for the complete list of changes.
|
||||
</Update>
|
||||
|
||||
<Update label="v5.32.0" description="July 2, 2026">
|
||||
### 🔎 Findings Triage
|
||||
|
||||
<Note>
|
||||
This feature is available exclusively in **Prowler Cloud** and **Prowler Private Cloud** with a [subscription](https://prowler.com/pricing).
|
||||
</Note>
|
||||
|
||||
Triage findings straight from the Findings view. Each finding gets a triage status you can move through its lifecycle:
|
||||
|
||||
**Open → Under Review → Remediating → Risk Accepted → False Positive → Resolved**
|
||||
|
||||
Add a triage note to record the decision, mute a finding, all from the row's actions menu. The current status shows inline on every finding row, so you keep track of what has been reviewed and stop re-checking the same issues scan after scan.
|
||||
|
||||

|
||||
|
||||
The status also follows the finding automatically across scans: when a finding flips from `FAIL` to `PASS` on the next scan it moves to **Resolved**, and when it flips from `PASS` back to `FAIL` it moves to **Reopened**. You always know whether an issue is genuinely fixed or has regressed, without touching it by hand.
|
||||
|
||||

|
||||
|
||||
Read more in the [Findings Triage documentation](/user-guide/tutorials/prowler-app-findings-triage).
|
||||
|
||||
### ⚙️ Scan Configuration
|
||||
|
||||
<Note>
|
||||
This feature is available exclusively in **Prowler Cloud** and **Prowler Private Cloud** with a [subscription](https://prowler.com/pricing).
|
||||
</Note>
|
||||
|
||||
Create named, reusable scan configurations from a dedicated **Scans / Configuration** page. Each configuration is YAML that follows the structure of [`prowler/config/config.yaml`](https://github.com/prowler-cloud/prowler/blob/master/prowler/config/config.yaml), so you only include the keys you want to override; the rest fall back to the built-in defaults. Values are validated on save against a per-provider, type-safe configuration schema that range-checks each field and rejects unknown keys, so a malformed config is caught before it ever reaches a scan. Attach a configuration to one or more providers so it applies on their next scan, or save it now and attach providers later.
|
||||
|
||||

|
||||
|
||||
From the Providers view you can pick which configuration a provider uses (`Default` or any of your saved ones) without leaving the page. No more passing config files around by hand.
|
||||
|
||||

|
||||
|
||||
Read more in the [Scan Configuration documentation](/user-guide/tutorials/prowler-app-scan-configuration).
|
||||
|
||||
### ✅ Per-Requirement Configuration Validation
|
||||
|
||||
<Note>
|
||||
This feature is available exclusively in **Prowler Cloud** and **Prowler Private Cloud** with a [subscription](https://prowler.com/pricing).
|
||||
</Note>
|
||||
|
||||
Compliance frameworks can now declare `ConfigRequirements` on a requirement, so it's reported as **FAIL** when its mapped checks ran under a configuration too loose to satisfy it. Even if every individual finding PASSed. This applies across all compliance outputs: CSV, OCSF, and console tables, and is the engine behind Scan Configuration's "marked as FAIL" behavior described above.
|
||||
|
||||

|
||||
|
||||
Read more in the [Configuration File documentation](/user-guide/cli/tutorials/configuration_file).
|
||||
|
||||
### ⏱️ Okta — Request Throttling & Retries
|
||||
|
||||
Prowler now proactively throttles Okta API requests to stay under rate limits, with reactive retries on HTTP 429 as a safety net. Both are set in the scan configuration (or their equivalent CLI flags):
|
||||
|
||||
- `okta_requests_per_second` (config file) / `--okta-requests-per-second` (CLI) — cap the request rate. Default: 4 req/s.
|
||||
- `okta_max_retries` (config file) / `--okta-retries-max-attempts` (CLI) — bound retry attempts. Default: 5.
|
||||
|
||||
This makes large Okta scans more reliable and less likely to be rate-limited.
|
||||
|
||||
Read more in the [Okta rate limit documentation](/user-guide/providers/okta/retry-configuration#request-throttling-requests-per-second).
|
||||
|
||||
### 📉 AWS — Cap Resources Scanned per Service
|
||||
|
||||
Large AWS accounts can now cap how many resources Prowler analyzes for the highest-volume services, keeping scan time and cost under control. Set a global limit with `max_scanned_resources_per_service`, or override it per service:
|
||||
|
||||
- EBS snapshots (`max_ebs_snapshots`)
|
||||
- Backup recovery points (`max_backup_recovery_points`)
|
||||
- CloudWatch log groups (`max_cloudwatch_log_groups`)
|
||||
- Lambda functions (`max_lambda_functions`)
|
||||
- ECS task definitions (`max_ecs_task_definitions`)
|
||||
- CodeArtifact packages (`max_codeartifact_packages`)
|
||||
|
||||
Limits are **disabled by default** (`0` = unlimited); only positive values cap the analyzed resources.
|
||||
|
||||
<Warning>
|
||||
When a positive limit is set, compliance results reflect only the sampled resources, not every matching resource in the account.
|
||||
</Warning>
|
||||
|
||||
Read more in the [configuration file documentation](/user-guide/cli/tutorials/configuration_file#supported-aws-resource-limits).
|
||||
|
||||
### 🏷️ Azure — Filter by Resource Group
|
||||
|
||||
Azure scans can now be scoped to one or more resource groups with the new `--azure-resource-group` / `--azure-resource-groups` option. This lets you run focused assessments against specific environments, teams, or workloads instead of scanning every accessible resource in the subscription. Thanks to @Legin-ML for contributing this feature!
|
||||
|
||||
```bash
|
||||
# Single resource group
|
||||
prowler azure --az-cli-auth --azure-resource-group rg-prod
|
||||
|
||||
# Multiple resource groups
|
||||
prowler azure --az-cli-auth --azure-resource-group rg-prod1 rg-prod2
|
||||
```
|
||||
|
||||
Read more in the [Azure Resource Groups documentation](/user-guide/providers/azure/resource-groups).
|
||||
|
||||
### 🧭 Provider Group Filter
|
||||
|
||||
Filter the **Overview, Findings, Resources, Scans, and Providers** views by provider group. Scope the whole app to a team, an environment, or a business unit in one click instead of filtering provider by provider.
|
||||
|
||||

|
||||
|
||||
Read more about managing provider groups in the [RBAC documentation](/user-guide/tutorials/prowler-app-rbac).
|
||||
|
||||
### 🔬 API — Timestamp Precision in Findings Filters
|
||||
|
||||
The `/api/v1/findings` endpoint now accepts full timestamps on the `inserted_at` and `updated_at` filters (`filter[inserted_at__gte]`, `filter[inserted_at__lte]`, and the `updated_at` variants), so you can query narrow time windows instead of whole days. Date-only filtering keeps working, so existing integrations are unaffected.
|
||||
|
||||
```bash
|
||||
# Findings inserted within a precise timestamp window
|
||||
curl --globoff \
|
||||
'http://localhost:8080/api/v1/findings?filter[inserted_at__gte]=2026-07-01T06:12:18Z&filter[inserted_at__lte]=2026-07-02T19:25:55Z' \
|
||||
-H 'Authorization: Bearer <YOUR_TOKEN>' \
|
||||
-H 'Accept: application/vnd.api+json'
|
||||
```
|
||||
|
||||
### 🕸️ Attack Paths — Neptune as a persistent sink
|
||||
|
||||
Attack Paths can now persist its graph in **AWS Neptune** in addition to Neo4j, selectable via `ATTACK_PATHS_SINK_DATABASE=neptune` (default `neo4j`). Cartography's per-scan ingest database stays on Neo4j. The scan task preflights the ingest database and the configured sink before ingestion, and provider graph cleanup now deletes relationships in directed batches before deleting nodes.
|
||||
|
||||
This is the groundwork for scale: a managed graph database lets Attack Paths hold much larger graphs, extend coverage to more providers, and link resources across them so an attack path can cross provider boundaries instead of stopping at one cloud's edge.
|
||||
|
||||
Read more in the [Attack Paths documentation](/user-guide/tutorials/prowler-app-attack-paths).
|
||||
|
||||
### 🔐 New Secret-Scanning Engine — Kingfisher
|
||||
|
||||
Prowler's secret-scanning checks now run on [Kingfisher](https://github.com/mongodb/kingfisher) instead of `detect-secrets`. Scans run **fully offline by default**, and obvious placeholder values (e.g. `password123`, `changeme`) are no longer reported, cutting down false positives.
|
||||
|
||||
Opt in to **live validation** with the new `--scan-secrets-validate` flag (or the `aws.secrets_validate` config option): Prowler checks discovered secrets against the provider APIs, and any secret confirmed to be **live is reported as critical**, so you can prioritize the credentials that actually work.
|
||||
|
||||
<Note>
|
||||
The `detect_secrets_plugins` configuration option has been removed, as it is no longer used by the new engine.
|
||||
</Note>
|
||||
|
||||
Read more in the [secret detection documentation](/user-guide/cli/tutorials/pentesting#detect-secrets).
|
||||
|
||||
### 🔍 Checks
|
||||
|
||||
#### AWS
|
||||
|
||||
- `stepfunctions_statemachine_encrypted_with_cmk` — Step Functions state machines use a customer-managed KMS key for encryption at rest instead of the default AWS-owned key. Thanks to @Sid-0602!
|
||||
- `waf_regional_webacl_logging_enabled` — AWS WAF Classic Regional Web ACLs have logging enabled to a Kinesis Data Firehose stream. Thanks to @Sid-0602!
|
||||
- **IAM privilege escalation** — the privesc checks now cover **AWS Bedrock AgentCore** paths across Runtime, Harness, Code Interpreter, and Custom Browser. Thanks to @MrCloudSec!
|
||||
- `apigateway_restapi_no_secrets_in_stage_variables` — scans API Gateway REST API stage variables for hardcoded passwords, API keys, and tokens. Thanks to @chirag1206!
|
||||
- `awslambda_function_no_secrets_in_code` — this check now supports a `secrets_ignore_files` audit-config option to skip files inside the deployment package by glob pattern (e.g. `*.deps.json`), suppressing .NET dependency-manifest false positives without masking real secrets.
|
||||
- `s3_bucket_object_public` — spot-checks a configurable sample of object ACLs in each bucket and flags objects granted to the `AllUsers` or `AuthenticatedUsers` groups. Disabled by default; opt in via the `s3_bucket_object_public_enabled` configuration option. Thanks to @Synchx00!
|
||||
|
||||
#### Microsoft 365
|
||||
|
||||
New **Conditional Access** hardening checks:
|
||||
|
||||
- `entra_conditional_access_policy_explicitly_targets_azure_devops` — at least one enabled policy explicitly includes the Azure DevOps cloud application, rather than relying on a broad "All cloud apps" policy. Thanks to @mzl2233!
|
||||
- `entra_conditional_access_policy_no_exclusion_gaps` — every user, group, role, or application excluded from an enabled policy stays in scope of another enabled policy. Thanks to @UTKARSH698 with @arieleli01212 as co-author!
|
||||
- `entra_conditional_access_policy_groups_management_restricted` — every security group referenced by an enabled or report-only policy is management-restricted or role-assignable. Thanks to @SAMurai-16!
|
||||
- `exchange_application_access_policy_restricts_mailbox_apps` — every service principal with Microsoft Graph application-level Exchange mailbox permissions is restricted by an Exchange Online Application Access Policy. Thanks to @VasistAcharya!
|
||||
|
||||
### 📚 Compliance
|
||||
|
||||
#### CIS Benchmark Refresh — Six New Versions
|
||||
|
||||
Prowler ships a coordinated refresh of the CIS Benchmarks across six providers:
|
||||
|
||||
- **AWS** — CIS Amazon Web Services Foundations Benchmark v7.0.0, adding the new Organizations section (2.1.1-2.1.6), resource policy (2.21), web front-end access logging (4.10), and VPC Endpoints (6.8) recommendations.
|
||||
- **Azure** — CIS Microsoft Azure Foundations Benchmark v6.0.0.
|
||||
- **GCP** — CIS Google Cloud Platform Foundation Benchmark v5.0.0.
|
||||
- **Kubernetes** — CIS Kubernetes Benchmark v2.0.1.
|
||||
- **GitHub** — CIS GitHub Benchmark v1.2.0.
|
||||
- **Microsoft 365** — CIS Microsoft 365 Foundations Benchmark v7.0.0.
|
||||
|
||||
#### CIS Controls v8.1 — Universal Framework
|
||||
|
||||
A new **universal** (cross-provider) compliance framework mapping existing checks across 18 providers — AWS, Azure, GCP, Kubernetes, M365, GitHub, AlibabaCloud, OracleCloud, GoogleWorkspace, Okta, Cloudflare, Vercel, MongoDB Atlas, OpenStack, Linode, StackIT, NHN, and Scaleway — to the 18 CIS Critical Security Controls and their Safeguards. Ships with a dedicated detail view and report mapping in the UI.
|
||||
|
||||
Read more in the [compliance documentation](/user-guide/compliance/tutorials/compliance). Explore the full compliance catalog at [Prowler Hub](https://hub.prowler.com/compliance).
|
||||
|
||||
### 🙌 External Contributors
|
||||
|
||||
Thank you to our community contributors for this release!
|
||||
|
||||
- @chirag1206 — `apigateway_restapi_no_secrets_in_stage_variables` check ([#11188](https://github.com/prowler-cloud/prowler/pull/11188))
|
||||
- @MrCloudSec — AWS Bedrock AgentCore privilege escalation paths in the IAM privesc checks ([#11726](https://github.com/prowler-cloud/prowler/pull/11726))
|
||||
- @Sid-0602 — `stepfunctions_statemachine_encrypted_with_cmk` ([#11538](https://github.com/prowler-cloud/prowler/pull/11538)) and `waf_regional_webacl_logging_enabled` ([#11539](https://github.com/prowler-cloud/prowler/pull/11539)) checks
|
||||
- @mzl2233 — `entra_conditional_access_policy_explicitly_targets_azure_devops` check ([#11182](https://github.com/prowler-cloud/prowler/pull/11182))
|
||||
- @UTKARSH698 with @arieleli01212 as co-author — `entra_conditional_access_policy_no_exclusion_gaps` check ([#11577](https://github.com/prowler-cloud/prowler/pull/11577))
|
||||
- @SAMurai-16 — `entra_conditional_access_policy_groups_management_restricted` check ([#11342](https://github.com/prowler-cloud/prowler/pull/11342))
|
||||
- @vahidg — Azure PostgreSQL flexible server collection resilience fix ([#11595](https://github.com/prowler-cloud/prowler/pull/11595))
|
||||
- @davletd — Azure `keyvault_logging_enabled` `AuditEvent` category fix ([#11660](https://github.com/prowler-cloud/prowler/pull/11660))
|
||||
- @VasistAcharya — `exchange_application_access_policy_restricts_mailbox_apps` ([#11247](https://github.com/prowler-cloud/prowler/pull/11247))
|
||||
- @Legin-ML — Filter scans at Resource Group level ([#10657](https://github.com/prowler-cloud/prowler/pull/10657))
|
||||
- @Synchx00 — `s3_bucket_object_public` check ([#9517](https://github.com/prowler-cloud/prowler/pull/9517))
|
||||
|
||||
See the [full release notes on GitHub](https://github.com/prowler-cloud/prowler/releases/tag/5.32.0) for the complete list of changes.
|
||||
</Update>
|
||||
|
||||
<Update label="v5.31.0" description="June 23, 2026">
|
||||
### 🗓️ Flexible Scan Scheduling
|
||||
|
||||
<Note>
|
||||
Available exclusively in **Prowler Cloud**. Prowler Local Server supports daily scans only.
|
||||
</Note>
|
||||
|
||||

|
||||
|
||||
You can now set a per-provider scan schedule from the Providers page. Pick a **scan time** and a **repeat cadence**: Daily, Every 48 hours, Weekly (with a day-of-week selector), or Monthly. Schedules can be edited or removed at any time, and a new scan never interrupts access to existing data.
|
||||
|
||||

|
||||
|
||||
All schedules are listed in one place under the **Scheduled** tab in **Scan Jobs**, showing each provider's cadence, next scan, and last scan at a glance.
|
||||
|
||||

|
||||
|
||||
Read more in the [scan scheduling documentation](/user-guide/tutorials/prowler-scan-scheduling).
|
||||
|
||||
### 📚 DORA — Expanded Provider Coverage
|
||||
|
||||
Prowler extends [**DORA**](https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en) (Digital Operational Resilience Act, Regulation (EU) 2022/2554) coverage to **Azure**, **GCP**, **Cloudflare**, and **Alibaba Cloud**, mapping each provider's existing checks across the five DORA pillars.
|
||||
|
||||

|
||||
|
||||
<Note>
|
||||
The framework follows the `<name>_<version>` naming convention as `DORA_2022_2554`.
|
||||
</Note>
|
||||
|
||||
Read more in the [compliance documentation](/user-guide/compliance/tutorials/compliance).
|
||||
|
||||
### 🚀 Guided Onboarding
|
||||
|
||||
<Note>
|
||||
Available exclusively in **Prowler Cloud**.
|
||||
</Note>
|
||||
|
||||
New accounts now get a guided first-run experience. The Overview greets you with an **"Add your first provider"** prompt: connect a provider so Prowler has something to scan and assess, then get started in one click (or skip for now).
|
||||
|
||||

|
||||
|
||||
From there, contextual empty states across the product point you to the next action rather than leaving you stuck. Attack Paths, for example, explains that you need a completed scan before it can build a graph and links straight to **Scan Jobs**, with a **"See how it works"** affordance for first-timers.
|
||||
|
||||

|
||||
|
||||
### 🔐 Optional SAML SSO `userType`
|
||||
|
||||
The SAML `userType` attribute is now optional. If your IdP does not send it, or sends it blank, Prowler keeps the user's existing roles unchanged instead of replacing them with a fallback role.
|
||||
|
||||
When `userType` is provided, Prowler still maps the user to the matching role. If that role does not exist yet, Prowler creates it with read-only access: visibility over all providers, with no management permissions.
|
||||
|
||||
Read more in the [SAML SSO documentation](/user-guide/tutorials/prowler-app-sso).
|
||||
|
||||
### 🏢 New Provider — Linode
|
||||
|
||||
Prowler now scans [**Linode**](https://www.linode.com/) (Akamai Cloud), covering its administration, compute, and networking services. Thanks to @varunmamillapalli for their 1st provider in Prowler!
|
||||
|
||||
<Note>
|
||||
Linode is not officially supported. For more information, [contact us](https://prowler.com/contact).
|
||||
</Note>
|
||||
|
||||
Read more in the [Linode documentation](/user-guide/providers/linode/getting-started-linode). Explore all Linode checks at [Prowler Hub](https://hub.prowler.com/check?provider=linode).
|
||||
|
||||
### 🔍 Checks
|
||||
|
||||
#### AWS
|
||||
|
||||
**Post-Quantum Cryptography readiness** — get ahead of the migration to quantum-resistant cryptography:
|
||||
|
||||
- `cloudfront_distributions_pqc_tls_enabled` — CloudFront distributions enforce a post-quantum TLS 1.3 security policy.
|
||||
- `apigateway_domain_name_pqc_tls_enabled` — API Gateway custom domain names use a post-quantum TLS security policy.
|
||||
- `transfer_server_pqc_ssh_kex_enabled` — Transfer Family servers use a post-quantum hybrid SSH key exchange.
|
||||
- `acmpca_certificate_authority_pqc_key_algorithm` — Private CA authorities use a post-quantum (ML-DSA) key algorithm (new `acmpca` service).
|
||||
- `rolesanywhere_trust_anchor_pqc_pki` — IAM Roles Anywhere trust anchors are backed by a post-quantum (ML-DSA) PKI (new `rolesanywhere` service).
|
||||
|
||||
**Organization-wide governance:**
|
||||
|
||||
- `securityhub_delegated_admin_enabled_all_regions` — Security Hub has a delegated administrator, active in all opted-in regions, with organization auto-enable on. Thanks to @ernestprovo23!
|
||||
- `config_delegated_admin_and_org_aggregator_all_regions` — AWS Config has a delegated administrator and an organization aggregator covering all regions. Thanks to @ernestprovo23!
|
||||
|
||||
**Machine learning:**
|
||||
|
||||
- `sagemaker_clarify_exists` — verifies at least one SageMaker Clarify processing job exists per scanned region, so bias-detection and model-explainability controls are in place. Thanks to @AlexanderSanin!
|
||||
|
||||
#### Azure
|
||||
|
||||
A large batch of new Azure checks spanning data, compute, identity, and networking:
|
||||
|
||||
- **Cosmos DB** — automatic failover, continuous backup policy, minimum TLS 1.2, and public network access disabled.
|
||||
- **MySQL & PostgreSQL Flexible Servers** — geo-redundant backup and high availability.
|
||||
- **AKS** — auto-upgrade, Azure Monitor (Container Insights), local accounts disabled, and Microsoft Defender enabled.
|
||||
- **Databricks** — public network access disabled and secure cluster connectivity (no public IP).
|
||||
- **Defender** — CSPM on the Standard tier.
|
||||
- **Networking** — NSG association on subnets and DDoS Network Protection on VNets.
|
||||
- **Entra ID** — app registration credential expiry, users with recent sign-in and strong authentication enforcement.
|
||||
- **Recovery Services** — vaults with at least one protected backup item and vaults with adequate backup policy.
|
||||
|
||||
Thanks to @s1ns3nz0 for all these contributions!
|
||||
|
||||
#### GCP
|
||||
|
||||
New coverage for high availability and public-exposure detection:
|
||||
|
||||
- `cloudsql_instance_high_availability_enabled` — Cloud SQL primary instances use `REGIONAL` availability for automatic zone failover.
|
||||
- `cloudfunction_function_inside_vpc` — Cloud Functions use a Serverless VPC Access connector for private egress.
|
||||
- `cloudfunction_function_not_publicly_accessible` — detects `allUsers` / `allAuthenticatedUsers` IAM invocation bindings.
|
||||
- `secretmanager_secret_not_publicly_accessible` — detects Secret Manager secrets with public IAM bindings.
|
||||
- `secretmanager_secret_rotation_enabled` — verifies Secret Manager secrets have automatic rotation configured with a period of 90 days or less and no missed rotation.
|
||||
|
||||
Thanks to @s1ns3nz0 for all these contributions!
|
||||
|
||||
#### Kubernetes
|
||||
|
||||
New core checks for container resource governance and reliability: CPU limits, CPU requests, memory limits, memory requests, fixed image tags, liveness probes, and readiness probes. Thanks to @Nikhilkumar2311 for all these contributions!
|
||||
|
||||
#### Microsoft 365
|
||||
|
||||
- `entra_directory_sync_object_takeover_blocked` — hybrid Entra tenants block cloud object takeover through soft-match and hard-match directory synchronization. Thanks to @PrettyFox0 and @omobolajiadeyan!
|
||||
- `entra_conditional_access_policy_no_deleted_object_references` — flags Conditional Access policies that reference user, group, or role objects that no longer resolve in the directory. Thanks to @ernestprovo23!
|
||||
|
||||
#### Oracle Cloud Infrastructure
|
||||
|
||||
- `identity_storage_service_level_admins_scoped` — CIS 3.1 control 1.15, ensuring storage service-level administrators exclude delete permissions.
|
||||
|
||||
Explore all checks at [Prowler Hub](https://hub.prowler.com/check).
|
||||
|
||||
### 🐍 Python 3.13 Support
|
||||
|
||||
The Prowler SDK now supports **Python 3.13**. Thanks to @branchv!
|
||||
|
||||
### 🔐 Security Updates
|
||||
|
||||
- **SDK** — `pytest` 8.3.5 → 9.0.3, `black` 25.1.0 → 26.3.1, `microsoft-kiota-*` → 1.9.9, and `aiohttp` → 3.14.0, patching known CVEs.
|
||||
- **API** — `aiohttp` → 3.14.0 and `idna` → 3.15, patching known CVEs.
|
||||
- **UI** — bumped vulnerable `Next.js`, React, AI SDK, `postcss`, `hono`, `qs`, `esbuild`, and Alpine OpenSSL packages; `dompurify` 3.4.2 → 3.4.10, patching XSS sanitization bypass advisories.
|
||||
- **Containers** — base image bumped to `python:3.12.13-slim-bookworm` (patches `libgnutls30` CVE-2026-33845 and CVE-2026-42010) and `trivy` to 0.71.0 (patches embedded `golang.org/x/crypto` and Go stdlib CVEs).
|
||||
|
||||
### 🙌 External Contributors
|
||||
|
||||
Thank you to our community contributors for this release!
|
||||
|
||||
- @varunmamillapalli — New Linode provider: administration, compute, and networking services ([#11633](https://github.com/prowler-cloud/prowler/pull/11633))
|
||||
- @s1ns3nz0 — 20+ Azure & GCP checks across Cosmos DB, AKS, Databricks, Flexible Servers, Entra, networking, and GCP public-exposure
|
||||
- @Nikhilkumar2311 — Kubernetes resource limits, requests, image tag, and probe checks ([#11373](https://github.com/prowler-cloud/prowler/pull/11373))
|
||||
- @ernestprovo23 — AWS Security Hub/Config org-wide delegated admin checks ([#11259](https://github.com/prowler-cloud/prowler/pull/11259)) and M365 conditional access check ([#11236](https://github.com/prowler-cloud/prowler/pull/11236))
|
||||
- @AlexanderSanin — `sagemaker_clarify_exists` check ([#11211](https://github.com/prowler-cloud/prowler/pull/11211))
|
||||
- @PrettyFox0 with @omobolajiadeyan as co-author — M365 directory sync object takeover check ([#11098](https://github.com/prowler-cloud/prowler/pull/11098))
|
||||
- @branchv — Python 3.13 support ([#9293](https://github.com/prowler-cloud/prowler/pull/9293))
|
||||
- @alinealfa — GCP audit-filtered aggregated sinks fix ([#11575](https://github.com/prowler-cloud/prowler/pull/11575))
|
||||
- @b-abderrahmane — Configurable Celery worker concurrency ([#11075](https://github.com/prowler-cloud/prowler/pull/11075))
|
||||
|
||||
See the [full release notes on GitHub](https://github.com/prowler-cloud/prowler/releases/tag/5.31.0) for the complete list of changes.
|
||||
</Update>
|
||||
|
||||
<Update label="Earlier releases">
|
||||
Release notes for v5.30.0 and earlier, along with every patch release, are on [GitHub Releases](https://github.com/prowler-cloud/prowler/releases).
|
||||
</Update>
|
||||
@@ -0,0 +1,467 @@
|
||||
---
|
||||
title: "Attack Paths Queries"
|
||||
---
|
||||
|
||||
This guide explains how to write and maintain Prowler Attack Paths queries: the read-only openCypher queries that traverse the Cartography-ingested cloud graph to detect privilege escalation chains, network exposure, and other graph-shaped security risks.
|
||||
|
||||
<Info>
|
||||
**New to Attack Paths?** Start with the user documentation:
|
||||
- [Attack Paths](/user-guide/tutorials/prowler-app-attack-paths) - What Attack Paths detects, how to run built-in queries, and how to explore the resulting graph.
|
||||
- [Writing Custom openCypher Queries](/user-guide/tutorials/prowler-app-attack-paths#writing-custom-opencypher-queries) - Run ad-hoc read-only queries from the Prowler App.
|
||||
</Info>
|
||||
|
||||
## Introduction
|
||||
|
||||
Attack Paths queries run against a property graph populated by [Cartography](https://github.com/cartography-cncf/cartography), an open-source graph ingestion framework, and enriched with Prowler findings. Every query is read-only openCypher (Version 9) so it runs on both the Neo4j and Amazon Neptune sinks.
|
||||
|
||||
Two categories of query exist, each with a different isolation model:
|
||||
|
||||
| | Predefined queries | Custom queries |
|
||||
| ------------------ | ----------------------------------------------------------- | --------------------------------------------------------------------- |
|
||||
| Where they live | `api/src/backend/api/attack_paths/queries/{provider}.py` | User-supplied through the custom query API endpoint |
|
||||
| Provider isolation | `AWSAccount {id: $provider_uid}` anchor plus path connectivity | Automatic `_Provider_{uuid}` label injection by `cypher_sanitizer.py` |
|
||||
| What to write | Chain every `MATCH` from the `aws` variable | Plain Cypher, no isolation boilerplate |
|
||||
| Internal labels | Never use | Never use (system-injected) |
|
||||
|
||||
For **predefined queries**, every node must be reachable from the `AWSAccount` root through graph traversal. That reachability is the isolation boundary.
|
||||
|
||||
For **custom queries**, the runner injects a `_Provider_{uuid}` label into every node pattern, and a post-query filter handles edge cases, so query authors write natural Cypher without isolation boilerplate.
|
||||
|
||||
The rest of this guide focuses on predefined queries, though the graph model, list-property handling, and compatibility rules apply to both.
|
||||
|
||||
## The Graph Model
|
||||
|
||||
### Cartography Schema
|
||||
|
||||
Node labels, relationship types, and properties follow the upstream Cartography schema for each provider. Do not guess them, fetch the schema for the pinned Cartography version:
|
||||
|
||||
```bash
|
||||
grep cartography api/pyproject.toml
|
||||
```
|
||||
|
||||
Then read the schema for that exact tag:
|
||||
|
||||
```text
|
||||
# Git pin (prowler-cloud/cartography@<TAG>):
|
||||
https://raw.githubusercontent.com/prowler-cloud/cartography/refs/tags/<TAG>/docs/root/modules/{provider}/schema.md
|
||||
|
||||
# PyPI pin (cartography==<TAG>):
|
||||
https://raw.githubusercontent.com/cartography-cncf/cartography/refs/tags/<TAG>/docs/root/modules/{provider}/schema.md
|
||||
```
|
||||
|
||||
The public schema reference for AWS is available at [Cartography AWS Schema](https://cartography-cncf.github.io/cartography/modules/aws/schema.html).
|
||||
|
||||
### Prowler-Specific Additions
|
||||
|
||||
The Prowler sync task enriches the Cartography graph with the following labels and relationships. These are not part of the upstream schema:
|
||||
|
||||
| Label / Relationship | Description |
|
||||
| ---------------------- | ----------------------------------------------------------- |
|
||||
| `ProwlerFinding` | Finding node (`status`, `severity`, `check_id`) |
|
||||
| `Internet` | Internet sentinel node used to model public exposure |
|
||||
| `CAN_ACCESS` | `(Internet)-[:CAN_ACCESS]->(resource)` exposure edge |
|
||||
| `HAS_FINDING` | `(resource)-[:HAS_FINDING]->(:ProwlerFinding)` finding link |
|
||||
| `TRUSTS_AWS_PRINCIPAL` | Role trust relationship |
|
||||
| `STS_ASSUMEROLE_ALLOW` | Principal can assume a role |
|
||||
|
||||
### Internal Isolation Labels
|
||||
|
||||
The sync layer also adds internal labels used only for tenant and provider isolation: `_ProviderResource`, `_AWSResource`, `_Tenant_*`, and `_Provider_*`. These must never appear in query text, predefined or custom. The runner applies isolation automatically.
|
||||
|
||||
## Query Structure
|
||||
|
||||
### Provider Scoping Parameter
|
||||
|
||||
| Parameter | Property | Used on | Purpose |
|
||||
| --------------- | -------- | ------------ | -------------------------------------- |
|
||||
| `$provider_uid` | `id` | `AWSAccount` | Scopes the query to a specific account |
|
||||
|
||||
The runner binds `$provider_uid` automatically. Every other node is isolated by path connectivity from the `AWSAccount` anchor.
|
||||
|
||||
### Imports
|
||||
|
||||
```python
|
||||
from api.attack_paths.queries.types import (
|
||||
AttackPathsQueryAttribution,
|
||||
AttackPathsQueryDefinition,
|
||||
AttackPathsQueryParameterDefinition,
|
||||
)
|
||||
from tasks.jobs.attack_paths.config import PROWLER_FINDING_LABEL
|
||||
```
|
||||
|
||||
Always reference `PROWLER_FINDING_LABEL` through f-string interpolation, never hardcode `"ProwlerFinding"`.
|
||||
|
||||
### Definition Fields
|
||||
|
||||
- **id**: kebab-case `{provider}-{category}-{description}`, e.g. `aws-ec2-privesc-passrole-iam`.
|
||||
- **name**: short, human-friendly label. Sourced queries append the reference ID: `"EC2 Instance Launch with Privileged Role (EC2-001)"`.
|
||||
- **short_description**: one sentence, no technical permissions.
|
||||
- **description**: full technical explanation, plain text.
|
||||
- **provider**: `aws`, `azure`, `gcp`, `kubernetes`, or `github`.
|
||||
- **cypher**: f-string Cypher body. Literal `{` and `}` are escaped as `{{` and `}}`.
|
||||
- **parameters**: `parameters=[]` when the query takes no input.
|
||||
- **attribution**: optional `AttackPathsQueryAttribution(text, link)` for sourced queries. The `link` uses the lowercase ID.
|
||||
|
||||
Append the constant to the `{PROVIDER}_QUERIES` list at the bottom of the provider file.
|
||||
|
||||
## The Predefined Query Template
|
||||
|
||||
The canonical shape combines a principal walk, an optional target walk, deduplicated nodes, and a typed finding overlay:
|
||||
|
||||
```python
|
||||
AWS_QUERY_NAME = AttackPathsQueryDefinition(
|
||||
id="aws-kebab-case-name",
|
||||
name="Label (REFERENCE_ID)",
|
||||
short_description="One sentence.",
|
||||
description="Full technical explanation.",
|
||||
attribution=AttackPathsQueryAttribution(
|
||||
text="pathfinding.cloud - REFERENCE_ID - permission",
|
||||
link="https://pathfinding.cloud/paths/reference_id_lowercase",
|
||||
),
|
||||
provider="aws",
|
||||
cypher=f"""
|
||||
// Find principals with the source permission
|
||||
MATCH path_principal = (aws:AWSAccount {{id: $provider_uid}})--(principal:AWSPrincipal)-[:POLICY]->(policy:AWSPolicy)-[:STATEMENT]->(stmt:AWSPolicyStatement {{effect: 'Allow'}})
|
||||
MATCH (stmt)-[:HAS_ACTION]->(act:AWSPolicyStatementActionItem)
|
||||
WHERE toLower(act.value) IN ['permission_lowercase', 'service:*']
|
||||
OR act.value = '*'
|
||||
WITH DISTINCT aws, principal, stmt, path_principal
|
||||
|
||||
// Pre-aggregate the statement's resource values (see "Avoiding Cartesian Products")
|
||||
MATCH (stmt)-[:HAS_RESOURCE]->(res:AWSPolicyStatementResourceItem)
|
||||
WITH aws, path_principal, collect(DISTINCT res.value) AS res_values
|
||||
WITH aws, path_principal, res_values, ('*' IN res_values) AS res_wildcard
|
||||
|
||||
// Match each target once against the in-memory resource list
|
||||
MATCH path_target = (aws)--(target_role:AWSRole)
|
||||
WITH path_principal, path_target, res_values, res_wildcard,
|
||||
target_role.name AS rname, target_role.arn AS rarn
|
||||
WHERE res_wildcard
|
||||
OR size([rv IN res_values WHERE rv CONTAINS rname OR rarn CONTAINS rv]) > 0
|
||||
|
||||
WITH DISTINCT path_principal, path_target
|
||||
WITH collect(path_principal) + collect(path_target) AS paths
|
||||
UNWIND paths AS p
|
||||
UNWIND nodes(p) AS n
|
||||
|
||||
WITH paths, collect(DISTINCT n) AS unique_nodes
|
||||
UNWIND unique_nodes AS n
|
||||
OPTIONAL MATCH (n)-[pfr:HAS_FINDING]-(pf:{PROWLER_FINDING_LABEL} {{status: 'FAIL'}})
|
||||
|
||||
RETURN paths, collect(DISTINCT pf) as dpf, collect(DISTINCT pfr) as dpfr
|
||||
""",
|
||||
parameters=[],
|
||||
)
|
||||
```
|
||||
|
||||
Key points:
|
||||
|
||||
- The principal walk types the `POLICY` and `STATEMENT` hops. Both are low-fan-out (each principal has a handful of policies; each policy a handful of statements), so the typed edge lets the planner cost a cheap inline filter.
|
||||
- The `(aws)--` hub hops stay anonymous. `AWSAccount` is a high-degree node that fans out to every principal, role, policy, and resource in the account; typing those edges forces the planner to enumerate from the hub and collapses performance on multi-tenant Neptune.
|
||||
- Other relationship types appear only where the file's existing queries already use one (`TRUSTS_AWS_PRINCIPAL`, `STS_ASSUMEROLE_ALLOW`, `MEMBER_AWS_GROUP`, `HAS_EXECUTION_ROLE`).
|
||||
- The finding probe is typed `:HAS_FINDING` and left undirected. The type lets Neptune apply an inline edge filter; the missing direction matches the convention of the rest of the file.
|
||||
- Collapse duplicate rows after each permission gate with `WITH DISTINCT`, carrying only the variables needed by later clauses.
|
||||
- The `RETURN` shape `paths, dpf, dpfr` is the contract the serializer and visualizer depend on. Do not change it.
|
||||
|
||||
## Avoiding Cartesian Products
|
||||
|
||||
The most common performance defect in Attack Paths queries is a Cartesian product between a target set and a policy statement's resource items. When the two are written as independent `MATCH` clauses, the planner pairs every target with every resource item before any filter runs. On accounts with many IAM principals, that multiplies into hundreds of thousands of rows and the query errors or times out.
|
||||
|
||||
### The Pattern That Causes It
|
||||
|
||||
```cypher
|
||||
// One row per (target_role x resource_item): a Cartesian product
|
||||
MATCH path_target = (aws)--(target_role:AWSRole)
|
||||
MATCH (stmt)-[:HAS_RESOURCE]->(res:AWSPolicyStatementResourceItem)
|
||||
WHERE res.value = '*'
|
||||
OR res.value CONTAINS target_role.name
|
||||
OR target_role.arn CONTAINS res.value
|
||||
```
|
||||
|
||||
The two `MATCH` clauses share no relationship, so the engine enumerates all targets multiplied by all resource items, applies a non-indexable `CONTAINS` to each pair, then expands the finding overlay for every surviving row. Cost grows with `targets × resources`, and a second constrained statement (`stmt2`) multiplies it again.
|
||||
|
||||
### The Pattern That Avoids It
|
||||
|
||||
Collect the statement's resource values into a list once, then match each target a single time against that in-memory list:
|
||||
|
||||
```cypher
|
||||
// Pre-aggregate the statement's resource values into a list
|
||||
MATCH (stmt)-[:HAS_RESOURCE]->(res:AWSPolicyStatementResourceItem)
|
||||
WITH aws, path_principal, collect(DISTINCT res.value) AS res_values
|
||||
WITH aws, path_principal, res_values, ('*' IN res_values) AS res_wildcard
|
||||
|
||||
// Match each target once; bind name/arn to locals so the predicate reads them once
|
||||
MATCH path_target = (aws)--(target_role:AWSRole)
|
||||
WITH path_principal, path_target, res_values, res_wildcard,
|
||||
target_role.name AS rname, target_role.arn AS rarn
|
||||
WHERE res_wildcard
|
||||
OR size([rv IN res_values WHERE rv CONTAINS rname OR rarn CONTAINS rv]) > 0
|
||||
```
|
||||
|
||||
Cost now grows with `targets + resources` (linear) rather than `targets × resources`. The rewrite is a pure algebraic identity: the result set is unchanged.
|
||||
|
||||
Guidelines:
|
||||
|
||||
- **Aggregate resources before matching targets, not after.** `collect(DISTINCT res.value)` reduces the resource items to a single list per statement.
|
||||
- **Short-circuit the wildcard grant** with `('*' IN res_values)`. When a statement grants `*`, every target matches, so the list scan is skipped entirely.
|
||||
- **Bind `target.name` and `target.arn` to local variables** in a `WITH` before the predicate. The list comprehension then reads each once per target instead of re-reading the property store once per resource value.
|
||||
- **Use `size([... ]) > 0`, not `any(...)`.** The `any()`, `all()`, and `none()` predicate functions are not part of the openCypher specification and fail on Amazon Neptune. See [openCypher Compatibility](#opencypher-compatibility).
|
||||
- **For two-statement queries**, aggregate each statement's resources into its own list (`res_values`, `res2_values`) and combine the two `size([... ]) > 0` checks with `AND`.
|
||||
|
||||
Every IAM privilege escalation query in `aws.py` uses this pattern. The lateral-movement variants that constrain the target with a relationship (`STS_ASSUMEROLE_ALLOW`, `TRUSTS_AWS_PRINCIPAL`) already limit the target set before the resource filter, which keeps them efficient without further aggregation.
|
||||
|
||||
## Privilege Escalation Sub-Patterns
|
||||
|
||||
Four `path_target` shapes cover the common escalation types. Each shares the canonical template's `path_principal`, the resource pre-aggregation, the deduplication tail, and the `RETURN`; only the `path_target` `MATCH` and its resource predicate differ.
|
||||
|
||||
| Sub-pattern | Target | `path_target` shape | Example |
|
||||
| ------------------- | ------------------------ | ------------------------------------------------------------------------------------------------------- | ------- |
|
||||
| Self-escalation | Principal's own policies | `(aws)--(target_policy:AWSPolicy)--(principal)` | IAM-001 |
|
||||
| Lateral to user | Other IAM users | `(aws)--(target_user:AWSUser)` | IAM-002 |
|
||||
| Assume-role lateral | Assumable roles | `(aws)--(target_role:AWSRole)-[:STS_ASSUMEROLE_ALLOW]-(principal)` | IAM-014 |
|
||||
| PassRole plus service | Service-trusting roles | `(aws)--(target_role:AWSRole)-[:TRUSTS_AWS_PRINCIPAL]-(:AWSPrincipal {arn: '{service}.amazonaws.com'})` | EC2-001 |
|
||||
|
||||
**Multi-permission queries** (for example PassRole plus a service-create action) add permission gates before `path_target`. Reuse the per-query counter for new variables (`act2`, `policy2`, `stmt2`) and collapse rows after each gate:
|
||||
|
||||
```cypher
|
||||
MATCH (principal)-[:POLICY]->(policy2:AWSPolicy)-[:STATEMENT]->(stmt2:AWSPolicyStatement {effect: 'Allow'})
|
||||
MATCH (stmt2)-[:HAS_ACTION]->(act2:AWSPolicyStatementActionItem)
|
||||
WHERE toLower(act2.value) IN ['service:*', 'service:createsomething']
|
||||
OR act2.value = '*'
|
||||
WITH DISTINCT aws, principal, stmt, stmt2, path_principal
|
||||
```
|
||||
|
||||
When a permission is an existence-only gate whose statement resource is not checked later, keep the policy and statement anonymous and carry only the variables still needed:
|
||||
|
||||
```cypher
|
||||
MATCH (principal)-[:POLICY]->(:AWSPolicy)-[:STATEMENT]->(:AWSPolicyStatement {effect: 'Allow'})-[:HAS_ACTION]->(act3:AWSPolicyStatementActionItem)
|
||||
WHERE toLower(act3.value) IN ['service:*', 'service:othersomething']
|
||||
OR act3.value = '*'
|
||||
WITH DISTINCT aws, principal, stmt, path_principal
|
||||
```
|
||||
|
||||
## Network Exposure Pattern
|
||||
|
||||
The Internet node is reached through `CAN_ACCESS` from an already-scoped resource, never as a standalone lookup:
|
||||
|
||||
```python
|
||||
cypher=f"""
|
||||
// Resource scoped through the account anchor
|
||||
MATCH path = (aws:AWSAccount {{id: $provider_uid}})--(resource:EC2Instance)
|
||||
WHERE resource.exposed_internet = true
|
||||
|
||||
// Internet node reached through path connectivity from the resource
|
||||
OPTIONAL MATCH (internet:Internet)-[can_access:CAN_ACCESS]->(resource)
|
||||
|
||||
WITH collect(path) AS paths, head(collect(internet)) AS internet, collect(can_access) AS can_access
|
||||
UNWIND paths AS p
|
||||
UNWIND nodes(p) AS n
|
||||
|
||||
WITH paths, internet, can_access, collect(DISTINCT n) AS unique_nodes
|
||||
UNWIND unique_nodes AS n
|
||||
OPTIONAL MATCH (n)-[pfr:HAS_FINDING]-(pf:{PROWLER_FINDING_LABEL} {{status: 'FAIL'}})
|
||||
|
||||
RETURN paths, collect(DISTINCT pf) as dpf, collect(DISTINCT pfr) as dpfr,
|
||||
internet, can_access
|
||||
"""
|
||||
```
|
||||
|
||||
The `CAN_ACCESS` edge stays typed and directed (`-[:CAN_ACCESS]->`); that is its canonical sync-time orientation. Network-exposure queries extend the `RETURN` contract with `internet, can_access`.
|
||||
|
||||
## Working with List-Typed Properties
|
||||
|
||||
Some Cartography node properties carry a list of values: `AWSPolicyStatement.action`, `AWSPolicyStatement.resource`, `AWSPolicyStatement.notaction`, `AWSPolicyStatement.notresource`, `KMSKey.encryption_algorithms`, `CloudFrontDistribution.aliases`, the container-definition lists on `ECSContainerDefinition`, and many others. The graph models each such property as a set of child item nodes connected to the parent by a typed edge. Queries reach the values by traversing the edge; the parent does not carry the list as a single field.
|
||||
|
||||
### Naming Convention
|
||||
|
||||
For a list-typed parent property the sink stores:
|
||||
|
||||
- **Child label**: `<ParentLabel><PropertyPascal>Item`. Example: `AWSPolicyStatement.resource` becomes `AWSPolicyStatementResourceItem`.
|
||||
- **Edge type**: `HAS_<PROPERTY_UPPER>`. Example: `resource` becomes `HAS_RESOURCE`.
|
||||
- **Child property**: `value`, a single scalar string per list element. For list-of-dict properties (rare; for example `SecretsManagerSecretVersion.tags`) the child carries the original dict keys as named fields per the catalog's `field_map`.
|
||||
|
||||
### Variable Naming for Child-Item Matches
|
||||
|
||||
`aws.py` uses a per-query counter for each `HAS_*` traversal so chained matches stay unambiguous. The counter resets at the top of every query.
|
||||
|
||||
| Edge | First | Second | Third |
|
||||
| ----------------- | ------ | ------- | ------- |
|
||||
| `HAS_ACTION` | `act` | `act2` | `act3` |
|
||||
| `HAS_RESOURCE` | `res` | `res2` | `res3` |
|
||||
| `HAS_NOTACTION` | `nact` | `nact2` | `nact3` |
|
||||
| `HAS_NOTRESOURCE` | `nres` | `nres2` | `nres3` |
|
||||
|
||||
### Matching an Action
|
||||
|
||||
To find statements that grant `iam:PassRole`, `iam:*`, or `*`, traverse the `HAS_ACTION` edge in its own `MATCH` clause and apply the predicate in the attached `WHERE`:
|
||||
|
||||
```cypher
|
||||
MATCH (stmt:AWSPolicyStatement {effect: 'Allow'})
|
||||
MATCH (stmt)-[:HAS_ACTION]->(act:AWSPolicyStatementActionItem)
|
||||
WHERE toLower(act.value) IN ['iam:passrole', 'iam:*']
|
||||
OR act.value = '*'
|
||||
```
|
||||
|
||||
The literal-action list is case-folded with `toLower(act.value)` because IAM authors mix case (`iam:PassRole`, `iam:passrole`); the `*` wildcard never lower-cases.
|
||||
|
||||
### Matching a Resource Against a Target
|
||||
|
||||
To find statements whose resource can target a specific node, pre-aggregate the resource values and test the target against the list once (see [Avoiding Cartesian Products](#avoiding-cartesian-products)):
|
||||
|
||||
```cypher
|
||||
MATCH (stmt)-[:HAS_RESOURCE]->(res:AWSPolicyStatementResourceItem)
|
||||
WITH aws, path_principal, collect(DISTINCT res.value) AS res_values
|
||||
WITH aws, path_principal, res_values, ('*' IN res_values) AS res_wildcard
|
||||
|
||||
MATCH path_target = (aws)--(target_role:AWSRole)
|
||||
WITH path_principal, path_target, res_values, res_wildcard,
|
||||
target_role.name AS rname, target_role.arn AS rarn
|
||||
WHERE res_wildcard
|
||||
OR size([rv IN res_values WHERE rv CONTAINS rname OR rarn CONTAINS rv]) > 0
|
||||
```
|
||||
|
||||
Three predicates cover the resource cases: full wildcard (`*`), a pattern containing the target name (`arn:aws:iam::*:role/admin*`), and a pattern that is a prefix or component of the actual ARN.
|
||||
|
||||
### Every-Item and Any-Item Predicates on a Custom Query
|
||||
|
||||
Custom queries can express list predicates directly with pattern comprehensions. To check whether *every* item satisfies a predicate, count the counter-examples and require zero, together with a guard that ensures at least one item is attached:
|
||||
|
||||
```cypher
|
||||
MATCH (stmt:AWSPolicyStatement)
|
||||
WHERE size([
|
||||
(stmt)-[:HAS_ACTION]->(a:AWSPolicyStatementActionItem)
|
||||
WHERE NOT toLower(a.value) STARTS WITH 's3:'
|
||||
| a
|
||||
]) = 0
|
||||
AND size([(stmt)-[:HAS_ACTION]->(a:AWSPolicyStatementActionItem) | a]) > 0
|
||||
RETURN stmt
|
||||
LIMIT 25
|
||||
```
|
||||
|
||||
To return the list of values directly, collect them from the child items:
|
||||
|
||||
```cypher
|
||||
MATCH (stmt:AWSPolicyStatement {effect: 'Allow'})
|
||||
OPTIONAL MATCH (stmt)-[:HAS_ACTION]->(a:AWSPolicyStatementActionItem)
|
||||
RETURN stmt, collect(a.value) AS actions
|
||||
LIMIT 25
|
||||
```
|
||||
|
||||
### Catalog of List Properties
|
||||
|
||||
The provider catalog lives in `api/src/backend/tasks/jobs/attack_paths/provider_config.py` (`AWS_NORMALIZED_LISTS`). Beyond policy statements it includes KMS algorithms, ECS container-definition lists (`entry_point`, `command`, `links`, `dns_servers`, and others), CloudFront aliases, Inspector finding URL and vulnerability lists, and RDS event-subscription categories. To query a list property that is not in the catalog, add an entry there first so the sync layer materializes it. Properties absent from the catalog are serialized to a comma-delimited string and emit a one-time warning during sync.
|
||||
|
||||
## Working with JSON-Encoded Properties
|
||||
|
||||
Some Cartography properties represent nested objects, most notably `condition` on `AWSPolicyStatement` and `S3PolicyStatement` nodes. To keep the schema portable across graph backends, object-typed properties are stored as JSON-encoded strings:
|
||||
|
||||
```
|
||||
'{"StringEquals":{"aws:SourceAccount":"123456789012"}}'
|
||||
```
|
||||
|
||||
No JSON parser is available at query time, so use `CONTAINS` for substring checks against keys or known values:
|
||||
|
||||
```cypher
|
||||
MATCH (stmt:AWSPolicyStatement)
|
||||
WHERE stmt.effect = 'Allow'
|
||||
AND stmt.condition CONTAINS '"aws:SourceAccount"'
|
||||
RETURN stmt
|
||||
LIMIT 25
|
||||
```
|
||||
|
||||
When a query needs to inspect the structured members of a condition (for example, to evaluate every operator and key), fetch the rows first and parse the JSON in application code. Cypher cannot navigate JSON object keys or values.
|
||||
|
||||
## openCypher Compatibility
|
||||
|
||||
Queries must run on both Neo4j and Amazon Neptune. Neptune implements a subset of Cypher, so several convenient constructs are unavailable. Avoid the following:
|
||||
|
||||
| Feature | Use instead |
|
||||
| --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| APOC procedures (`apoc.*`) | Real nodes and relationships in the graph |
|
||||
| Neptune extensions | Standard openCypher |
|
||||
| `any(x IN list ...)` | `size([x IN list WHERE pred]) > 0` |
|
||||
| `all(x IN list ...)` | `size([x IN list WHERE pred]) = size(list)` |
|
||||
| `none(x IN list ...)` | `size([x IN list WHERE pred]) = 0` |
|
||||
| `reduce()` | `UNWIND` plus `collect()` |
|
||||
| `FOREACH` | `WITH` plus `UNWIND` plus `SET` |
|
||||
| Regex `=~` | `toLower()` plus exact match, or `STARTS WITH` / `CONTAINS` |
|
||||
| `CALL () { UNION }` | Multi-label `OR` in `WHERE` |
|
||||
| Carried value plus aggregate expression | Project the aggregate first (`WITH principal_paths, collect(...) AS target_paths`), then combine lists in the next `WITH` |
|
||||
| `EXISTS { MATCH (pattern) WHERE pred }` | Standalone `MATCH (pattern)` plus `WHERE pred`; precede the downstream `collect(path...)` with `WITH DISTINCT <path-vars>` to dedupe the joins |
|
||||
|
||||
The carried-value-plus-aggregate rule is worth calling out because it is easy to hit. Neo4j 5.x rejects an expression that concatenates a carried list variable with an aggregate in the same projection:
|
||||
|
||||
```cypher
|
||||
// Rejected: "Aggregation column contains implicit grouping expressions"
|
||||
WITH principal_paths + collect(DISTINCT path_target) AS paths
|
||||
```
|
||||
|
||||
Split it into two `WITH` clauses so the aggregation resolves before the concatenation:
|
||||
|
||||
```cypher
|
||||
WITH principal_paths, collect(DISTINCT path_target) AS target_paths
|
||||
WITH principal_paths + target_paths AS paths
|
||||
```
|
||||
|
||||
For list-typed properties in the catalog (action, resource, and so on), traverse the `HAS_*` edges to the child item nodes rather than reading a single field; `split(...)` and comma-string predicates do not apply.
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Chain every MATCH from the account anchor.** An unanchored `MATCH (role:AWSRole)` returns roles from every provider in the graph; `MATCH (aws)--(role:AWSRole)` is scoped. A second-permission `MATCH` such as `MATCH (principal)--(policy2:AWSPolicy)--(stmt2:AWSPolicyStatement)` is safe because `principal` is already bound to the account subgraph.
|
||||
2. **Pre-aggregate resource lists before matching targets** to avoid Cartesian products (see [Avoiding Cartesian Products](#avoiding-cartesian-products)).
|
||||
3. **Type the finding probe.** Always `OPTIONAL MATCH (n)-[pfr:HAS_FINDING]-(pf:{PROWLER_FINDING_LABEL} {{status: 'FAIL'}})`. The type lets Neptune apply an inline edge filter; an untyped probe scans every incident edge of high-degree nodes.
|
||||
4. **Comment each MATCH.** One inline `// ...` line per clause explaining its role.
|
||||
5. **Never use internal labels.** `_ProviderResource`, `_AWSResource`, `_Tenant_*`, and `_Provider_*` are system isolation labels and must not appear in query text.
|
||||
6. **Reach the Internet node through path connectivity** with `(internet:Internet)-[:CAN_ACCESS]->(resource)`, never as a standalone match.
|
||||
7. **Preserve the RETURN contract.** `paths, dpf, dpfr` for the standard shape; add `internet, can_access` for network-exposure queries. The serializer and visualizer depend on these names.
|
||||
|
||||
## Naming Conventions
|
||||
|
||||
- **ID**: kebab-case `{provider}-{category}-{description}`, e.g. `aws-ec2-privesc-passrole-iam`.
|
||||
- **Constant**: `UPPER_SNAKE_CASE` `{PROVIDER}_{CATEGORY}_{DESCRIPTION}`, e.g. `AWS_EC2_PRIVESC_PASSROLE_IAM`.
|
||||
|
||||
## Creating a New Query
|
||||
|
||||
New queries come from one of two input sources: a [pathfinding.cloud](https://github.com/DataDog/pathfinding.cloud) research ID (for example `ECS-001`, `GLUE-001`) or a natural-language description from the requester. The aggregated `paths.json` is too large to fetch whole; query a single path by ID:
|
||||
|
||||
```bash
|
||||
# Fetch a single path by ID
|
||||
curl -s https://raw.githubusercontent.com/DataDog/pathfinding.cloud/main/docs/paths.json \
|
||||
| jq '.[] | select(.id == "ecs-002")'
|
||||
|
||||
# List all path IDs and names
|
||||
curl -s https://raw.githubusercontent.com/DataDog/pathfinding.cloud/main/docs/paths.json \
|
||||
| jq -r '.[] | "\(.id): \(.name)"'
|
||||
```
|
||||
|
||||
Then follow these steps:
|
||||
|
||||
1. **Read the queries module first** to match the existing style:
|
||||
|
||||
```text
|
||||
api/src/backend/api/attack_paths/queries/
|
||||
├── __init__.py
|
||||
├── types.py # dataclass definitions
|
||||
├── registry.py
|
||||
└── {provider}.py
|
||||
```
|
||||
|
||||
2. **Fetch the Cartography schema for the pinned version.** Do not guess labels, properties, or relationships. See [The Graph Model](#the-graph-model).
|
||||
|
||||
3. **Build the query** from the canonical template plus the appropriate sub-pattern (privilege escalation or network exposure). Pre-aggregate resource lists, traverse `HAS_*` edges for list-typed properties, and keep the `RETURN` contract.
|
||||
|
||||
4. **Register** the constant in the `{PROVIDER}_QUERIES` list at the bottom of the provider file.
|
||||
|
||||
5. **Verify compatibility** against the [openCypher Compatibility](#opencypher-compatibility) rules, and confirm the query parses and runs on Neo4j before it reaches Neptune.
|
||||
|
||||
<Note>
|
||||
AI assistants connected through Prowler MCP Server can fetch the exact Cartography schema for the active scan with the `prowler_get_attack_paths_cartography_schema` tool, which guarantees that generated queries match the schema version pinned by the running Prowler release.
|
||||
</Note>
|
||||
|
||||
## Reference
|
||||
|
||||
- **pathfinding.cloud**: [github.com/DataDog/pathfinding.cloud](https://github.com/DataDog/pathfinding.cloud) (use `curl | jq`; the aggregated `paths.json` is too large for a single fetch).
|
||||
- **Cartography AWS schema**: [cartography-cncf.github.io/cartography/modules/aws/schema.html](https://cartography-cncf.github.io/cartography/modules/aws/schema.html).
|
||||
- **Neptune openCypher compliance**: [docs.aws.amazon.com/neptune/latest/userguide/feature-opencypher-compliance.html](https://docs.aws.amazon.com/neptune/latest/userguide/feature-opencypher-compliance.html).
|
||||
- **Neptune openCypher rewrites**: [docs.aws.amazon.com/neptune/latest/userguide/migration-opencypher-rewrites.html](https://docs.aws.amazon.com/neptune/latest/userguide/migration-opencypher-rewrites.html).
|
||||
- **openCypher specification**: [github.com/opencypher/openCypher](https://github.com/opencypher/openCypher).
|
||||
@@ -40,7 +40,7 @@ The AWS provider implementation follows the general [Provider structure](/develo
|
||||
- **Key AWS Responsibilities:**
|
||||
- Receives an `AwsProvider` instance to access session, identity, and configuration.
|
||||
- Manages clients for all services by regions.
|
||||
- Provides `__threading_call__` method to make boto3 calls in parallel. By default, this calls are made by region, but it can be overridden with the first parameter of the method and use by resource.
|
||||
- Provides `__threading_call__` method to make boto3 calls in parallel. By default, these calls are made by region, but it can be overridden with the first parameter of the method and use by resource.
|
||||
- Exposes common audit context (`audited_account`, `audited_account_arn`, `audited_partition`, `audited_resources`) to subclasses.
|
||||
|
||||
### Exception Handling
|
||||
@@ -60,7 +60,7 @@ The generic service pattern is described in [service page](/developer-guide/serv
|
||||
- Directly in the code, in location [`prowler/providers/aws/services/`](https://github.com/prowler-cloud/prowler/tree/master/prowler/providers/aws/services)
|
||||
- In the [Prowler Hub](https://hub.prowler.com/). For a more human-readable view.
|
||||
|
||||
The best reference to understand how to implement a new service is following the [service implementation documentation](/developer-guide/services#adding-a-new-service) and taking other services already implemented as reference. In next subsection you can find a list of common patterns that are used accross all AWS services.
|
||||
The best reference to understand how to implement a new service is following the [service implementation documentation](/developer-guide/services#adding-a-new-service) and taking other services already implemented as reference. In next subsection you can find a list of common patterns that are used across all AWS services.
|
||||
|
||||
### AWS Service Common Patterns
|
||||
|
||||
@@ -69,7 +69,7 @@ The best reference to understand how to implement a new service is following the
|
||||
- The constructor (`__init__`) always calls `super().__init__` with the service name and provider (e.g. `super().__init__(__class__.__name__, provider))`). Ensure that the service name in boto3 is the same that you use in the constructor. Usually is used the `__class__.__name__` to get the service name because it is the same as the class name.
|
||||
- Resource containers **must** be initialized in the constructor. They should be dictionaries, with the key being the resource ARN or equivalent unique identifier and the value being the resource object.
|
||||
- Resource discovery and attribute collection are parallelized using `self.__threading_call__`, typically by region or resource, for performance. The first parameter of the method is the iterator, if not provided, it will be the region; but if present indicate an array of the resources to be processed.
|
||||
- Resource filtering is consistently enforced using `self.audit_resources` attribute and `is_resource_filtered` function, it is used to see if user has provided some resource that is not in the audit scope, so we can skip it in the service logic. Normally it is used befor storing the resource in the service container as follows: `if not self.audit_resources or (is_resource_filtered(resource["arn"], self.audit_resources)):`.
|
||||
- Resource filtering is consistently enforced using `self.audit_resources` attribute and `is_resource_filtered` function, it is used to see if user has provided some resource that is not in the audit scope, so we can skip it in the service logic. Normally it is used before storing the resource in the service container as follows: `if not self.audit_resources or (is_resource_filtered(resource["arn"], self.audit_resources)):`.
|
||||
- All AWS resources are represented as Pydantic `BaseModel` classes, providing type safety and structured access to resource attributes.
|
||||
- AWS API calls are wrapped in try/except blocks, with specific handling for `ClientError` and generic exceptions, always logging errors.
|
||||
- If ARN is not present for some resource, it can be constructed using string interpolation, always including partition, service, region, account, and resource ID.
|
||||
@@ -163,7 +163,7 @@ When you instantiate `Check_Report_AWS`, you must provide the check metadata and
|
||||
|
||||
If the resource object does not contain the required attributes, you must set them manually in the check logic.
|
||||
|
||||
Other attributes are inherited from the `Check_Report` class, from that ones you **always** have to set the `status` and `status_extended` attributes in the check logic.
|
||||
Other attributes are inherited from the `Check_Report` class, from those you **always** have to set the `status` and `status_extended` attributes in the check logic.
|
||||
|
||||
#### Example Usage
|
||||
|
||||
|
||||
@@ -58,7 +58,7 @@ The generic service pattern is described in [service page](/developer-guide/serv
|
||||
- Directly in the code, in location [`prowler/providers/azure/services/`](https://github.com/prowler-cloud/prowler/tree/master/prowler/providers/azure/services)
|
||||
- In the [Prowler Hub](https://hub.prowler.com/) for a more human-readable view.
|
||||
|
||||
The best reference to understand how to implement a new service is following the [service implementation documentation](/developer-guide/services#adding-a-new-service) and taking other services already implemented as reference. In next subsection you can find a list of common patterns that are used accross all Azure services.
|
||||
The best reference to understand how to implement a new service is following the [service implementation documentation](/developer-guide/services#adding-a-new-service) and taking other services already implemented as reference. In next subsection you can find a list of common patterns that are used across all Azure services.
|
||||
|
||||
### Azure Service Common Patterns
|
||||
|
||||
|
||||
@@ -173,7 +173,7 @@ else:
|
||||
|
||||
### Resource Identification in Prowler
|
||||
|
||||
Each check **must** populate the report with an unique identifier for the audited resource. This identifier or identifiers are going to depend on the provider and the resource that is being audited. Here are the criteria for each provider:
|
||||
Each check **must** populate the report with a unique identifier for the audited resource. This identifier or identifiers are going to depend on the provider and the resource that is being audited. Here are the criteria for each provider:
|
||||
|
||||
- AWS
|
||||
- Amazon Resource ID — `report.resource_id`.
|
||||
|
||||
@@ -134,6 +134,7 @@ Only fields with a numeric range, a fixed value set, or a length cap are listed.
|
||||
| `max_unused_sagemaker_access_days` | `7..180` days | |
|
||||
| `max_security_group_rules` | `1..1000` | AWS hard limit is 1000 rules per security group |
|
||||
| `max_ec2_instance_age_in_days` | `1..1095` days | 3 years |
|
||||
| `max_ec2_instance_stopped_days` | `1..1095` days | 3 years |
|
||||
| `ec2_high_risk_ports` | each port `1..65535` | port 0 is reserved |
|
||||
| `max_idle_disconnect_timeout_in_seconds` | `60..1800` s | NIST AC-12: cap at 30 min |
|
||||
| `max_disconnect_timeout_in_seconds` | `60..3600` s | |
|
||||
|
||||
@@ -9,9 +9,9 @@ Prowler documentation is built using [Mintlify](https://www.mintlify.com/docs),
|
||||
|
||||
The Prowler documentation is organized into several sections. The main ones are:
|
||||
|
||||
- **Getting Started**: Provides an overview of the Prowler platform and its different solutions, including Prowler Cloud/App, Prowler CLI, Prowler MCP Server, Prowler Hub, and Prowler Lighthouse AI. This section helps new users understand which Prowler solution best fits their needs and includes product comparisons.
|
||||
- **Getting Started**: Provides an overview of the Prowler platform and its two product families, Prowler Products (Prowler Cloud, Prowler Hub, Prowler MCP, Prowler Lighthouse AI) and Open Source (Prowler CLI, Prowler Local Server). This section helps new users understand which Prowler solution best fits their needs and includes product comparisons.
|
||||
|
||||
- **Guides**: Contains practical tutorials and how-to guides organized by product (Prowler Cloud/App, CLI) and provider (AWS, Azure, GCP, Kubernetes, Microsoft 365, GitHub, etc.). This section covers authentication, integrations, compliance, and advanced usage scenarios.
|
||||
- **Guides**: Contains practical tutorials and how-to guides organized by product (Prowler Cloud, CLI) and provider (AWS, Azure, GCP, Kubernetes, Microsoft 365, GitHub, etc.). This section covers authentication, integrations, compliance, and advanced usage scenarios.
|
||||
|
||||
- **Developer Guide**: Documentation for contributors looking to extend Prowler functionality. This includes guides on creating providers, services, checks, output formats, integrations, and compliance frameworks. Provider-specific implementation details and testing strategies are also covered here.
|
||||
|
||||
|
||||
@@ -3,11 +3,11 @@ title: 'End-to-End Tests for Prowler App'
|
||||
description: 'Write Playwright end-to-end tests for Prowler App covering user journeys, Page Object Models, storage state reuse, and organizing spec files by feature area.'
|
||||
---
|
||||
|
||||
End-to-end (E2E) tests validate complete user flows in Prowler App (UI + API). These tests are implemented with [Playwright](https://playwright.dev/) under the `ui/tests` folder and are designed to run against a Prowler App environment.
|
||||
End-to-end (E2E) tests validate complete user flows in Prowler Local Server (UI + API). These tests are implemented with [Playwright](https://playwright.dev/) under the `ui/tests` folder and are designed to run against a Prowler Local Server environment.
|
||||
|
||||
## General Recommendations
|
||||
|
||||
When adding or maintaining E2E tests for Prowler App, follow these guidelines:
|
||||
When adding or maintaining E2E tests for Prowler Local Server, follow these guidelines:
|
||||
|
||||
1. **Test real user journeys**
|
||||
Focus on full workflows (for example, sign-up → login → add provider → launch scan) instead of low-level UI details already covered by unit or integration tests.
|
||||
@@ -20,8 +20,8 @@ When adding or maintaining E2E tests for Prowler App, follow these guidelines:
|
||||
3. **Use a Page Model (Page Object Model)**
|
||||
- Encapsulate selectors and common actions in page classes instead of repeating them in each test.
|
||||
- Leverage and extend the existing Playwright page models in `ui/tests`—such as `ProvidersPage`, `ScansPage`, and others—which are all based on the shared `BasePage`.
|
||||
- Page models for Prowler App pages should be placed in their respective entity folders (for example, `ui/tests/providers/providers-page.ts`).
|
||||
- Page models for external pages (not part of Prowler App) should be grouped in the `external` folder (for example, `ui/tests/external/github-page.ts`).
|
||||
- Page models for Prowler Local Server pages should be placed in their respective entity folders (for example, `ui/tests/providers/providers-page.ts`).
|
||||
- Page models for external pages (not part of Prowler Local Server) should be grouped in the `external` folder (for example, `ui/tests/external/github-page.ts`).
|
||||
- This approach improves readability, reduces duplication, and makes refactors safer.
|
||||
|
||||
4. **Reuse authentication states (StorageState)**
|
||||
@@ -194,7 +194,7 @@ When adding or maintaining E2E tests for Prowler App, follow these guidelines:
|
||||
|
||||
## Running Prowler Tests
|
||||
|
||||
E2E tests for Prowler App run from the `ui` project using Playwright. The Playwright configuration lives in `ui/playwright.config.ts` and defines:
|
||||
E2E tests for Prowler Local Server run from the `ui` project using Playwright. The Playwright configuration lives in `ui/playwright.config.ts` and defines:
|
||||
|
||||
- `testDir: "./tests"` – location of E2E test files (relative to the `ui` project root, so `ui/tests`).
|
||||
- `webServer` – how to start the Next.js development server and connect to Prowler API.
|
||||
@@ -226,7 +226,7 @@ Before running E2E tests:
|
||||
- Start Prowler API so it is reachable on that URL (for example, via `docker-compose-dev.yml` or the development orchestration used locally).
|
||||
- If a different API URL is required, set `UI_API_BASE_URL` accordingly before running the tests.
|
||||
|
||||
- **Ensure Prowler App UI is available**
|
||||
- **Ensure Prowler Local Server UI is available**
|
||||
- Playwright automatically starts the Next.js server through the `webServer` block in `playwright.config.ts` (`pnpm run dev` by default).
|
||||
- If the UI is already running on `http://localhost:3000`, Playwright will reuse the existing server when `reuseExistingServer` is `true`.
|
||||
|
||||
@@ -247,7 +247,7 @@ Before running E2E tests:
|
||||
|
||||
### Executing Tests
|
||||
|
||||
To execute E2E tests for Prowler App:
|
||||
To execute E2E tests for Prowler Local Server:
|
||||
|
||||
1. **Run the full E2E suite (headless)**
|
||||
|
||||
|
||||
@@ -3,7 +3,7 @@ title: 'Environment Variable Naming Conventions'
|
||||
description: 'Namespace Prowler App, API, SDK, and MCP Server environment variables with component prefixes like UI_ and API_ to avoid conflicts in a shared .env file.'
|
||||
---
|
||||
|
||||
Prowler is a monorepo composed of several runtime components — Prowler App (the web user interface), Prowler API (the backend), Prowler SDK, and Prowler MCP Server (Model Context Protocol) — that frequently share a single `.env` file. To keep that shared configuration unambiguous, each component namespaces its environment variables with a component-specific prefix.
|
||||
Prowler is a monorepo composed of several runtime components — Prowler Local Server (the web user interface), Prowler API (the backend), Prowler SDK, and Prowler MCP Server (Model Context Protocol) — that frequently share a single `.env` file. To keep that shared configuration unambiguous, each component namespaces its environment variables with a component-specific prefix.
|
||||
|
||||
## Component Prefixes
|
||||
|
||||
@@ -11,7 +11,7 @@ Each component owns a dedicated prefix for the environment variables it reads:
|
||||
|
||||
| Component | Prefix | Status |
|
||||
|-----------|--------|--------|
|
||||
| Prowler App (web UI) | `UI_` | Adopted |
|
||||
| Prowler Local Server (web UI) | `UI_` | Adopted |
|
||||
| Prowler API (backend) | `API_` | Planned |
|
||||
| Prowler SDK | `SDK_` | Planned |
|
||||
| Prowler MCP Server | `MCP_` | Planned |
|
||||
@@ -22,11 +22,11 @@ Component prefixes solve three concrete problems in a shared configuration file:
|
||||
|
||||
- **Collisions in a shared `.env`:** Several components historically read identically named variables. The API base URL, for example, is consumed by more than one component, so a single unprefixed name is ambiguous. A component prefix removes that ambiguity.
|
||||
- **Explicit ownership:** A prefix states, at a glance, which component consumes a variable.
|
||||
- **Reduced accidental exposure:** For Prowler App, scoping browser-facing configuration under one intentional prefix prevents server-only values from leaking into the client bundle.
|
||||
- **Reduced accidental exposure:** For Prowler Local Server, scoping browser-facing configuration under one intentional prefix prevents server-only values from leaking into the client bundle.
|
||||
|
||||
## Prowler App
|
||||
## Prowler Local Server
|
||||
|
||||
Prowler App has adopted the `UI_` prefix. Its public configuration is resolved from the container environment at runtime rather than inlined at build time, so a single pre-built image serves any deployment. For the operational details on changing these values without rebuilding the image, see [Troubleshooting](/troubleshooting).
|
||||
Prowler Local Server has adopted the `UI_` prefix. Its public configuration is resolved from the container environment at runtime rather than inlined at build time, so a single pre-built image serves any deployment. For the operational details on changing these values without rebuilding the image, see [Troubleshooting](/troubleshooting).
|
||||
|
||||
The former build-time variables map to the new runtime variables as follows:
|
||||
|
||||
@@ -37,25 +37,28 @@ The former build-time variables map to the new runtime variables as follows:
|
||||
| `NEXT_PUBLIC_GOOGLE_TAG_MANAGER_ID` | `UI_GOOGLE_TAG_MANAGER_ID` |
|
||||
| `NEXT_PUBLIC_SENTRY_DSN`, `SENTRY_DSN` | `UI_SENTRY_DSN` |
|
||||
| `NEXT_PUBLIC_SENTRY_ENVIRONMENT`, `SENTRY_ENVIRONMENT` | `UI_SENTRY_ENVIRONMENT` |
|
||||
| `NEXT_PUBLIC_IS_CLOUD_ENV` | `UI_CLOUD_ENABLED` |
|
||||
|
||||
The build-time-only Sentry variables used for source-map upload — `SENTRY_ORG`, `SENTRY_PROJECT`, `SENTRY_AUTH_TOKEN`, and `SENTRY_RELEASE` — keep their names, as they are not part of the App's runtime configuration.
|
||||
`UI_CLOUD_ENABLED` is a plain runtime boolean flag that enables Prowler Cloud behavior when set to the exact string `"true"` and defaults to off; unlike the other renamed variables it has no legacy fallback, so `NEXT_PUBLIC_IS_CLOUD_ENV` is no longer read.
|
||||
|
||||
The build-time-only Sentry variables used for source-map upload — `SENTRY_ORG`, `SENTRY_PROJECT`, `SENTRY_AUTH_TOKEN`, and `SENTRY_RELEASE` — keep their names, as they are not part of Prowler Local Server's runtime configuration.
|
||||
|
||||
## Enabling Third-Party Integrations
|
||||
|
||||
Prowler App gates each optional third-party integration behind an explicit enable flag. When an integration is configured through its new `UI_*` variables, it loads only when its flag is set to the exact string `"true"`; any other value, including unset, leaves it off. This default-off behavior keeps a deployment free of third-party egress unless it opts in. Deployments still using the deprecated legacy variable names keep loading without the flag, for backward compatibility (see [Deprecated Names](#deprecated-names)).
|
||||
Prowler Local Server gates each optional third-party integration behind an explicit enable flag. When an integration is configured through its new `UI_*` variables, it loads only when its flag is set to the exact string `"true"`; any other value, including unset, leaves it off. This default-off behavior keeps a deployment free of third-party egress unless it opts in. Deployments still using the deprecated legacy variable names keep loading without the flag, for backward compatibility (see [Deprecated Names](#deprecated-names)).
|
||||
|
||||
| Integration | Enable flag | Required configuration when enabled |
|
||||
|-------------|-------------|-------------------------------------|
|
||||
| Sentry (error monitoring) | `UI_SENTRY_ENABLE` | `UI_SENTRY_DSN` |
|
||||
| Google Tag Manager | `UI_GOOGLE_TAG_MANAGER_ENABLE` | `UI_GOOGLE_TAG_MANAGER_ID` |
|
||||
| PostHog (product analytics) | `UI_POSTHOG_ENABLE` | `UI_POSTHOG_KEY` and `UI_POSTHOG_HOST` |
|
||||
| Sentry (error monitoring) | `UI_SENTRY_ENABLED` | `UI_SENTRY_DSN` |
|
||||
| Google Tag Manager | `UI_GOOGLE_TAG_MANAGER_ENABLED` | `UI_GOOGLE_TAG_MANAGER_ID` |
|
||||
| PostHog (product analytics) | `UI_POSTHOG_ENABLED` | `UI_POSTHOG_KEY` and `UI_POSTHOG_HOST` |
|
||||
|
||||
When an integration is enabled but its required configuration is missing, Prowler App fails fast at server startup with a clear error, so a misconfigured container never starts silently. A new `UI_*` value set while its enable flag is not `"true"` is ignored, and the server logs a one-time startup warning noting that the integration will not load. Legacy names follow the backward-compatible rule described in [Deprecated Names](#deprecated-names).
|
||||
When an integration is enabled but its required configuration is missing, Prowler Local Server fails fast at server startup with a clear error, so a misconfigured container never starts silently. A new `UI_*` value set while its enable flag is not `"true"` is ignored, and the server logs a one-time startup warning noting that the integration will not load. Legacy names follow the backward-compatible rule described in [Deprecated Names](#deprecated-names).
|
||||
|
||||
PostHog support is currently limited to configuration validation: Prowler App reads and validates the PostHog variables but does not yet load a PostHog client.
|
||||
PostHog support is currently limited to configuration validation: Prowler Local Server reads and validates the PostHog variables but does not yet load a PostHog client.
|
||||
|
||||
<Warning>
|
||||
Configuring an integration through the new `UI_*` variables now requires its enable flag. A deployment that adopted `UI_SENTRY_DSN` or `UI_GOOGLE_TAG_MANAGER_ID` must also set `UI_SENTRY_ENABLE=true` or `UI_GOOGLE_TAG_MANAGER_ENABLE=true` to keep the integration active. Deployments still using the legacy names (`NEXT_PUBLIC_*`, or `POSTHOG_KEY` and `POSTHOG_HOST`) keep working without the flag.
|
||||
Configuring an integration through the new `UI_*` variables now requires its enable flag. A deployment that adopted `UI_SENTRY_DSN` or `UI_GOOGLE_TAG_MANAGER_ID` must also set `UI_SENTRY_ENABLED=true` or `UI_GOOGLE_TAG_MANAGER_ENABLED=true` to keep the integration active. Deployments still using the legacy names (`NEXT_PUBLIC_*`, or `POSTHOG_KEY` and `POSTHOG_HOST`) keep working without the flag.
|
||||
</Warning>
|
||||
|
||||
## Upcoming Breaking Change
|
||||
@@ -68,5 +71,5 @@ Prowler API, Prowler SDK, and Prowler MCP Server have not yet adopted the conven
|
||||
|
||||
## Deprecated Names
|
||||
|
||||
- **Prowler App:** The bare server-side `SENTRY_DSN` and `SENTRY_ENVIRONMENT` are no longer read; the server and edge runtimes now read `UI_SENTRY_DSN` and `UI_SENTRY_ENVIRONMENT`. The former `NEXT_PUBLIC_*` names — and, for PostHog, the unprefixed `POSTHOG_KEY` and `POSTHOG_HOST` — are deprecated but stay backward compatible: they are read at runtime regardless of the enable flag, so an existing deployment keeps its integration active without opting in. The new `UI_*` names, by contrast, load only when the matching enable flag is set to `"true"`. These legacy names will be removed in a future release, so migrate to the `UI_*` runtime variables — and set the enable flag — on the running container.
|
||||
- **Prowler Local Server:** The bare server-side `SENTRY_DSN` and `SENTRY_ENVIRONMENT` are no longer read; the server and edge runtimes now read `UI_SENTRY_DSN` and `UI_SENTRY_ENVIRONMENT`. The former `NEXT_PUBLIC_*` names — and, for PostHog, the unprefixed `POSTHOG_KEY` and `POSTHOG_HOST` — are deprecated but stay backward compatible: they are read at runtime regardless of the enable flag, so an existing deployment keeps its integration active without opting in. The new `UI_*` names, by contrast, load only when the matching enable flag is set to `"true"`. These legacy names will be removed in a future release, so migrate to the `UI_*` runtime variables — and set the enable flag — on the running container.
|
||||
- **Prowler API, Prowler SDK, and Prowler MCP Server:** The current, unprefixed variable names are deprecated. They continue to work today and will be removed once the prefixed convention is adopted for each component, as described in [Upcoming Breaking Change](#upcoming-breaking-change).
|
||||
@@ -103,7 +103,7 @@ The generic service pattern is described in [service page](/developer-guide/serv
|
||||
- Directly in the code, in location [`prowler/providers/gcp/services/`](https://github.com/prowler-cloud/prowler/tree/master/prowler/providers/gcp/services)
|
||||
- In the [Prowler Hub](https://hub.prowler.com/) for a more human-readable view.
|
||||
|
||||
The best reference to understand how to implement a new service is following the [service implementation documentation](/developer-guide/services#adding-a-new-service) and taking other services already implemented as reference. In next subsection you can find a list of common patterns that are used accross all GCP services.
|
||||
The best reference to understand how to implement a new service is following the [service implementation documentation](/developer-guide/services#adding-a-new-service) and taking other services already implemented as reference. In next subsection you can find a list of common patterns that are used across all GCP services.
|
||||
|
||||
### GCP Service Common Patterns
|
||||
|
||||
@@ -114,7 +114,7 @@ The best reference to understand how to implement a new service is following the
|
||||
- Only projects with the API enabled are included in the audit scope.
|
||||
- Resource discovery and attribute collection can be parallelized using `self.__threading_call__`, typically by region/zone or resource.
|
||||
- All GCP resources are represented as Pydantic `BaseModel` classes, providing type safety and structured access to resource attributes.
|
||||
- Each GCP API calls are wrapped in try/except blocks, always logging errors.
|
||||
- Each GCP API call is wrapped in try/except blocks, always logging errors.
|
||||
- **Retry Configuration**: All `request.execute()` calls must include `num_retries=DEFAULT_RETRY_ATTEMPTS` for automatic retry on rate limiting errors (HTTP 429).
|
||||
- Tags and additional attributes that cannot be retrieved from the default call should be collected and stored for each resource using dedicated methods and threading.
|
||||
|
||||
@@ -162,7 +162,7 @@ When you instantiate `Check_Report_GCP`, you must provide the check metadata and
|
||||
- Defaults to "global" if none are available.
|
||||
|
||||
All these attributes can be overridden by passing the corresponding argument to the constructor. If the resource object does not contain the required attributes, you must set them manually.
|
||||
Others attributes are inherited from the `Check_Report` class, from that ones you **always** have to set the `status` and `status_extended` attributes in the check logic.
|
||||
Other attributes are inherited from the `Check_Report` class, from those you **always** have to set the `status` and `status_extended` attributes in the check logic.
|
||||
|
||||
#### Example Usage
|
||||
|
||||
|
||||
@@ -46,6 +46,9 @@ Prowler is constantly evolving. Contributions to checks, services, or integratio
|
||||
<Card title="Adding New Integrations" icon="link" href="/developer-guide/integrations">
|
||||
Prowler can work with other tools and platforms through integrations.
|
||||
</Card>
|
||||
<Card title="Adding New Attack Paths Queries" icon="diagram-project" href="/developer-guide/attack-paths-queries">
|
||||
Want to detect new privilege escalation or exposure patterns? Contribute read-only openCypher queries that traverse the cloud graph.
|
||||
</Card>
|
||||
<Card title="Proposing or Implementing Features" icon="lightbulb" href="https://github.com/prowler-cloud/prowler/issues/new?template=feature-request.yml">
|
||||
Propose brand-new features or enhancements to existing ones, or help implement community-requested improvements.
|
||||
</Card>
|
||||
@@ -73,7 +76,7 @@ Remember, our community is here to help! If you need guidance, do not hesitate t
|
||||
|
||||
|
||||
|
||||
## Setting up your development environment
|
||||
## Setting Up Your Development Environment
|
||||
|
||||
### Prerequisites
|
||||
|
||||
@@ -241,7 +244,7 @@ prowler/
|
||||
├── README.md # Project overview and getting started
|
||||
├── Makefile # Common development commands
|
||||
├── Dockerfile # SDK Docker container
|
||||
├── docker-compose.yml # Prowler App Docker compose
|
||||
├── docker-compose.yml # Prowler Local Server Docker compose
|
||||
└── ... # Other supporting files
|
||||
```
|
||||
|
||||
|
||||
@@ -133,7 +133,7 @@ The MCP client manages connections to the Prowler MCP Server using a singleton p
|
||||
|
||||
- **Connection Management**: Retry logic with configurable attempts and delays
|
||||
- **Tool Discovery**: Fetches available tools from MCP server on initialization
|
||||
- **Authentication Injection**: Automatically adds JWT tokens to `prowler_app_*` tool calls
|
||||
- **Authentication Injection**: Automatically adds JWT tokens to `prowler_*` tool calls
|
||||
- **Reconnection**: Supports forced reconnection after server restarts
|
||||
|
||||
Key constants:
|
||||
@@ -142,10 +142,14 @@ Key constants:
|
||||
- `RECONNECT_INTERVAL_MS`: 5 minutes before retry after failure
|
||||
|
||||
```typescript
|
||||
// Authentication injection for Prowler App tools
|
||||
// Authentication injection for core prowler_ tools (Hub/Docs excluded)
|
||||
private handleBeforeToolCall = ({ name, args }) => {
|
||||
// Only inject auth for prowler_app_* tools (user-specific data)
|
||||
if (!name.startsWith("prowler_app_")) {
|
||||
// Only inject auth for prowler_* tools (user-specific data).
|
||||
// The legacy prowler_app_ prefix is also accepted for a resilient rollout.
|
||||
if (
|
||||
!name.startsWith("prowler_") &&
|
||||
!name.startsWith("prowler_app_")
|
||||
) {
|
||||
return { args };
|
||||
}
|
||||
|
||||
@@ -308,15 +312,15 @@ MCP tools are organized into three namespaces based on authentication requiremen
|
||||
|
||||
| Namespace | Auth Required | Description |
|
||||
|-----------|---------------|-------------|
|
||||
| `prowler_app_*` | Yes (JWT) | Prowler Cloud/App tools for findings, providers, scans, resources |
|
||||
| `prowler_*` | Yes (JWT) | Prowler Cloud, Prowler Private Cloud, and Prowler Local Server tools for findings, providers, scans, resources |
|
||||
| `prowler_hub_*` | No | Security checks catalog, compliance frameworks |
|
||||
| `prowler_docs_*` | No | Documentation search and retrieval |
|
||||
|
||||
### Authentication Flow
|
||||
|
||||
1. User authenticates with Prowler App, receiving a JWT token
|
||||
1. User authenticates with Prowler Local Server, receiving a JWT token
|
||||
2. Token is stored in session and propagated via `authContextStorage`
|
||||
3. MCP client injects `Authorization: Bearer <token>` header for `prowler_app_*` calls
|
||||
3. MCP client injects `Authorization: Bearer <token>` header for `prowler_*` calls
|
||||
4. MCP Server validates token and applies RLS filtering
|
||||
|
||||
### Tool Execution Pattern
|
||||
@@ -324,7 +328,7 @@ MCP tools are organized into three namespaces based on authentication requiremen
|
||||
The agent uses meta-tools rather than direct tool registration:
|
||||
|
||||
```
|
||||
Agent needs data → describe_tool("prowler_app_search_findings")
|
||||
Agent needs data → describe_tool("prowler_search_findings")
|
||||
→ Returns parameter schema → execute_tool with parameters
|
||||
→ MCP client adds auth header → MCP Server executes
|
||||
→ Results returned to agent → Agent continues reasoning
|
||||
|
||||
@@ -102,4 +102,4 @@ The LLM provider seamlessly integrates with Prowler's existing infrastructure:
|
||||
- **Output Formats**: Supports all Prowler output formats (JSON, CSV, HTML, etc.)
|
||||
- **Compliance Frameworks**: Integrates with Prowler's compliance reporting
|
||||
- **Fixer Integration**: Supports automated remediation recommendations
|
||||
- **Dashboard Integration**: Compatible with Prowler App for centralized management
|
||||
- **Dashboard Integration**: Compatible with Prowler Cloud and Prowler Local Server for centralized management
|
||||
@@ -19,11 +19,15 @@ The Prowler MCP Server brings the entire Prowler ecosystem to AI assistants thro
|
||||
|
||||
The server follows a modular architecture with three independent sub-servers:
|
||||
|
||||
| Sub-Server | Auth Required | Description |
|
||||
|------------|---------------|-------------|
|
||||
| Prowler App | Yes | Full access to Prowler Cloud and Self-Managed features |
|
||||
| Prowler Hub | No | Security checks catalog with **over 1000 checks**, fixers, and **70+ compliance frameworks** |
|
||||
| Prowler Documentation | No | Full-text search and retrieval of official documentation |
|
||||
| Sub-Server | Tool Prefix | Auth Required | Description |
|
||||
|------------|-------------|---------------|-------------|
|
||||
| Prowler | `prowler_` | Yes | Full access to Prowler Cloud, Prowler Private Cloud, and Prowler Local Server features |
|
||||
| Prowler Hub | `prowler_hub_` | No | Security checks catalog with **over 2,000 checks**, fixers, and **70+ compliance frameworks** |
|
||||
| Prowler Documentation | `prowler_docs_` | No | Full-text search and retrieval of official documentation |
|
||||
|
||||
<Note>
|
||||
The core Prowler sub-server is served under the `prowler_` tool prefix, while its source lives in the `prowler_app/` module for historical reasons. Tool names use the prefix; import paths use the module.
|
||||
</Note>
|
||||
|
||||
<Note>
|
||||
For a complete list of tools and their descriptions, see the [Tools Reference](/getting-started/basic-usage/prowler-mcp-tools).
|
||||
@@ -54,9 +58,9 @@ mcp_server/prowler_mcp_server/
|
||||
The MCP Server uses two patterns for tool registration:
|
||||
|
||||
1. **Direct Decorators** (Prowler Hub/Docs): Tools are registered using `@mcp.tool()` decorators
|
||||
2. **Auto-Discovery** (Prowler App): All public methods of `BaseTool` subclasses are auto-registered
|
||||
2. **Auto-Discovery** (`prowler_app`): All public methods of `BaseTool` subclasses are auto-registered
|
||||
|
||||
## Adding Tools to Prowler App
|
||||
## Adding Tools to the `prowler_app` Sub-Server
|
||||
|
||||
### Step 1: Create the Tool Class
|
||||
|
||||
@@ -349,7 +353,7 @@ result = await self.api_client.poll_task_until_complete(
|
||||
|
||||
### Tool Docstrings
|
||||
|
||||
Tool docstrings become description that is going to be read by the LLM. Provide clear usage instructions and common workflows:
|
||||
Tool docstrings become the description that is going to be read by the LLM. Provide clear usage instructions and common workflows:
|
||||
|
||||
```python
|
||||
async def search_items(self, status: str = Field(...)) -> dict:
|
||||
@@ -414,7 +418,7 @@ uv run prowler-mcp
|
||||
uv run prowler-mcp --transport http --host 0.0.0.0 --port 8000
|
||||
|
||||
# Run with environment variables
|
||||
PROWLER_APP_API_KEY="pk_xxx" uv run prowler-mcp
|
||||
PROWLER_API_KEY="pk_xxx" uv run prowler-mcp
|
||||
```
|
||||
|
||||
For complete installation and deployment options, see:
|
||||
@@ -423,6 +427,150 @@ For complete installation and deployment options, see:
|
||||
|
||||
For development I recommend to use the [Model Context Protocol Inspector](https://github.com/modelcontextprotocol/inspector) as MCP client to test and debug your tools.
|
||||
|
||||
## Testing
|
||||
|
||||
Tests live in `mcp_server/tests/`, mirroring the source tree, and use the `test_*.py`
|
||||
prefix (the same convention as the API, not the SDK's `*_test.py` suffix).
|
||||
|
||||
From `mcp_server/`:
|
||||
|
||||
```bash
|
||||
cd mcp_server
|
||||
|
||||
uv run pytest # Whole suite
|
||||
uv run pytest tests/prowler_app/models # One area
|
||||
uv run pytest --cov=./prowler_mcp_server # With coverage
|
||||
```
|
||||
|
||||
From the repository root:
|
||||
|
||||
```bash
|
||||
make test-mcp # Runs the MCP suite exactly as CI does
|
||||
```
|
||||
|
||||
Async tests need no marker — `asyncio_mode` is set to `auto`.
|
||||
|
||||
### Reading the Coverage Numbers
|
||||
|
||||
<Warning>
|
||||
Coverage here has a high floor that means nothing. `coverage.py` measures
|
||||
*statements*, and in a Pydantic model module nearly every statement is a class-body
|
||||
field declaration that runs at **import** time. `prowler_app/server.py` imports
|
||||
every tool module — and therefore every model module — when it is first imported,
|
||||
so all of those declarations execute and count as covered before a single test runs.
|
||||
|
||||
Importing the package and executing no tests at all already reports **36% overall**,
|
||||
with individual model modules between 54% and 84%. A model module sitting at ~68%
|
||||
with no tests written for it has **none** of its behaviour covered: the covered lines
|
||||
are its imports, `class` statements and `Field(...)` declarations, and the missing
|
||||
ranges are its `from_api_response()` bodies.
|
||||
|
||||
Judge a module against that import-only floor, not against zero, and do not set a
|
||||
Codecov target from the raw total.
|
||||
</Warning>
|
||||
|
||||
### Shared Fixtures
|
||||
|
||||
All fixtures live in `mcp_server/tests/conftest.py`. Three are autouse and apply to
|
||||
every test: the environment is pinned to deterministic values, real socket
|
||||
connections are blocked, and the API client singleton registry is snapshotted and
|
||||
restored.
|
||||
|
||||
| Fixture | What it gives you |
|
||||
|---------|-------------------|
|
||||
| `mock_api_client` | The API client singleton with its transport mocked. The workhorse. |
|
||||
| `mock_router` | Route registry and request recorder |
|
||||
| `mcp_root_server` | The mounted root server, for in-memory client tests |
|
||||
| `health_client` | Starlette `TestClient` for the `/health` route |
|
||||
| `http_request_headers` | Injects request headers for HTTP-transport auth tests |
|
||||
| `hub_router` / `docs_router` | Mock the Hub and Docs sub-servers' sync HTTP clients |
|
||||
| `api_client` / `isolated_api_client` | The live singleton / a freshly-constructed one |
|
||||
|
||||
Helpers live in `mcp_server/tests/helpers/`: JSON:API document builders
|
||||
(`jsonapi.py`), the `MockRouter` (`http.py`), tool-contract assertions
|
||||
(`assertions.py`) and fake credentials (`tokens.py`).
|
||||
|
||||
### Writing a Tool Test
|
||||
|
||||
Drive tools through an in-memory MCP client, and open the client inside the test —
|
||||
FastMCP warns that holding a client in a fixture causes event-loop problems.
|
||||
|
||||
```python
|
||||
from fastmcp import Client
|
||||
|
||||
from tests.helpers.jsonapi import jsonapi_collection, jsonapi_resource
|
||||
|
||||
FINDING_ATTRIBUTES = {
|
||||
"uid": "prowler-aws-s3_bucket_public_access-123456789012-us-east-1-my-bucket",
|
||||
"status": "FAIL",
|
||||
"severity": "high",
|
||||
"status_extended": "S3 bucket my-bucket is publicly accessible.",
|
||||
"delta": "new",
|
||||
"muted": False,
|
||||
"muted_reason": None,
|
||||
"check_metadata": {"checkid": "s3_bucket_public_access"},
|
||||
}
|
||||
|
||||
|
||||
async def test_search_without_dates_queries_the_latest_scan_endpoint(
|
||||
mcp_root_server, mock_api_client, mock_router
|
||||
):
|
||||
"""With no date range the tool targets the cheaper `/findings/latest`."""
|
||||
mock_router.add(
|
||||
"GET",
|
||||
"/api/v1/findings/latest",
|
||||
json=jsonapi_collection(
|
||||
[jsonapi_resource("findings", "f1", FINDING_ATTRIBUTES)]
|
||||
),
|
||||
)
|
||||
|
||||
async with Client(mcp_root_server) as client:
|
||||
result = await client.call_tool("prowler_search_security_findings", {})
|
||||
|
||||
assert result.data["findings"][0]["check_id"] == "s3_bucket_public_access"
|
||||
assert mock_router.paths() == ["GET /api/v1/findings/latest"]
|
||||
```
|
||||
|
||||
The exemplar suite covers `findings` end to end — `tests/prowler_app/models/test_findings.py`
|
||||
and `tests/prowler_app/tools/test_findings.py`. It is deliberately one feature
|
||||
across both layers rather than a scattering of unrelated samples, and `findings`
|
||||
is the feature that exercises the whole foundation: two-tier models, nested
|
||||
sub-models, both relationship shapes, endpoint switching on a date range,
|
||||
list-to-CSV filter encoding, and a tool that returns prose instead of a model.
|
||||
|
||||
Note the two files share a name. That is why `__init__.py` is required in every
|
||||
`tests/` subdirectory here — without it they would collide on import.
|
||||
|
||||
<Warning>
|
||||
Tool parameters are declared with pydantic `Field(default=...)`, and only FastMCP's
|
||||
tool wrapper resolves those defaults. Calling a tool method directly with an
|
||||
argument omitted leaves it as a raw `FieldInfo` object, which is truthy — so a
|
||||
filter such as `if email:` silently builds a query out of the `FieldInfo` repr.
|
||||
Call tools through the client, or pass every argument explicitly.
|
||||
</Warning>
|
||||
|
||||
### Why the API Key Is Pinned, Not Stripped
|
||||
|
||||
`prowler_app/server.py` builds every tool at import time. Constructing a tool
|
||||
reaches `ProwlerAppAuth`, which raises when `PROWLER_API_KEY` is missing, and
|
||||
`load_all_tools` swallows that error per tool class. The result is that the whole
|
||||
`prowler_*` namespace registers **zero** tools while the server still logs
|
||||
"Successfully mounted Prowler tools server".
|
||||
|
||||
The suite therefore pins a fake key in `[tool.pytest_env]`, which is applied before
|
||||
any test module is imported, and `tests/test_server.py` asserts each namespace is
|
||||
non-empty so this failure can never return silently.
|
||||
|
||||
<Note>
|
||||
`ProwlerAppAuth` resolves `PROWLER_MCP_TRANSPORT_MODE` and `API_BASE_URL` in its
|
||||
default arguments, which Python evaluates once at module import. `monkeypatch.setenv`
|
||||
cannot change them — pass `mode=` and `base_url=` explicitly in auth tests.
|
||||
</Note>
|
||||
|
||||
For the full set of rules and templates, see the
|
||||
[`prowler-test-mcp` skill](https://github.com/prowler-cloud/prowler/blob/master/skills/prowler-test-mcp/SKILL.md)
|
||||
and the [official FastMCP testing guide](https://gofastmcp.com/development/tests).
|
||||
|
||||
## Related Documentation
|
||||
|
||||
<CardGroup cols={2}>
|
||||
|
||||
@@ -32,7 +32,7 @@ Before implementing a new provider, you need to determine which type it belongs
|
||||
|
||||
#### Decision Criteria
|
||||
|
||||
Once you have decided the provider you want or need to add to Prowler, the next step is to study how to retrieve data from it. Based on that, the provider will fall into one of the following types: SDK, API or Tool/Wrapper (maybe in the future there will be new types but for now this are the only ones).
|
||||
Once you have decided the provider you want or need to add to Prowler, the next step is to study how to retrieve data from it. Based on that, the provider will fall into one of the following types: SDK, API or Tool/Wrapper (maybe in the future there will be new types but for now these are the only ones).
|
||||
|
||||
**Choose SDK Provider if:**
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@ description: 'Prowler Studio is a Claude Code workflow that generates consistent
|
||||
**Prowler Studio is an AI workflow that ensures Claude Code follows Prowler's skills, guardrails, and best practices when creating new security checks.** What lands in the resulting pull request is consistent, tested, and ready for human review — not half-correct boilerplate that needs to be rewritten.
|
||||
|
||||
<Info>
|
||||
**Contributor Tool**: Prowler Studio is a workflow for advanced contributors adding new Prowler security checks. It is not part of Prowler Cloud, Prowler App, or Prowler CLI.
|
||||
**Contributor Tool**: Prowler Studio is a workflow for advanced contributors adding new Prowler security checks. It is not part of Prowler Cloud, Prowler Local Server, or Prowler CLI.
|
||||
</Info>
|
||||
|
||||
<Warning>
|
||||
|
||||
@@ -267,7 +267,7 @@ Every legacy compliance file is a JSON document with the following top-level key
|
||||
| Field | Type | Required | Description |
|
||||
|---|---|---|---|
|
||||
| `Framework` | string | Yes | Canonical framework identifier, for example `CIS`, `NIST-800-53-Revision-5`, `ENS`, `CCC`. |
|
||||
| `Name` | string | Yes | Human-readable framework name displayed by Prowler App. |
|
||||
| `Name` | string | Yes | Human-readable framework name displayed by Prowler Cloud and Prowler Local Server. |
|
||||
| `Version` | string | Yes (recommended) | Framework version, e.g. `2.0`. See [Version Handling](#version-handling). |
|
||||
| `Provider` | string | Yes | Upper-cased provider identifier: `AWS`, `AZURE`, `GCP`, `KUBERNETES`, `M365`, `GITHUB`, `GOOGLEWORKSPACE`, and so on. |
|
||||
| `Description` | string | Yes | Short description of the framework's scope and purpose. |
|
||||
@@ -536,7 +536,7 @@ Each entry in the list is a single constraint with the following fields:
|
||||
|
||||
### How guardrails are evaluated
|
||||
|
||||
All evaluation lives in one shared module, `prowler/lib/check/compliance_config_eval.py`, consumed by every compliance output (CSV, OCSF, and the CLI tables) and reused by the Prowler App backend so the rule is defined exactly once.
|
||||
All evaluation lives in one shared module, `prowler/lib/check/compliance_config_eval.py`, consumed by every compliance output (CSV, OCSF, and the CLI tables) and reused by the Prowler API backend so the rule is defined exactly once.
|
||||
|
||||
1. The applied configuration is the scan-global `audit_config` (the same mapping for every resource and region), resolved via `get_scan_audit_config()`.
|
||||
2. For each requirement that declares constraints, `evaluate_config_constraints()` walks the list and returns `(is_compliant, reason)`. The requirement is compliant when **every** explicitly-set key satisfies its constraint.
|
||||
@@ -659,7 +659,7 @@ uv run pytest -n auto \
|
||||
tests/lib/outputs/compliance/
|
||||
```
|
||||
|
||||
## Version handling
|
||||
## Version Handling
|
||||
|
||||
Prowler matches frameworks by concatenating `Framework` and `Version`. A missing or empty `Version` collapses several frameworks to the same key and breaks CLI filtering with `--compliance`.
|
||||
|
||||
@@ -737,9 +737,9 @@ Open the generated CSV and confirm:
|
||||
- Every requirement has at least one row per scanned resource (when there are findings).
|
||||
- Attribute values such as `Requirements_Attributes_Section` reflect the JSON content.
|
||||
|
||||
### 5. Verify the framework in Prowler App
|
||||
### 5. Verify the Framework in Prowler Local Server
|
||||
|
||||
Launch Prowler App locally (`docker compose up` from the repository root) and run a scan with the new compliance framework. Confirm the compliance page renders the requirements, sections, and status widgets correctly.
|
||||
Launch Prowler Local Server (`docker compose up` from the repository root) and run a scan with the new compliance framework. Confirm the compliance page renders the requirements, sections, and status widgets correctly.
|
||||
|
||||
## Testing
|
||||
|
||||
@@ -757,7 +757,7 @@ uv run pytest -n auto tests/lib/check/universal_compliance_models_test.py \
|
||||
|
||||
For guidance on writing Prowler SDK tests, refer to [Unit Testing](/developer-guide/unit-testing).
|
||||
|
||||
## Running and listing your framework
|
||||
## Running and Listing Your Framework
|
||||
|
||||
Once the file is in place, the CLI auto-discovers it:
|
||||
|
||||
@@ -770,7 +770,7 @@ prowler <provider> --compliance <framework_key> --list-compliance-requirements <
|
||||
|
||||
For end-user-facing tutorials (recommended for high-profile frameworks), add a dedicated page under `docs/user-guide/compliance/tutorials/` and register it in the `"Compliance"` group of `docs/docs.json`. See `docs/user-guide/compliance/tutorials/threatscore.mdx` as a reference.
|
||||
|
||||
## Submitting the pull request
|
||||
## Submitting the Pull Request
|
||||
|
||||
Before opening the pull request:
|
||||
|
||||
@@ -795,7 +795,7 @@ The following issues are the most common when contributing a compliance framewor
|
||||
- **CSV file is missing after the scan (legacy).** The transformer class is not registered in `prowler/lib/outputs/compliance/compliance_output.py`, or `transform()` raises silently. Run the scan with `--log-level DEBUG`.
|
||||
- **Findings do not roll up under a requirement.** A check listed in `Checks` either does not exist for that provider or is spelled incorrectly. Run `--list-checks | grep <check_name>` to confirm, or run the check-existence cross-check from "Validating Your Framework".
|
||||
|
||||
## Reference examples
|
||||
## Reference Examples
|
||||
|
||||
Use the following files as templates when modeling a new contribution.
|
||||
|
||||
|
||||
@@ -10,7 +10,7 @@ First ensure that the provider you want to add the service is already created. I
|
||||
</Note>
|
||||
## Introduction
|
||||
|
||||
In Prowler, a **service** represents a specific solution or resource offered by one of the supported [Prowler Providers](/developer-guide/provider), for example, [EC2](https://aws.amazon.com/ec2/) in AWS, or [Microsoft Exchange](https://www.microsoft.com/en-us/microsoft-365/exchange/exchange-online) in M365. Services are the building blocks that allow Prowler interact directly with the various resources exposed by each provider.
|
||||
In Prowler, a **service** represents a specific solution or resource offered by one of the supported [Prowler Providers](/developer-guide/provider), for example, [EC2](https://aws.amazon.com/ec2/) in AWS, or [Microsoft Exchange](https://www.microsoft.com/en-us/microsoft-365/exchange/exchange-online) in M365. Services are the building blocks that allow Prowler to interact directly with the various resources exposed by each provider.
|
||||
|
||||
Each service is implemented as a class that encapsulates all the logic, data models, and API interactions required to gather and store information about that service's resources. All of this data is used by the [Prowler checks](/developer-guide/checks) to generate the security findings.
|
||||
|
||||
@@ -22,9 +22,9 @@ Within this folder the following files are also to be created:
|
||||
|
||||
- `__init__.py` (empty) – Ensures Python recognizes this folder as a package.
|
||||
- `<new_service_name>_service.py` – Contains all the logic and API calls of the service.
|
||||
- `<new_service_name>_client_.py` – Contains the initialization of the freshly created service's class so that the checks can use it.
|
||||
- `<new_service_name>_client.py` – Contains the initialization of the freshly created service's class so that the checks can use it.
|
||||
|
||||
Once the files are create, you can check that the service has been created by running the following command: `uv run python prowler-cli.py <provider> --list-services | grep <new_service_name>`.
|
||||
Once the files are created, you can check that the service has been created by running the following command: `uv run python prowler-cli.py <provider> --list-services | grep <new_service_name>`.
|
||||
|
||||
## Service Structure and Initialisation
|
||||
|
||||
@@ -32,7 +32,7 @@ The Prowler's service structure is as outlined below. To initialise it, just imp
|
||||
|
||||
### Service Base Class
|
||||
|
||||
All Prowler provider service should inherit from a common base class to avoid code duplication. This base class handles initialization and storage of functions and objects needed across services. The exact implementation depends on the provider's API requirements, but the following are the most common responsibilities:
|
||||
All Prowler provider services should inherit from a common base class to avoid code duplication. This base class handles initialization and storage of functions and objects needed across services. The exact implementation depends on the provider's API requirements, but the following are the most common responsibilities:
|
||||
|
||||
- Initialize/store clients to interact with the provider's API.
|
||||
- Store the audit and fixer configuration.
|
||||
|
||||
@@ -60,7 +60,7 @@ StackIT uses service account keys for API authentication. Service account keys a
|
||||
1. **Navigate to Service Accounts**
|
||||
- Go to the [StackIT Portal](https://portal.stackit.cloud/)
|
||||
- Select your project
|
||||
- Click on **Service Accounts** in the left sidebar
|
||||
- Click **Service Accounts** in the left sidebar
|
||||
|
||||
2. **Create or Select Service Account**
|
||||
- If you don't have a service account, click **Create Service Account**
|
||||
|
||||
@@ -0,0 +1,123 @@
|
||||
<p align="center">
|
||||
<img src="https://raw.githubusercontent.com/prowler-cloud/prowler/master/docs/dockerhub/prowler-logo.svg" width="252" alt="Prowler">
|
||||
</p>
|
||||
<p align="center">
|
||||
<b>Prowler</b> is the Open Cloud Security platform trusted by thousands to automate security and compliance in any cloud environment — AWS, Azure, Google Cloud, Kubernetes, M365, GitHub and more.
|
||||
</p>
|
||||
<p align="center">
|
||||
<b>Learn more at <a href="https://prowler.com">prowler.com</a> · <a href="https://goto.prowler.com/slack">Join our Slack community</a></b>
|
||||
</p>
|
||||
|
||||
<p align="center">
|
||||
<a href="https://github.com/prowler-cloud/prowler"><img alt="GitHub" src="https://img.shields.io/github/stars/prowler-cloud/prowler?style=social"></a>
|
||||
<a href="https://github.com/prowler-cloud/prowler/releases"><img alt="Version" src="https://img.shields.io/github/v/release/prowler-cloud/prowler"></a>
|
||||
<a href="https://pypi.org/project/prowler/"><img alt="PyPI" src="https://img.shields.io/pypi/v/prowler.svg"></a>
|
||||
<a href="https://github.com/prowler-cloud/prowler"><img alt="License" src="https://img.shields.io/github/license/prowler-cloud/prowler"></a>
|
||||
</p>
|
||||
|
||||
---
|
||||
|
||||
# Prowler container images
|
||||
|
||||
All Prowler images are built from a single repository — [github.com/prowler-cloud/prowler](https://github.com/prowler-cloud/prowler) — and published together on every release.
|
||||
|
||||
| Image | What it is | Dockerfile |
|
||||
|---|---|---|
|
||||
| [`prowlercloud/prowler`](https://hub.docker.com/r/prowlercloud/prowler) | **Prowler CLI.** Runs scans from your terminal, a CI job, a Kubernetes Job or any container platform. | [`Dockerfile`](https://github.com/prowler-cloud/prowler/blob/master/Dockerfile) |
|
||||
| [`prowlercloud/prowler-api`](https://hub.docker.com/r/prowlercloud/prowler-api) | **Prowler Local Server — API.** Django REST backend plus the Celery worker and scheduler that run scans and store results. | [`api/Dockerfile`](https://github.com/prowler-cloud/prowler/blob/master/api/Dockerfile) |
|
||||
| [`prowlercloud/prowler-ui`](https://hub.docker.com/r/prowlercloud/prowler-ui) | **Prowler Local Server — UI.** Next.js web interface for launching scans and exploring findings. | [`ui/Dockerfile`](https://github.com/prowler-cloud/prowler/blob/master/ui/Dockerfile) |
|
||||
| [`prowlercloud/prowler-mcp`](https://hub.docker.com/r/prowlercloud/prowler-mcp) | **Prowler MCP.** Gives AI assistants access to the Prowler ecosystem over the Model Context Protocol. | [`mcp_server/Dockerfile`](https://github.com/prowler-cloud/prowler/blob/master/mcp_server/Dockerfile) |
|
||||
| [`toniblyx/prowler`](https://hub.docker.com/r/toniblyx/prowler) | **Legacy home of the Prowler CLI image.** Still mirrored on every release for backwards compatibility. New deployments should use `prowlercloud/prowler`. | [`Dockerfile`](https://github.com/prowler-cloud/prowler/blob/master/Dockerfile) |
|
||||
|
||||
All images are published for `linux/amd64` and `linux/arm64`.
|
||||
|
||||
## Tags
|
||||
|
||||
| Tag | Meaning |
|
||||
|---|---|
|
||||
| `stable` | Always points to the latest stable release. **Recommended for production.** |
|
||||
| `<x.y.z>` | A specific release, e.g. `5.14.0`. Immutable. |
|
||||
| `latest` | Built from the `master` branch on every merge. Not a stable version. |
|
||||
| `<short-sha>` | A specific `master` commit (`prowler-api`, `prowler-ui` and `prowler-mcp` only). |
|
||||
|
||||
`v3-*` and `v4-*` tags on `prowlercloud/prowler` are frozen historical artifacts of Prowler v3/v4 and no longer receive updates.
|
||||
|
||||
## Other registries
|
||||
|
||||
The Prowler CLI image is also available on AWS Public ECR: [`public.ecr.aws/prowler-cloud/prowler`](https://gallery.ecr.aws/prowler-cloud/prowler).
|
||||
|
||||
---
|
||||
|
||||
# Quick start
|
||||
|
||||
## Prowler Local Server (UI + API)
|
||||
|
||||
```console
|
||||
curl -LO https://raw.githubusercontent.com/prowler-cloud/prowler/refs/heads/master/docker-compose.yml
|
||||
curl -LO https://raw.githubusercontent.com/prowler-cloud/prowler/refs/heads/master/.env
|
||||
docker compose up -d
|
||||
```
|
||||
|
||||
Then open http://localhost:3000 and sign up with your email and password.
|
||||
|
||||
Full guide: [Prowler Local Server installation](https://docs.prowler.com/getting-started/installation/prowler-app)
|
||||
|
||||
## Prowler CLI
|
||||
|
||||
```console
|
||||
docker run -ti --rm \
|
||||
-v /your/local/dir/prowler-output:/home/prowler/output \
|
||||
--name prowler \
|
||||
--env AWS_ACCESS_KEY_ID \
|
||||
--env AWS_SECRET_ACCESS_KEY \
|
||||
--env AWS_SESSION_TOKEN \
|
||||
prowlercloud/prowler:stable aws
|
||||
```
|
||||
|
||||
Swap `aws` for `azure`, `gcp`, `kubernetes`, `m365` or `github` to scan another provider. The CLI is also on PyPI: `pip install prowler`.
|
||||
|
||||
Full guide: [Prowler CLI installation](https://docs.prowler.com/getting-started/installation/prowler-cli)
|
||||
|
||||
## Prowler MCP
|
||||
|
||||
```console
|
||||
# STDIO mode (for local MCP clients)
|
||||
docker run --rm -i prowlercloud/prowler-mcp
|
||||
|
||||
# HTTP mode (for remote access)
|
||||
docker run --rm -p 8000:8000 prowlercloud/prowler-mcp \
|
||||
--transport http --host 0.0.0.0 --port 8000
|
||||
```
|
||||
|
||||
Full guide: [Prowler MCP installation](https://docs.prowler.com/getting-started/installation/prowler-mcp)
|
||||
|
||||
> **Note on architecture:** if your workstation's architecture is incompatible, set `DOCKER_DEFAULT_PLATFORM=linux/amd64` or pass `--platform linux/amd64` to your Docker command.
|
||||
|
||||
---
|
||||
|
||||
# What Prowler covers
|
||||
|
||||
Hundreds of built-in checks mapped to the frameworks you get audited against — CIS, NIST 800 / CSF, CISA, PCI-DSS, GDPR, HIPAA, FFIEC, SOC2, GXP, FedRAMP, RBI, AWS Well-Architected (Security Pillar), AWS FTR, ENS — plus your own custom frameworks.
|
||||
|
||||
For live check, service, framework and category counts, see [**Prowler Hub**](https://hub.prowler.com).
|
||||
|
||||
List what's available for any provider:
|
||||
|
||||
```console
|
||||
prowler <provider> --list-checks
|
||||
prowler <provider> --list-services
|
||||
prowler <provider> --list-compliance
|
||||
prowler <provider> --list-categories
|
||||
```
|
||||
|
||||
# Documentation and support
|
||||
|
||||
- **Documentation:** [docs.prowler.com](https://docs.prowler.com/)
|
||||
- **Source:** [github.com/prowler-cloud/prowler](https://github.com/prowler-cloud/prowler)
|
||||
- **Issues:** [github.com/prowler-cloud/prowler/issues](https://github.com/prowler-cloud/prowler/issues)
|
||||
- **Community:** [Prowler Slack](https://goto.prowler.com/slack)
|
||||
- **Troubleshooting:** [docs.prowler.com/troubleshooting](https://docs.prowler.com/troubleshooting)
|
||||
|
||||
# License
|
||||
|
||||
Prowler is licensed under the Apache License 2.0. A copy is available at http://www.apache.org/licenses/LICENSE-2.0.
|
||||
@@ -0,0 +1,7 @@
|
||||
<svg xmlns="http://www.w3.org/2000/svg" width="252" height="78.2" viewBox="0 0 252 78.2" role="img" aria-label="Prowler">
|
||||
<title>Prowler</title>
|
||||
<rect width="252" height="78.2" rx="10" fill="#0C0A09"/>
|
||||
<g transform="translate(26 22.5) scale(0.1621179084)" fill="#ffffff">
|
||||
<path d="M1169.38,132.04c20.76-12.21,34.44-34.9,34.44-59.79,0-38.18-31.06-69.25-69.25-69.25l-216.9.23v145.17h-64.8V3h-79.95s-47.14,95.97-47.14,95.97V3h-52.09s-47.14,95.97-47.14,95.97V3h-53.48v69.6C560.37,30.64,521.34,0,475.28,0c-42.63,0-79.24,26.25-94.54,63.43-4.35-34.03-33.48-60.43-68.67-60.43h-100.01v47.43C202.9,22.91,176.91,3,146.35,3H0s46.34,46.33,46.34,46.33v151.64h53.47v-76.68l17.21,17.21h29.33c30.56,0,56.54-19.91,65.71-47.43v106.91h53.48v-81.51l76.01,81.51h69.62l-64.29-68.94c11.14-6.56,20.22-16.15,26.26-27.46,1.27,55.26,46.58,99.82,102.14,99.82,46.06,0,85.09-30.64,97.81-72.6v69.18h60.88l38.34-78.06v78.06h60.88l66.2-134.78v135.69h95.41l22.86-22.86v22.86h95.05l21.84-21.84v20.93h53.48v-81.5l76.01,81.5h69.62l-64.29-68.94ZM146.35,88.02h-46.54v-31.54h46.54c8.7,0,15.77,7.07,15.77,15.77s-7.07,15.77-15.77,15.77ZM312.07,88.02l-46.54-.18v-31.36h46.54c8.7,0,15.77,7.07,15.77,15.77s-7.08,15.77-15.77,15.77ZM475.28,150.92c-26.86,0-48.72-21.86-48.72-48.72s21.86-48.72,48.72-48.72,48.72,21.86,48.72,48.72-21.86,48.72-48.72,48.72ZM1034.56,148.41h-63.41v-20.35h42.91v-50.88h-42.91v-20.46h63.41v91.69ZM1134.57,88.02l-46.54-.18v-31.36h46.54c8.7,0,15.77,7.07,15.77,15.77s-7.07,15.77-15.77,15.77Z"/>
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 1.5 KiB |
@@ -38,61 +38,90 @@
|
||||
{
|
||||
"group": "Welcome",
|
||||
"pages": [
|
||||
"introduction"
|
||||
"introduction",
|
||||
"getting-started/products/index"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Prowler Cloud",
|
||||
"group": "Prowler Products",
|
||||
"pages": [
|
||||
"getting-started/products/prowler-cloud",
|
||||
"getting-started/products/prowler-cloud-pricing",
|
||||
"getting-started/products/prowler-cloud-aws-marketplace",
|
||||
"getting-started/goto/prowler-cloud",
|
||||
"getting-started/goto/prowler-api-reference"
|
||||
{
|
||||
"group": "Prowler Cloud",
|
||||
"pages": [
|
||||
"getting-started/products/prowler-cloud",
|
||||
"getting-started/products/prowler-cloud-pricing",
|
||||
"getting-started/products/prowler-cloud-aws-marketplace",
|
||||
"getting-started/goto/prowler-cloud",
|
||||
"getting-started/goto/prowler-api-reference"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Prowler Lighthouse AI",
|
||||
"pages": [
|
||||
"getting-started/products/prowler-cloud-lighthouse"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Prowler Hub",
|
||||
"pages": [
|
||||
"getting-started/products/prowler-hub",
|
||||
"getting-started/goto/prowler-hub"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Prowler MCP",
|
||||
"pages": [
|
||||
"getting-started/products/prowler-mcp",
|
||||
"getting-started/basic-usage/prowler-mcp",
|
||||
"getting-started/basic-usage/prowler-mcp-tools",
|
||||
"getting-started/installation/prowler-mcp"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Prowler for AI Agents",
|
||||
"pages": [
|
||||
"user-guide/ai-agents/index",
|
||||
"user-guide/ai-agents/claude-code",
|
||||
"user-guide/ai-agents/claude-desktop",
|
||||
"user-guide/ai-agents/codex",
|
||||
"user-guide/ai-agents/cursor",
|
||||
"user-guide/ai-agents/vscode"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Prowler for MSPs and MSSPs",
|
||||
"pages": [
|
||||
"getting-started/products/prowler-for-msps",
|
||||
"user-guide/tutorials/prowler-for-msps-sign-up",
|
||||
"user-guide/tutorials/prowler-for-msps-organization",
|
||||
"user-guide/tutorials/prowler-for-msps-team",
|
||||
"user-guide/tutorials/prowler-for-msps-customers",
|
||||
"user-guide/tutorials/prowler-for-msps-billing",
|
||||
"user-guide/tutorials/prowler-for-msps-branding"
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Prowler CLI",
|
||||
"group": "Open Source",
|
||||
"pages": [
|
||||
"getting-started/products/prowler-cli",
|
||||
"getting-started/installation/prowler-cli",
|
||||
"getting-started/basic-usage/prowler-cli"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Prowler App",
|
||||
"pages": [
|
||||
"getting-started/products/prowler-app",
|
||||
"getting-started/installation/prowler-app",
|
||||
"getting-started/basic-usage/prowler-app"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Prowler Lighthouse AI",
|
||||
"pages": [
|
||||
"getting-started/products/prowler-cloud-lighthouse"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Prowler for Claude Code",
|
||||
"pages": [
|
||||
"getting-started/products/prowler-claude-code-plugin"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Prowler MCP Server",
|
||||
"pages": [
|
||||
"getting-started/products/prowler-mcp",
|
||||
"getting-started/installation/prowler-mcp",
|
||||
"getting-started/basic-usage/prowler-mcp",
|
||||
"getting-started/basic-usage/prowler-mcp-tools"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Prowler Hub",
|
||||
"pages": [
|
||||
"getting-started/products/prowler-hub",
|
||||
"getting-started/goto/prowler-hub"
|
||||
{
|
||||
"group": "Prowler CLI",
|
||||
"pages": [
|
||||
"getting-started/products/prowler-cli",
|
||||
"getting-started/installation/prowler-cli",
|
||||
"getting-started/basic-usage/prowler-cli"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Prowler Local Server",
|
||||
"pages": [
|
||||
"getting-started/products/prowler-app",
|
||||
"getting-started/installation/prowler-app",
|
||||
"getting-started/basic-usage/prowler-app"
|
||||
]
|
||||
},
|
||||
"getting-started/products/prowler-sdk"
|
||||
]
|
||||
},
|
||||
{
|
||||
@@ -111,35 +140,45 @@
|
||||
"tab": "Guides",
|
||||
"groups": [
|
||||
{
|
||||
"group": "Prowler Cloud/App",
|
||||
"group": "Prowler Cloud",
|
||||
"pages": [
|
||||
"user-guide/tutorials/prowler-app",
|
||||
{
|
||||
"group": "Authentication",
|
||||
"group": "Authentication & Access",
|
||||
"pages": [
|
||||
"user-guide/tutorials/prowler-app-api-keys",
|
||||
"user-guide/tutorials/prowler-app-multi-tenant",
|
||||
"user-guide/tutorials/prowler-app-sso",
|
||||
"user-guide/tutorials/prowler-app-social-login",
|
||||
"user-guide/tutorials/prowler-app-sso"
|
||||
"user-guide/tutorials/prowler-app-rbac"
|
||||
]
|
||||
},
|
||||
"user-guide/tutorials/prowler-app-rbac",
|
||||
"user-guide/tutorials/prowler-app-multi-tenant",
|
||||
"user-guide/tutorials/prowler-app-api-keys",
|
||||
"user-guide/tutorials/prowler-import-findings",
|
||||
"user-guide/tutorials/prowler-scan-scheduling",
|
||||
"user-guide/tutorials/prowler-alerts",
|
||||
"user-guide/tutorials/prowler-app-scan-configuration",
|
||||
"user-guide/tutorials/prowler-app-findings-triage",
|
||||
{
|
||||
"group": "Mutelist",
|
||||
"expanded": true,
|
||||
"group": "Attack Paths",
|
||||
"pages": [
|
||||
"user-guide/tutorials/prowler-app-simple-mutelist",
|
||||
"user-guide/tutorials/prowler-app-mute-findings"
|
||||
"user-guide/tutorials/prowler-app-attack-paths",
|
||||
"user-guide/tutorials/prowler-app-attack-paths-active-queries"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Compliance",
|
||||
"pages": [
|
||||
"user-guide/compliance/tutorials/compliance",
|
||||
"user-guide/compliance/tutorials/cross-provider-type-compliance",
|
||||
"user-guide/compliance/tutorials/cross-provider-compliance",
|
||||
"user-guide/compliance/tutorials/threatscore"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Findings",
|
||||
"pages": [
|
||||
"user-guide/tutorials/prowler-alerts",
|
||||
"user-guide/tutorials/prowler-app-finding-groups",
|
||||
"user-guide/tutorials/prowler-app-findings-triage"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Integrations",
|
||||
"expanded": true,
|
||||
"pages": [
|
||||
"user-guide/tutorials/prowler-app-s3-integration",
|
||||
"user-guide/tutorials/prowler-app-security-hub-integration",
|
||||
@@ -147,40 +186,80 @@
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "AWS Organizations",
|
||||
"expanded": true,
|
||||
"group": "Mutelist",
|
||||
"pages": [
|
||||
"user-guide/tutorials/prowler-cloud-aws-organizations"
|
||||
"user-guide/tutorials/prowler-app-mute-findings",
|
||||
"user-guide/tutorials/prowler-app-simple-mutelist"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Lighthouse AI (Prowler Cloud)",
|
||||
"group": "Providers",
|
||||
"pages": [
|
||||
"user-guide/tutorials/prowler-cloud-aws-organizations",
|
||||
"user-guide/tutorials/prowler-cloud-azure-management-groups",
|
||||
"user-guide/tutorials/prowler-cloud-gcp-organizations"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Scans",
|
||||
"pages": [
|
||||
"user-guide/tutorials/prowler-app-scan-configuration",
|
||||
"user-guide/tutorials/prowler-import-findings",
|
||||
"user-guide/tutorials/prowler-scan-scheduling"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Tutorials",
|
||||
"pages": [
|
||||
"user-guide/tutorials/aws-organizations-bulk-provisioning",
|
||||
"user-guide/tutorials/bulk-provider-provisioning",
|
||||
"user-guide/tutorials/prowler-app-sso-entra",
|
||||
"user-guide/tutorials/prowler-app-sso-google-workspace"
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Prowler for MSPs and MSSPs",
|
||||
"pages": [
|
||||
"user-guide/tutorials/prowler-for-msps-sign-up",
|
||||
"user-guide/tutorials/prowler-for-msps-organization",
|
||||
"user-guide/tutorials/prowler-for-msps-team",
|
||||
"user-guide/tutorials/prowler-for-msps-customers",
|
||||
"user-guide/tutorials/prowler-for-msps-billing",
|
||||
"user-guide/tutorials/prowler-for-msps-branding"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Prowler Lighthouse AI",
|
||||
"pages": [
|
||||
{
|
||||
"group": "Prowler Cloud",
|
||||
"pages": [
|
||||
"user-guide/tutorials/prowler-cloud-lighthouse-multi-llm"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Lighthouse AI (Open Source)",
|
||||
"group": "Prowler Local Server",
|
||||
"pages": [
|
||||
"getting-started/products/prowler-lighthouse-ai",
|
||||
"user-guide/tutorials/prowler-app-lighthouse",
|
||||
"user-guide/tutorials/prowler-app-lighthouse-multi-llm"
|
||||
]
|
||||
},
|
||||
"user-guide/tutorials/prowler-app-attack-paths",
|
||||
"user-guide/tutorials/prowler-app-finding-groups",
|
||||
"user-guide/tutorials/prowler-cloud-public-ips",
|
||||
{
|
||||
"group": "Tutorials",
|
||||
"pages": [
|
||||
"user-guide/tutorials/prowler-app-sso-entra",
|
||||
"user-guide/tutorials/prowler-app-sso-google-workspace",
|
||||
"user-guide/tutorials/bulk-provider-provisioning",
|
||||
"user-guide/tutorials/aws-organizations-bulk-provisioning"
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Prowler for AI Agents",
|
||||
"pages": [
|
||||
"user-guide/ai-agents/index",
|
||||
"user-guide/ai-agents/claude-code",
|
||||
"user-guide/ai-agents/claude-desktop",
|
||||
"user-guide/ai-agents/codex",
|
||||
"user-guide/ai-agents/cursor",
|
||||
"user-guide/ai-agents/vscode"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "CI/CD",
|
||||
"pages": [
|
||||
@@ -222,6 +301,13 @@
|
||||
{
|
||||
"group": "Providers",
|
||||
"pages": [
|
||||
{
|
||||
"group": "Alibaba Cloud",
|
||||
"pages": [
|
||||
"user-guide/providers/alibabacloud/getting-started-alibabacloud",
|
||||
"user-guide/providers/alibabacloud/authentication"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "AWS",
|
||||
"pages": [
|
||||
@@ -249,6 +335,27 @@
|
||||
"user-guide/providers/azure/create-prowler-service-principal"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Cloudflare",
|
||||
"pages": [
|
||||
"user-guide/providers/cloudflare/getting-started-cloudflare",
|
||||
"user-guide/providers/cloudflare/authentication"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "E2E Networks",
|
||||
"pages": [
|
||||
"user-guide/providers/e2enetworks/getting-started-e2enetworks",
|
||||
"user-guide/providers/e2enetworks/authentication"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "GitHub",
|
||||
"pages": [
|
||||
"user-guide/providers/github/getting-started-github",
|
||||
"user-guide/providers/github/authentication"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Google Cloud",
|
||||
"pages": [
|
||||
@@ -260,10 +367,31 @@
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Alibaba Cloud",
|
||||
"group": "Google Workspace",
|
||||
"pages": [
|
||||
"user-guide/providers/alibabacloud/getting-started-alibabacloud",
|
||||
"user-guide/providers/alibabacloud/authentication"
|
||||
"user-guide/providers/googleworkspace/getting-started-googleworkspace",
|
||||
"user-guide/providers/googleworkspace/authentication"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Huawei Cloud",
|
||||
"pages": [
|
||||
"user-guide/providers/huaweicloud/getting-started-huaweicloud",
|
||||
"user-guide/providers/huaweicloud/authentication"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "IaC",
|
||||
"pages": [
|
||||
"user-guide/providers/iac/getting-started-iac",
|
||||
"user-guide/providers/iac/authentication"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Image",
|
||||
"pages": [
|
||||
"user-guide/providers/image/getting-started-image",
|
||||
"user-guide/providers/image/authentication"
|
||||
]
|
||||
},
|
||||
{
|
||||
@@ -273,6 +401,19 @@
|
||||
"user-guide/providers/kubernetes/misc"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Linode",
|
||||
"pages": [
|
||||
"user-guide/providers/linode/getting-started-linode",
|
||||
"user-guide/providers/linode/authentication"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "LLM",
|
||||
"pages": [
|
||||
"user-guide/providers/llm/getting-started-llm"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Microsoft 365",
|
||||
"pages": [
|
||||
@@ -281,27 +422,6 @@
|
||||
"user-guide/providers/microsoft365/use-of-powershell"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Google Workspace",
|
||||
"pages": [
|
||||
"user-guide/providers/googleworkspace/getting-started-googleworkspace",
|
||||
"user-guide/providers/googleworkspace/authentication"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "GitHub",
|
||||
"pages": [
|
||||
"user-guide/providers/github/getting-started-github",
|
||||
"user-guide/providers/github/authentication"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "IaC",
|
||||
"pages": [
|
||||
"user-guide/providers/iac/getting-started-iac",
|
||||
"user-guide/providers/iac/authentication"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "MongoDB Atlas",
|
||||
"pages": [
|
||||
@@ -310,30 +430,11 @@
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Cloudflare",
|
||||
"group": "Okta",
|
||||
"pages": [
|
||||
"user-guide/providers/cloudflare/getting-started-cloudflare",
|
||||
"user-guide/providers/cloudflare/authentication"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Image",
|
||||
"pages": [
|
||||
"user-guide/providers/image/getting-started-image",
|
||||
"user-guide/providers/image/authentication"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "LLM",
|
||||
"pages": [
|
||||
"user-guide/providers/llm/getting-started-llm"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Oracle Cloud Infrastructure",
|
||||
"pages": [
|
||||
"user-guide/providers/oci/getting-started-oci",
|
||||
"user-guide/providers/oci/authentication"
|
||||
"user-guide/providers/okta/getting-started-okta",
|
||||
"user-guide/providers/okta/authentication",
|
||||
"user-guide/providers/okta/retry-configuration"
|
||||
]
|
||||
},
|
||||
{
|
||||
@@ -343,6 +444,13 @@
|
||||
"user-guide/providers/openstack/authentication"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Oracle Cloud Infrastructure",
|
||||
"pages": [
|
||||
"user-guide/providers/oci/getting-started-oci",
|
||||
"user-guide/providers/oci/authentication"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Scaleway",
|
||||
"pages": [
|
||||
@@ -363,38 +471,9 @@
|
||||
"user-guide/providers/vercel/getting-started-vercel",
|
||||
"user-guide/providers/vercel/authentication"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Okta",
|
||||
"pages": [
|
||||
"user-guide/providers/okta/getting-started-okta",
|
||||
"user-guide/providers/okta/authentication",
|
||||
"user-guide/providers/okta/retry-configuration"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Linode",
|
||||
"pages": [
|
||||
"user-guide/providers/linode/getting-started-linode",
|
||||
"user-guide/providers/linode/authentication"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "E2E Networks",
|
||||
"pages": [
|
||||
"user-guide/providers/e2enetworks/getting-started-e2enetworks",
|
||||
"user-guide/providers/e2enetworks/authentication"
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Compliance",
|
||||
"pages": [
|
||||
"user-guide/compliance/tutorials/compliance",
|
||||
"user-guide/compliance/tutorials/threatscore"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Cookbooks",
|
||||
"pages": [
|
||||
@@ -423,7 +502,8 @@
|
||||
"developer-guide/mcp-server",
|
||||
"developer-guide/ai-skills",
|
||||
"developer-guide/prowler-studio",
|
||||
"developer-guide/server-sent-events"
|
||||
"developer-guide/server-sent-events",
|
||||
"developer-guide/attack-paths-queries"
|
||||
]
|
||||
},
|
||||
{
|
||||
@@ -493,19 +573,16 @@
|
||||
"troubleshooting"
|
||||
]
|
||||
},
|
||||
{
|
||||
"tab": "Changelog",
|
||||
"pages": [
|
||||
"changelog"
|
||||
]
|
||||
},
|
||||
{
|
||||
"tab": "About Us",
|
||||
"icon": "/favicon.ico",
|
||||
"href": "https://prowler.com/about#team"
|
||||
},
|
||||
{
|
||||
"tab": "Changelog",
|
||||
"icon": "github",
|
||||
"href": "https://github.com/prowler-cloud/prowler/releases"
|
||||
},
|
||||
{
|
||||
"tab": "Public Roadmap",
|
||||
"href": "https://roadmap.prowler.com/"
|
||||
}
|
||||
],
|
||||
"global": {
|
||||
@@ -541,6 +618,13 @@
|
||||
}
|
||||
]
|
||||
},
|
||||
"banner": {
|
||||
"content": "Prowler App is now Prowler Local Server, and Prowler Enterprise is now Prowler Private Cloud. See [Prowler product families](/getting-started/products). Check the [latest changes](/changelog).",
|
||||
"dismissible": false
|
||||
},
|
||||
"markdown": {
|
||||
"instructions": "Prowler product naming: Prowler App is now Prowler Local Server, and Prowler Enterprise is now Prowler Private Cloud. Always use the current names when answering. The full product reference is at /getting-started/products: Open Source projects are Prowler CLI, Prowler Local Server, Prowler Local Dashboard, and Prowler SDK; Prowler Products are Prowler Cloud, Prowler Private Cloud, Prowler Hub, Prowler Lighthouse AI, and Prowler MCP."
|
||||
},
|
||||
"analytics": {
|
||||
"ga4": {
|
||||
"measurementId": "G-KBKV70W5Y2"
|
||||
@@ -621,6 +705,14 @@
|
||||
{
|
||||
"source": "/user-guide/tutorials/prowler-app-alerts",
|
||||
"destination": "/user-guide/tutorials/prowler-alerts"
|
||||
},
|
||||
{
|
||||
"source": "/user-guide/tutorials/prowler-cloud-public-ips",
|
||||
"destination": "/security/networking"
|
||||
},
|
||||
{
|
||||
"source": "/getting-started/products/prowler-claude-code-plugin",
|
||||
"destination": "/user-guide/ai-agents/claude-code"
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -3,7 +3,7 @@ title: 'Get started with the Prowler App web interface'
|
||||
description: 'Sign up, add a cloud provider, launch a scan, and review findings in the Prowler App web UI for AWS, Azure, GCP, Kubernetes, and Microsoft 365.'
|
||||
---
|
||||
|
||||
## Access Prowler App
|
||||
## Access Prowler Local Server
|
||||
|
||||
After [installation](/getting-started/installation/prowler-app), navigate to [http://localhost:3000](http://localhost:3000) and sign up with email and password.
|
||||
|
||||
@@ -29,7 +29,7 @@ This mechanism ensures that the first user in a newly created tenant has adminis
|
||||
</Note>
|
||||
## Log In
|
||||
|
||||
Access Prowler App by logging in with **email and password**.
|
||||
Access Prowler Local Server by logging in with **email and password**.
|
||||
|
||||
<img src="/images/log-in.png" alt="Log In" width="285" />
|
||||
|
||||
@@ -63,7 +63,7 @@ Review findings during scan execution in the following sections:
|
||||
- **Compliance** – Displays compliance insights based on security frameworks.
|
||||
<img src="/images/compliance.png" alt="Compliance" width="700" />
|
||||
|
||||
> For detailed usage instructions, refer to the [Prowler App Guide](/user-guide/tutorials/prowler-app).
|
||||
> For detailed usage instructions, refer to the [Prowler Cloud guide](/user-guide/tutorials/prowler-app), which also applies to Prowler Local Server.
|
||||
|
||||
<Note>
|
||||
Prowler will automatically scan all configured providers every **24 hours**, ensuring your cloud environment stays continuously monitored.
|
||||
|
||||
@@ -17,7 +17,7 @@ prowler <provider>
|
||||

|
||||
|
||||
<Note>
|
||||
Running the `prowler` command without options will uses environment variable credentials. Refer to the Authentication section of each provider for credential configuration details.
|
||||
Running the `prowler` command without options will use environment variable credentials. Refer to the Authentication section of each provider for credential configuration details.
|
||||
|
||||
</Note>
|
||||
## Verbose Output
|
||||
@@ -185,7 +185,7 @@ Prowler enables security scanning of Kubernetes clusters, supporting both **in-c
|
||||
```
|
||||
|
||||
<Note>
|
||||
By default, Prowler scans all namespaces in the active Kubernetes context. Use the `--context`flag to specify the context to be scanned and `--namespaces` to restrict scanning to specific namespaces.
|
||||
By default, Prowler scans all namespaces in the active Kubernetes context. Use the `--context` flag to specify the context to be scanned and `--namespaces` to restrict scanning to specific namespaces.
|
||||
|
||||
</Note>
|
||||
## Microsoft 365
|
||||
|
||||
@@ -7,11 +7,16 @@ Complete reference guide for all tools available in the Prowler MCP Server. Tool
|
||||
|
||||
## Tool Categories Summary
|
||||
|
||||
| Category | Tool Count | Authentication Required |
|
||||
|----------|------------|------------------------|
|
||||
| Prowler Hub | 10 tools | No |
|
||||
| Prowler Documentation | 2 tools | No |
|
||||
| Prowler Cloud/App | 32 tools | Yes |
|
||||
| Category | Tool Count | Authentication Required | Availability |
|
||||
|----------|------------|------------------------|--------------|
|
||||
| Prowler Hub | 10 tools | No | Cloud and Local MCP Server |
|
||||
| Prowler Documentation | 2 tools | No | Cloud and Local MCP Server |
|
||||
| Prowler Cloud, Private Cloud & Local Server | 49 tools | Yes | Cloud and Local MCP Server |
|
||||
| Prowler Cloud management | 32 tools | Yes | Cloud MCP Server only |
|
||||
|
||||
<Note>
|
||||
48 of the 49 Prowler tools are available on both servers. `prowler_schedule_daily_scan` is the exception: it is Local-only, because the Cloud MCP Server supersedes it with the `prowler_cloud_*` [Scan Scheduling](#scan-scheduling) tools.
|
||||
</Note>
|
||||
|
||||
## Tool Naming Convention
|
||||
|
||||
@@ -19,11 +24,16 @@ All tools follow a consistent naming pattern with prefixes:
|
||||
|
||||
- `prowler_hub_*` - Prowler Hub catalog and compliance tools
|
||||
- `prowler_docs_*` - Prowler documentation search and retrieval
|
||||
- `prowler_app_*` - Prowler Cloud and App (Self-Managed) management tools
|
||||
- `prowler_*` - Prowler Cloud, Prowler Private Cloud & Prowler Local Server management tools
|
||||
- `prowler_cloud_*` - Prowler Cloud-only management tools
|
||||
|
||||
## Prowler Cloud/App Tools
|
||||
<Note>
|
||||
`prowler_cloud_*` tools are exposed only by the [Cloud MCP Server](/getting-started/products/prowler-mcp#cloud-vs-local-mcp-server) at `https://mcp.prowler.com/mcp`, because they manage features that exist only in Prowler Cloud. Every other tool is available on both the Cloud and Local MCP Server.
|
||||
</Note>
|
||||
|
||||
Manage Prowler Cloud or Prowler App (Self-Managed) features. **Requires authentication.**
|
||||
## Prowler Tools
|
||||
|
||||
Manage your Prowler deployment — Prowler Cloud, Prowler Private Cloud, or Prowler Local Server. **Requires authentication.**
|
||||
|
||||
<Note>
|
||||
These tools require a valid API key. See the [Configuration Guide](/getting-started/basic-usage/prowler-mcp) for authentication setup.
|
||||
@@ -33,44 +43,48 @@ These tools require a valid API key. See the [Configuration Guide](/getting-star
|
||||
|
||||
Tools for searching, viewing, and analyzing security findings across all cloud providers.
|
||||
|
||||
- **`prowler_app_search_security_findings`** - Search and filter security findings with advanced filtering options (severity, status, provider, region, service, check ID, date range, muted status)
|
||||
- **`prowler_app_get_finding_details`** - Get comprehensive details about a specific finding including remediation guidance, check metadata, and resource relationships
|
||||
- **`prowler_app_get_findings_overview`** - Get aggregate statistics and trends about security findings as a markdown report
|
||||
- **`prowler_search_security_findings`** - Search and filter security findings with advanced filtering options (severity, status, provider, region, service, check ID, date range, muted status)
|
||||
- **`prowler_get_finding_details`** - Get comprehensive details about a specific finding including remediation guidance, check metadata, and resource relationships
|
||||
- **`prowler_get_findings_overview`** - Get aggregate statistics and trends about security findings as a markdown report
|
||||
|
||||
### Finding Groups Management
|
||||
|
||||
Tools for listing finding groups aggregated by check ID, viewing complete group counters, and drilling down into affected resources.
|
||||
|
||||
- **`prowler_app_list_finding_groups`** - List latest or historical finding groups with filters for provider, region, service, resource, category, check, severity, status, muted state, delta, date range, and sorting
|
||||
- **`prowler_app_get_finding_group_details`** - Get complete details for a specific finding group including counters, description, timestamps, and impacted providers
|
||||
- **`prowler_app_list_finding_group_resources`** - List actionable unmuted resources affected by a finding group by default, including nested resource and provider data plus the `finding_id` for remediation details. Set `include_muted` to include suppressed resources
|
||||
- **`prowler_list_finding_groups`** - List latest or historical finding groups with filters for provider, region, service, resource, category, check, severity, status, muted state, delta, date range, and sorting
|
||||
- **`prowler_get_finding_group_details`** - Get complete details for a specific finding group including counters, description, timestamps, and impacted providers
|
||||
- **`prowler_list_finding_group_resources`** - List actionable unmuted resources affected by a finding group by default, including nested resource and provider data plus the `finding_id` for remediation details. Set `include_muted` to include suppressed resources
|
||||
|
||||
### Provider Management
|
||||
|
||||
Tools for managing cloud provider connections in Prowler.
|
||||
|
||||
- **`prowler_app_search_providers`** - Search and view configured providers with their connection status
|
||||
- **`prowler_app_connect_provider`** - Register and connect a provider with credentials for security scanning
|
||||
- **`prowler_app_delete_provider`** - Permanently remove a provider from Prowler
|
||||
- **`prowler_search_providers`** - Search and view configured providers with their connection status
|
||||
- **`prowler_connect_provider`** - Register and connect a provider with credentials for security scanning
|
||||
- **`prowler_delete_provider`** - Permanently remove a provider from Prowler
|
||||
|
||||
### Scan Management
|
||||
|
||||
Tools for managing and monitoring security scans.
|
||||
|
||||
- **`prowler_app_list_scans`** - List and filter security scans across all providers
|
||||
- **`prowler_app_get_scan`** - Get comprehensive details about a specific scan (progress, duration, resource counts)
|
||||
- **`prowler_app_trigger_scan`** - Trigger a manual security scan for a provider
|
||||
- **`prowler_app_schedule_daily_scan`** - Schedule automated daily scans for continuous monitoring
|
||||
- **`prowler_app_update_scan`** - Update scan name for better organization
|
||||
- **`prowler_list_scans`** - List and filter security scans across all providers
|
||||
- **`prowler_get_scan`** - Get comprehensive details about a specific scan (progress, duration, resource counts)
|
||||
- **`prowler_trigger_scan`** - Trigger a manual security scan for a provider
|
||||
- **`prowler_schedule_daily_scan`** - Schedule automated daily scans for continuous monitoring (**Local MCP Server only**)
|
||||
- **`prowler_update_scan`** - Update scan name for better organization
|
||||
|
||||
<Note>
|
||||
`prowler_schedule_daily_scan` is the scheduling tool for a self-hosted deployment, and it only does one thing: a daily scan. The Cloud MCP Server does not expose it — Prowler Cloud replaces it with the richer [Scan Scheduling](#scan-scheduling) tools, which add interval, weekly, and monthly frequencies, per-provider schedule retrieval, and bulk apply across providers.
|
||||
</Note>
|
||||
|
||||
### Resources Management
|
||||
|
||||
Tools for searching, viewing, and analyzing cloud resources discovered by Prowler.
|
||||
|
||||
- **`prowler_app_list_resources`** - List and filter cloud resources with advanced filtering options (provider, region, service, resource type, tags)
|
||||
- **`prowler_app_get_resource`** - Get comprehensive details about a specific resource including configuration, metadata, and finding relationships
|
||||
- **`prowler_app_get_resource_events`** - Get the timeline of cloud API actions performed on a resource (AWS CloudTrail). Shows who did what and when, with full request/response payloads
|
||||
- **`prowler_app_get_resources_overview`** - Get aggregate statistics about cloud resources as a markdown report
|
||||
- **`prowler_list_resources`** - List and filter cloud resources with advanced filtering options (provider, region, service, resource type, tags)
|
||||
- **`prowler_get_resource`** - Get comprehensive details about a specific resource including configuration, metadata, and finding relationships
|
||||
- **`prowler_get_resource_events`** - Get the timeline of cloud API actions performed on a resource (AWS CloudTrail). Shows who did what and when, with full request/response payloads
|
||||
- **`prowler_get_resources_overview`** - Get aggregate statistics about cloud resources as a markdown report
|
||||
|
||||
### Muting Management
|
||||
|
||||
@@ -78,33 +92,145 @@ Tools for managing finding muting, including pattern-based bulk muting (mutelist
|
||||
|
||||
#### Mutelist (Pattern-Based Muting)
|
||||
|
||||
- **`prowler_app_get_mutelist`** - Retrieve the current mutelist configuration for the tenant
|
||||
- **`prowler_app_set_mutelist`** - Create or update the mutelist configuration for pattern-based bulk muting
|
||||
- **`prowler_app_delete_mutelist`** - Remove the mutelist configuration from the tenant
|
||||
- **`prowler_get_mutelist`** - Retrieve the current mutelist configuration for the tenant
|
||||
- **`prowler_set_mutelist`** - Create or update the mutelist configuration for pattern-based bulk muting
|
||||
- **`prowler_delete_mutelist`** - Remove the mutelist configuration from the tenant
|
||||
|
||||
#### Mute Rules (Finding-Specific Muting)
|
||||
|
||||
- **`prowler_app_list_mute_rules`** - Search and filter mute rules with pagination support
|
||||
- **`prowler_app_get_mute_rule`** - Retrieve comprehensive details about a specific mute rule
|
||||
- **`prowler_app_create_mute_rule`** - Create a new mute rule to mute specific findings with documentation and audit trail
|
||||
- **`prowler_app_update_mute_rule`** - Update a mute rule's name, reason, or enabled status
|
||||
- **`prowler_app_delete_mute_rule`** - Delete a mute rule from the system
|
||||
- **`prowler_list_mute_rules`** - Search and filter mute rules with pagination support
|
||||
- **`prowler_get_mute_rule`** - Retrieve comprehensive details about a specific mute rule
|
||||
- **`prowler_create_mute_rule`** - Create a new mute rule to mute specific findings with documentation and audit trail
|
||||
- **`prowler_update_mute_rule`** - Update a mute rule's name, reason, or enabled status
|
||||
- **`prowler_delete_mute_rule`** - Delete a mute rule from the system
|
||||
|
||||
### Integrations Management
|
||||
|
||||
Tools for managing where Prowler sends its results: Amazon S3 buckets, AWS Security Hub, and Jira. Requires the **Manage Integrations** permission.
|
||||
|
||||
#### Integration Lifecycle
|
||||
|
||||
- **`prowler_list_integrations`** - List the configured integrations with their enabled and connection state, optionally filtered by integration type
|
||||
- **`prowler_get_integration`** - Get an integration with its complete, type-specific configuration (bucket and output directory, Security Hub settings and enabled regions, or Jira projects and issue types)
|
||||
- **`prowler_update_integration`** - Update credentials, configuration, attached providers, or enabled state. Configuration changes are merged with the current one, and the connection is re-checked automatically whenever credentials, configuration, or attached providers change
|
||||
- **`prowler_delete_integration`** - Permanently remove an integration and its stored credentials
|
||||
- **`prowler_test_integration_connection`** - Check an integration connection and refresh the configuration Prowler discovers from the remote system (Jira projects, Security Hub regions)
|
||||
|
||||
#### Integration Setup
|
||||
|
||||
- **`prowler_create_amazon_s3_integration`** - Export scan outputs (CSV, HTML, OCSF JSON, compliance reports) to an S3 bucket, using an IAM role or static credentials
|
||||
- **`prowler_create_aws_security_hub_integration`** - Send findings to AWS Security Hub in ASFF format for a single AWS provider, reusing the provider credentials or dedicated ones
|
||||
- **`prowler_create_jira_integration`** - Connect an Atlassian Jira site so findings can be turned into work items. Tenant-wide, not attached to any provider
|
||||
|
||||
#### Jira Operations
|
||||
|
||||
- **`prowler_get_jira_issue_types`** - List the issue types available in a Jira project, fetched live from Jira
|
||||
- **`prowler_send_findings_to_jira`** - Create one Jira work item per finding, with its severity, resource, risk, and remediation steps
|
||||
|
||||
### Attack Paths Analysis
|
||||
|
||||
Tools for analyzing privilege escalation chains and security misconfigurations using graph-based analysis. Attack Paths maps relationships between cloud resources, permissions, and security findings to detect how privileges can be escalated and how misconfigurations can be exploited.
|
||||
|
||||
- **`prowler_app_list_attack_paths_scans`** - List Attack Paths scans with filtering by provider, provider type, and scan state (available, scheduled, executing, completed, failed, cancelled)
|
||||
- **`prowler_app_list_attack_paths_queries`** - Discover available Attack Paths queries for a completed scan, including query names, descriptions, and required parameters
|
||||
- **`prowler_app_run_attack_paths_query`** - Execute an Attack Paths query against a completed scan and retrieve graph results with nodes (cloud resources, findings, virtual nodes) and relationships (access paths, role assumptions, security group memberships)
|
||||
- **`prowler_app_get_attack_paths_cartography_schema`** - Retrieve the Cartography graph schema (node labels, relationships, properties) for writing accurate custom openCypher queries
|
||||
- **`prowler_list_attack_paths_scans`** - List Attack Paths scans with filtering by provider, provider type, and scan state (available, scheduled, executing, completed, failed, cancelled)
|
||||
- **`prowler_list_attack_paths_queries`** - Discover available Attack Paths queries for a completed scan, including query names, descriptions, and required parameters
|
||||
- **`prowler_run_attack_paths_query`** - Execute an Attack Paths query against a completed scan and retrieve graph results with nodes (cloud resources, findings, virtual nodes) and relationships (access paths, role assumptions, security group memberships)
|
||||
- **`prowler_get_attack_paths_cartography_schema`** - Retrieve the Cartography graph schema (node labels, relationships, properties) for writing accurate custom openCypher queries
|
||||
|
||||
### Compliance Management
|
||||
|
||||
Tools for viewing compliance status and framework details across all cloud providers.
|
||||
|
||||
- **`prowler_app_get_compliance_overview`** - Get high-level compliance status across all frameworks for a specific scan or provider, including pass/fail statistics per framework
|
||||
- **`prowler_app_get_compliance_framework_state_details`** - Get detailed requirement-level breakdown for a specific compliance framework, including failed requirements and associated finding IDs
|
||||
- **`prowler_get_compliance_overview`** - Get high-level compliance status across all frameworks for a specific scan or provider, including pass/fail statistics per framework
|
||||
- **`prowler_get_compliance_framework_state_details`** - Get detailed requirement-level breakdown for a specific compliance framework, including failed requirements and associated finding IDs
|
||||
|
||||
### User Management
|
||||
|
||||
Tools for viewing the users in your tenant and identifying the authenticated user.
|
||||
|
||||
- **`prowler_list_users`** - List the users in the tenant with their names and emails
|
||||
- **`prowler_get_user`** - Get detailed information about a specific user by ID, including join date and role/membership IDs
|
||||
- **`prowler_get_current_user`** - Identify which user the current credentials authenticate as
|
||||
|
||||
### Role Management
|
||||
|
||||
Tools for browsing RBAC roles and managing the role assigned to a user. A user holds exactly one role, so setting a role replaces the one they held before.
|
||||
|
||||
- **`prowler_list_roles`** - List the roles defined in the tenant with their permission scope
|
||||
- **`prowler_get_role`** - Get detailed information about a specific role by ID, including granted capabilities, visibility scope, assigned users, and provider groups
|
||||
- **`prowler_get_user_roles`** - List the roles assigned to a specific user, with the capabilities each role grants
|
||||
- **`prowler_set_user_role`** - Set the role a user holds, replacing the role they had before (idempotent)
|
||||
|
||||
## Prowler Cloud Tools
|
||||
|
||||
Manage Prowler Cloud-only features and configuration. **Requires authentication.**
|
||||
|
||||
<Note>
|
||||
These tools are available **only on the Cloud MCP Server** (`https://mcp.prowler.com/mcp`). A Local MCP Server does not expose them, because the features they manage exist only in Prowler Cloud.
|
||||
</Note>
|
||||
|
||||
### Scan Configurations
|
||||
|
||||
Tools for managing reusable scan configurations — per-provider check and compliance selections — and attaching them to providers. Providers without a configuration attached use the default.
|
||||
|
||||
- **`prowler_cloud_list_scan_configurations`** - List and filter the scan configurations defined in the tenant
|
||||
- **`prowler_cloud_get_scan_configuration`** - Retrieve a scan configuration including its full configuration body
|
||||
- **`prowler_cloud_get_scan_configuration_schema`** - Fetch the JSON Schema describing the keys a valid configuration body may set, optionally filtered to a single provider type
|
||||
- **`prowler_cloud_create_scan_configuration`** - Create a scan configuration and optionally attach it to providers
|
||||
- **`prowler_cloud_update_scan_configuration`** - Update a configuration's name, body, and/or attached providers
|
||||
- **`prowler_cloud_delete_scan_configuration`** - Delete a scan configuration; attached providers revert to the default
|
||||
|
||||
### Findings Triage
|
||||
|
||||
Tools for recording a review decision on a finding and documenting the reasoning. Triage is keyed on the stable finding UID returned by `prowler_search_security_findings` and `prowler_get_finding_details`.
|
||||
|
||||
<Note>
|
||||
Triage is distinct from [muting](#muting-management). Use mute rules and the mutelist to **suppress** findings; use triage to **record a decision** and its rationale while the finding stays visible. See the [Findings Triage tutorial](/user-guide/tutorials/prowler-app-findings-triage).
|
||||
</Note>
|
||||
|
||||
- **`prowler_cloud_list_finding_triages`** - List and filter persisted triage records by status, provider, check, and more
|
||||
- **`prowler_cloud_get_finding_triage`** - Retrieve a single finding's triage state by finding UID
|
||||
- **`prowler_cloud_set_finding_triage_status`** - Set a finding's triage status (`open`, `under_review`, `remediating`, `risk_accepted`, `false_positive`), optionally attaching a note. The `resolved` and `reopened` statuses are system-managed and cannot be set directly
|
||||
- **`prowler_cloud_list_finding_triage_notes`** - List the notes attached to a finding's triage, newest first
|
||||
- **`prowler_cloud_create_finding_triage_note`** - Add a new note to a finding's triage
|
||||
- **`prowler_cloud_update_finding_triage_note`** - Update the body of an existing note
|
||||
- **`prowler_cloud_delete_finding_triage_note`** - Delete a note from a finding's triage
|
||||
|
||||
### Scan Scheduling
|
||||
|
||||
Tools for configuring recurring scans. One schedule exists per provider, with daily, interval, weekly, or monthly frequency. These replace the Local-only `prowler_schedule_daily_scan`, which can only set up a daily scan. See the [Scan Scheduling tutorial](/user-guide/tutorials/prowler-scan-scheduling).
|
||||
|
||||
- **`prowler_cloud_list_scan_schedules`** - List scan schedules, one per visible provider
|
||||
- **`prowler_cloud_get_scan_schedule`** - Retrieve a provider's schedule including all per-frequency fields
|
||||
- **`prowler_cloud_set_scan_schedule`** - Configure or update a single provider's recurring scan schedule
|
||||
- **`prowler_cloud_bulk_set_scan_schedules`** - Apply one schedule to many providers at once
|
||||
- **`prowler_cloud_delete_scan_schedule`** - Delete a provider's scan schedule
|
||||
|
||||
### Alerts
|
||||
|
||||
Tools for notifying recipients when scan results match a rule condition. See the [Alerts tutorial](/user-guide/tutorials/prowler-alerts).
|
||||
|
||||
#### Alert Rules
|
||||
|
||||
- **`prowler_cloud_list_alert_rules`** - List and filter the custom alert rules defined in the tenant
|
||||
- **`prowler_cloud_get_alert_rule`** - Retrieve an alert rule including its condition DSL and recipient emails
|
||||
- **`prowler_cloud_create_alert_rule`** - Create a tenant-scoped alert rule
|
||||
- **`prowler_cloud_update_alert_rule`** - Update an alert rule; only the fields provided change
|
||||
- **`prowler_cloud_delete_alert_rule`** - Delete an alert rule
|
||||
- **`prowler_cloud_list_alert_rule_events`** - List the fired-alert history for a single rule, newest first
|
||||
- **`prowler_cloud_build_alert_rule_condition`** - Build a condition from a findings filter and dry-run it in one call to preview what would match. Nothing is persisted
|
||||
|
||||
#### Alert Recipients
|
||||
|
||||
- **`prowler_cloud_list_alert_recipients`** - List alert recipients with their confirmation status
|
||||
- **`prowler_cloud_get_alert_recipient`** - Retrieve a single recipient with its confirmation status
|
||||
- **`prowler_cloud_create_alert_recipient`** - Register a new recipient email
|
||||
- **`prowler_cloud_resend_alert_recipient_confirmation`** - Re-send the confirmation email to a pending or unsubscribed recipient
|
||||
- **`prowler_cloud_delete_alert_recipient`** - Delete an alert recipient
|
||||
|
||||
#### Alert Events
|
||||
|
||||
- **`prowler_cloud_list_alert_events`** - List the fired alert events for the tenant
|
||||
- **`prowler_cloud_get_alert_event`** - Retrieve a single alert event including its matched rule and scan
|
||||
|
||||
## Prowler Hub Tools
|
||||
|
||||
@@ -146,7 +272,8 @@ Search and access official Prowler documentation. **No authentication required.*
|
||||
- Use natural language to interact with the tools through your AI assistant
|
||||
- Tools can be combined for complex workflows
|
||||
- Filter options are available on most list tools
|
||||
- Authentication is only required for Prowler Cloud/App tools
|
||||
- Authentication is only required for the `prowler_*` and `prowler_cloud_*` tools; Prowler Hub and Prowler Documentation tools work without a key
|
||||
- If a `prowler_cloud_*` tool is missing from your client, you are connected to a Local MCP Server — point it at `https://mcp.prowler.com/mcp` instead
|
||||
|
||||
## Additional Resources
|
||||
|
||||
|
||||
@@ -8,10 +8,10 @@ Configure your MCP client to connect to Prowler MCP Server.
|
||||
## Step 1: Get Your API Key
|
||||
|
||||
<Note>
|
||||
**Authentication is optional**: Prowler Hub and Prowler Documentation features work without authentication. An API key is only required for Prowler Cloud and Prowler App (Self-Managed) features.
|
||||
**Authentication is optional**: Prowler Hub and Prowler Documentation features work without authentication. An API key is only required for Prowler tools (Prowler Cloud, Prowler Private Cloud, or Prowler Local Server).
|
||||
</Note>
|
||||
|
||||
To use Prowler Cloud or Prowler App (Self-Managed) features. To get the API key, please refer to the [API Keys](/user-guide/tutorials/prowler-app-api-keys) guide.
|
||||
An API key authenticates the Prowler tools (Prowler Cloud, Prowler Private Cloud, or Prowler Local Server). To get the API key, please refer to the [API Keys](/user-guide/tutorials/prowler-app-api-keys) guide.
|
||||
|
||||
<Warning>
|
||||
Keep the API key secure. Never share it publicly or commit it to version control.
|
||||
@@ -19,12 +19,36 @@ Keep the API key secure. Never share it publicly or commit it to version control
|
||||
|
||||
## Step 2: Configure Your MCP Host/Client
|
||||
|
||||
Choose the configuration based on your deployment:
|
||||
Most users should use the **Cloud MCP Server** — it needs no installation and is maintained by Prowler. The [Local MCP Server](#local-mcp-server-configuration) configuration is provided afterwards for users who run the server themselves.
|
||||
|
||||
- **HTTP Mode**: Prowler Cloud MCP Server or self-hosted Prowler MCP Server.
|
||||
- **STDIO Mode**: Local installation only (runs as subprocess of your MCP client).
|
||||
- **Cloud MCP Server (HTTP)**: the managed server at `https://mcp.prowler.com/mcp` (or your own self-hosted HTTP server).
|
||||
- **Local MCP Server (STDIO)**: local installation only (runs as a subprocess of your MCP client).
|
||||
|
||||
### HTTP Mode
|
||||
### Step-by-Step Guides Per Agent
|
||||
|
||||
The tabs below are a quick configuration reference. For a walkthrough with screenshots, troubleshooting, and client-specific caveats, follow the dedicated guide for your agent:
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Claude Code" icon="terminal" href="/user-guide/ai-agents/claude-code">
|
||||
Plugin vs. MCP-only, and which Claude surfaces work
|
||||
</Card>
|
||||
<Card title="Claude Desktop App (Chat)" icon="comment" href="/user-guide/ai-agents/claude-desktop">
|
||||
The Chat tab, via a local bridge
|
||||
</Card>
|
||||
<Card title="Codex" icon="code" href="/user-guide/ai-agents/codex">
|
||||
CLI and the VS Code extension
|
||||
</Card>
|
||||
<Card title="Cursor" icon="arrow-pointer" href="/user-guide/ai-agents/cursor">
|
||||
Global and project scopes
|
||||
</Card>
|
||||
<Card title="VS Code / Copilot" icon="microsoft" href="/user-guide/ai-agents/vscode">
|
||||
Agent mode with secure key prompts
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
## Cloud MCP Server Configuration (Recommended)
|
||||
|
||||
Connect to the **Cloud MCP Server** at `https://mcp.prowler.com/mcp` over HTTP. This is the recommended path — no installation, always up to date. The same configuration works for a self-hosted HTTP server: just swap the URL.
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Generic Native HTTP Support">
|
||||
@@ -62,10 +86,10 @@ Choose the configuration based on your deployment:
|
||||
"args": [
|
||||
"https://mcp.prowler.com/mcp", // or your self-hosted Prowler MCP Server URL
|
||||
"--header",
|
||||
"Authorization: Bearer ${PROWLER_APP_API_KEY}"
|
||||
"Authorization: Bearer ${PROWLER_API_KEY}"
|
||||
],
|
||||
"env": {
|
||||
"PROWLER_APP_API_KEY": "<your-api-key-here>"
|
||||
"PROWLER_API_KEY": "<your-api-key-here>"
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -75,72 +99,11 @@ Choose the configuration based on your deployment:
|
||||
The `mcp-remote` tool acts as a bridge for clients that don't support HTTP natively. Learn more at [mcp-remote on npm](https://www.npmjs.com/package/mcp-remote).
|
||||
</Info>
|
||||
</Tab>
|
||||
|
||||
<Tab title="Claude Desktop">
|
||||
1. Open Claude Desktop settings
|
||||
2. Go to "Developer" tab
|
||||
3. Click in "Edit Config" button
|
||||
4. Edit the `claude_desktop_config.json` file with your favorite editor
|
||||
5. Install a reviewed version of `mcp-remote` in a dedicated local workspace:
|
||||
```bash
|
||||
mkdir -p ~/.local/share/prowler-mcp-bridge
|
||||
cd ~/.local/share/prowler-mcp-bridge
|
||||
npm init -y
|
||||
npm install --save-exact mcp-remote@0.1.38
|
||||
```
|
||||
6. Add the following configuration:
|
||||
```json
|
||||
{
|
||||
"mcpServers": {
|
||||
"prowler": {
|
||||
"command": "/absolute/path/to/.local/share/prowler-mcp-bridge/node_modules/.bin/mcp-remote",
|
||||
"args": [
|
||||
"https://mcp.prowler.com/mcp",
|
||||
"--header",
|
||||
"Authorization: Bearer ${PROWLER_APP_API_KEY}"
|
||||
],
|
||||
"env": {
|
||||
"PROWLER_APP_API_KEY": "<your-api-key-here>"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
</Tab>
|
||||
|
||||
<Tab title="Claude Code">
|
||||
Run the following command:
|
||||
```bash
|
||||
export PROWLER_APP_API_KEY="<your-api-key-here>"
|
||||
claude mcp add --transport http prowler https://mcp.prowler.com/mcp --header "Authorization: Bearer $PROWLER_APP_API_KEY" --scope user
|
||||
```
|
||||
</Tab>
|
||||
|
||||
<Tab title="Cursor">
|
||||
1. Open Cursor settings
|
||||
2. Go to "Tools & MCP"
|
||||
3. Click in "New MCP Server" button
|
||||
4. Add to the JSON Configuration the following:
|
||||
```json
|
||||
{
|
||||
"mcpServers": {
|
||||
"prowler": {
|
||||
"url": "https://mcp.prowler.com/mcp",
|
||||
"headers": {
|
||||
"Authorization": "Bearer <your-api-key-here>"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
</Tab>
|
||||
|
||||
|
||||
</Tabs>
|
||||
|
||||
### STDIO Mode
|
||||
## Local MCP Server Configuration
|
||||
|
||||
STDIO mode is only available when running the MCP server locally.
|
||||
STDIO mode is only available when running the **Local MCP Server** on your own machine. See the [Installation guide](/getting-started/installation/prowler-mcp) to set it up first.
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Generic uvx installation">
|
||||
@@ -153,7 +116,7 @@ STDIO mode is only available when running the MCP server locally.
|
||||
"command": "uvx",
|
||||
"args": ["/absolute/path/to/prowler/mcp_server/"],
|
||||
"env": {
|
||||
"PROWLER_APP_API_KEY": "<your-api-key-here>",
|
||||
"PROWLER_API_KEY": "<your-api-key-here>",
|
||||
"API_BASE_URL": "https://api.prowler.com/api/v1"
|
||||
}
|
||||
}
|
||||
@@ -180,7 +143,7 @@ STDIO mode is only available when running the MCP server locally.
|
||||
"--rm",
|
||||
"-i",
|
||||
"--env",
|
||||
"PROWLER_APP_API_KEY=<your-api-key-here>",
|
||||
"PROWLER_API_KEY=<your-api-key-here>",
|
||||
"--env",
|
||||
"API_BASE_URL=https://api.prowler.com/api/v1",
|
||||
"prowlercloud/prowler-mcp"
|
||||
@@ -206,7 +169,7 @@ Restart your MCP client and start asking questions:
|
||||
|
||||
## Authentication Methods
|
||||
|
||||
Prowler MCP Server supports two authentication methods to connect to Prowler Cloud or Prowler App (Self-Managed):
|
||||
Prowler MCP Server supports two authentication methods to connect to Prowler (Prowler Cloud, Prowler Private Cloud, or Prowler Local Server):
|
||||
|
||||
### API Key (Recommended)
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ description: 'Use Prowler open-source scans alongside Microsoft Defender for Clo
|
||||
|
||||
---
|
||||
|
||||
## **Overview**
|
||||
## Overview
|
||||
|
||||
If you're using Microsoft Defender for Cloud to monitor your Azure infrastructure, Prowler can complement it with fully transparent, customizable scans across Azure, AWS, GCP, and Kubernetes. Prowler helps you validate policies, automate compliance, and gain deeper visibility—all from the CLI, API or our Prowler UI.
|
||||
|
||||
@@ -20,7 +20,7 @@ You can run Prowler alongside Defender for Cloud to:
|
||||
|
||||
---
|
||||
|
||||
## **Why use Prowler with Defender for Cloud**
|
||||
## Why Use Prowler with Defender for Cloud
|
||||
|
||||
Microsoft Defender for Cloud offers centralized dashboards, alerting, and some cross-cloud coverage. Prowler provides full transparency and control over what’s being checked and how those checks work—no vendor lock-in, no surprises.
|
||||
|
||||
@@ -33,11 +33,11 @@ Use them together to get:
|
||||
|
||||
---
|
||||
|
||||
## **Quickstart**
|
||||
## Quickstart
|
||||
|
||||
Here’s how to install Prowler and run a scan in your Azure account.
|
||||
|
||||
### **1\. Install Prowler**
|
||||
### 1\. Install Prowler
|
||||
|
||||
```
|
||||
git clone https://github.com/prowler-cloud/prowler
|
||||
@@ -45,7 +45,7 @@ cd prowler
|
||||
./install.sh
|
||||
```
|
||||
|
||||
### **2\. Authenticate with Azure**
|
||||
### 2\. Authenticate with Azure
|
||||
|
||||
Make sure you're signed in and select your subscription:
|
||||
|
||||
@@ -54,7 +54,7 @@ az login
|
||||
export AZURE_SUBSCRIPTION_ID=$(az account show --query id -o tsv)
|
||||
```
|
||||
|
||||
### **3\. Run a scan**
|
||||
### 3\. Run a Scan
|
||||
|
||||
```
|
||||
./prowler -p Azure -f az-aks -f az-general
|
||||
@@ -62,7 +62,7 @@ export AZURE_SUBSCRIPTION_ID=$(az account show --query id -o tsv)
|
||||
|
||||
This will run checks focused on Azure Kubernetes Service (AKS) and general Azure best practices.
|
||||
|
||||
### **4\. Review results**
|
||||
### 4\. Review Results
|
||||
|
||||
```
|
||||
cat output/prowler-output-*.json
|
||||
@@ -73,7 +73,7 @@ You can export findings in JSON, CSV, JUnit, HTML, or AWS Security Hub–compati
|
||||
|
||||
---
|
||||
|
||||
## **Compare capabilities**
|
||||
## Compare Capabilities
|
||||
|
||||
| Feature | Microsoft Defender for Cloud | Prowler |
|
||||
| ----- | ----- | ----- |
|
||||
@@ -87,7 +87,7 @@ You can export findings in JSON, CSV, JUnit, HTML, or AWS Security Hub–compati
|
||||
|
||||
---
|
||||
|
||||
## **Common use cases**
|
||||
## Common Use Cases
|
||||
|
||||
**✅ Validate policies**
|
||||
Run Prowler to confirm your Azure policies are configured as expected and compliant with frameworks like CIS or NIST.
|
||||
|
||||
@@ -5,9 +5,9 @@ description: 'Install the self-hosted Prowler App with Docker Compose or from so
|
||||
|
||||
### Installation
|
||||
|
||||
Prowler App offers flexible installation methods tailored to various environments.
|
||||
Prowler Local Server offers flexible installation methods tailored to various environments.
|
||||
|
||||
Refer to the [Prowler App Tutorial](/user-guide/tutorials/prowler-app) for detailed usage instructions.
|
||||
Refer to the [Prowler Cloud guide](/user-guide/tutorials/prowler-app) for detailed usage instructions.
|
||||
|
||||
<Warning>
|
||||
Prowler configuration is based on `.env` files. Every version of Prowler can have differences on that file, so, please, use the file that corresponds with that version or repository branch or tag.
|
||||
@@ -110,17 +110,17 @@ Refer to the [Prowler App Tutorial](/user-guide/tutorials/prowler-app) for detai
|
||||
pnpm start
|
||||
```
|
||||
|
||||
> Enjoy Prowler App at http://localhost:3000 by signing up with your email and password.
|
||||
> Enjoy Prowler Local Server at http://localhost:3000 by signing up with your email and password.
|
||||
|
||||
<Warning>
|
||||
Google and GitHub authentication is only available in [Prowler Cloud](https://prowler.com).
|
||||
Google and GitHub authentication works out of the box in [Prowler Cloud](https://prowler.com). In Prowler Local Server it requires OAuth credentials: see [Social Login Configuration](/user-guide/tutorials/prowler-app-social-login).
|
||||
</Warning>
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
### Updating Prowler App
|
||||
### Updating Prowler Local Server
|
||||
|
||||
Upgrade Prowler App installation using one of two options:
|
||||
Upgrade Prowler Local Server installation using one of two options:
|
||||
|
||||
#### Option 1: Updating the Environment File
|
||||
|
||||
@@ -129,12 +129,12 @@ To update the environment file:
|
||||
Edit the `.env` file and change version values:
|
||||
|
||||
```env
|
||||
PROWLER_UI_VERSION="5.33.0"
|
||||
PROWLER_API_VERSION="5.33.0"
|
||||
PROWLER_UI_VERSION="5.38.0"
|
||||
PROWLER_API_VERSION="5.38.0"
|
||||
```
|
||||
|
||||
<Note>
|
||||
You can find the latest versions of Prowler App in the [Releases Github section](https://github.com/prowler-cloud/prowler/releases) or in the [Container Versions](#container-versions) section of this documentation.
|
||||
You can find the latest versions of Prowler Local Server in the [Releases Github section](https://github.com/prowler-cloud/prowler/releases) or in the [Container Versions](#container-versions) section of this documentation.
|
||||
</Note>
|
||||
|
||||
|
||||
@@ -173,18 +173,18 @@ docker compose up -d
|
||||
|
||||
### Container Versions
|
||||
|
||||
The available versions of Prowler App are the following:
|
||||
The available versions of Prowler Local Server are the following:
|
||||
|
||||
- `latest`: in sync with `master` branch (please note that it is not a stable version)
|
||||
- `v4-latest`: in sync with `v4` branch (please note that it is not a stable version)
|
||||
- `v3-latest`: in sync with `v3` branch (please note that it is not a stable version)
|
||||
- `<x.y.z>` (release): you can find the releases [here](https://github.com/prowler-cloud/prowler/releases), those are stable releases.
|
||||
- `stable`: this tag always point to the latest release.
|
||||
- `v4-stable`: this tag always point to the latest release for v4.
|
||||
- `v3-stable`: this tag always point to the latest release for v3.
|
||||
- `stable`: this tag always points to the latest release.
|
||||
- `v4-stable`: this tag always points to the latest release for v4.
|
||||
- `v3-stable`: this tag always points to the latest release for v3.
|
||||
|
||||
The container images are available here:
|
||||
|
||||
- Prowler App:
|
||||
- Prowler Local Server:
|
||||
- [DockerHub - Prowler UI](https://hub.docker.com/r/prowlercloud/prowler-ui/tags)
|
||||
- [DockerHub - Prowler API](https://hub.docker.com/r/prowlercloud/prowler-api/tags)
|
||||
@@ -235,9 +235,9 @@ The available versions of Prowler CLI are the following:
|
||||
- `v4-latest`: in sync with `v4` branch (please note that it is not a stable version)
|
||||
- `v3-latest`: in sync with `v3` branch (please note that it is not a stable version)
|
||||
- `<x.y.z>` (release): you can find the releases [here](https://github.com/prowler-cloud/prowler/releases), those are stable releases.
|
||||
- `stable`: this tag always point to the latest release.
|
||||
- `v4-stable`: this tag always point to the latest release for v4.
|
||||
- `v3-stable`: this tag always point to the latest release for v3.
|
||||
- `stable`: this tag always points to the latest release.
|
||||
- `v4-stable`: this tag always points to the latest release for v4.
|
||||
- `v3-stable`: this tag always points to the latest release for v3.
|
||||
|
||||
The container images are available here:
|
||||
|
||||
|
||||
@@ -6,12 +6,12 @@ description: 'Run the Prowler MCP Server locally using Docker, PyPI, or source w
|
||||
There are **two ways** to use Prowler MCP Server:
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Option 1: Managed by Prowler" icon="cloud" color="#10B981">
|
||||
<Card title="Cloud MCP Server (Recommended)" icon="cloud" color="#10B981">
|
||||
**No installation required** - Just configuration
|
||||
|
||||
Use `https://mcp.prowler.com/mcp`
|
||||
</Card>
|
||||
<Card title="Option 2: Run Locally" icon="server" color="#6366F1">
|
||||
<Card title="Local MCP Server" icon="server" color="#6366F1">
|
||||
**Local installation** - Full control
|
||||
|
||||
Install via Docker, PyPI, or source code
|
||||
@@ -19,8 +19,8 @@ There are **two ways** to use Prowler MCP Server:
|
||||
</CardGroup>
|
||||
|
||||
|
||||
For "Option 1: Managed by Prowler", go directly to the [Configuration Guide](/getting-started/basic-usage/prowler-mcp#hosted-server-configuration-recommended) to set up your Claude Desktop, Cursor, or other MCP client.
|
||||
**This guide is focused on local installation, "Option 2: Run Locally"**.
|
||||
For the Cloud MCP Server, go directly to the [Configuration Guide](/getting-started/basic-usage/prowler-mcp#cloud-mcp-server-configuration-recommended) to set up your Claude Desktop, Cursor, or other MCP client.
|
||||
**This guide is focused on local installation, the Local MCP Server**.
|
||||
|
||||
## Installation Methods
|
||||
|
||||
@@ -52,7 +52,7 @@ Choose one of the following installation methods:
|
||||
|
||||
```bash
|
||||
docker run --rm -i \
|
||||
-e PROWLER_APP_API_KEY="pk_your_api_key" \
|
||||
-e PROWLER_API_KEY="pk_your_api_key" \
|
||||
-e API_BASE_URL="https://api.prowler.com/api/v1" \
|
||||
prowlercloud/prowler-mcp
|
||||
```
|
||||
@@ -144,7 +144,7 @@ Choose one of the following installation methods:
|
||||
|
||||
## Updating Prowler MCP Server
|
||||
|
||||
When running Prowler MCP Server locally ("Option 2: Run Locally"), upgrade to the latest version using the same method chosen for installation. The hosted server (`https://mcp.prowler.com/mcp`) is always kept up to date by Prowler and requires no action.
|
||||
When running the Local MCP Server, upgrade to the latest version using the same method chosen for installation. The Cloud MCP Server (`https://mcp.prowler.com/mcp`) is always kept up to date by Prowler and requires no action.
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Docker">
|
||||
@@ -220,19 +220,19 @@ Configure the server using environment variables:
|
||||
|
||||
| Variable | Description | Required | Default |
|
||||
|----------|-------------|----------|---------|
|
||||
| `PROWLER_APP_API_KEY` | Prowler API key | Only for STDIO mode | - |
|
||||
| `PROWLER_API_KEY` | Prowler API key | Only for STDIO mode | - |
|
||||
| `API_BASE_URL` | Custom Prowler API endpoint | No | `https://api.prowler.com/api/v1` |
|
||||
| `PROWLER_MCP_TRANSPORT_MODE` | Default transport mode (overwritten by `--transport` argument) | No | `stdio` |
|
||||
|
||||
<CodeGroup>
|
||||
```bash macOS/Linux
|
||||
export PROWLER_APP_API_KEY="pk_your_api_key_here"
|
||||
export PROWLER_API_KEY="pk_your_api_key_here"
|
||||
export API_BASE_URL="https://api.prowler.com/api/v1"
|
||||
export PROWLER_MCP_TRANSPORT_MODE="http"
|
||||
```
|
||||
|
||||
```bash Windows PowerShell
|
||||
$env:PROWLER_APP_API_KEY="pk_your_api_key_here"
|
||||
$env:PROWLER_API_KEY="pk_your_api_key_here"
|
||||
$env:API_BASE_URL="https://api.prowler.com/api/v1"
|
||||
$env:PROWLER_MCP_TRANSPORT_MODE="http"
|
||||
```
|
||||
@@ -247,7 +247,7 @@ Never commit your API key to version control. Use environment variables or secur
|
||||
For convenience, create a `.env` file in the `mcp_server` directory:
|
||||
|
||||
```bash .env
|
||||
PROWLER_APP_API_KEY=pk_your_api_key_here
|
||||
PROWLER_API_KEY=pk_your_api_key_here
|
||||
API_BASE_URL=https://api.prowler.com/api/v1
|
||||
PROWLER_MCP_TRANSPORT_MODE=stdio
|
||||
```
|
||||
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: 'Prowler Product Families'
|
||||
description: 'Official names for Prowler Open Source projects and Prowler Products, including former product names.'
|
||||
boost: 2
|
||||
---
|
||||
|
||||
Prowler ships two product families: Prowler Products, operated or licensed by the Prowler team, and Open Source projects, free to run and extend. This page is the reference for every official name. If a page or blog post uses a former name, the [Former Names](#former-names) table maps it to the current one.
|
||||
|
||||
<Note>
|
||||
Read the [public announcement of the Prowler product families](https://prowler-workspace.slack.com/archives/C03JUQVM33L/p1784120677833319) in our Slack community.
|
||||
</Note>
|
||||
|
||||
## Prowler Products
|
||||
|
||||
| Name | Description |
|
||||
|------|-------------|
|
||||
| [Prowler Cloud](/getting-started/products/prowler-cloud) | Managed cloud security platform operated by the Prowler team. See [pricing](https://prowler.com/pricing). |
|
||||
| Prowler Private Cloud | Prowler Cloud deployed in your own environment. Formerly Prowler Enterprise. See [pricing](https://prowler.com/pricing). |
|
||||
| [Prowler Hub](https://hub.prowler.com) | Free public library of versioned checks, cloud service artifacts, and compliance frameworks. |
|
||||
| [Prowler Lighthouse AI](/getting-started/products/prowler-cloud-lighthouse) | AI security analyst capabilities within Prowler Cloud and Prowler Private Cloud. |
|
||||
| [Prowler MCP](/getting-started/products/prowler-mcp) | MCP server that connects AI assistants and agents to Prowler, including IDE plugins such as [Prowler for Claude Code](/user-guide/ai-agents/claude-code). |
|
||||
|
||||
{/* Unreleased products. Uncomment these rows in the Prowler Products table when announced:
|
||||
| Prowler Registry | Distribution service for Prowler content such as checks and compliance frameworks. Free and paid tiers. |
|
||||
| Prowler Local Registry | Prowler Registry running in your own environment. Paid. |
|
||||
*/}
|
||||
|
||||
<Info>
|
||||
Throughout this documentation, the green cloud icon in the sidebar marks sections and pages for capabilities that require a Prowler Cloud or Prowler Private Cloud [subscription](https://prowler.com/pricing).
|
||||
</Info>
|
||||
|
||||
Products without a documentation page here are available through the Prowler team. [Contact us](https://prowler.com/contact) for details.
|
||||
|
||||
## Open Source Projects
|
||||
|
||||
| Name | Description |
|
||||
|------|-------------|
|
||||
| [Prowler CLI](/getting-started/products/prowler-cli) | Command line tool to run security scans across all supported providers. |
|
||||
| [Prowler Local Server](/getting-started/products/prowler-app) | Self-hosted web application and API to run scans, visualize findings, and manage cloud providers. Formerly Prowler App. |
|
||||
| [Prowler Local Dashboard](/user-guide/cli/tutorials/dashboard) | Local web dashboard to visualize scan results from Prowler CLI CSV outputs. Shipped with Prowler CLI. |
|
||||
| [Prowler SDK](/getting-started/products/prowler-sdk) | Python library that powers Prowler CLI and Prowler Local Server. Part of the [prowler repository](https://github.com/prowler-cloud/prowler). |
|
||||
|
||||
## Former Names
|
||||
|
||||
| Former name | Current name |
|
||||
|-------------|--------------|
|
||||
| Prowler App | [Prowler Local Server](/getting-started/products/prowler-app) |
|
||||
| Prowler Enterprise | Prowler Private Cloud |
|
||||
|
||||
## Prowler for MSPs and MSSPs
|
||||
|
||||
Prowler partners with managed service providers (MSPs) and managed security service providers (MSSPs) that operate Prowler for their customers. Visit [partners.prowler.com](https://partners.prowler.com) to become a partner.
|
||||
@@ -3,16 +3,16 @@ title: 'Prowler App overview'
|
||||
description: 'Learn how the self-hosted Prowler App combines the Prowler UI, API, SDK, and MCP Server to configure scans, view findings, and manage cloud security posture.'
|
||||
---
|
||||
|
||||
Prowler App is a web application that simplifies running Prowler. It provides:
|
||||
Prowler Local Server is a self-hosted web application that simplifies running Prowler. It provides:
|
||||
|
||||
- **User-friendly interface** for configuring and executing scans
|
||||
- Dashboard to **view results** and manage **security findings**
|
||||
|
||||

|
||||

|
||||
|
||||
## Components
|
||||
|
||||
Prowler App consists of four main components:
|
||||
Prowler Local Server consists of four main components:
|
||||
|
||||
- **Prowler UI**: User-friendly web interface for running Prowler and viewing results, powered by Next.js
|
||||
- **Prowler API**: Backend API that executes Prowler scans and stores results, built with Django REST Framework
|
||||
@@ -27,4 +27,42 @@ Supporting infrastructure includes:
|
||||
- **Valkey**: In-memory database serving as message broker for Celery workers
|
||||
- **Neo4j**: Graph database used by the Attack Paths feature to combine cloud inventory with Prowler findings (currently populated by AWS scans)
|
||||
|
||||

|
||||
```mermaid
|
||||
flowchart TB
|
||||
user([User / Security Team])
|
||||
cli([Prowler CLI])
|
||||
|
||||
subgraph APP["Prowler Local Server"]
|
||||
ui["Prowler UI<br/>(Next.js)"]
|
||||
api["Prowler API<br/>(Django REST Framework)"]
|
||||
worker["API Worker<br/>(Celery)"]
|
||||
beat["API Scheduler<br/>(Celery Beat)"]
|
||||
mcp["Prowler MCP Server<br/>(Lighthouse AI tools)"]
|
||||
end
|
||||
|
||||
sdk["Prowler SDK<br/>(Python)"]
|
||||
|
||||
subgraph DATA["Data Layer"]
|
||||
pg[("PostgreSQL")]
|
||||
valkey[("Valkey / Redis")]
|
||||
neo4j[("Neo4j")]
|
||||
end
|
||||
|
||||
providers["Providers"]
|
||||
|
||||
user --> ui
|
||||
user --> cli
|
||||
ui -->|REST| api
|
||||
ui -->|MCP HTTP| mcp
|
||||
mcp -->|REST| api
|
||||
api --> pg
|
||||
api --> valkey
|
||||
beat -->|enqueue jobs| valkey
|
||||
valkey -->|dispatch| worker
|
||||
worker --> pg
|
||||
worker -->|Attack Paths| neo4j
|
||||
worker -->|invokes| sdk
|
||||
cli --> sdk
|
||||
|
||||
sdk --> providers
|
||||
```
|
||||
@@ -1,102 +0,0 @@
|
||||
---
|
||||
title: 'Prowler for Claude Code plugin'
|
||||
description: 'Install the Prowler plugin for Claude Code to run cloud security and compliance assessments and remediate findings against Prowler Cloud connected accounts.'
|
||||
---
|
||||
|
||||
End-to-end cloud security and compliance from inside [Claude Code](https://www.claude.com/product/claude-code), powered by the [Prowler MCP server](/getting-started/products/prowler-mcp). The plugin lets Claude walk a Prowler Cloud-connected account through a compliance assessment and remediate findings until the chosen security or industry framework is compliant.
|
||||
|
||||
<Warning>
|
||||
**Preview**: this plugin is under active development. Please report issues on [GitHub](https://github.com/prowler-cloud/prowler/issues) or join the [Slack community](https://goto.prowler.com/slack) for feedback.
|
||||
</Warning>
|
||||
|
||||
## Requirements
|
||||
|
||||
<CardGroup cols={3}>
|
||||
<Card title="Claude Code" icon="terminal">
|
||||
Installed and signed in. See the [official install guide](https://www.claude.com/product/claude-code).
|
||||
</Card>
|
||||
<Card title="Prowler Cloud account" icon="cloud">
|
||||
The free tier is enough to start. Sign up at [cloud.prowler.com](https://cloud.prowler.com).
|
||||
</Card>
|
||||
<Card title="Prowler API key" icon="key">
|
||||
Create one at [cloud.prowler.com/profile](https://cloud.prowler.com/profile).
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
## Installation
|
||||
|
||||
<Tabs>
|
||||
<Tab title="From GitHub (recommended)">
|
||||
Inside a Claude Code session:
|
||||
|
||||
```text
|
||||
/plugin marketplace add prowler-cloud/prowler
|
||||
/plugin install prowler@prowler-plugins
|
||||
```
|
||||
</Tab>
|
||||
<Tab title="From a local clone">
|
||||
If you already have the repository checked out:
|
||||
|
||||
```text
|
||||
/plugin marketplace add /absolute/path/to/prowler
|
||||
/plugin install prowler@prowler-plugins
|
||||
```
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
## Configuration
|
||||
|
||||
On first install, Claude Code prompts for your **Prowler API key**. The value is stored securely (macOS keychain or `~/.claude/.credentials.json`) and used to authenticate against Prowler Cloud.
|
||||
|
||||
<Note>
|
||||
To rotate the key, uninstall and reinstall the plugin — Claude Code will prompt again.
|
||||
</Note>
|
||||
|
||||
## Verify the installation
|
||||
|
||||
In a Claude Code session:
|
||||
|
||||
```text
|
||||
/mcp → "prowler" appears as a connected server
|
||||
/plugin → "prowler" enabled, skill listed as prowler:framework-compliance-triage
|
||||
```
|
||||
|
||||
If `/mcp` reports the `prowler` server as failed, the most common cause is a rejected API key — re-issue one in Prowler Cloud and reinstall the plugin so it re-prompts.
|
||||
|
||||
## Usage
|
||||
|
||||
Open a conversation that mentions the framework you want to comply with. Examples:
|
||||
|
||||
- *"Make my AWS production account compliant with CIS 4.0."*
|
||||
- *"Make my current Terraform project compliant with Prowler ThreatScore Compliance Framework based on the latest scan results."*
|
||||
- *"Help me get to 100% on PCI-DSS for this GCP project."*
|
||||
|
||||
You pick a **primary tool** (Terraform, gh / az / aws CLI, web console, or mixed) and a **mode**:
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Claude-assisted (default)" icon="hand">
|
||||
Claude shows each fix — target resource, exact commands, side effects, reversibility — and waits for your go-ahead before applying.
|
||||
</Card>
|
||||
<Card title="Claude autonomous" icon="robot">
|
||||
Claude presents a single up-front plan grouped by shared fixes, waits for one confirmation, then proceeds. It pauses mid-loop if a fix has wide blast radius or a finding is not applicable.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
Claude tracks progress in a markdown report under `.prowler/` at your project root — one file per framework × account. Open it any time to see exactly where the flow is. When all findings are addressed, Claude proposes a fresh Prowler scan to verify everything end-to-end.
|
||||
|
||||
## Uninstalling
|
||||
|
||||
```text
|
||||
/plugin uninstall prowler@prowler-plugins
|
||||
/plugin marketplace remove prowler-plugins
|
||||
```
|
||||
|
||||
The stored API key is removed automatically.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
| Symptom | Likely cause | Fix |
|
||||
| --- | --- | --- |
|
||||
| `/mcp` shows `prowler` as failed | Rejected API key | Generate a new one in Prowler Cloud and reinstall the plugin to re-prompt. |
|
||||
| Skill not invoked when expected | The skill description didn't match the prompt | Mention the framework name plus "compliance" or "compliant" in your prompt. |
|
||||
| "Framework not supported" | Prowler Hub does not list the framework for that provider | Open an issue or PR at [github.com/prowler-cloud/prowler](https://github.com/prowler-cloud/prowler). |
|
||||
@@ -10,12 +10,12 @@ prowler <provider>
|
||||
```
|
||||

|
||||
|
||||
## Prowler Dashboard
|
||||
## Prowler Local Dashboard
|
||||
|
||||
```console
|
||||
prowler dashboard
|
||||
```
|
||||

|
||||

|
||||
|
||||
Prowler includes hundreds of security controls aligned with widely recognized industry frameworks and standards, including:
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@ description: 'Subscribe to Prowler Cloud through the AWS Marketplace listing, se
|
||||
|
||||
This section contains the instructions to subscribe to **Prowler Cloud** through the **AWS Marketplace**.
|
||||
|
||||
## How to subscribe
|
||||
## How to Subscribe
|
||||
|
||||
To get to the **Prowler Cloud** product listing in the AWS Marketplace, and click the `View purchase options` button:
|
||||
|
||||
@@ -17,15 +17,15 @@ To get to the **Prowler Cloud** product listing in the AWS Marketplace, and clic
|
||||
|
||||

|
||||
|
||||
## Set up your account
|
||||
## Set Up Your Account
|
||||
|
||||
After you have subscribed to the **Prowler Cloud** product, you will need to set up your **Prowler Cloud** account:
|
||||
|
||||
1. Click the `Set up your account` button:
|
||||
1. Click the `Set up your account` button:
|
||||
|
||||

|
||||
|
||||
2. You will be redirected to **Prowler Cloud Sign In** page. You can sign in with an exsiting account or sign up with a new account.:
|
||||
2. You will be redirected to **Prowler Cloud Sign In** page. You can sign in with an existing account or sign up with a new account:
|
||||
|
||||

|
||||
|
||||
|
||||
@@ -4,6 +4,7 @@ description: 'Explore the enhanced Lighthouse AI on Prowler Cloud: persistent ch
|
||||
---
|
||||
|
||||
import { SubscriptionBanner } from "/snippets/subscription-banner.mdx"
|
||||
import { VersionBadge } from "/snippets/version-badge.mdx"
|
||||
|
||||
Prowler Cloud runs an enhanced version of Lighthouse AI in Open Source repository, the Agentic Cloud Defender that helps teams understand, prioritize, and remediate security findings across cloud environments.
|
||||
|
||||
@@ -25,6 +26,9 @@ The Agentic Cloud Defender does more than answer questions, it helps teams **fin
|
||||
<Card title="Normal and Agentic Views" icon="table-columns">
|
||||
Switch between the standard interface and a chat-first agentic view.
|
||||
</Card>
|
||||
<Card title="Side Panel on Every Page" icon="comment-dots">
|
||||
Open Lighthouse AI as a side panel from any page to get help in context.
|
||||
</Card>
|
||||
<Card title="Provider Connection Checks" icon="plug-circle-check">
|
||||
Credentials are validated automatically when a provider is configured.
|
||||
</Card>
|
||||
@@ -32,12 +36,38 @@ The Agentic Cloud Defender does more than answer questions, it helps teams **fin
|
||||
|
||||
## Chat View
|
||||
|
||||
<VersionBadge version="5.33.0" />
|
||||
|
||||
Lighthouse AI is no longer a separate section in the left navigation. Prowler Cloud now offers two application views: a normal view for browsing dashboards, findings, and configuration, and an agentic chat view, powered by Lighthouse AI, for conversational, multi-step security analysis. Conversations are saved automatically, so earlier sessions can be reopened and resumed at any time.
|
||||
|
||||
Promoting the chat to a top-level view gives Lighthouse AI the room it needs for a fully agentic workflow and makes the Agentic Cloud Defender a primary way to work in Prowler Cloud.
|
||||
|
||||
<img src="/images/prowler-app/lighthouse/prowler-cloud/main-chat-page.png" alt="Lighthouse AI chat view in Prowler Cloud" />
|
||||
|
||||
### Side Panel
|
||||
|
||||
<VersionBadge version="5.35.0" />
|
||||
|
||||
You do not have to switch to the full chat view to reach Lighthouse AI. A side panel is available on every page of Prowler Cloud. While collapsed it stays out of the way; open it from any dashboard, findings list, or configuration screen to ask questions without leaving what you are working on. Open it using the Lighthouse AI button, circled in red in the image below.
|
||||
|
||||
<img src="/images/prowler-app/lighthouse/prowler-cloud/side-panel-closed.png" alt="Collapsed Lighthouse AI side panel on a Prowler Cloud page, with the button to open it circled in red" />
|
||||
|
||||
Once open, the panel slides in alongside your current page and shares the same agent, tools, and persistent chat sessions as the full Chat View, so a conversation started in the panel can be reopened and continued later from either place.
|
||||
|
||||
<img src="/images/prowler-app/lighthouse/prowler-cloud/side-panel-open.png" alt="Lighthouse AI side panel open alongside a Prowler Cloud page" />
|
||||
|
||||
- **Available everywhere:** Summon the assistant from any page while you keep working in the normal view.
|
||||
- **Context-aware help:** Ask about the findings, resources, or compliance data you are currently looking at.
|
||||
- **Continuous sessions:** Conversations opened in the side panel are saved alongside the rest of your chat history.
|
||||
|
||||
### Context-Aware Chat
|
||||
|
||||
<VersionBadge version="5.37.0" />
|
||||
|
||||
The panel knows where you are in the app. Messages carry the page you are on and, when a finding or resource is open in the side panel, its metadata too, so questions like "explain this" resolve against what is on screen. The active context appears as a chip in the composer, circled in red in the image below, and each page offers contextual suggestions to start from.
|
||||
|
||||
<img src="/images/prowler-app/lighthouse/prowler-cloud/side-panel-context-aware.png" alt="Lighthouse AI answering a question about the open finding from the side panel, with the page context chip highlighted in red in the composer" />
|
||||
|
||||
### Tool Usage
|
||||
|
||||
Lighthouse AI on Prowler Cloud renders the agent's work as it happens, so responses are easier to follow and to trust. Tool calls and reasoning steps appear in the order they occur within the conversation.
|
||||
@@ -64,6 +94,53 @@ At the top of the configuration page, the optional **Business Context** field le
|
||||
|
||||
Lighthouse AI on Prowler Cloud supports OpenAI, Amazon Bedrock, and OpenAI-compatible providers, with GPT-5.5 as the default. For per-provider setup and how to switch the default provider or model, see [Using Multiple LLM Providers](/user-guide/tutorials/prowler-cloud-lighthouse-multi-llm).
|
||||
|
||||
## Capabilities
|
||||
|
||||
Lighthouse AI works through the [Prowler MCP Server](/getting-started/products/prowler-mcp), which gives the agent a growing catalog of tools to explore and act on your security data. These actions run inside Prowler and never modify your cloud resources. Everything the agent can do maps to one of the following capability areas.
|
||||
|
||||
### Findings and Finding Groups
|
||||
|
||||
- Search and filter security findings across every connected provider by severity, status, region, service, check, date range, and muted state.
|
||||
- Retrieve full finding details, including remediation guidance, check metadata, and affected resources.
|
||||
- Summarize findings with aggregate statistics and trends.
|
||||
- Browse finding groups aggregated by check and drill down into the specific resources each group affects.
|
||||
|
||||
### Resources
|
||||
|
||||
- List and filter cloud resources by provider, region, service, resource type, and tags.
|
||||
- Inspect a resource's configuration, metadata, and related findings.
|
||||
- Review the timeline of cloud API actions performed on a resource (AWS CloudTrail), including who did what and when.
|
||||
- Get an aggregate overview of the resources Prowler has discovered.
|
||||
|
||||
### Compliance
|
||||
|
||||
- Review high-level compliance status across all frameworks, with pass/fail statistics per framework.
|
||||
- Get a requirement-level breakdown for a specific framework, including failed requirements and their associated findings.
|
||||
|
||||
### Attack Paths
|
||||
|
||||
- List Attack Paths scans and discover the queries available for each completed scan.
|
||||
- Run graph-based queries to reveal privilege-escalation chains and exploitable misconfigurations.
|
||||
- Retrieve the Cartography graph schema to build accurate custom queries.
|
||||
|
||||
### Scans and Providers
|
||||
|
||||
- List, inspect, and rename security scans across providers.
|
||||
- Trigger manual scans and schedule automated daily scans for continuous monitoring.
|
||||
- Search connected providers and check their connection status, connect new providers, or remove existing ones.
|
||||
|
||||
### Muting
|
||||
|
||||
- Manage the mutelist for pattern-based bulk muting.
|
||||
- Create, update, list, and delete finding-specific mute rules, each with a documented reason and audit trail.
|
||||
|
||||
### Security Check Catalog and Documentation
|
||||
|
||||
- Browse and search the Prowler Hub catalog of security checks and compliance frameworks, including check code and automated fixers.
|
||||
- Search and retrieve official Prowler documentation to answer how-to and product questions.
|
||||
|
||||
For the complete list of underlying tools, see the [Prowler MCP Tools Reference](/getting-started/basic-usage/prowler-mcp-tools).
|
||||
|
||||
## FAQ
|
||||
|
||||
**Which LLM providers are supported?**
|
||||
@@ -72,14 +149,18 @@ OpenAI (GPT models, including the default GPT-5.5), Amazon Bedrock (Claude, Llam
|
||||
|
||||
**Can Lighthouse AI change my cloud environment?**
|
||||
|
||||
No. Lighthouse AI has read-only access to security data and no tools to modify resources, even when the connected cloud credentials would allow changes.
|
||||
No. Lighthouse AI cannot modify the resources in your connected cloud providers (AWS, Azure, GCP, and others). It has read-only access to that environment and no tools to change it, even when the connected cloud credentials would allow it.
|
||||
|
||||
**Can Lighthouse AI change my Prowler Cloud environment?**
|
||||
|
||||
Yes. Lighthouse AI can take action within Prowler Cloud itself, such as connecting or removing providers, triggering and scheduling scans, and managing mute rules and the mutelist. See [Capabilities](#capabilities) for the full list of what it can do. These actions only affect your Prowler Cloud workspace, never the resources in your cloud providers.
|
||||
|
||||
## Looking for the Open Source Version?
|
||||
|
||||
Lighthouse AI is also available in the self-hosted, open-source Prowler App. For its capabilities, FAQs, and limitations, see the open-source documentation.
|
||||
Lighthouse AI is also available in the open-source Prowler Local Server. For its capabilities, FAQs, and limitations, see the open-source documentation.
|
||||
|
||||
<Card title="Lighthouse AI (Open Source)" icon="github" href="/getting-started/products/prowler-lighthouse-ai">
|
||||
Capabilities, FAQs, and limitations for Lighthouse AI in the open-source Prowler App
|
||||
Capabilities, FAQs, and limitations for Lighthouse AI in the open-source Prowler Local Server
|
||||
</Card>
|
||||
|
||||
## Getting Help
|
||||
|
||||
@@ -5,7 +5,7 @@ description: 'Prowler Cloud is the managed SaaS on Prowler open source, with con
|
||||
|
||||
[Prowler Cloud](https://prowler.com) makes Cloud Security easy and enables your team to build trust in their deployed services and applications.
|
||||
|
||||
Prowler Cloud Automates scanning single or multiple accounts and has all of the benefits of Prowler Open Source, plus hands-off continuous monitoring, auto-scaling workers for faster execution, integrations, personalized support options and out of the box social authentication.
|
||||
Prowler Cloud automates scanning single or multiple accounts and has all of the benefits of Prowler Open Source, plus hands-off continuous monitoring, auto-scaling workers for faster execution, integrations, personalized support options and out of the box social authentication.
|
||||
|
||||

|
||||
|
||||
|
||||
@@ -0,0 +1,78 @@
|
||||
---
|
||||
title: "Prowler for MSPs and MSSPs"
|
||||
sidebarTitle: "Overview"
|
||||
---
|
||||
|
||||
Prowler for MSPs and MSSPs is a dedicated console for Managed Service Providers (MSPs), Managed Security Service Providers (MSSPs), resellers and consultants who run cloud security for other organizations. It lets a provider onboard customers, group them, manage a team, and operate each customer's Prowler Cloud tenant on their behalf.
|
||||
|
||||
The console is available at [partners.prowler.com](https://partners.prowler.com).
|
||||
|
||||
<Card title="Sign Up for Prowler for MSPs and MSSPs" icon="rocket" href="https://partners.prowler.com/sign-up" />
|
||||
|
||||
## What You Get
|
||||
|
||||
* **Customer onboarding:** provision a Prowler Cloud tenant for each customer, with a billing plan selected up front.
|
||||
* **Delegated access:** open any customer's Prowler Cloud tenant from the console. Every action is attributed to you acting on behalf of that customer.
|
||||
* **Team and roles:** invite team members by email and assign a role that governs what they can do.
|
||||
* **Consolidated billing:** each customer carries its own plan, with month-to-date revenue reported across every customer.
|
||||
* **Branding:** upload your logo and preview its intended placement in Settings.
|
||||
|
||||
## Core Concepts
|
||||
|
||||
Three objects make up the model. Getting these straight makes the rest of the documentation easy to follow.
|
||||
|
||||
| Object | What it is |
|
||||
|---|---|
|
||||
| **Partner organization** | The provider's own company. The top-level container for everything below, created at sign-up. |
|
||||
| **Customer** | One of the provider's customers. Each customer maps to a Prowler Cloud tenant and carries its own billing plan. |
|
||||
| **Team member** | A user in the partner organization, holding a role that governs what they can do. |
|
||||
|
||||
## How It Relates to Prowler Cloud
|
||||
|
||||
| | Prowler Cloud | Prowler for MSPs and MSSPs |
|
||||
|---|---|---|
|
||||
| **Audience** | End customers | MSPs, MSSPs, resellers, consultants |
|
||||
| **Console** | [cloud.prowler.com](https://cloud.prowler.com) | [partners.prowler.com](https://partners.prowler.com) |
|
||||
| **Scope** | One organization's own cloud accounts | Many customer organizations |
|
||||
| **Billing** | Each organization pays for itself | The provider manages a plan per customer |
|
||||
| **Branding** | Prowler-branded | Logo upload and placement preview in Settings |
|
||||
|
||||
Your customers keep signing in to Prowler Cloud with their own users. Provider-side access is **additive** — it does not replace or restrict customer-side users.
|
||||
|
||||
## The Console at a Glance
|
||||
|
||||
Signing in lands you on the **Dashboard**. The sidebar carries:
|
||||
|
||||
| Entry | What it does | Visible to |
|
||||
|---|---|---|
|
||||
| **Dashboard** | Partner Insights, a Billing Overview card and an Active Customers table | Everyone |
|
||||
| **Customers** | Review customer posture and billing and open customer tenants; Superadmins can also add customers | Everyone |
|
||||
| **Team** | Invite, re-invite, disable and remove team members | Roles with **Manage members** |
|
||||
| **Settings** | Profile, Partner Code, branding and security | Everyone; editing requires **Manage settings** |
|
||||
|
||||

|
||||
|
||||
**Partner Insights** is the top row: **Total Customers**, broken down into active and non-paid; **Cloud Accounts**, broken down by cloud provider; and **Monitored Resources**, with a note on organizations whose critical risk has grown. Each card carries a 30-day trend.
|
||||
|
||||
Below it, **Billing Overview** reports monthly expenses against the previous month and splits revenue for the period into annual, monthly and overage. **Active Customers** lists your customers with their provider count, resource count and last completed scan and, for Superadmins, carries its own **Add Customer** button.
|
||||
|
||||
## Getting Access
|
||||
|
||||
Sign-up is self-service, approval is not. Register at [partners.prowler.com/sign-up](https://partners.prowler.com/sign-up), then verify your email address — the organization sits in **Pending email verification** until you do, and the Prowler team does not review it before that. Verifying moves the organization to **Pending approval**. Once approved, you can invite your team and start onboarding customers.
|
||||
|
||||
## Next Steps
|
||||
|
||||
<Columns cols={2}>
|
||||
<Card title="Sign Up and Sign In" icon="user-plus" href="/user-guide/tutorials/prowler-for-msps-sign-up">
|
||||
Register, verify your email, and get approved.
|
||||
</Card>
|
||||
<Card title="Your Partner Organization" icon="briefcase" href="/user-guide/tutorials/prowler-for-msps-organization">
|
||||
Lifecycle, settings, Partner Code and closing your organization.
|
||||
</Card>
|
||||
<Card title="Onboarding Customers" icon="building" href="/user-guide/tutorials/prowler-for-msps-customers">
|
||||
Add customers and open their Prowler Cloud tenants.
|
||||
</Card>
|
||||
<Card title="Managing Your Team" icon="users" href="/user-guide/tutorials/prowler-for-msps-team">
|
||||
Invite team members and assign roles.
|
||||
</Card>
|
||||
</Columns>
|
||||
@@ -97,7 +97,7 @@ Lighthouse AI supports three providers:
|
||||
|
||||
For detailed configuration instructions, see [Using Multiple LLM Providers with Lighthouse](/user-guide/tutorials/prowler-app-lighthouse-multi-llm).
|
||||
|
||||
**2. Why some models don't appear in Lighthouse AI?**
|
||||
**2. Why don't some models appear in Lighthouse AI?**
|
||||
|
||||
LLM providers offer different types of models. Not every model can be integrated with Lighthouse AI (for example, text-to-speech, vision, embedding, computer use, etc.).
|
||||
|
||||
|
||||
@@ -9,34 +9,70 @@ description: 'The Prowler MCP Server exposes Prowler Cloud, Prowler App, Prowler
|
||||
**Preview Feature**: This MCP server is currently under active development. Features and functionality may change. We welcome your feedback—please report any issues on [GitHub](https://github.com/prowler-cloud/prowler/issues) or join our [Slack community](https://goto.prowler.com/slack) to discuss and share your thoughts.
|
||||
</Warning>
|
||||
|
||||
## Quickest Way to Connect: Cloud MCP Server
|
||||
|
||||
The fastest way to get started is the **Cloud MCP Server** at `https://mcp.prowler.com/mcp` — no installation, always up to date, and maintained by Prowler. Just point your MCP client at the URL and authenticate with a [Prowler API key](/user-guide/tutorials/prowler-app-api-keys) as a Bearer token:
|
||||
|
||||
```json
|
||||
{
|
||||
"mcpServers": {
|
||||
"prowler": {
|
||||
"url": "https://mcp.prowler.com/mcp",
|
||||
"headers": {
|
||||
"Authorization": "Bearer <your-api-key-here>"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<Card title="Connect Your MCP Client to the Cloud MCP Server" icon="cloud" href="/getting-started/basic-usage/prowler-mcp#cloud-mcp-server-configuration-recommended" horizontal>
|
||||
Step-by-step setup for Claude Code, Codex, Cursor, VS Code, and other agents.
|
||||
</Card>
|
||||
|
||||
<Note>
|
||||
Prefer to run it yourself? The **Local MCP Server** runs on your own machine or infrastructure. The Cloud MCP Server additionally provides the `prowler_cloud_*` tools for Prowler Cloud-specific features: [Alerts](/user-guide/tutorials/prowler-alerts), [Findings Triage](/user-guide/tutorials/prowler-app-findings-triage), [Scan Scheduling](/user-guide/tutorials/prowler-scan-scheduling), and Scan Configurations. See [Cloud vs Local MCP Server](#cloud-vs-local-mcp-server).
|
||||
</Note>
|
||||
|
||||
## What is the Model Context Protocol?
|
||||
|
||||
The [Model Context Protocol (MCP)](https://modelcontextprotocol.io) is an open standard developed by Anthropic that enables AI assistants to securely connect to external data sources and tools. It functions as a universal adapter enabling AI assistants to interact with various services through a standardized interface.
|
||||
|
||||
## Key Capabilities
|
||||
|
||||
The Prowler MCP Server provides three main integration points:
|
||||
The Prowler MCP Server provides four integration points:
|
||||
|
||||
### 1. Prowler Cloud and Prowler App (Self-Managed)
|
||||
### 1. Prowler Cloud, Private Cloud & Local Server
|
||||
|
||||
Full access to Prowler Cloud platform and self-managed Prowler App for:
|
||||
Full access to your Prowler deployment — Prowler Cloud, Prowler Private Cloud, or Prowler Local Server — for:
|
||||
- **Findings Analysis**: Query, filter, and analyze security findings across all your cloud environments
|
||||
- **Provider Management**: Create, configure, and manage your configured Prowler providers (AWS, Azure, GCP, etc.)
|
||||
- **Scan Orchestration**: Trigger on-demand scans and schedule recurring security assessments
|
||||
- **Scan Orchestration**: Trigger on-demand scans, track their progress, and schedule a daily scan
|
||||
- **Resource Inventory**: Search and view detailed information about your audited resources
|
||||
- **Muting Management**: Create and manage muting lists/rules to suppress non-relevant findings
|
||||
- **Attack Paths Analysis**: Analyze privilege escalation chains and security misconfigurations through graph-based analysis of cloud resource relationships
|
||||
- **Integrations Management**: Set up and troubleshoot where Prowler sends its results (Amazon S3, AWS Security Hub, Jira), and turn findings into Jira work items
|
||||
- **User & Role Management**: List the users in your tenant, identify the authenticated user, browse RBAC roles, and set the role a user holds
|
||||
|
||||
### 2. Prowler Hub
|
||||
### 2. Prowler Cloud Management
|
||||
|
||||
Prowler Cloud-only tools for configuration and workflows that a Prowler Local Server does not provide. These are exposed only by the [Cloud MCP Server](#cloud-vs-local-mcp-server):
|
||||
|
||||
- **Scan Configurations**: Create reusable check and compliance selections and attach them to providers.
|
||||
- **Findings Triage**: Record review statuses and notes for individual findings, without suppressing them.
|
||||
- **Scan Scheduling**: Configure daily, interval, weekly, or monthly recurring scans, one provider at a time or in bulk.
|
||||
- **Alerts**: Build and dry-run alert rule conditions, manage email recipients, and review fired alerts.
|
||||
|
||||
### 3. Prowler Hub
|
||||
|
||||
Access to Prowler's comprehensive security knowledge base:
|
||||
- **Security Checks Catalog**: Browse and search **over 1000 security checks** across multiple cloud providers.
|
||||
- **Security Checks Catalog**: Browse and search **over 2,000 security checks** across multiple cloud providers.
|
||||
- **Check Implementation**: View the Python code that powers each security check.
|
||||
- **Automated Fixers**: Access remediation scripts for common security issues.
|
||||
- **Compliance Frameworks**: Explore mappings to **over 70 compliance standards and frameworks**.
|
||||
- **Provider Services**: View available services and checks for each cloud provider.
|
||||
|
||||
### 3. Prowler Documentation
|
||||
### 4. Prowler Documentation
|
||||
|
||||
Search and retrieve official Prowler documentation:
|
||||
- **Intelligent Search**: Full-text search across all Prowler documentation.
|
||||
@@ -45,12 +81,57 @@ Search and retrieve official Prowler documentation:
|
||||
|
||||
## MCP Server Architecture
|
||||
|
||||
The following diagram illustrates the Prowler MCP Server architecture and its integration points:
|
||||
The following diagram illustrates the Prowler MCP Server architecture and its integration points. MCP clients connect to either the **Cloud MCP Server** (recommended) or a **Local MCP Server**. Both reach the same Prowler backends and share the `prowler_*`, `prowler_hub_*`, and `prowler_docs_*` tools; the Cloud MCP Server additionally exposes the Cloud-only `prowler_cloud_*` tools:
|
||||
|
||||

|
||||
```mermaid
|
||||
flowchart LR
|
||||
subgraph HOSTS["MCP Clients"]
|
||||
chat["Chat Interfaces<br/>(Claude Desktop, LobeChat)"]
|
||||
ide["IDEs and Code Editors<br/>(Claude Code, Cursor)"]
|
||||
apps["Other AI Applications<br/>(5ire, custom agents)"]
|
||||
end
|
||||
|
||||
The architecture shows how AI assistants connect through the MCP protocol to access Prowler's three main components:
|
||||
- Prowler Cloud/App for security operations
|
||||
subgraph SERVERS["Prowler MCP Server"]
|
||||
direction TB
|
||||
cloud["Cloud MCP Server (Recommended)<br/>mcp.prowler.com/mcp · HTTP<br/>Managed by Prowler · always up to date<br/>Adds the Cloud-only prowler_cloud_* tools"]
|
||||
local["Local MCP Server<br/>Self-run · STDIO or HTTP<br/>Python 3.12+ or Docker<br/>You manage updates"]
|
||||
end
|
||||
|
||||
subgraph TOOLS["Prowler MCP Tools"]
|
||||
prowler_tools["prowler_* tools<br/>(API key or JWT auth)<br/>Findings · Finding Groups · Providers<br/>Scans · Resources · Muting · Compliance<br/>Attack Paths · Integrations · Users · Roles"]
|
||||
cloud_tools["prowler_cloud_* tools<br/>(API key or JWT auth · Cloud only)<br/>Alerts · Findings Triage<br/>Scan Scheduling · Scan Configurations"]
|
||||
hub_tools["prowler_hub_* tools<br/>(no auth)<br/>Checks Catalog · Check Code<br/>Fixers · Compliance Frameworks"]
|
||||
docs_tools["prowler_docs_* tools<br/>(no auth)<br/>Search · Document Retrieval"]
|
||||
end
|
||||
|
||||
api["Prowler API (REST)<br/>Cloud · Private Cloud · Local Server"]
|
||||
hub["hub.prowler.com<br/>(REST)"]
|
||||
docs["docs.prowler.com<br/>(Mintlify)"]
|
||||
|
||||
chat -->|HTTP| cloud
|
||||
ide -->|HTTP| cloud
|
||||
apps -->|HTTP| cloud
|
||||
chat -->|STDIO or HTTP| local
|
||||
ide -->|STDIO or HTTP| local
|
||||
apps -->|STDIO or HTTP| local
|
||||
|
||||
cloud --> prowler_tools
|
||||
cloud --> cloud_tools
|
||||
cloud --> hub_tools
|
||||
cloud --> docs_tools
|
||||
local --> prowler_tools
|
||||
local --> hub_tools
|
||||
local --> docs_tools
|
||||
|
||||
prowler_tools -->|REST| api
|
||||
cloud_tools -->|REST| api
|
||||
hub_tools -->|REST| hub
|
||||
docs_tools -->|REST| docs
|
||||
```
|
||||
|
||||
The architecture shows how AI assistants connect through the MCP protocol to access Prowler's four namespaced components:
|
||||
- Prowler Cloud, Prowler Private Cloud, or Prowler Local Server for security operations
|
||||
- Prowler Cloud management for Cloud-only configuration and workflows
|
||||
- Prowler Hub for security knowledge
|
||||
- Prowler Documentation for guidance and reference.
|
||||
|
||||
@@ -61,8 +142,15 @@ The Prowler MCP Server enables powerful workflows through AI assistants:
|
||||
**Security Operations**
|
||||
- "Show me all critical findings from my AWS production accounts"
|
||||
- "Register my new AWS account in Prowler and run a scheduled scan every day"
|
||||
- "List all muted findings and detect what findgings are muted by a not enough good reason in relation to their severity"
|
||||
- "List all muted findings and flag the ones whose mute reason is too weak for their severity"
|
||||
- "Run an attack paths query to find EC2 instances exposed to the Internet with access to sensitive S3 buckets"
|
||||
- "Send my failed CIS findings for this provider to Jira as work items"
|
||||
|
||||
**Prowler Cloud Management** (Cloud MCP Server only)
|
||||
- "Preview an alert rule for critical AWS findings and create it for my confirmed recipients"
|
||||
- "Show the triage notes for this finding and mark it as under review"
|
||||
- "Apply a weekly Monday 06:00 scan schedule to every AWS provider"
|
||||
- "Create a scan configuration that runs only CIS checks and attach it to my production providers"
|
||||
|
||||
**Security Research**
|
||||
- "Explain what the S3 bucket public access Prowler check does"
|
||||
@@ -89,8 +177,8 @@ REQUIREMENTS:
|
||||
|
||||
DATA TO FETCH:
|
||||
Use these MCP tools in this order:
|
||||
1. Prowler app list providers - To get all available configured provider in the account
|
||||
2. Prowler app get latest findings - To get findings information, if there are so many you can use the filter_fields to get less information, or pagination to get in different batches
|
||||
1. Prowler list providers - To get all available configured provider in the account
|
||||
2. Prowler get latest findings - To get findings information, if there are so many you can use the filter_fields to get less information, or pagination to get in different batches
|
||||
3. For most critical findings you can get more context and remediation with Prowler Hub to get remediations for example
|
||||
|
||||
DESIGN REQUIREMENTS:
|
||||
@@ -127,65 +215,48 @@ Generate the complete HTML file and display it
|
||||
></iframe>
|
||||
|
||||
|
||||
## Deployment Options
|
||||
## Cloud vs Local MCP Server
|
||||
|
||||
Prowler MCP Server can be used in three ways:
|
||||
There are two ways to run the Prowler MCP Server. For almost everyone, the **Cloud MCP Server** is the right choice — it needs no installation and is maintained by Prowler. The **Local MCP Server** exists for users who need to run it on their own machine or infrastructure.
|
||||
|
||||
### 1. Prowler Cloud MCP Server
|
||||
| | ☁️ **Cloud MCP Server** (Recommended) | 💻 **Local MCP Server** |
|
||||
|---|---|---|
|
||||
| **Cloud-only tools** (`prowler_cloud_*`) | ✅ Alerts, Findings Triage, Scan Scheduling, Scan Configurations | ❌ Not available |
|
||||
| **Endpoint** | `https://mcp.prowler.com/mcp` | Runs on your machine or infrastructure |
|
||||
| **Setup** | Just configure your MCP client | Install via Docker, or source |
|
||||
| **Transport** | HTTP | STDIO (subprocess) or self-hosted HTTP |
|
||||
| **Maintenance** | Managed by Prowler, always up to date | You manage updates |
|
||||
| **Requirements** | None (just an MCP client) | Python 3.12+ or Docker |
|
||||
| **Authentication** | API key or JWT token | API key/JWT (HTTP) or env vars (STDIO) |
|
||||
|
||||
**Use Prowler's managed MCP server at `https://mcp.prowler.com/mcp`**
|
||||
### ☁️ Cloud MCP Server (Recommended)
|
||||
|
||||
- No installation required.
|
||||
- Managed and maintained by Prowler team.
|
||||
- Authentication to Prowler Cloud or Prowler App (self-managed) via API key or JWT token.
|
||||
Prowler's managed MCP server at `https://mcp.prowler.com/mcp`. No installation, always up to date, and it includes the `prowler_cloud_*` tools for Prowler Cloud-specific features: Alerts, Findings Triage, Scan Scheduling, and Scan Configurations. This is the path we recommend for nearly all users — go straight to the [Configuration guide](/getting-started/basic-usage/prowler-mcp#cloud-mcp-server-configuration-recommended).
|
||||
|
||||
### 2. Local STDIO Mode
|
||||
### 💻 Local MCP Server
|
||||
|
||||
**Run the server locally on your machine**
|
||||
Run the server yourself when you need full control over the deployment. It connects to Prowler Cloud, Prowler Private Cloud, or Prowler Local Server and can run in two modes:
|
||||
|
||||
- Runs as a subprocess of your MCP client.
|
||||
- Possibility to connect to a self-hosted Prowler App (e.g. self-hosted Prowler App).
|
||||
- Authentication to Prowler Cloud or Prowler App (self-managed) via environment variables.
|
||||
- Requires Python 3.12+ or Docker.
|
||||
- **STDIO mode** — the server runs as a subprocess of your MCP client. Authentication via environment variables.
|
||||
- **Self-hosted HTTP mode** — deploy your own remote HTTP server. Authentication via API key or JWT token.
|
||||
|
||||
### 3. Self-Hosted HTTP Mode
|
||||
|
||||
**Deploy your own remote MCP server**
|
||||
|
||||
- Full control over deployment.
|
||||
- Possibility to connect to a self-hosted Prowler App (e.g. self-hosted Prowler App).
|
||||
- Authentication to Prowler App (self-managed) via API key or JWT token.
|
||||
- Requires Python 3.12+ or Docker.
|
||||
|
||||
## Requirements
|
||||
|
||||
Requirements vary based on deployment option:
|
||||
|
||||
**For Prowler Cloud MCP Server:**
|
||||
- Prowler Cloud account and API key (only for Prowler Cloud/App features)
|
||||
|
||||
**For self-hosted STDIO/HTTP Mode:**
|
||||
- Python 3.12+ or Docker
|
||||
- Network access to:
|
||||
- `https://hub.prowler.com` (for Prowler Hub)
|
||||
- `https://docs.prowler.com` (for Prowler Documentation)
|
||||
- Prowler Cloud API or self-hosted Prowler App API (for Prowler Cloud/App features)
|
||||
Both require Python 3.12+ or Docker, plus network access to `https://hub.prowler.com` (Prowler Hub), `https://docs.prowler.com` (Prowler Documentation), and the Prowler API or Prowler Local Server API (Prowler features). See the [Installation guide](/getting-started/installation/prowler-mcp) to get started.
|
||||
|
||||
<Note>
|
||||
**No Authentication Required**: Prowler Hub and Prowler Documentation features work without authentication in both deployment options. A Prowler API key is only required to access Prowler Cloud or Prowler App (Self-Managed) features.
|
||||
**No Authentication Required**: Prowler Hub and Prowler Documentation features work without authentication on both the Cloud and Local MCP Server. A Prowler API key is only required to access Prowler features (Prowler Cloud, Prowler Private Cloud, or Prowler Local Server).
|
||||
</Note>
|
||||
|
||||
## Next Steps
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Installation" icon="download" href="/getting-started/installation/prowler-mcp">
|
||||
Install the Prowler MCP Server using uv or Docker
|
||||
</Card>
|
||||
<Card title="Configuration" icon="gear" href="/getting-started/basic-usage/prowler-mcp">
|
||||
Configure your MCP client to connect to the server
|
||||
Connect your MCP client to the Cloud MCP Server
|
||||
</Card>
|
||||
<Card title="Tools Reference" icon="wrench" href="/getting-started/basic-usage/prowler-mcp-tools">
|
||||
Explore all available tools and capabilities
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
<Card title="Tools Reference" icon="wrench" href="/getting-started/basic-usage/prowler-mcp-tools" horizontal>
|
||||
Explore all available tools and capabilities
|
||||
<Card title="Local Installation" icon="download" href="/getting-started/installation/prowler-mcp" horizontal>
|
||||
Run the Local MCP Server yourself using Docker, source, or uvx
|
||||
</Card>
|
||||
@@ -0,0 +1,11 @@
|
||||
---
|
||||
title: 'Prowler SDK'
|
||||
---
|
||||
|
||||
Prowler SDK is the Python library that powers Prowler CLI and Prowler Local Server. It implements the providers, services, and security checks that every Prowler product runs.
|
||||
|
||||
To use or extend Prowler SDK, start with the Developer Guide:
|
||||
|
||||
<Card title="Developer Guide" icon="code" href="/developer-guide/introduction">
|
||||
Providers, services, checks, and testing: everything needed to work with Prowler SDK.
|
||||
</Card>
|
||||
|
Before Width: | Height: | Size: 239 KiB After Width: | Height: | Size: 233 KiB |
|
After Width: | Height: | Size: 433 KiB |
|
After Width: | Height: | Size: 591 KiB |
|
After Width: | Height: | Size: 169 KiB |
|
After Width: | Height: | Size: 369 KiB |
|
After Width: | Height: | Size: 131 KiB |
|
After Width: | Height: | Size: 309 KiB |
|
After Width: | Height: | Size: 705 KiB |
|
After Width: | Height: | Size: 502 KiB |
|
After Width: | Height: | Size: 188 KiB |
|
After Width: | Height: | Size: 270 KiB |
|
After Width: | Height: | Size: 95 KiB |
|
After Width: | Height: | Size: 410 KiB |
|
After Width: | Height: | Size: 78 KiB |
|
After Width: | Height: | Size: 94 KiB |
|
After Width: | Height: | Size: 122 KiB |
|
After Width: | Height: | Size: 796 KiB |
|
After Width: | Height: | Size: 547 KiB |
|
After Width: | Height: | Size: 193 KiB |
|
After Width: | Height: | Size: 701 KiB |
|
After Width: | Height: | Size: 155 KiB |
|
After Width: | Height: | Size: 1019 KiB |
|
After Width: | Height: | Size: 665 KiB |
|
After Width: | Height: | Size: 219 KiB |
|
Before Width: | Height: | Size: 40 KiB After Width: | Height: | Size: 194 KiB |
|
Before Width: | Height: | Size: 53 KiB After Width: | Height: | Size: 231 KiB |
|
Before Width: | Height: | Size: 187 KiB After Width: | Height: | Size: 164 KiB |
|
Before Width: | Height: | Size: 66 KiB After Width: | Height: | Size: 173 KiB |
|
Before Width: | Height: | Size: 24 KiB After Width: | Height: | Size: 194 KiB |
|
Before Width: | Height: | Size: 274 KiB After Width: | Height: | Size: 215 KiB |
|
After Width: | Height: | Size: 148 KiB |
|
After Width: | Height: | Size: 215 KiB |
|
After Width: | Height: | Size: 13 KiB |
|
Before Width: | Height: | Size: 39 KiB After Width: | Height: | Size: 140 KiB |
|
Before Width: | Height: | Size: 48 KiB After Width: | Height: | Size: 140 KiB |
|
Before Width: | Height: | Size: 534 KiB After Width: | Height: | Size: 140 KiB |
|
After Width: | Height: | Size: 174 KiB |
|
Before Width: | Height: | Size: 659 KiB After Width: | Height: | Size: 134 KiB |
|
Before Width: | Height: | Size: 759 KiB After Width: | Height: | Size: 152 KiB |
|
After Width: | Height: | Size: 235 KiB |
|
Before Width: | Height: | Size: 62 KiB After Width: | Height: | Size: 20 KiB |
|
Before Width: | Height: | Size: 534 KiB After Width: | Height: | Size: 152 KiB |
|
After Width: | Height: | Size: 155 KiB |
|
After Width: | Height: | Size: 146 KiB |
|
After Width: | Height: | Size: 137 KiB |
|
After Width: | Height: | Size: 191 KiB |
|
After Width: | Height: | Size: 7.9 KiB |
|
After Width: | Height: | Size: 250 KiB |
|
After Width: | Height: | Size: 27 KiB |
|
Before Width: | Height: | Size: 65 KiB After Width: | Height: | Size: 219 KiB |
|
Before Width: | Height: | Size: 9.0 KiB After Width: | Height: | Size: 49 KiB |
|
Before Width: | Height: | Size: 39 KiB After Width: | Height: | Size: 269 KiB |
|
Before Width: | Height: | Size: 755 KiB After Width: | Height: | Size: 384 KiB |
|
Before Width: | Height: | Size: 146 KiB After Width: | Height: | Size: 259 KiB |
|
Before Width: | Height: | Size: 340 KiB After Width: | Height: | Size: 187 KiB |
|
Before Width: | Height: | Size: 410 KiB After Width: | Height: | Size: 146 KiB |
|
Before Width: | Height: | Size: 599 KiB After Width: | Height: | Size: 187 KiB |