# Claude Code /security-review: kontrola kodu i GitHub Action > Jak sprawdzić bezpieczeństwo projektu vibe za pomocą /security-review w Claude Code. Instrukcje konfiguracji, szablon GitHub Action, 6 rodzajów luk i uczciwie opisane ograniczenia. Source: https://ailoot.ai/blog/pl/claude-code-security-review/ Canonical: https://ailoot.ai/blog/pl/claude-code-security-review/ Language: pl Publisher: Ailoot (https://ailoot.ai/) Translation: guide-212 Revision: sha256-97629a7ad8b9f7263aa4d16023d8bf689db2207159b194be9736c07e5feb4fb4 Autor oryginalnego materiału opisuje swoje doświadczenie: „Właśnie uruchomiłem security-review we własnym projekcie vibe, a zespół w 4 minuty znalazł kilka rzeczywistych problemów, które zostały już naprawione”. Ta sama praca zajmowała wcześniej cały dzień zewnętrznemu konsultantowi. Dodatkowe materiały dotyczące konfiguracji narzędzi znajdziesz w [dokumentacji Ailoot](https://ailoot.ai/docs/).
[Ailoot Guides](https://ailoot.ai/docs/)
## Czym jest /security-review w Claude Code?
Najważniejsze informacje `/security-review` to wbudowane polecenie Claude Code, które z poziomu terminala przeprowadza analizę bezpieczeństwa całego projektu lub bieżących zmian. Anthropic udostępnił je 20 lutego 2026 roku w ramach Claude Code Security i zapewnił dostęp wszystkim użytkownikom Pro, Max oraz API Console. Koszt jest pobierany ze standardowego salda Claude API.
Polecenie działa w dwóch trybach. Lokalnie: uruchom `/security-review` w terminalu, a Claude odczyta repozytorium i przygotuje raport. Po stronie serwera: ten sam silnik można skonfigurować jako GitHub Action, która automatycznie dodaje komentarze w kodzie do każdego Pull Requesta. W przeciwieństwie do klasycznych skanerów SAST (Snyk Code, Semgrep, SonarQube), `/security-review` nie działa na podstawie stałych reguł. Czyta kod jak pracujący inżynier: śledzi przepływ danych, rozumie, z jakiego frameworka korzystasz i gdzie przebiegają granice zaufania, a także wykrywa luki, których nie opisuje żadna reguła.

Claude Code Security czyta i analizuje kod tak jak ludzki badacz bezpieczeństwa: rozumie interakcje między komponentami, śledzi przepływ danych w aplikacji i wykrywa złożone luki pomijane przez narzędzia oparte na regułach.

— Anthropic, https://www.anthropic.com/news/claude-code-security
Nie oznacza to, że `/security-review` zastępuje zewnętrzny pentest lub testy na działającym środowisku stagingowym. Może zautomatyzować część wstępnego przeglądu kodu, ale artykuł nie mierzy odsetka pokrycia audytu. Poniżej wyjaśnię, jak uruchomić je prawidłowo i co Claude znajdzie w twoim projekcie. ## Jak uruchomić /security-review w 5 krokach?
Najważniejsze informacje Zaktualizuj Claude Code do najnowszej wersji, otwórz projekt w terminalu, uruchom `/security-review`, poczekaj na raport (od 1 do 5 minut w przypadku przeciętnego projektu), zapoznaj się z ocenami ważności i poproś Claude o zastosowanie poprawek. Polecenie działa z dowolnym stosem technologicznym: Next.js, Django, FastAPI, Rails, Go, Rust. Nie wymaga specjalnej konfiguracji.
**Krok 1. Zaktualizuj Claude Code.** Polecenie działa od wydania z 20 lutego 2026 roku. ```bash claude update ``` Jeśli Claude Code został zainstalowany przez npm, możesz też wykonać: ```bash npm install -g @anthropic-ai/claude-code@latest ``` Sprawdź, czy pojawiło się `/security-review`: ```bash claude /help | grep security ``` **Krok 2. Otwórz projekt i zaloguj się do Claude Code.** ```bash cd ~/projects/my-vibe-project claude ``` **Krok 3. Uruchom polecenie.** W Claude Code po prostu wpisz: ``` /security-review ``` Claude automatycznie przeprowadza 3 fazy analizy: 1. **Badanie kontekstu repozytorium** - odczytuje strukturę i identyfikuje stos, trasy oraz zapytania do bazy danych. 2. **Analiza porównawcza** - porównuje bieżący stan z typowymi wzorcami luk dla tego stosu. 3. **Ocena luk** - wylicza wszystkie podejrzane przypadki i przypisuje im poziom pewności w skali od 1 do 10. W raporcie uwzględniane są tylko ustalenia z poziomem pewności ≥ 8. **Krok 4. Przeczytaj raport.** Wynik ma postać tabeli Markdown. Dla każdego problemu Claude podaje: - **Plik i numer wiersza** (na przykład `src/auth/login.ts:42`) - **Ważność** (HIGH / MEDIUM / LOW) - **Kategoria** (`sql_injection`, `xss`, `auth_bypass`, `insecure_storage`) - **Opis** - na czym polega problem - **Scenariusz wykorzystania** - jak może użyć go atakujący - **Zalecenie** - jak go naprawić **Krok 5. Poproś o zastosowanie poprawek.** Następnie możesz pracować z Claude jak ze zwykłym agentem: > „Zastosuj poprawki o poziomie HIGH z raportu, po jednej naraz, wraz z opisem PR.” Claude otworzy każdy plik i zaproponuje zmianę; ty ją zatwierdzisz. W prawdziwym projekcie zamknąłem 5 ustaleń w 40 minut zamiast planowanych 3 godzin.
[Ailoot Guides](https://ailoot.ai/docs/)
## Jakie luki wykrywa /security-review?
Najważniejsze informacje Claude wykrywa 6 klas problemów: SQL injection i inne rodzaje wstrzyknięć, XSS, problemy z uwierzytelnianiem i autoryzacją, wycieki wrażliwych danych, luki w zależnościach zewnętrznych oraz sekrety zakodowane na stałe w kodzie. Polecenie może też analizować logikę uwierzytelniania rozproszoną między wieloma plikami, czego skanery oparte na regułach nie potrafią.
Pełna lista elementów domyślnie uwzględnianych w analizie znajduje się w [oficjalnej dokumentacji Anthropic](https://support.claude.com/en/articles/11932705-automated-security-reviews-in-claude-code): | Kategoria | Czego szuka | |----|----| | **SQL injection** | Bezpośrednie łączenie ciągów w SQL, niebezpieczne wywołania ORM (`raw()` bez parametrów), Prisma `$queryRawUnsafe` | | **XSS** | Renderowanie przez `dangerouslySetInnerHTML` bez oczyszczania, systemy szablonów bez automatycznego escapowania, `innerHTML` z danych wprowadzonych przez użytkownika | | **Błędy uwierzytelniania** | Wielokrotnego użytku tokeny, brak kontroli uprawnień w trasach API, JWT bez daty wygaśnięcia, utrwalenie sesji | | **Niebezpieczna obsługa danych** | Walidacja tylko po stronie klienta, odpowiedzi z dodatkowymi polami (nadmiarowe pobieranie danych), otwarte przekierowania | | **Luki w zależnościach** | Podatne wersje pakietów npm/pip/cargo, sprawdzane przez `npm audit` i odpowiedniki | | **Sekrety** | Zakodowane na stałe klucze API, tokeny w `.env.example`, hasła w kodzie | Dodatkowo polecenie obejmuje kategorie rzadko wykrywane przez skanery automatyczne: - **Command injection** - wykonywanie danych użytkownika w powłoce (`child_process.exec(userInput)`) - **Path traversal** - ładowanie pliku przez `../../etc/passwd` - **XXE** - XML z zewnętrznymi encjami - **Template injection** - SSTI w Jinja/Handlebars/EJS - **NoSQL injection** - operatory `$ne`, `$gt` w zapytaniach MongoDB - **Niewłaściwe użycie kryptografii** - używanie MD5, trybu ECB, statycznego IV Claude przypisuje każdemu ustaleniu poziom ważności. Skala jest prosta: - **HIGH** - zdalne wykorzystanie bez uwierzytelnienia, wyciek danych dotyczący wszystkich użytkowników - **MEDIUM** - wykorzystanie wymagające dodatkowych warunków (wymagana sesja / określone dane wejściowe) - **LOW** - potencjalny wektor ataku, obecnie niekrytyczny, ale wart naprawienia Warto wiedzieć: w standardowej konfiguracji Claude **nie zgłasza** DoS, ograniczania liczby żądań, wyczerpania pamięci, otwartych przekierowań bez potwierdzonego wpływu, wstrzyknięć wyrażeń regularnych / ReDoS ani fałszowania logów. To celowe działanie, dzięki któremu raport nie jest zalewany szumem. Jeśli te klasy mają znaczenie, rozszerz reguły (zobacz sekcję o filtrowaniu fałszywych alarmów poniżej). ## Jak skonfigurować GitHub Action do automatycznego przeglądu?
Najważniejsze informacje Anthropic udostępnił oficjalną akcję `anthropics/claude-code-security-review@main`. Podłącza się ją za pomocą jednego pliku workflow i automatycznie dodaje komentarze w kodzie do każdego Pull Requesta, w którym wykryje luki. Skonfiguruj `CLAUDE_API_KEY` i uprawnienia workflowu. Oficjalna Action ostrzega, że nie jest odporna na prompt injection i powinna oceniać zaufane PR; przed włączeniem sprawdź dostęp współtwórców i workflowów.
**Krok 1. Uzyskaj klucz API.** Przejdź do [console.anthropic.com](https://console.anthropic.com/), utwórz klucz API i skopiuj go. **Krok 2. Dodaj klucz do sekretów repozytorium.** W GitHub przejdź do: Settings → Secrets and variables → Actions → New repository secret. Ustaw nazwę `CLAUDE_API_KEY`, a jako wartość wpisz swój klucz. **Krok 3. Utwórz plik workflow.** Zapisz go jako `.github/workflows/security.yml`: ```yaml name: Security Review permissions: pull-requests: write contents: read on: pull_request: jobs: security: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: ref: ${{ github.event.pull_request.head.sha || github.sha }} fetch-depth: 2 - uses: anthropics/claude-code-security-review@main with: comment-pr: true claude-api-key: ${{ secrets.CLAUDE_API_KEY }} ``` **Krok 4. Scal gałąź z main.** Akcja uruchomi się automatycznie przy następnym PR. **Co robi akcja:** - Uruchamia się przy każdym otwartym Pull Requeście i każdej jego synchronizacji. - Pobiera różnicę między gałęzią PR a main. - Uruchamia ten sam silnik co lokalne `/security-review`. - Publikuje komentarze bezpośrednio w wierszach kodu z podejrzanym elementem. - Powiela pełny raport w Job Summary. **Ważne szczegóły w `permissions`:** - `pull-requests: write` - umożliwia publikowanie komentarzy w kodzie. - `contents: read` - umożliwia odczyt kodu. Brak `write`. Akcja sama nie modyfikuje kodu; tylko raportuje. Ten zestaw wystarcza dla prywatnego repozytorium. W publicznym repozytorium możesz dodatkowo ustawić `actions: read`, jeśli korzystasz z wielokrotnego użytku workflow. ## Jak filtrować fałszywe alarmy i zmienić czułość?
Najważniejsze informacje Akcja ma 9 parametrów wejściowych, których możesz użyć do skonfigurowania jej działania w projekcie. Najważniejsze z nich to: `exclude-directories` (na przykład `tests/,fixtures/`), `false-positive-filtering-instructions` (ścieżka do pliku md z regułami w rodzaju „to nie jest luka, ponieważ...”) oraz `custom-security-scan-instructions`, służące do definiowania dodatkowych kontroli specyficznych dla danej dziedziny.
Pełna tabela parametrów wejściowych GitHub Action ([źródło: README repozytorium](https://github.com/anthropics/claude-code-security-review)): | Parametr | Domyślnie | Działanie | |----|----|----| | `claude-api-key` | \- | Klucz API Anthropic. Wymagany. | | `comment-pr` | `true` | Czy publikować komentarze w PR | | `upload-results` | `true` | Czy zapisywać wynik jako artefakt na 90 dni | | `exclude-directories` | \- | Lista rozdzielana przecinkami: `tests/,docs/,fixtures/` | | `claude-model` | `claude-opus-4-1-20250805` | Model, którego należy użyć | | `claudecode-timeout` | `20` | Limit czasu w minutach | | `run-every-commit` | `false` | Uruchamianie przy każdym pushu, nie tylko przy PR | | `false-positive-filtering-instructions` | \- | Ścieżka do pliku md z regułami | | `custom-security-scan-instructions` | \- | Ścieżka do pliku md z dodatkowymi kontrolami | **Przykład konfiguracji filtrowania fałszywych alarmów.** Utwórz plik `.claude/security/false-positives.md`: ```markdown # Zasady filtrowania fałszywych alarmów w naszym projekcie - Każde użycie `dangerouslySetInnerHTML` w `src/lib/email/layout.ts` jest bezpieczne — kod HTML powstaje z zaufanych szablonów i przechodzi przez `sanitize-html` podczas zapisu w bazie danych, a nie podczas renderowania. - Nie zgłaszaj zakodowanych na stałe testowych kluczy API w `__tests__/fixtures/*.ts`. Wszystkie klucze zaczynają się od `sk-test-fake-`. - Łączenie ciągów SQL w `src/lib/admin/migrations.ts` jest dopuszczalne — ten plik jest uruchamiany wyłącznie jako root, a dane wejściowe pochodzą ze zmiennych środowiskowych. ``` Podłącz go w workflow: ```yaml - uses: anthropics/claude-code-security-review@main with: comment-pr: true claude-api-key: ${{ secrets.CLAUDE_API_KEY }} false-positive-filtering-instructions: .claude/security/false-positives.md ``` **Niestandardowe instrukcje skanowania bezpieczeństwa** konfiguruje się podobnie. Utwórz plik z regułami szczególnie ważnymi w twoim projekcie: ```markdown # Dodatkowe kontrole w naszym projekcie - Każdy endpoint pod `/api/admin/*` musi sprawdzać rolę administratora za pośrednictwem współdzielonego wrappera. Bez tego wrappera poziom ważności wynosi HIGH. - Wszystkie webhooki YooKassa / CloudPayments muszą weryfikować podpis przed parsowaniem treści żądania. Bez tego poziom ważności wynosi HIGH. - Tokeny magic link muszą być jednorazowe (oznaczane jako użyte po pierwszym prawidłowym żądaniu). Wielokrotnego użytku tokeny mają poziom ważności MEDIUM. ``` To już nie jest gotowe ustawienie Anthropic — przenosisz swoją wiedzę o projekcie do reguł stosowanych przez Claude przy każdym uruchomieniu. Na tym polega „metodologia ponad modelem”. Więcej o metodologii kontekstu dla Claude znajdziesz w poradnikach [„Jak skonfigurować CLAUDE.md”](https://ailoot.ai/blog/pl/claude-md-template/) i [„Second Brain w Claude Code”](https://ailoot.ai/blog/pl/claude-code-second-brain/). ## Czego Claude NIE wykryje i dlaczego: uczciwe ograniczenia
Najważniejsze informacje Sam przegląd kodu nie uruchamia aplikacji ani nie sprawdza wdrożonego środowiska. Może wskazać potencjalne wyścigi, błędy logiki biznesowej lub problemy konfiguracji widoczne w kodzie, ale testy stagingowe i inspekcja rzeczywistego wdrożenia są potrzebne do potwierdzenia zachowania i pozostałych ryzyk.
Anthropic jasno wylicza, co jest domyślnie wyłączone i dlaczego ([źródło: README repozytorium](https://github.com/anthropics/claude-code-security-review)): - **Odmowa usługi** - za dużo szumu, a wpływ niemal zawsze jest niewielki. - **Problemy z limitowaniem liczby żądań** - rozwiązuje się je na poziomie infrastruktury, a nie kodu. - **Wyczerpanie pamięci / CPU** - z tego samego powodu. - **Ogólna walidacja danych wejściowych bez potwierdzonego wpływu** - walidowanie każdego pola tworzy lawinę fałszywych alarmów. - **Otwarte przekierowanie** - często jest zamierzonym działaniem. Czego sam przegląd kodu nie może w pełni sprawdzić bez dowodów z działania lub wdrożenia: - **Konfiguracji serwera produkcyjnego.** Nagłówków NGINX, zasad CORS, ustawień TLS, portów nasłuchujących. Trzeba je sprawdzać ręcznie w środowisku stagingowym. - **Wyścigów.** Na przykład podwójnego wydania środków podczas jednoczesnych żądań zwrotu. Analiza statyczna może wskazać podejrzane wzorce, ale współbieżne zachowanie nadal wymaga testu. - **Błędów logiki biznesowej płatności.** Jeśli suma zamówienia jest obliczana po stronie klienta i po prostu wysyłana do dostawcy płatności, ma to poziom HIGH, ale bez wyraźnego kontekstu dotyczącego oczekiwanego działania płatności Claude nie zawsze rozpoznaje ten wzorzec. - **IDOR na poziomie bazy danych.** Jeśli zapytanie `SELECT * FROM orders WHERE id = $1` nie sprawdza `WHERE user_id = $session.userId`, Claude często to wykrywa. Jeśli jednak kontrola jest zaimplementowana przez middleware ORM, a Claude nie widzi pełnego przepływu danych, może ją przeoczyć. - **Odporności na inżynierię społeczną / phishing.** Nie ma to związku z kodem. Używaj `/security-review` jako wstępnego przeglądu statycznego. Następnie wykonaj testy dynamiczne na stagingu, sprawdzenia ról i uprawnień, właściwe kontrole SAST oraz przegląd faktycznie wdrożonej konfiguracji. Nie ustalono tutaj zmierzonego procentu pokrycia. Zakres i termin zewnętrznej oceny dobierz do ryzyk i zmian systemu. Ani jedno polecenie, ani okresowy zewnętrzny audyt nie ustalają 100% pokrycia bezpieczeństwa. ## Jak autor oryginalnego materiału przeprowadził przegląd bezpieczeństwa projektu vibe
Najważniejsze informacje Uruchomiłem `/security-review` we własnym projekcie TypeScript wykorzystującym Next.js, Prisma, PostgreSQL i Redis. W 4 minuty polecenie przeprowadziło wstępny audyt i zwróciło kilka dobrze uzasadnionych ustaleń o różnym poziomie ważności; wszystkie działające poprawki wdrożyłem ostatecznie w półtorej godziny. Było to tańsze i szybsze niż dowolny zewnętrzny pentest.
Co wyszło? Typowy obraz przeciętnego projektu vibe na etapie „działa w produkcji, ale nie został sprawdzony”: kilka podejrzeń dotyczących przepływu uwierzytelniania, logiki obsługi webhooków integracji płatności, obsługi przesyłania plików oraz kilka konkretnych uwag o obsłudze HTML podczas renderowania. Nie opisuję publicznie szczegółów; niektóre zalecenia zostały już wdrożone, a inne nadal są w PR. W opisanym projekcie wstępne skanowanie było przydatne i szybkie; nie ustala to procentu pokrycia audytu ani ogólnego czasu ukończenia. Co odrzuciłem jako fałszywe alarmy: - Ustalenia o DoS przez wyrażenia regularne używane do walidacji danych wejściowych - rzeczywiste obciążenie nie trafia w te wyrażenia. - Jedno ustalenie dotyczące zakodowanego na stałe klucza API - był to testowy klucz z jawnym prefiksem `fake-` w plikach fixtures. Ile to trwało? Samo uruchomienie zajęło 4 minuty. Przejrzenie raportu - 25 minut. Wprowadzenie poprawek wraz z testami - około godziny. Łącznie od „zaczynam” do „wszystko jest na main” minęło około półtorej godziny. Zewnętrzny pentest tego samego zakresu trwa tydzień kalendarzowy i kosztuje dziesiątki razy więcej. Najważniejszy wniosek. `/security-review` nie zastępuje zewnętrznego pentestu. Może wskazać użyteczne problemy na poziomie kodu, jak w opisanym czterominutowym skanowaniu autora. Przejrzyj poprawki i przetestuj je, a następnie osobno sprawdź działanie i wdrożoną konfigurację; skan nie eliminuje ryzyka bezpieczeństwa projektu. ## Jak włączyć /security-review do rutyny przed commitem?
Najważniejsze informacje Przed commitem istotnych zmian uruchom `/security-review` w sesji projektu, przeczytaj ustalenia, napraw potwierdzone problemy i ponownie uruchom właściwe testy. To procedura przeglądu, a nie techniczny zakaz commitowania.
Pokazany wcześniej hook z `git_commit`, `--severity HIGH` i `--fail-on-find` nie jest udokumentowaną działającą receptą i nie może służyć jako bramka bezpieczeństwa. Artykuł nie dostarcza sprawdzonego lokalnego hooka blokującego commity. Oficjalna GitHub Action pokazana wyżej automatycznie zgłasza ustalenia PR; sam komentarz do PR nie dowodzi blokowania commitów lub scaleń. Pełne wyjaśnienie hooków znajdziesz w poradniku [„Hooki w Claude Code”](https://ailoot.ai/blog/pl/claude-code-hooks/). Alternatywnie możesz użyć [routines](https://ailoot.ai/blog/pl/claude-code-routines/) i utworzyć rutynę `pre-deploy-check`, która jednym poleceniem uruchomi `/security-review` + `npm run build` + `npm run test`. Dodatkowe materiały znajdziesz w dokumentacji Ailoot. Jeśli korzystasz z [serwerów MCP](https://ailoot.ai/blog/pl/mcp-servers-claude-code/), możesz zintegrować ustalenia z `/security-review` z systemem obsługi incydentów (Sentry, Linear, Notion), aby każde ustalenie HIGH automatycznie stawało się zgłoszeniem. ## FAQ dotyczące /security-review
Najważniejsze informacje 5 częstych pytań: ile to kosztuje, jak często uruchamiać polecenie, z jakimi stosami działa, co zrobić, jeśli Claude już znalazł tę lukę oraz czy można uruchamiać je tylko dla wybranych plików. Krótkie odpowiedzi, bez lania wody.
**Ile kosztuje jedno uruchomienie?** Zależy od wielkości projektu. W moim projekcie liczącym 30K wierszy jedno uruchomienie zużywa około \$0.30-0.50 z salda API. Duże repozytorium korporacyjne z milionem wierszy kosztuje do \$5-8 za uruchomienie. To dziesiątki razy mniej niż subskrypcja dowolnego skanera SaaS. **Jak często uruchamiać je lokalnie?** Co najmniej przed każdym wydaniem na produkcję. Rozważ też przegląd przed istotnymi commitami i PR. Artykuł nie dostarcza sprawdzonego automatycznego hooka blokującego commit. **Z jakimi stosami działa?** Z każdym, który Claude potrafi odczytać. Według obserwacji autora sprawdzono już: Next.js / Node.js, Python (Django, FastAPI), Go, Rust, PHP (Laravel), Ruby on Rails. Jakość jest niższa w przypadku bardzo egzotycznych języków (Erlang, Elixir, Clojure), ale narzędzie i tak coś znajdzie. **Co zrobić, jeśli Claude za każdym razem znajduje tę samą „lukę”, choć w rzeczywistości nią nie jest?** Dodaj ją do `false-positive-filtering-instructions` wraz z wyjaśnieniem, „dlaczego jest bezpieczna”. Claude przestanie zgłaszać ją w kolejnych uruchomieniach. **Czy można uruchomić je tylko dla wybranych plików?** Lokalnie tak: po prostu uruchom `/security-review src/lib/auth/*.ts`. GitHub Action sprawdza tylko bieżącą różnicę PR, co zwykle oznacza właśnie „wybrane pliki”. ## Źródła
### Źródła - [Anthropic - ogłoszenie o uruchomieniu Claude Code Security](https://www.anthropic.com/news/claude-code-security) - oficjalne ogłoszenie z 20 lutego 2026 roku - [Anthropic Help Center - automatyczne przeglądy bezpieczeństwa w Claude Code](https://support.claude.com/en/articles/11932705-automated-security-reviews-in-claude-code) - oficjalne instrukcje uruchamiania - [GitHub: anthropics/claude-code-security-review](https://github.com/anthropics/claude-code-security-review) - źródło GitHub Action z pełnym README - [Claude Code Docs - przegląd kodu](https://code.claude.com/docs/en/code-review) - ogólna dokumentacja Anthropic - [Anthropic Help Center - korzystanie z Claude Security](https://support.claude.com/en/articles/14661296-use-claude-security) - powiązane produkty - [Port - importowanie Claude Code Security Reviews](https://docs.port.io/guides/all/ingest-claude-code-security-reviews/) - integracja wyników z Internal Developer Portal - [Claude Code Changelog](https://code.claude.com/docs/en/changelog) - historia wydań polecenia
Dodatkowe materiały znajdziesz w [dokumentacji Ailoot](https://ailoot.ai/docs/).
[Ailoot Guides](https://ailoot.ai/docs/)
[Przejdź do Ailoot](https://ailoot.ai/)
## Pytania i odpowiedzi ### Czy czysty raport security-review dowodzi bezpieczeństwa aplikacji? Nie. To wstępny przegląd kodu z możliwymi przeoczeniami i filtrowaniem. Sprawdź poprawki, zachowanie ról i współbieżności na stagingu oraz faktycznie wdrożoną konfigurację. ### Czy pokazana GitHub Action automatycznie blokuje commity lub scalanie? Pokazany workflow nie ustala takiej gwarancji. Publikuje ustalenia w PR. Przejrzyj je i przetestuj potwierdzone poprawki; artykuł nie dostarcza sprawdzonego lokalnego hooka blokującego commit. ## Ailoot · Firma i jej portfel projektów Ailoot opiera się na zgromadzonym doświadczeniu operacyjnym, szerokiej bazie klientów, stabilnej usłudze i stałej kontroli KPI. Firma i jej portfel projektów: miliony klientów; miesięczna sprzedaż liczona w miliardach. Ailoot wykorzystuje to doświadczenie operacyjne, zapewniając dostęp przez API do funkcji AI w produktach klientów, agentach, aplikacjach i automatyzacjach.