Prowler — automatyczny audyt bezpieczeństwa środowisk chmurowych

Infrastruktura w chmurze konfiguruje się klikaniem i to jest jej największy problem bezpieczeństwa. Kubełek otwarty „na chwilę", żeby klient zobaczył podglądy. Klucz dostępowy z polityką Action: "*", bo szło o wdrożenie na piątek. Grupa bezpieczeństwa wpuszczająca ruch na port 22 z 0.0.0.0/0, założona przez kogoś, kto już nie pracuje w firmie. Nic z tego nie było złośliwe i nic z tego nie zostało wycofane, bo nikt nie pamięta, że istnieje.

Ręczny audyt jednego konta AWS to dzień pracy osoby, która wie, czego szukać — i wynik jest nieaktualny nazajutrz, bo w międzyczasie ktoś wdrożył nową usługę. Przy trzech kontach, dwóch subskrypcjach Azure i klastrze Kubernetesa ta droga się kończy.

Prowler (github.com/prowler-cloud/prowler) automatyzuje ten audyt: ponad tysiąc gotowych kontroli bezpieczeństwa dla kilkunastu dostawców, mapowanych na standardy zgodności, uruchamianych jedną komendą i nadających się do wpięcia w CI. Poniżej: co realnie obejmuje, jak to uruchomić, gdzie leży granica między częścią otwartą a płatnym produktem, i jak używać tego w firmie, która nie ma trzystu kont AWS — bo najbardziej użyteczny scenariusz dla małego zespołu wcale nie wymaga chmury.

Rzecz oczywista, ale trzeba ją powiedzieć: to narzędzie uruchamiamy na infrastrukturze, którą zarządzamy albo do której mamy pisemne upoważnienie od właściciela. Skan cudzego konta bez zgody nie jest audytem.

Stan projektu

Dane z API GitHuba na 14 września 2026:

14 772 gwiazdki i 2379 forków,
repozytorium założone 24 sierpnia 2016 — dziesięć lat ciągłego rozwoju, co w narzędziach bezpieczeństwa jest rzadkością i najlepszym dostępnym dowodem, że projekt nie zniknie w przyszłym kwartale,
kod w Pythonie, licencja Apache-2.0, ostatni commit z 9 września 2026,
najnowsze wydanie 5.41.0 z 2 września 2026, a przed nim 5.40.0 z 28 sierpnia, 5.39.1 z 18 sierpnia i 5.39.0 z 13 sierpnia. Wydanie niemal co tydzień — przy narzędziu, które musi nadążać za zmianami w API dostawców chmury, to właściwa kadencja,
ponad sto commitów w ostatnim miesiącu i 367 otwartych zgłoszeń.

Zasięg: kontrole i dostawcy

Liczby z tabeli w README (projekt zaznacza, że aktualizuje je okresowo, a najświeższe dane są w Prowler Hub):

AWS — 639 kontroli, 86 usług, 47 frameworków zgodności, 19 kategorii,
Azure — 191 kontroli, 22 usługi, 21 frameworków,
M365 — 143 kontrole, GCP — 109, Kubernetes — 92, Google Workspace — 65, Alibaba Cloud — 63, OCI — 52, OpenStack — 34, Cloudflare — 29, Okta — 29, Vercel — 26, GitHub — 24, MongoDB Atlas — 10,
IaC — skanowanie kodu infrastruktury, liczba reguł po stronie Trivy,
LLM — testy czerwonego zespołu dla modeli, po stronie promptfoo, dostępne tylko z CLI,
Image — skanowanie obrazów kontenerów.

Osobno oznaczone jako nieoficjalne, dostępne tylko z CLI i z kontaktem do zespołu: Linode, Huawei Cloud, E2E Networks, Scaleway, StackIT i NHN. To rozróżnienie warto brać poważnie — „nieoficjalne" oznacza tu kilkanaście kontroli i brak gwarancji utrzymania.

Zwróć uwagę na trzech dostawców, których nie ma w typowej liście narzędzi CSPM: GitHub, Cloudflare i Vercel. Dla agencji, która nie utrzymuje własnej chmury, ale ma organizację na GitHubie, strefy w Cloudflare i wdrożenia na Vercelu, to jest cała powierzchnia do audytu — i Prowler ją pokrywa.

Zgodność

Każda kontrola jest zmapowana na jeden albo więcej frameworków, więc jeden skan produkuje jednocześnie wynik techniczny i dowód zgodności. Z listy: CIS Benchmarks, NIST 800-53, NIST CSF, CISA, MITRE ATT&CK, PCI-DSS, SOC 2, ISO 27001, RODO, HIPAA, FFIEC, FedRAMP, NIS2, GXP, BSI C5, CSA CCM, AWS Foundational Technical Review, AWS Well-Architected, hiszpański ENS RD2022, koreański KISA ISMS-P, indyjski RBI — plus frameworki własne.

Do tego Prowler ThreatScore: ważona punktacja priorytetyzująca ryzyko, żeby zacząć od rzeczy najważniejszych, a nie od pierwszej na liście. Przy 639 kontrolach dla samego AWS to nie jest ozdoba, a jedyny sposób, żeby raport nie wylądował w archiwum.

Co jest open source, a co produktem

Projekt rozdziela to jasno i warto to znać przed obiecaniem komukolwiek funkcji, której w wersji otwartej nie ma. Na Apache-2.0:

Prowler CLI — narzędzie wiersza poleceń do skanów u wszystkich dostawców,
Prowler Local Server (dawniej Prowler App) — samodzielna aplikacja webowa z API do uruchamiania skanów, przeglądania findings i zarządzania dostawcami,
Prowler Local Dashboard — lokalny panel do wizualizacji wyników z plików CSV wygenerowanych przez CLI,
Prowler SDK — biblioteka Pythona, na której stoją CLI i Local Server.

Produkty zespołu Prowlera, płatne albo hostowane:

Prowler Cloud — zarządzana platforma, i Prowler Private Cloud (dawniej Prowler Enterprise) — ta sama platforma we własnym środowisku,
Prowler Lighthouse AI — funkcje analityka bezpieczeństwa wspierane modelem, dostępne w Cloud i Private Cloud,
Prowler MCP — serwer MCP łączący asystentów AI z Prowlerem, wraz z wtyczkami do IDE,
Prowler Hub — darmowa, publiczna biblioteka wersjonowanych kontroli i frameworków zgodności.

W dokumentacji funkcje wymagające subskrypcji są oznaczone zieloną ikoną chmury w nawigacji, a na stronach dodatkowo notką „dostępne wyłącznie w Prowler Cloud i Prowler Private Cloud". Przykład z praktyki: w sekcji zgodności zakładka „Multiple Scans", agregująca jeden framework po wielu skanach i dostawcach, jest właśnie taką funkcją. Wersja otwarta pokazuje zgodność dla jednego skanu.

Trzeba to powiedzieć wprost, bo bywa mylące: samo skanowanie i wszystkie kontrole są w wersji otwartej. Płatne są funkcje platformy — agregacja między kontami, historia, dostęp zespołowy w większej skali, warstwa AI. Dla zespołu, który chce audytować własną infrastrukturę i wpiąć to w CI, otwarta część wystarcza w całości.

Instalacja CLI

Trzy drogi. Przez pip, z wymaganiem Pythona co najmniej 3.10 i mniej niż 3.13:

pip install prowler
prowler -v

Przez kontener — obrazy są na Docker Hubie i w AWS Public ECR, z ważnym rozróżnieniem tagów:

latest — synchronizowany z gałęzią master, oznaczony w dokumentacji jako niestabilny,
stable — zawsze najnowsze wydanie,
x.y.z — konkretne, stabilne wydanie.

Do CI używamy stable albo dokładnej wersji. latest w pipeline'ie oznacza, że skan może zacząć się wywracać po cudzym commicie.

Z repozytorium, przez uv, gdy chcemy grzebać w kodzie albo pisać własne kontrole:

git clone https://github.com/prowler-cloud/prowler
cd prowler
uv sync
source .venv/bin/activate
python prowler-cli.py -v

Pierwszy skan i zawężanie zakresu

Podstawowa forma to nazwa dostawcy jako argument. Bez argumentu Prowler przyjmuje AWS — zgodność wstecz z wersją 2:

prowler aws
prowler azure --az-cli-auth
prowler gcp --project-ids projekt-1 projekt-2
prowler kubernetes
prowler github

Poświadczenia brane są ze zmiennych środowiskowych, o ile nie wskażemy inaczej. Dla AWS działa profil i filtrowanie regionów (domyślnie skanowane są wszystkie):

prowler aws --profile audyt-klienta -f eu-central-1 eu-west-1

Azure wymaga jawnego wskazania metody uwierzytelniania: --sp-env-auth dla service principala, --az-cli-auth, --browser-auth --tenant-id "..." albo --managed-identity-auth. GCP domyślnie korzysta z poświadczeń użytkownika z gcloud auth application-default login, alternatywnie z pliku konta usługowego przez --credentials-file. Przy błędach limitu (HTTP 429) jest --gcp-retries-max-attempts.

Rozpoznanie tego, co narzędzie w ogóle potrafi, robi się czterema listami:

prowler aws --list-checks
prowler aws --list-services
prowler aws --list-compliance
prowler aws --list-categories

A zawężanie zakresu — kombinacją flag, których warto znać sześć:

# konkretne kontrole albo usługi
prowler aws --services s3 ec2 iam
prowler azure --checks storage_blob_public_access_level_is_disabled

# wykluczenia
prowler aws --excluded-checks s3_bucket_public_access
prowler gcp --excluded-services kms

# tylko krytyczne i wysokie
prowler aws --severity critical high

# tylko to, co nie przeszło
prowler aws --status FAIL

# kategoria tematyczna
prowler aws --categories secrets

# lista kontroli z pliku JSON
prowler aws --checks-file kontrole-produkcja.json

Ważności są zdefiniowane pięciostopniowo: informational, low, medium, high, critical. Pierwszy skan warto puścić z --severity critical high --status FAIL, bo pełny wynik dla AWS to sześćset kilkadziesiąt kontroli i raport, którego nikt nie przeczyta.

Raporty

Domyślnie powstają trzy formaty: CSV, JSON-OCSF i HTML. Dodatkowo, zależnie od dostawcy:

JSON-ASFF (tylko AWS) — format przyjmowany przez AWS Security Hub,
SARIF (tylko IaC) — format czytany przez GitHub Code Scanning.

prowler aws -M csv json-ocsf html json-asff

Wyniki z CSV można od razu obejrzeć w lokalnym panelu, bez stawiania czegokolwiek:

prowler dashboard

I jedna flaga, która decyduje o zachowaniu w CI: Prowler zwraca kod wyjścia 3, gdy jakakolwiek kontrola nie przeszła. To domyślnie wywraca zadanie w pipeline'ie, co zwykle jest tym, czego chcemy. Gdy nie jest — -z / --ignore-exit-code-3.

Fixer, czyli automatyczna remediacja

Prowler potrafi nie tylko wykryć, ale i naprawić część odstępstw. Dostępne naprawy wypisuje --list-fixers, a uruchamia --fixer:

prowler aws --list-fixers
prowler aws -c ec2_ebs_default_encryption s3_account_level_public_access_blocks --fixer

Trzy uwagi, z których pierwsza jest ostrzeżeniem samej dokumentacji:

Fixery dla Access Analyzera, GuardDuty i Security Huba mogą generować koszty w AWS — te usługi uruchamiają działania albo wdrażają zasoby, za które przyjdzie rachunek. Naprawa „jednym kliknięciem" jest tu decyzją budżetową,
Nie uruchamiaj --fixer bez zawężenia przez -c. Skan jest operacją tylko do odczytu; fixer pisze do produkcyjnej infrastruktury. To są dwie zupełnie różne klasy ryzyka i powinny być uruchamiane przez dwie różne role, z dwoma różnymi zestawami uprawnień,
Zawsze przejrzyj wynik skanu przed naprawą. Część „odstępstw" jest świadomą decyzją architektoniczną, a automatyczna naprawa potrafi zepsuć działającą usługę.

Własny fixer to plik <check_id>_fixer.py w katalogu kontroli, z funkcją fixer przyjmującą region albo zasób i zwracającą wartość logiczną. Przykład z dokumentacji, włączający domyślne szyfrowanie EBS w regionie:

from prowler.lib.logger import logger
from prowler.providers.aws.services.ec2.ec2_client import ec2_client


def fixer(region):
    try:
        regional_client = ec2_client.regional_clients[region]
        return regional_client.enable_ebs_encryption_by_default()[
            "EbsEncryptionByDefault"
        ]
    except Exception as error:
        logger.error(f"{region} -- {error}")
        return False

Dokumentacja podaje przy tym wymagane uprawnienie IAM (ec2:EnableEbsEncryptionByDefault) i ostrzega, że własne klucze KMS dla domyślnego szyfrowania EBS mogą zostać nadpisane. Ten poziom szczegółowości w komentarzu do przykładowego kodu mówi coś dobrego o projekcie.

Własne kontrole

Kontrole można dopisywać bez forkowania projektu. Katalog wskazuje -x / --checks-folder, a struktura jest sztywna:

każda kontrola w osobnym podkatalogu,
__init__.py — pusty, żeby Python widział pakiet,
nazwa_kontroli.py — logika,
nazwa_kontroli.metadata.json — metadane,
nazwa musi zaczynać się od nazwy usługi i podkreślnika, na przykład ec2_instance_public_ip.

Katalog z kontrolami może leżeć na S3 (s3://bucket/prefix/checks_folder/) — poświadczenia potrzebują wtedy s3:GetObject. To ładne rozwiązanie dla zespołu, który chce mieć wspólny zestaw firmowych kontroli bez pakowania go do każdego obrazu:

prowler aws -x s3://nasz-bucket/prowler/checks/ -c nasza_kontrola_tagowania

Mutelist, czyli świadomie zaakceptowane odstępstwa

Bez tego mechanizmu drugi i każdy kolejny skan pokazuje te same dwadzieścia findings, które zespół już świadomie zaakceptował — a nowe, istotne rzeczy giną w szumie. Kubełek otwarty na świat, bo hostuje publiczną stronę. Otwarty port wymagany przez konkretną aplikację. To nie są błędy, to decyzje, i trzeba je zapisać w miejscu, które narzędzie rozumie.

Mutelist to plik YAML podawany flagą -w / --mutelist-file:

Mutelist:
  Accounts:
    "123456789012":
      Checks:
        "iam_user_hardware_mfa_enabled":
          Regions:
            - "eu-central-1"
          Resources:
            - "user-1"
            - "user-2"
          Description: "Konta serwisowe bez klucza sprzętowego — zaakceptowane 2026-03"
        "ec2_*":
          Regions:
            - "*"
          Resources:
            - "*"

prowler aws -w mutelist.yaml

Logika dopasowania jest koniunkcją i to jest najważniejsza rzecz do zrozumienia: finding zostaje wyciszony tylko wtedy, gdy zgadzają się wszystkie warunki — konto, kontrola, region, zasób i (jeśli podane) tagi. Każdy z nich przyjmuje dopasowanie dokładne, wyrażenie regularne albo *. Niezgodność jednego kryterium oznacza, że finding nie jest wyciszony.

Tagi mają przy tym własną, niesymetryczną semantykę, którą łatwo pomylić:

Wiele tagów na liście to koniunkcja — wszystkie muszą być obecne na zasobie,
Alternatywa robi się wyrażeniem regularnym w obrębie jednego tagu: "environment=dev|environment=stg" dopasuje albo dev, albo stg.

Wyciszony finding nie znika z raportu, tylko zmienia status: w JSON-OCSF status_id przyjmuje wartość Suppressed, a w CSV pole muted ustawia się na True, przy czym oryginalny status pozostaje zachowany. Audytowo jest to właściwe rozwiązanie — widać, że odstępstwo istnieje i że zostało świadomie przyjęte.

Trzy rzeczy, które oszczędzą godzinę na diagnozie:

Pola „konto" i „region" znaczą różne rzeczy u różnych dostawców. W Azure konto to nazwa subskrypcji, a region to lokalizacja. W GCP konto to identyfikator projektu, a region to strefa. W Kubernetesie konto to nazwa klastra, a region to przestrzeń nazw,
Nie ma alternatywy między różnymi zestawami reguł. Jedna kontrola może mieć jeden blok reguł, a wszystkie warunki w nim są łączone koniunkcją. Dokumentacja podaje obejście: dwa osobne pliki mutelisty, dwa skany i scalenie wyników w potoku raportowania,
Nie da się zapisać „wszystkie regiony oprócz X". Regiony do wyciszenia trzeba wymienić jawnie.

Skanowanie własnego repozytorium — bez chmury

To jest scenariusz najbliższy naszej codzienności i najtańszy do wdrożenia, bo nie wymaga żadnych poświadczeń chmurowych. Dostawca iac skanuje kod infrastruktury lokalnie, używając pod spodem Trivy.

Rozpoznawane formaty pokrywają wszystko, co leży w typowym repozytorium projektu w Laravelu wdrażanego kontenerowo:

Docker — Dockerfile, Containerfile,
Kubernetes i Helm — *.yml, *.yaml, *.tpl, archiwa,
Terraform — *.tf, *.tfvars, plany,
CloudFormation, Azure ARM, Ansible, gołe YAML-e i JSON-y.

Dostępne są cztery skanery: misconfig (błędy konfiguracji), secret (sekrety w kodzie), vuln (podatności) i license (licencje). Domyślnie działają dwa pierwsze.

# skan lokalnego katalogu
prowler iac --scan-path .

# z wybranymi skanerami i wykluczeniami
prowler iac --scan-path . --scanners misconfig secret vuln \
  --exclude-path ./tests ./storage

# skan zdalnego repozytorium
prowler iac --scan-repository-url https://github.com/organizacja/repo.git

Dla prywatnych repozytoriów uwierzytelnienie idzie przez nazwę użytkownika z tokenem osobistym (--github-username, --personal-access-token), token aplikacji OAuth (--oauth-app-token) albo odpowiednie zmienne środowiskowe. Flagi --scan-path i --scan-repository-url wykluczają się wzajemnie.

Jedna różnica względem pozostałych dostawców, o której trzeba pamiętać: przy IaC wyciszanie findings obsługuje Trivy, nie mutelist Prowlera. Konfiguracja wyjątków wygląda tu więc inaczej niż w skanach chmurowych.

Audyt organizacji na GitHubie

Drugi scenariusz nie wymagający chmury, a często pomijany: 24 kontrole dla GitHuba obejmujące zarówno ustawienia repozytoriów, jak i ustawienia organizacji. Uwierzytelnianie idzie przez zmienne środowiskowe, sprawdzane w ustalonej kolejności — GITHUB_PERSONAL_ACCESS_TOKEN, potem GITHUB_OAUTH_APP_TOKEN, potem para GITHUB_APP_ID i GITHUB_APP_KEY. Dokumentacja zaleca token osobisty o precyzyjnych uprawnieniach, a poświadczenia aplikacji GitHuba wprost odradza z powodu ograniczonego dostępu do danych.

export GITHUB_PERSONAL_ACCESS_TOKEN="ghp_..."
prowler github

I tu jest pułapka, którą dokumentacja opatruje ostrzeżeniem, bo cicho zmienia zakres audytu:

prowler github — wszystkie repozytoria, do których token ma dostęp, bez kontroli na poziomie organizacji,
prowler github --repository owner/repo — jedno repozytorium, również bez kontroli organizacyjnych,
prowler github --organization nazwa-org — repozytoria organizacji oraz jej ustawienia, czyli dopiero tu sprawdzane jest wymuszanie 2FA, polityki bezpieczeństwa i pozostałe rzeczy na poziomie organizacji.

Innymi słowy: skan bez flagi --organization przechodzi na zielono, nie sprawdziwszy tego, co w audycie organizacji jest najważniejsze. Członkowie kilku organizacji muszą wskazać każdą osobno.

Duże konta i limity API

Pełny skan dużego konta AWS to setki wywołań API i trafia w ograniczenia przepustowości dostawcy. Prowler ma na to dwie odpowiedzi.

Pierwsza to ponowienia z wykładniczym wycofaniem. Domyślna liczba prób to trzy i przy dużych kontach dokumentacja zaleca ją podnieść:

prowler aws --aws-retries-max-attempts 10

Druga to równoległe uruchamianie jednego skanu na usługę. Dokumentacja podaje gotową strategię: wygenerować listę usług, a potem puścić je równolegle z ograniczoną liczbą procesów:

prowler aws --list-services | awk -F"- " '{print $2}' | sed '/^$/d' > services

Przy takim podejściu trzeba pamiętać, że limity w AWS działają per usługa i per wywołanie API, więc zrównoleglenie po usługach rozkłada obciążenie sensownie — ale przekroczenie progu nadal skończy się błędem ThrottlingException. Pięć równoległych procesów to wartość, od której warto zacząć.

W pipeline'ie: gotowa akcja GitHuba

Projekt dostarcza oficjalną akcję, która uruchamia skan w obrazie Dockera i — co najważniejsze — wrzuca wynik jako SARIF do zakładki Security → Code scanning oraz jako adnotacje wprost w pull requeście. To zmienia charakter narzędzia: zamiast raportu, który ktoś kiedyś przeczyta, dostajemy komentarz przy linijce kodu, w momencie, w którym ktoś ten kod pisze.

name: Prowler IaC Scan
on:
  pull_request:

permissions:
  contents: read
  security-events: write
  actions: read

jobs:
  prowler:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: prowler-cloud/prowler@5.25
        with:
          provider: iac
          output-formats: sarif json-ocsf
          upload-sarif: true
          flags: --severity critical high

Uprawnienie security-events: write jest wymagane do wysłania SARIF-a — bez niego zadanie przejdzie, a findings nigdzie się nie pojawią. Akcja obsługuje wszystkich wspieranych dostawców, nie tylko IaC, i ma opcjonalne --push-to-cloud do wysyłania findings do Prowler Cloud.

Dla zespołu, który dziś nie ma żadnego audytu bezpieczeństwa, jest to najlepszy możliwy pierwszy krok: kilkanaście linii w workflow, zero poświadczeń, zero infrastruktury i natychmiastowy zwrot w postaci adnotacji przy Dockerfile'u.

Panel na własnym serwerze

Prowler Local Server to aplikacja webowa z API, przeznaczona do uruchamiania i przeglądania skanów przez interfejs. Instalacja pobiera pliki z konkretnego taga wydania:

VERSION=$(curl -s https://api.github.com/repos/prowler-cloud/prowler/releases/latest | jq -r .tag_name)
curl -sLO "https://raw.githubusercontent.com/prowler-cloud/prowler/refs/tags/${VERSION}/docker-compose.yml"
curl -sLO "https://raw.githubusercontent.com/prowler-cloud/prowler/refs/tags/${VERSION}/.env"
docker compose up -d

Panel wstaje na http://localhost:3000, gdzie zakłada się konto mailem i hasłem. Trzy rzeczy z dokumentacji, które trzeba zrobić świadomie:

Nie zostawiaj domyślnych wartości w .env. Dokumentacja mówi to wprost przy każdej komendzie instalacyjnej,
Klucze podpisywania tokenów. API generuje własną parę DJANGO_TOKEN_SIGNING_KEY i DJANGO_TOKEN_VERIFYING_KEY i zapisuje ją w ~/.config/prowler-api albo w podmontowanym wolumenie (_data/api w kontenerze). Kluczy nie wolno commitować ani reużywać między instancjami; rotacja polega na usunięciu plików i restarcie API,
Przy przyjmowaniu roli IAM w AWS może być potrzebne podmontowanie lokalnego katalogu .aws do kontenera (${HOME}/.aws:/home/prowler/.aws:ro). To najczęstszy problem przy instalacji z gotowych obrazów.

Attack Paths

Nowsza funkcja warta odnotowania, bo pokazuje kierunek rozwoju: po każdym zakończonym skanie AWS worker API buduje graf łączący inwentarz chmury z findings Prowlera, korzystając z Cartography. Zamiast listy pojedynczych odstępstw dostajemy odpowiedź na pytanie, które z nich układają się w ścieżkę ataku.

Grafowe zaplecze wybiera zmienna ATTACK_PATHS_SINK_DATABASE: Neo4j (domyślnie, usługa jest już w plikach Compose) albo Amazon Neptune (opcjonalnie, uwierzytelnianie SigV4 przez standardowy łańcuch poświadczeń boto3, więc nie ma zmiennej z hasłem). Jest tu jedna pułapka konfiguracyjna, którą dokumentacja wyróżnia notką: ingest Cartography zawsze używa tymczasowej bazy Neo4j, więc zmienne NEO4J_* muszą pozostać ustawione także wtedy, gdy docelowym zapleczem jest Neptune. Funkcja obejmuje na razie tylko AWS.

Ciekawostka: Prowler wersjonuje instrukcje dla agentów

Element, który w kontekście naszej pracy zasługuje na wzmiankę: repozytorium zawiera zestaw AI Skills — ustrukturyzowanych instrukcji, które dają asystentom kodującym kontekst o konwencjach projektu. Są tam skille generyczne (typescript, react-19, nextjs-15, tailwind-4, pytest, django-drf, playwright) i specyficzne dla Prowlera (prowler-sdk-check, prowler-compliance, prowler-provider, prowler-test-api i kilka dalszych).

./skills/setup.sh

Skrypt tworzy symlinki zgodnie ze standardem agentskills.io — do .claude/skills/, .codex/skills/, .github/skills/ i .gemini/skills/, zależnie od używanego asystenta. Sam wzorzec jest wart skopiowania niezależnie od Prowlera: instrukcje dotyczące konwencji projektu leżą w repozytorium, są wersjonowane razem z kodem i działają dla całego zespołu, a nie tylko dla osoby, która je napisała.

Pułapki

Skan i naprawa to dwie różne operacje o różnym ryzyku. Do skanowania używaj poświadczeń tylko do odczytu, o zakresie opisanym w dokumentacji uwierzytelniania danego dostawcy. Uprawnienia do zapisu daj wyłącznie roli uruchamiającej --fixer, i tylko wtedy, gdy naprawa jest świadomą decyzją,
Pełny skan to setki wywołań API u dostawcy. Przy dużych kontach oznacza to czas, ograniczenia przepustowości (dla GCP jest osobna flaga na ponowienia) i w niektórych przypadkach koszt. Dlatego istnieją flagi zawężania zakresu i warto ich używać od pierwszego dnia,
639 kontroli AWS na start to raport, którego nikt nie przeczyta. Pierwszy przebieg zawężaj do --severity critical high --status FAIL, a zaakceptowane odstępstwa od razu wpisuj do mutelisty. Raport, który za drugim razem pokazuje to samo, przestaje być czytany po tygodniu,
Python 3.10–3.12. Wersja 3.13 nie jest wspierana — przy instalacji przez pip na świeżym systemie to najczęstszy powód niepowodzenia,
Tag latest to gałąź master i jest jawnie oznaczony jako niestabilny. W CI używaj stable albo dokładnej wersji,
Nie każdy dostawca jest oficjalny. Linode, Huawei Cloud, Scaleway, StackIT, E2E Networks i NHN mają po kilkanaście kontroli, status nieoficjalny i tylko interfejs CLI,
Część funkcji panelu wymaga subskrypcji. Skanowanie i kontrole są otwarte, ale agregacja wielu skanów, warstwa AI i część widoków zgodności należą do produktów komercyjnych,
Przy IaC wyjątki konfiguruje Trivy, a nie mutelist Prowlera — łatwo szukać w niewłaściwym miejscu,
367 otwartych zgłoszeń przy dwudziestu kilku dostawcach oznacza, że przy niszowym dostawcy i nietypowej konfiguracji można trafić na znany błąd. Warto sprawdzić zgłoszenia dla swojego dostawcy przed wpisaniem narzędzia do procedury audytowej.

Podsumowanie

Prowler jest jednym z tych narzędzi, których brak zauważa się dopiero po incydencie. Zamienia audyt bezpieczeństwa chmury z jednorazowego przedsięwzięcia w komendę, którą da się uruchomić przy każdym pull requeście — a przy okazji produkuje dowody zgodności z frameworkami, o które i tak zapyta klient korporacyjny. Co z tego wynika przy planowaniu wdrożenia:

Projekt jest dojrzały i bardzo aktywny — dziesięć lat historii (pierwszy commit w sierpniu 2016), 14 772 gwiazdki, wydanie 5.41.0 z 2 września 2026, nowa wersja niemal co tydzień,
Zacznij od prowler iac --scan-path . — nie wymaga żadnych poświadczeń chmurowych, a skanuje Dockerfile'e, manifesty i Terraform, które i tak leżą w repozytorium,
Wpnij oficjalną akcję GitHuba z upload-sarif: true — findings pojawiają się w zakładce Security i jako adnotacje w pull requeście. Pamiętaj o uprawnieniu security-events: write,
Pierwszy skan chmury zawężaj do --severity critical high --status FAIL, a potem systematycznie buduj mutelistę zaakceptowanych odstępstw,
Rozdziel poświadczenia do skanu i do naprawy. Skan jest tylko do odczytu; --fixer pisze do produkcji, a dla części usług AWS generuje dodatkowe koszty,
Nie zapomnij o dostawcach spoza chmury — GitHub, Cloudflare, Vercel, Okta i Google Workspace to dla wielu firm cała powierzchnia ataku, a Prowler ma dla nich gotowe kontrole,
Do CI przypnij stable albo konkretną wersję, nigdy latest,
Kod wyjścia 3 oznacza nieudane kontrole — to domyślnie wywraca zadanie w pipeline'ie i zwykle właśnie tego chcemy; wyłącza to -z,
Zbuduj mutelistę od pierwszego tygodnia — pamiętając, że dopasowanie jest koniunkcją konta, kontroli, regionu, zasobu i tagów, a alternatywę zapisuje się wyrażeniem regularnym w obrębie jednego warunku,
Audyt GitHuba wymaga flagi --organization — bez niej kontrole na poziomie organizacji, w tym wymuszanie 2FA, w ogóle się nie wykonają,
Przy dużych kontach podnieś --aws-retries-max-attempts z domyślnych trzech i rozważ równoległy skan po usługach,
Własne kontrole trzymaj w jednym miejscu, choćby na S3, i podłączaj przez -x. Struktura katalogu i nazewnictwo są sztywne,
Panel na własnym serwerze wymaga uwagi przy kluczach — para do podpisywania tokenów generuje się sama i nie wolno jej commitować ani reużywać między instancjami.

Licencja: Prowler jest rozpowszechniany na Apache License 2.0, i to w całości otwartej części projektu — CLI, Local Server, Local Dashboard i SDK. Jest to licencja permisywna, bez copyleftu, dopuszczająca komercyjne użycie bez żadnych warunków poza zachowaniem noty o prawach autorskich i wskazaniem istotnych zmian w plikach objętych licencją. Apache-2.0 udziela też jawnej licencji patentowej, co przy narzędziu bezpieczeństwa wchodzącym do procedur audytowych ma realne znaczenie. W praktyce oznacza to, że agencja może uruchamiać Prowlera w audytach dla klientów, dołączać jego raporty do swoich usług i budować na nim własne narzędzia bez obowiązku publikowania czegokolwiek. Granicą nie jest tu licencja, a znak towarowy i produkty komercyjne: sprzedawanie usługi pod nazwą Prowlera albo obiecywanie funkcji z Prowler Cloud w otwartej instancji to dwie różne rzeczy i tylko pierwsza z nich wymaga rozmowy z zespołem projektu.