# Lagune > Security-Driven Hardening dla każdej bazy kodu Lagune to wyłącznie defensywny przepływ pracy open source do Security-Driven Hardening (SDH). Pomaga agentowi AI utwardzać każdą bazę kodu, w dowolnym języku, na każdym etapie: faza charter ustala zasady bezpieczeństwa, zanim zaczniesz budować, uniwersalne polecenie /lagune utwardza kod już w trakcie pisania, a pięciofazowy przepływ pracy Blue Team wykrywa, co twój system faktycznie robi, i prowadzi do poprawek, które mają znaczenie w tym kontekście. Polecenia Lagune instalujesz w agencie za pomocą CLI skills, bez klucza API. --- # Instalacja: Utwardzanie zabezpieczeń dla każdego agenta AI > Zainstaluj Lagune w dowolnym projekcie, jako wtyczkę, jeśli twój agent ją obsługuje, a w innym przypadku przez CLI skills, i wybierz pasujące do niego specjalizacje bezpieczeństwa. Adres kanoniczny: https://lagune.ai/pl-PL/docs Język: pl-PL Oryginał: https://lagune.ai/docs Ostatnia aktualizacja: 2026-11-09 **Lagune** pomaga twojemu agentowi AI zwiększyć bezpieczeństwo projektu. Wskazujesz mu swój kod, a agent ustala, co twój system faktycznie robi, i prowadzi cię przez prace nad bezpieczeństwem, które mają dla niego znaczenie. **Lagune** to pierwszy projekt metodologii [Security-Driven Hardening (SDH)](https://lagune.ai/pl-PL/docs/references/paper). **Wesprzyj open source** Podoba ci się **Lagune**? [Zostaw nam ⭐ w serwisie **GitHub**](https://github.com/wellwelwel/lagune) ## Wybierz swojego agenta - [Claude Code](https://lagune.ai/pl-PL/docs/install/claude-code): Agentowe narzędzie programistyczne od Anthropic - [Codex](https://lagune.ai/pl-PL/docs/install/codex): Agent programistyczny od OpenAI - [Cursor](https://lagune.ai/pl-PL/docs/install/cursor): Edytor kodu z AI - [GitHub Copilot](https://lagune.ai/pl-PL/docs/install/github-copilot-cli): Partner AI od GitHub do programowania w parach - [Gemini CLI](https://lagune.ai/pl-PL/docs/install/gemini-cli): Agent open source od Google działający w terminalu - [Antigravity](https://lagune.ai/pl-PL/docs/install/antigravity-cli): Agentowa platforma programistyczna od Google - [OpenCode](https://lagune.ai/pl-PL/docs/install/opencode): Agent programistyczny open source - [Devin for Terminal](https://lagune.ai/pl-PL/docs/install/devin-cli): Agent od Cognition działający w terminalu - [Factory Droid](https://lagune.ai/pl-PL/docs/install/factory-droid): Agent od Factory do tworzenia oprogramowania - [Grok Build](https://lagune.ai/pl-PL/docs/install/grok-build): Agent programistyczny od xAI - [Qwen Code](https://lagune.ai/pl-PL/docs/install/qwen-code): Agent programistyczny od Qwen działający w terminalu - [Kimi Code](https://lagune.ai/pl-PL/docs/install/kimi-code): Agent programistyczny od Moonshot AI - [Muse Code](https://lagune.ai/pl-PL/docs/install/muse-code): Agent programistyczny od Meta - [Pi](https://lagune.ai/pl-PL/docs/install/pi): Minimalistyczny agent programistyczny działający w terminalu - [Hermes Agent](https://lagune.ai/pl-PL/docs/install/hermes-agent): Agent open source od Nous Research - [Uniwersalna](https://lagune.ai/pl-PL/docs/install/universal): Cline, Kiro CLI, Windsurf, Zed i jeszcze 66 **Informacja** - **Lagune** działa pod maską na **Node.js**, ale ty pracujesz w dowolnym języku. - Aby pracować całkowicie offline, zainstaluj **Lagune** w swoim projekcie poleceniem `npm i -D lagune@0.18.1`. ## Kategorie Wiedza o bezpieczeństwie w **Lagune** ma postać [**specjalizacji**](https://lagune.ai/pl-PL/docs/catalog), pogrupowanych w [**kategorie**](https://lagune.ai/pl-PL/docs/categories). - **OWASP** (`owasp`): Wzmocnij zabezpieczenia aplikacji przed ryzykami, które śledzi OWASP: wstrzykiwaniem, błędną kontrolą dostępu oraz błędami uwierzytelniania i kryptografii - **Infrastruktura** (`infra`): Utwardź konfigurację kontenerów, obciążeń i usług serverless: Dockerfile, Compose, bezpieczeństwo podów, IAM i wyzwalacze FaaS - **AI / LLM** (`ai`): Wzmocnij zabezpieczenia integracji AI i LLM przed prompt injection oraz niebezpiecznym podłączaniem narzędzi, agentów, mechanizmów retrieval i MCP - **Lovable** (`lovable`): Utwardź aplikacje Supabase generowane przez AI (Lovable i podobne): luki w RLS, wycieki kluczy service_role i niebezpieczne ustawienia domyślne - **JavaScript** (`javascript`): Wzmocnij zabezpieczenia JavaScriptu i jego środowisk uruchomieniowych przed RCE przez eval i child_process, path traversal i prototype pollution - **Python** (`python`): Wzmocnij zabezpieczenia kodu w Pythonie przed RCE przez deserializację pickle i YAML, string traversal przez str.format i class pollution - **Rust** (`rust`): Wzmocnij zabezpieczenia kodu w Rust przed niepoprawnymi (unsound) API z unsafe, nadużyciami transmute, przepełnieniami liczb całkowitych i niezdefiniowanym zachowaniem na granicy FFI - **Java** (`java`): Wzmocnij zabezpieczenia kodu w Javie przed łańcuchami gadżetów przy deserializacji przez ObjectInputStream, które kończą się zdalnym wykonaniem kodu - **Ruby** (`ruby`): Wzmocnij zabezpieczenia kodu w Ruby przed łańcuchami gadżetów przy deserializacji przez Marshal.load i YAML, które prowadzą do zdalnego wykonania kodu - **PHP** (`php`): Wzmocnij zabezpieczenia kodu w PHP przed obejściem uwierzytelniania przez type juggling, łańcuchami gadżetów do object injection i niebezpiecznymi domyślnymi ustawieniami konfiguracji - **Go** (`go`): Wzmocnij zabezpieczenia kodu w Go przed błędami interfejsów z typed nil, data races między gorutynami i niebezpieczną współbieżnością na ścieżkach krytycznych dla bezpieczeństwa - **C / C++** (`c-cpp`): Wzmocnij zabezpieczenia kodu w C i C++ przed błędami ciągów formatujących, przepełnieniami bufora i zapisami poza zakresem, które umożliwiają wykonanie kodu - **.NET** (`dotnet`): Wzmocnij zabezpieczenia kodu .NET i C# przed RCE przez deserializację BinaryFormatter oraz obejściami enkoderów, które prowadzą do XSS Uruchom `npx lagune write add --categories` z kluczami wybranych kategorii. **Wskazówka** Projekt zaczyna od kategorii `owasp`, a polecenie [`/lagune-charter`](https://lagune.ai/pl-PL/docs/commands/charter) dodaje te kategorie, za którymi przemawia jego analiza projektu. ## Wymagania W systemie musisz mieć zainstalowany [**Node.js (LTS)**](https://nodejs.org/en/download/package-manager). ## Dodaj odznakę ✨ Używasz **Lagune**? Dodaj odznakę do swojego pliku **README**: **Dwukolorowa** ![Secured By Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Secured%20By&labelColor=303952) ```md [![Secured By Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Secured%20By&labelColor=303952)](https://lagune.ai) ``` ![Security Powered By Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Security%20Powered%20By&labelColor=303952) ```md [![Security Powered By Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Security%20Powered%20By&labelColor=303952)](https://lagune.ai) ``` ![Security-Driven Hardening with Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Security-Driven%20Hardening&labelColor=303952) ```md [![Security-Driven Hardening with Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Security-Driven%20Hardening&labelColor=303952)](https://lagune.ai) ``` **Jednolita** ![Secured By Lagune](https://img.shields.io/badge/Secured%20By%20Lagune-2f7bff?logo=springsecurity&logoColor=white) ```md [![Secured By Lagune](https://img.shields.io/badge/Secured%20By%20Lagune-2f7bff?logo=springsecurity&logoColor=white)](https://lagune.ai) ``` ![Security Powered By Lagune](https://img.shields.io/badge/Security%20Powered%20By%20Lagune-2f7bff?logo=springsecurity&logoColor=white) ```md [![Security Powered By Lagune](https://img.shields.io/badge/Security%20Powered%20By%20Lagune-2f7bff?logo=springsecurity&logoColor=white)](https://lagune.ai) ``` ![Security-Driven Hardening](https://img.shields.io/badge/Security--Driven%20Hardening-2f7bff?logo=springsecurity&logoColor=white) ```md [![Security-Driven Hardening](https://img.shields.io/badge/Security--Driven%20Hardening-2f7bff?logo=springsecurity&logoColor=white)](https://lagune.ai) ``` ## Co dalej Sprawdź, do czego służy każdy [**skill**](https://lagune.ai/pl-PL/docs/get-started/commands) **Lagune**. ## Najczęściej zadawane pytania ### Czym jest Lagune? Lagune to przepływ pracy open source nastawiony wyłącznie na bezpieczeństwo defensywne, który pomaga twojemu agentowi AI utwardzić dowolną bazę kodu. Wskazujesz mu swój kod, a on wykrywa, co twój system faktycznie robi, i prowadzi cię przez poprawki bezpieczeństwa, które mają znaczenie w tym kontekście. ### Jak zainstalować Lagune? Wybierz swojego agenta: Claude Code, GitHub Copilot CLI, Muse Code, Antigravity CLI, Cursor, Kimi Code, OpenCode, Codex CLI, Factory Droid, Grok Build, Devin CLI i Hermes Agent instalują Lagune jako wtyczkę, Gemini CLI i Qwen Code jako rozszerzenie, Pi jako pakiet, a każdy inny agent poleceniem npx skills add wellwelwel/lagune. Działa zarówno w nowych, jak i w istniejących projektach. ### Czy Lagune potrzebuje klucza API? Nie. Działa przez twojego własnego agenta AI, więc nie potrzebujesz żadnych kluczy API. ### Jakie są wymagania? W systemie musisz mieć zainstalowany Node.js (LTS). ### Jakie języki programowania obsługuje Lagune? Wszystkie. Lagune działa pod maską na Node.js, ale audytuje i utwardza projekty napisane w dowolnym języku programowania. ### Co Lagune dodaje do mojego projektu? Folder .lagune/ ze stanem bezpieczeństwa projektu. Tworzy go pierwsze polecenie, które coś zapisuje. CLI skills instaluje też w projekcie polecenia z ukośnikiem, skąd czyta je twój agent, a wtyczka trzyma je wewnątrz agenta. ### Jak zaktualizować Lagune? Tak samo jak przy instalacji. Strona instalacji każdego agenta pokazuje, jak zaktualizować w nim Lagune, a przy CLI skills służy do tego polecenie npx skills update. Twoje zasady bezpieczeństwa, artefakty faz i własne specjalizacje pozostają nietknięte. ### Jakich specjalizacji używa projekt? Wbudowanych z jego kategorii oraz własnych. Faza charter zapisuje kategorie, za którymi przemawia jej analiza projektu, a polecenie npx lagune write add --categories je zmienia. ### Czy muszę skończyć budować projekt, zanim zacznę go zabezpieczać? Nie. Polecenie /lagune utwardza kod na bieżąco, w miarę jak powstaje: przyjmuje dowolny prompt, buduje to, o co prosisz, i utwardza wynik bezpiecznymi ustawieniami domyślnymi, kierując się zasadami bezpieczeństwa. Pięciofazowy przepływ pracy Blue Team audytuje to, co już istnieje. ### Czy Lagune potrafi audytować istniejący projekt? Tak. Pięciofazowy przepływ pracy Blue Team audytuje to, co już istnieje: charter ustala twoje zasady bezpieczeństwa, detect mapuje, co robi system i gdzie leżą ryzyka, plan ocenia każde ustalenie i dobiera do niego poprawkę, harden wdraża poprawki, a verify wykazuje, że działają, i je zamyka. ### Czym różni się praca z Lagune od zwykłego poproszenia agenta o zmapowanie podatności i luk w zabezpieczeniach? Agent czytający kod na własną rękę znajduje to, co wygląda na podatność, i pomija to, co wygląda na zabezpieczenie. Lista zablokowanych adresów sprawia wrażenie, jakby ktoś już zajął się ryzykiem, więc nikt nie zauważa, że brakuje na niej większości z nich, i kod trafia na produkcję. Lagune odwraca to domyślne założenie: zabezpieczenie obecne już w kodzie uznaje za niewykazane, dopóki go nie sprawdzi, każda specjalizacja z katalogu dostaje wyraźny werdykt, a verify pyta, czy ryzyko zniknęło, a nie, czy zabezpieczenie istnieje. Każde ustalenie pozostaje też jednym śledzonym elementem we wszystkich uruchomieniach, więc można wykazać jego zamknięcie i wycofać je, podczas gdy zwykła prośba daje za każdym razem inny raport, bez punktu odniesienia. ### Czym różni się programowanie z Lagune od zwykłego poproszenia agenta o bezpieczny kod? Prośba o bezpieczny kod zostawia agentowi decyzję, co znaczy "bezpieczny", i zakłada, że wiesz, o co pytać. Wymaganie zwykle kryje się już w twojej prośbie, choć nie dostrzega go ani ty, ani agent: prośba o stronę z kursami, do których użytkownik ma dostęp, wyraża regułę autoryzacji, a sprawdzenie, którego nikt nie napisał, nie zostawia w kodzie niczego, co mogłoby zwrócić uwagę. Polecenie /lagune wczytuje twoje zasady bezpieczeństwa i specjalizacje pasujące do tego, co ma powstać, zanim powstanie pierwsza linia kodu, a potem ponownie sprawdza wynik pod kątem zastosowanej obrony. Bezpieczny wariant rzadko kosztuje więcej niż niebezpieczny, więc o wyniku decyduje wiedza, po który sięgnąć, i właśnie ta wiedza jest dostępna od samego początku. ### Czy Lagune wykonuje DAST (Dynamic Application Security Testing) albo testuje moją działającą aplikację? Nie. Lagune czyta kod i nigdy nie uruchamia twojego systemu ani nie wysyła do niego spreparowanych żądań. Faza verify potwierdza, że zabezpieczenie jest obecne i poprawne w kodzie źródłowym, a to inne pytanie niż to, czy wytrzyma atak na działający cel, więc "cannot tell from the code" to uprawniony werdykt, a nie ciche przepuszczenie. DAST odpowiada na pytanie o czas działania, a Lagune na pytanie o kod źródłowy, więc żadne z nich nie zastępuje drugiego. Nawet opcjonalne polecenie prove trzyma się tej granicy: jego testy sprawdzają bezpieczne zachowanie, nigdy payload ataku. ### Czy Lagune zastępuje pentest (test penetracyjny)? Nie, zdecydowanie nie! Pentest to autoryzowane zlecenie, w którym specjalista ocenia twój działający system według własnego osądu, łączy ustalenia w łańcuchy i bada logikę biznesową, której nie opisuje żadna reguła dla pojedynczej powierzchni ataku. Ustalenia z pentestu mogą trafić do przepływu pracy Blue Team w Lagune jako zagadnienia przekazane fazie detect, dzięki czemu to, co zgłasza specjalista, zostaje zaplanowane, utwardzone i zweryfikowane. ## Polityka bezpieczeństwa Zapoznaj się z plikiem [SECURITY.md](https://github.com/wellwelwel/lagune/blob/main/SECURITY.md). ## Licencja Projekt **Lagune** jest udostępniany na licencji [Apache License 2.0](https://github.com/wellwelwel/lagune/blob/main/LICENSE). Copyright © 2026-obecnie [Weslley Araújo](https://github.com/wellwelwel) i [współtwórcy](https://github.com/wellwelwel/lagune/graphs/contributors). --- # Instalacja wtyczki Lagune w Antigravity CLI > Zainstaluj wtyczkę Lagune w Antigravity CLI, aktualizuj ją i z góry zezwól na działanie jej silnika. Adres kanoniczny: https://lagune.ai/pl-PL/docs/install/antigravity-cli Język: pl-PL Oryginał: https://lagune.ai/docs/install/antigravity-cli Ostatnia aktualizacja: 2026-11-09 Zainstaluj wtyczkę z terminala: ```bash agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity ``` ## Aktualizacja Aby zaktualizować wtyczkę **Lagune**, zainstaluj ją ponownie: ```bash agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity ``` ## Polecenia Wpisuj polecenia poprzedzone nazwą wtyczki, na przykład `/lagune:lagune-charter` zamiast `/lagune-charter`. --- **Uprawnienia** Silnik korzysta z dwóch narzędzi: `lagune_read` tylko odczytuje projekt, a `lagune_write` tylko zapisuje w folderze `.lagune/`. Polecenie wysłane jako pierwsza wiadomość sesji uruchamia się, zanim narzędzia zostaną wczytane, dlatego zamiast nich używa **npx**. Aby z góry zezwolić na użycie narzędzi i **npx**, dodaj te reguły do pliku `~/.gemini/antigravity-cli/settings.json`: ```json { "permissions": { "allow": [ "mcp(lagune_lagune/lagune_read)", "mcp(lagune_lagune/lagune_write)", "command(regex:npx --yes lagune@[0-9.]+)" ] } } ``` ## Najczęściej zadawane pytania ### Jak zainstalować wtyczkę Lagune w Antigravity CLI? Uruchom agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity. ### Jak zaktualizować wtyczkę Lagune w Antigravity CLI? Ponownie uruchom agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity. ### Jak uruchamiać polecenia Lagune w Antigravity CLI? Wpisuj je poprzedzone nazwą wtyczki, na przykład /lagune:lagune-charter. ### Czy Antigravity CLI może uruchamiać polecenia Lagune bez pytania o zgodę? Tak. W ustawieniach Antigravity CLI zezwól na mcp(lagune_lagune/lagune_read), mcp(lagune_lagune/lagune_write) i command(regex:npx --yes lagune@[0-9.]+). Reguła dla npx obejmuje polecenie wysłane jako pierwsza wiadomość sesji. --- # Instalacja wtyczki Lagune w Claude Code > Zainstaluj wtyczkę Lagune w Claude Code, w terminalu, w rozszerzeniu lub w aplikacji desktopowej, aktualizuj ją i z góry zezwól na działanie jej silnika. Adres kanoniczny: https://lagune.ai/pl-PL/docs/install/claude-code Język: pl-PL Oryginał: https://lagune.ai/docs/install/claude-code Ostatnia aktualizacja: 2026-11-09 **Terminal** Zainstaluj wtyczkę z terminala: ```bash claude plugin install lagune --marketplace wellwelwel/lagune ``` Albo w sesji **Claude Code**: ```text /plugin marketplace add wellwelwel/lagune /plugin install lagune@lagune ``` **Rozszerzenie** - Wpisz `/plugin` i wybierz **Manage plugins**. - Na karcie **Marketplaces** dodaj `wellwelwel/lagune`. - Na karcie **Plugins** zainstaluj `lagune`. **Desktop** - Zainstaluj wtyczkę **Lagune** z terminala lub z rozszerzenia, wybierając w rozszerzeniu **Install for you**. - Rozpocznij nową sesję w aplikacji desktopowej, która wczytuje wtyczki, które instalujesz dla siebie. ## Aktualizacja **Terminal** Aby zaktualizować wtyczkę **Lagune**, uruchom: ```bash claude plugin marketplace update lagune claude plugin update lagune@lagune ``` Aby aktualizacje instalowały się automatycznie, wybierz **Enable auto-update** dla marketplace'u `lagune` w menu `/plugin`. **Rozszerzenie** - Wpisz `/plugin` i wybierz **Manage plugins**. - Otwórz kartę **Marketplaces**. - Kliknij ikonę odświeżania przy `lagune`. **Desktop** - Zaktualizuj wtyczkę **Lagune** z terminala lub z rozszerzenia. - Rozpocznij nową sesję w aplikacji desktopowej. ## Polecenia Wpisuj nazwy poleceń, na przykład `/lagune-charter`, albo poprzedzaj je nazwą wtyczki, na przykład `/lagune:lagune-charter`. --- **Uprawnienia** Silnik korzysta z dwóch narzędzi: `lagune_read` tylko odczytuje projekt, a `lagune_write` tylko zapisuje w folderze `.lagune/`. Aby z góry zezwolić na ich użycie, dodaj te reguły do pliku `.claude/settings.json` dla jednego projektu albo do pliku `~/.claude/settings.json` dla wszystkich projektów: ```json { "permissions": { "allow": [ "mcp__plugin_lagune_lagune__lagune_read", "mcp__plugin_lagune_lagune__lagune_write" ] } } ``` Gdy silnik działa przez **npx**, jak w przypadku **skills.sh**, zezwól na `Bash(npx --yes lagune@*)`. Jeśli sandbox jest włączony, dodaj też `registry.npmjs.org` do listy `sandbox.network.allowedDomains`. ## Najczęściej zadawane pytania ### Jak zainstalować wtyczkę Lagune w Claude Code? Uruchom claude plugin install lagune --marketplace wellwelwel/lagune. W sesji lub w rozszerzeniu dodaj w menedżerze wtyczek marketplace wellwelwel/lagune i zainstaluj lagune. Aplikacja desktopowa wczyta wtyczkę, gdy zainstalujesz ją dla siebie w terminalu lub w rozszerzeniu. ### Jak zaktualizować wtyczkę Lagune w Claude Code? Uruchom claude plugin marketplace update lagune, a następnie claude plugin update lagune@lagune albo wybierz Enable auto-update dla marketplace'u lagune w menu /plugin. W rozszerzeniu otwórz Manage plugins z poziomu /plugin i kliknij ikonę odświeżania marketplace'u lagune. Aplikacja desktopowa wczyta aktualizację w następnej sesji. ### Jak uruchamiać polecenia Lagune w Claude Code? Wpisuj ich nazwy, na przykład /lagune-charter, albo poprzedzaj je nazwą wtyczki, na przykład /lagune:lagune-charter. ### Czy Claude Code może uruchamiać polecenia Lagune bez pytania o zgodę? Tak. W ustawieniach Claude Code zezwól na mcp__plugin_lagune_lagune__lagune_read i mcp__plugin_lagune_lagune__lagune_write, a gdy silnik działa przez npx, także na Bash(npx --yes lagune@*). --- # Instalacja wtyczki Lagune w Codex CLI > Zainstaluj wtyczkę Lagune w Codex CLI, aktualizuj ją i uruchamiaj jej silnik w sandboxie. Adres kanoniczny: https://lagune.ai/pl-PL/docs/install/codex Język: pl-PL Oryginał: https://lagune.ai/docs/install/codex Ostatnia aktualizacja: 2026-11-09 Zainstaluj wtyczkę z terminala: ```bash codex plugin marketplace add wellwelwel/lagune codex plugin add lagune@lagune ``` ## Aktualizacja Aby zaktualizować wtyczkę **Lagune**, uruchom: ```bash codex plugin marketplace upgrade lagune ``` ## Polecenia Wpisz `$` i polecenie poprzedzone nazwą wtyczki, a po nim własny tekst, na przykład `$lagune:lagune-charter` zamiast `/lagune-charter`. Po wpisaniu `$` pojawia się lista poleceń, a wybranie jednego z nich wstawia jego pełną nazwę. --- **Sandbox** Sandbox agenta **Codex** nie ma dostępu do sieci. Zainstaluj silnik w projekcie z własnego terminala, raz, a potem po każdej aktualizacji: ```bash npm i -D lagune@0.18.1 ``` ## Najczęściej zadawane pytania ### Jak zainstalować wtyczkę Lagune w Codex CLI? Uruchom codex plugin marketplace add wellwelwel/lagune, a następnie codex plugin add lagune@lagune. ### Jak zaktualizować wtyczkę Lagune w Codex CLI? Uruchom codex plugin marketplace upgrade lagune. ### Jak uruchamiać polecenia Lagune w Codex CLI? Wpisz $ i polecenie poprzedzone nazwą wtyczki, a po nim własny tekst, na przykład $lagune:lagune-charter. ### Czy Lagune działa w sandboxie agenta Codex? Tak, gdy zainstalujesz silnik w projekcie poleceniem npm i -D lagune@0.18.1 z własnego terminala, raz, a potem po każdej aktualizacji. --- # Instalacja wtyczki Lagune w edytorze Cursor > Zainstaluj wtyczkę Lagune w edytorze Cursor i w Cursor CLI, aktualizuj ją i z góry zezwól na działanie jej silnika. Adres kanoniczny: https://lagune.ai/pl-PL/docs/install/cursor Język: pl-PL Oryginał: https://lagune.ai/docs/install/cursor Ostatnia aktualizacja: 2026-11-09 **Cursor** - Otwórz **Customize**. - Wybierz **From GitHub Repository** i wpisz `https://github.com/wellwelwel/lagune`. - Przy **Lagune** wybierz **Install** i wskaż zakres: projekt lub użytkownik. **Cursor CLI** - Dodaj marketplace z terminala: ```bash agent plugin marketplace add https://github.com/wellwelwel/lagune --git-ref plugin-cursor ``` - Wpisz `/plugins` w sesji `agent`. - Zainstaluj wtyczkę **Lagune**. Jeśli wtyczka **Lagune** jest już zainstalowana w **Claude Code**, **Cursor CLI** wczyta ją stamtąd. ## Aktualizacja **Cursor** - Otwórz **Customize**. - Dla marketplace'u `lagune` wybierz **Refresh**. **Cursor CLI** - Podmień marketplace z terminala: ```bash agent plugin marketplace remove lagune agent plugin marketplace add https://github.com/wellwelwel/lagune --git-ref plugin-cursor ``` - Wpisz `/plugins` w sesji `agent`. - Ponownie zainstaluj wtyczkę **Lagune**. ## Polecenia Wpisuj nazwy poleceń, na przykład `/lagune-charter`. --- **Uprawnienia** W edytorze **Cursor** polecenia uruchamiają silnik przez **npx**, na co domyślny tryb Auto-review zezwala bez pytania. W **Cursor CLI** silnik korzysta z dwóch narzędzi: `lagune_read` tylko odczytuje projekt, a `lagune_write` tylko zapisuje w folderze `.lagune/`. Aby z góry zezwolić na ich użycie, dodaj te reguły do pliku `.cursor/cli.json` dla jednego projektu albo do pliku `~/.cursor/cli-config.json` dla wszystkich projektów: ```json { "permissions": { "allow": [ "Mcp(plugin-lagune-lagune:lagune_read)", "Mcp(plugin-lagune-lagune:lagune_write)" ] } } ``` Gdy silnik działa przez **npx**, jak w przypadku **skills.sh**, zezwól na `Shell(npx:--yes lagune@*)`. ## Najczęściej zadawane pytania ### Jak zainstalować wtyczkę Lagune w edytorze Cursor? W edytorze Cursor otwórz Customize, wybierz From GitHub Repository, wpisz https://github.com/wellwelwel/lagune i zainstaluj wtyczkę Lagune. W Cursor CLI uruchom agent plugin marketplace add https://github.com/wellwelwel/lagune --git-ref plugin-cursor, a następnie zainstaluj wtyczkę Lagune w /plugins. ### Jak zaktualizować wtyczkę Lagune w edytorze Cursor? W edytorze Cursor wybierz w Customize opcję Refresh dla marketplace'u lagune. W Cursor CLI usuń marketplace lagune, dodaj go ponownie, a następnie ponownie zainstaluj wtyczkę Lagune w /plugins. ### Jak uruchamiać polecenia Lagune w edytorze Cursor? Wpisuj ich nazwy, na przykład /lagune-charter. ### Czy Cursor może uruchamiać polecenia Lagune bez pytania o zgodę? Tak. Domyślny tryb Auto-review w edytorze Cursor już na to zezwala. W Cursor CLI zezwól na Mcp(plugin-lagune-lagune:lagune_read) i Mcp(plugin-lagune-lagune:lagune_write), a gdy silnik działa przez npx, także na Shell(npx:--yes lagune@*). --- # Instalacja wtyczki Lagune w Devin CLI > Zainstaluj wtyczkę Lagune w Devin CLI i aktualizuj ją. Adres kanoniczny: https://lagune.ai/pl-PL/docs/install/devin-cli Język: pl-PL Oryginał: https://lagune.ai/docs/install/devin-cli Ostatnia aktualizacja: 2026-11-09 Zaloguj się na konto **Devin**, a następnie zainstaluj wtyczkę z terminala: ```bash devin auth login devin plugins install wellwelwel/lagune ``` ## Aktualizacja Aby zaktualizować wtyczkę **Lagune**, uruchom: ```bash devin plugins update lagune ``` ## Polecenia Wpisuj polecenia poprzedzone nazwą wtyczki, na przykład `/lagune:lagune-charter` zamiast `/lagune-charter`. Wyświetla je też menu `/`. ## Najczęściej zadawane pytania ### Jak zainstalować wtyczkę Lagune w Devin CLI? Zaloguj się poleceniem devin auth login, a następnie uruchom devin plugins install wellwelwel/lagune. ### Jak zaktualizować wtyczkę Lagune w Devin CLI? Uruchom devin plugins update lagune. ### Jak uruchamiać polecenia Lagune w Devin CLI? Wpisuj je poprzedzone nazwą wtyczki, na przykład /lagune:lagune-charter. Wyświetla je też menu /. --- # Instalacja wtyczki Lagune w Factory Droid > Zainstaluj wtyczkę Lagune w Factory Droid, aktualizuj ją i zezwól na użycie narzędzi jej silnika. Adres kanoniczny: https://lagune.ai/pl-PL/docs/install/factory-droid Język: pl-PL Oryginał: https://lagune.ai/docs/install/factory-droid Ostatnia aktualizacja: 2026-11-09 Zainstaluj wtyczkę z terminala: ```bash droid plugin marketplace add wellwelwel/lagune droid plugin install lagune@lagune ``` ## Aktualizacja Aby zaktualizować wtyczkę **Lagune**, uruchom: ```bash droid plugin marketplace update lagune droid plugin update lagune@lagune ``` ## Polecenia Wpisuj nazwy poleceń, na przykład `/lagune-charter`. ## Najczęściej zadawane pytania ### Jak zainstalować wtyczkę Lagune w Factory Droid? Uruchom droid plugin marketplace add wellwelwel/lagune, a następnie droid plugin install lagune@lagune. ### Jak zaktualizować wtyczkę Lagune w Factory Droid? Uruchom droid plugin marketplace update lagune, a następnie droid plugin update lagune@lagune. ### Jak uruchamiać polecenia Lagune w Factory Droid? Wpisuj ich nazwy, na przykład /lagune-charter. ### Czy Factory Droid może uruchamiać polecenia Lagune bez pytania o zgodę? Tak. Gdy Factory Droid zapyta o zgodę, wybierz stałe zezwolenie na lagune_read i lagune_write. Zapyta ponownie po zsynchronizowaniu nowego commita marketplace'u lagune. --- # Instalacja rozszerzenia Lagune w Gemini CLI > Zainstaluj rozszerzenie Lagune w Gemini CLI, aktualizuj je i z góry zezwól na działanie jego silnika. Adres kanoniczny: https://lagune.ai/pl-PL/docs/install/gemini-cli Język: pl-PL Oryginał: https://lagune.ai/docs/install/gemini-cli Ostatnia aktualizacja: 2026-11-09 Zainstaluj rozszerzenie z terminala: ```bash gemini extensions install https://github.com/wellwelwel/lagune ``` ## Aktualizacja Aby zaktualizować rozszerzenie **Lagune**, uruchom: ```bash gemini extensions update lagune ``` Aby aktualizacje instalowały się automatycznie, zainstaluj rozszerzenie z flagą `--auto-update`. ## Polecenia Wpisuj polecenia poprzedzone nazwą rozszerzenia, na przykład `/lagune:lagune-charter` zamiast `/lagune-charter`. --- **Uprawnienia** Silnik korzysta z dwóch narzędzi: `lagune_read` tylko odczytuje projekt, a `lagune_write` tylko zapisuje w folderze `.lagune/`. **Gemini CLI** uruchamia je wyłącznie w zaufanym folderze. Aby z góry zezwolić na ich użycie, zapisz tę regułę w pliku `~/.gemini/policies/lagune.toml`: ```toml [[rule]] mcpName = "lagune" toolName = ["lagune_read", "lagune_write"] decision = "allow" priority = 100 ``` Gdy silnik działa przez **npx**, jak w przypadku **skills.sh**, dodaj do tego samego pliku tę regułę: ```toml [[rule]] toolName = "run_shell_command" commandRegex = 'npx --yes lagune@\d+\.\d+\.\d+\s' decision = "allow" priority = 100 ``` ## Najczęściej zadawane pytania ### Jak zainstalować rozszerzenie Lagune w Gemini CLI? Uruchom gemini extensions install https://github.com/wellwelwel/lagune. ### Jak zaktualizować rozszerzenie Lagune w Gemini CLI? Uruchom gemini extensions update lagune albo zainstaluj rozszerzenie z flagą --auto-update. ### Jak uruchamiać polecenia Lagune w Gemini CLI? Wpisuj je poprzedzone nazwą rozszerzenia, na przykład /lagune:lagune-charter. ### Czy Gemini CLI może uruchamiać polecenia Lagune bez pytania o zgodę? Tak. Dodaj regułę polityki, która zezwala na narzędzia lagune_read i lagune_write serwera lagune, a gdy silnik działa przez npx, także regułę dla run_shell_command z npx --yes lagune@ i numerem wersji. --- # Instalacja wtyczki Lagune w GitHub Copilot CLI > Zainstaluj wtyczkę Lagune w GitHub Copilot CLI i aktualizuj ją. Adres kanoniczny: https://lagune.ai/pl-PL/docs/install/github-copilot-cli Język: pl-PL Oryginał: https://lagune.ai/docs/install/github-copilot-cli Ostatnia aktualizacja: 2026-11-09 Zainstaluj wtyczkę z terminala: ```bash copilot plugin marketplace add wellwelwel/lagune copilot plugin install lagune@lagune ``` W edytorze zainstaluj polecenia **Lagune** dla **GitHub Copilot** za pomocą [**skills.sh**](https://lagune.ai/pl-PL/docs/install/universal). ## Aktualizacja Aby zaktualizować wtyczkę **Lagune**, uruchom: ```bash copilot plugin marketplace update lagune copilot plugin update lagune@lagune ``` ## Polecenia Wpisuj nazwy poleceń, na przykład `/lagune-charter`. ## Najczęściej zadawane pytania ### Jak zainstalować wtyczkę Lagune w GitHub Copilot CLI? Uruchom copilot plugin marketplace add wellwelwel/lagune, a następnie copilot plugin install lagune@lagune. ### Jak zaktualizować wtyczkę Lagune w GitHub Copilot CLI? Uruchom copilot plugin marketplace update lagune, a następnie copilot plugin update lagune@lagune. ### Jak uruchamiać polecenia Lagune w GitHub Copilot CLI? Wpisuj ich nazwy, na przykład /lagune-charter. ### Czy Lagune działa z GitHub Copilot w VS Code? Tak. W VS Code lub innym edytorze zainstaluj polecenia Lagune za pomocą skills.sh zamiast wtyczki. --- # Instalacja wtyczki Lagune w Grok Build > Zainstaluj wtyczkę Lagune w Grok Build, aktualizuj ją i z góry zezwól na działanie jej silnika. Adres kanoniczny: https://lagune.ai/pl-PL/docs/install/grok-build Język: pl-PL Oryginał: https://lagune.ai/docs/install/grok-build Ostatnia aktualizacja: 2026-11-09 Zainstaluj wtyczkę z terminala: ```bash grok plugin install wellwelwel/lagune@plugin-grok --trust ``` ## Aktualizacja Aby zaktualizować wtyczkę **Lagune**, uruchom: ```bash grok plugin update lagune ``` ## Polecenia Wpisuj nazwy poleceń, na przykład `/lagune-charter`, albo poprzedzaj je nazwą wtyczki, na przykład `/lagune:lagune-charter`. --- **Uprawnienia** Silnik korzysta z dwóch narzędzi: `lagune_read` tylko odczytuje projekt, a `lagune_write` tylko zapisuje w folderze `.lagune/`. Aby z góry zezwolić na ich użycie, dodaj te reguły do pliku `~/.grok/config.toml`: ```toml [permission] allow = ["MCPTool(lagune__lagune_read)", "MCPTool(lagune__lagune_write)"] ``` Gdy silnik działa przez **npx**, jak w przypadku **skills.sh**, zezwól na `Bash(npx --yes lagune@*)`. ## Najczęściej zadawane pytania ### Jak zainstalować wtyczkę Lagune w Grok Build? Uruchom grok plugin install wellwelwel/lagune@plugin-grok --trust. ### Jak zaktualizować wtyczkę Lagune w Grok Build? Uruchom grok plugin update lagune. ### Jak uruchamiać polecenia Lagune w Grok Build? Wpisuj ich nazwy, na przykład /lagune-charter, albo poprzedzaj je nazwą wtyczki, na przykład /lagune:lagune-charter. ### Czy Grok Build może uruchamiać polecenia Lagune bez pytania o zgodę? Tak. W konfiguracji Grok Build zezwól na MCPTool(lagune__lagune_read) i MCPTool(lagune__lagune_write), a gdy silnik działa przez npx, także na Bash(npx --yes lagune@*). --- # Instalacja wtyczki Lagune w Hermes Agent > Zainstaluj wtyczkę Lagune w Hermes Agent i aktualizuj ją. Adres kanoniczny: https://lagune.ai/pl-PL/docs/install/hermes-agent Język: pl-PL Oryginał: https://lagune.ai/docs/install/hermes-agent Ostatnia aktualizacja: 2026-11-09 Zainstaluj wtyczkę z terminala: ```bash hermes plugins install wellwelwel/lagune --enable ``` - Gdy **Hermes Agent** poprosi o potwierdzenie wtyczki spoza swojego katalogu, **potwierdź**. - Gdy zaproponuje zainstalowanie zależności **Node.js** z repozytorium, **odmów**. ## Aktualizacja Aby zaktualizować wtyczkę **Lagune**, uruchom: ```bash hermes plugins update lagune ``` ## Polecenia Wpisuj polecenia poprzedzone nazwą wtyczki, na przykład `/lagune:lagune-charter` zamiast `/lagune-charter` i `/lagune:lagune` zamiast `/lagune`. ## Najczęściej zadawane pytania ### Jak zainstalować wtyczkę Lagune w Hermes Agent? Uruchom hermes plugins install wellwelwel/lagune --enable. Potwierdź wtyczkę, gdy pojawi się pytanie, i odmów zainstalowania zależności Node.js z repozytorium. ### Jak zaktualizować wtyczkę Lagune w Hermes Agent? Uruchom hermes plugins update lagune. ### Jak uruchamiać polecenia Lagune w Hermes Agent? Wpisuj je poprzedzone nazwą wtyczki, na przykład /lagune:lagune-charter i /lagune:lagune. --- # Instalacja wtyczki Lagune w Kimi Code > Zainstaluj wtyczkę Lagune w Kimi Code i aktualizuj ją. Adres kanoniczny: https://lagune.ai/pl-PL/docs/install/kimi-code Język: pl-PL Oryginał: https://lagune.ai/docs/install/kimi-code Ostatnia aktualizacja: 2026-11-09 Zainstaluj wtyczkę w sesji **Kimi Code**, wybierz **Trust and install**, a następnie rozpocznij nową sesję, aby wczytać wtyczkę: ```text /plugins install https://github.com/wellwelwel/lagune /new ``` ## Aktualizacja Aby zaktualizować wtyczkę **Lagune**, zainstaluj ją ponownie: ```text /plugins install https://github.com/wellwelwel/lagune /new ``` ## Polecenia Wpisuj polecenia poprzedzone nazwą wtyczki, na przykład `/lagune:lagune-charter` zamiast `/lagune-charter`. Menu `/` pokazuje je jako `/skill:lagune:lagune-charter` i ta forma również działa. ## Najczęściej zadawane pytania ### Jak zainstalować wtyczkę Lagune w Kimi Code? W sesji Kimi Code uruchom /plugins install https://github.com/wellwelwel/lagune, wybierz Trust and install, a następnie uruchom /new. ### Jak zaktualizować wtyczkę Lagune w Kimi Code? Ponownie uruchom /plugins install https://github.com/wellwelwel/lagune, a następnie /new. ### Jak uruchamiać polecenia Lagune w Kimi Code? Wpisuj je poprzedzone nazwą wtyczki, na przykład /lagune:lagune-charter, albo tak, jak pokazuje je menu /, na przykład /skill:lagune:lagune-charter. --- # Instalacja wtyczki Lagune w Muse Code > Zainstaluj wtyczkę Lagune w Muse Code, aktualizuj ją i uruchamiaj jej silnik w sandboxie. Adres kanoniczny: https://lagune.ai/pl-PL/docs/install/muse-code Język: pl-PL Oryginał: https://lagune.ai/docs/install/muse-code Ostatnia aktualizacja: 2026-11-09 Zainstaluj wtyczkę z terminala: ```bash muse plugins marketplace add lagune wellwelwel/lagune muse plugins install lagune@lagune ``` ## Aktualizacja Aby zaktualizować wtyczkę **Lagune**, odśwież marketplace i zainstaluj ją ponownie: ```bash muse plugins marketplace update lagune muse plugins remove lagune muse plugins install lagune@lagune ``` ## Polecenia Wpisuj nazwy poleceń, na przykład `/lagune-charter`, albo poprzedzaj je nazwą wtyczki, na przykład `/lagune:lagune-charter`. --- **Sandbox** Sandbox **Muse Code** nie może pobrać silnika. Zainstaluj go w swoim projekcie z własnego terminala, raz, a potem po każdej aktualizacji: ```bash npm i -D lagune@0.18.1 ``` ## Najczęściej zadawane pytania ### Jak zainstalować wtyczkę Lagune w Muse Code? Uruchom muse plugins marketplace add lagune wellwelwel/lagune, a następnie muse plugins install lagune@lagune. ### Jak zaktualizować wtyczkę Lagune w Muse Code? Uruchom muse plugins marketplace update lagune, a następnie zainstaluj wtyczkę ponownie poleceniami muse plugins remove lagune i muse plugins install lagune@lagune. ### Jak uruchamiać polecenia Lagune w Muse Code? Wpisuj ich nazwy, na przykład /lagune-charter, albo poprzedzaj je nazwą wtyczki, na przykład /lagune:lagune-charter. ### Czy Lagune działa w sandboxie Muse Code? Tak, gdy zainstalujesz silnik w swoim projekcie poleceniem npm i -D lagune@0.18.1 z własnego terminala, raz, a potem po każdej aktualizacji. --- # Instalacja wtyczki Lagune w OpenCode > Zainstaluj wtyczkę Lagune w OpenCode 1.x i 2.x i aktualizuj ją. Adres kanoniczny: https://lagune.ai/pl-PL/docs/install/opencode Język: pl-PL Oryginał: https://lagune.ai/docs/install/opencode Ostatnia aktualizacja: 2026-11-09 **OpenCode 2.x** Zainstaluj wtyczkę z terminala: ```bash opencode plugin add lagune ``` Albo dodaj ją do listy `plugins` w pliku `opencode.json`: ```json { "plugins": ["lagune"] } ``` **OpenCode 1.x** Zainstaluj wtyczkę w swoim projekcie z terminala albo dodaj `-g`, aby zainstalować ją dla wszystkich swoich projektów: ```bash opencode plugin lagune ``` Albo dodaj ją do listy `plugin` w pliku `opencode.json`: ```json { "plugin": ["lagune"] } ``` ## Aktualizacja **OpenCode 2.x** Aby zaktualizować wtyczkę **Lagune**, uruchom: ```bash opencode plugin update lagune opencode reload ``` **OpenCode 1.x** Aby zaktualizować wtyczkę **Lagune**, zainstaluj nową wersję w miejsce starej, dodając `-g`, jeśli wtyczka jest zainstalowana dla wszystkich twoich projektów: ```bash opencode plugin lagune@0.18.1 --force ``` ## Polecenia **OpenCode 2.x** Wpisz `@` i wybierz polecenie, na przykład `@lagune-charter`, a następnie dopisz swoją treść w tej samej wiadomości. **OpenCode 1.x** Wpisuj nazwy poleceń, na przykład `/lagune-charter`. Znajdziesz je na liście `/skills`, a nie w menu `/`. ## Najczęściej zadawane pytania ### Jak zainstalować wtyczkę Lagune w OpenCode? W OpenCode 2.x uruchom opencode plugin add lagune. W OpenCode 1.x uruchom opencode plugin lagune, dodając -g, aby zainstalować wtyczkę dla wszystkich swoich projektów. ### Jak zaktualizować wtyczkę Lagune w OpenCode? W OpenCode 2.x uruchom opencode plugin update lagune, a następnie opencode reload. W OpenCode 1.x uruchom opencode plugin lagune@0.18.1 --force. ### Jak uruchamiać polecenia Lagune w OpenCode? W OpenCode 2.x wpisz @ i wybierz polecenie, na przykład @lagune-charter, a następnie dopisz swoją treść w tej samej wiadomości. W OpenCode 1.x wpisuj je, podając ich nazwę, na przykład /lagune-charter, albo znajdź je na liście /skills. ### Czy OpenCode pyta o zgodę, zanim Lagune zacznie działać? Nie. OpenCode uruchamia oba narzędzia silnika, lagune_read i lagune_write, bez pytania o zgodę. --- # Instalacja pakietu Lagune w Pi > Zainstaluj pakiet Lagune w Pi z npm lub z serwisu GitHub i aktualizuj go. Adres kanoniczny: https://lagune.ai/pl-PL/docs/install/pi Język: pl-PL Oryginał: https://lagune.ai/docs/install/pi Ostatnia aktualizacja: 2026-11-09 **npm** Zainstaluj pakiet z terminala: ```bash pi install npm:lagune ``` **GitHub** Zainstaluj najnowszy commit z serwisu **GitHub**. Ta wersja uruchamia silnik przez **npx**: ```bash pi install git:github.com/wellwelwel/lagune ``` ## Aktualizacja **npm** Aby zaktualizować pakiet **Lagune**, uruchom: ```bash pi update npm:lagune ``` **GitHub** Aby zaktualizować pakiet **Lagune**, uruchom: ```bash pi update git:github.com/wellwelwel/lagune ``` Polecenie `pi update --extensions` aktualizuje wszystkie zainstalowane pakiety, a samo `pi update` aktualizuje tylko **Pi**. ## Polecenia Wpisuj polecenia z prefiksem `skill:`, na przykład `/skill:lagune-charter` zamiast `/lagune-charter`. ## Najczęściej zadawane pytania ### Jak zainstalować pakiet Lagune w Pi? Uruchom pi install npm:lagune albo pi install git:github.com/wellwelwel/lagune, aby zainstalować najnowszy commit z serwisu GitHub. ### Jak zaktualizować pakiet Lagune w Pi? Uruchom pi update npm:lagune albo pi update git:github.com/wellwelwel/lagune, jeśli pakiet pochodzi z serwisu GitHub. Polecenie pi update --extensions aktualizuje wszystkie zainstalowane pakiety. ### Jak uruchamiać polecenia Lagune w Pi? Wpisuj je z prefiksem skill:, na przykład /skill:lagune-charter. --- # Instalacja rozszerzenia Lagune w Qwen Code > Zainstaluj rozszerzenie Lagune w Qwen Code, aktualizuj je i z góry zezwól na działanie jego silnika. Adres kanoniczny: https://lagune.ai/pl-PL/docs/install/qwen-code Język: pl-PL Oryginał: https://lagune.ai/docs/install/qwen-code Ostatnia aktualizacja: 2026-11-09 Zainstaluj rozszerzenie z terminala: ```bash qwen extensions install lagune ``` ## Aktualizacja Aby zaktualizować rozszerzenie **Lagune**, uruchom: ```bash qwen extensions update lagune ``` Aby rozszerzenie aktualizowało się automatycznie, zainstaluj je z opcją `--auto-update`. ## Polecenia Wpisuj polecenia poprzedzone nazwą rozszerzenia, na przykład `/lagune:lagune-charter` zamiast `/lagune-charter`. --- **Uprawnienia** Silnik korzysta z dwóch narzędzi: `lagune_read` tylko odczytuje projekt, a `lagune_write` tylko zapisuje w folderze `.lagune/`. Aby z góry zezwolić na ich użycie, dodaj te reguły do pliku `.qwen/settings.json` dla jednego projektu albo do pliku `~/.qwen/settings.json` dla wszystkich projektów: ```json { "permissions": { "allow": ["mcp__lagune__lagune_read", "mcp__lagune__lagune_write"] } } ``` Gdy silnik działa przez **npx**, jak w przypadku **skills.sh**, zezwól na `Shell(npx --yes lagune@*)`. ## Najczęściej zadawane pytania ### Jak zainstalować rozszerzenie Lagune w Qwen Code? Uruchom qwen extensions install lagune. ### Jak zaktualizować rozszerzenie Lagune w Qwen Code? Uruchom qwen extensions update lagune albo zainstaluj rozszerzenie z opcją --auto-update. ### Jak uruchamiać polecenia Lagune w Qwen Code? Wpisuj je poprzedzone nazwą rozszerzenia, na przykład /lagune:lagune-charter. ### Czy Qwen Code może uruchamiać polecenia Lagune bez pytania o zgodę? Tak. W ustawieniach Qwen Code zezwól na mcp__lagune__lagune_read i mcp__lagune__lagune_write, a gdy silnik działa przez npx, także na Shell(npx --yes lagune@*). --- # Instalacja poleceń Lagune w dowolnym agencie przez skills.sh lub GitHub CLI > Zainstaluj polecenia Lagune w dowolnym agencie AI za pomocą CLI skills lub GitHub CLI i aktualizuj je. Adres kanoniczny: https://lagune.ai/pl-PL/docs/install/universal Język: pl-PL Oryginał: https://lagune.ai/docs/install/universal Ostatnia aktualizacja: 2026-11-09 **skills.sh** Zainstaluj polecenia **Lagune** w swoim projekcie z terminala za pomocą [**skills.sh**](https://www.skills.sh/wellwelwel/lagune), pozostawiając **Project** jako zakres instalacji: ```bash npx skills add wellwelwel/lagune --skill '*' ``` Albo wklej ten prompt swojemu agentowi: ```md Uruchom `npx --yes skills add wellwelwel/lagune` i od razu wykonaj wygenerowane instrukcje skilla. Przeczytaj cały wynik polecenia, w razie potrzeby najpierw przekierowując go do pliku tymczasowego. Ścieżki względne rozwiązuj od folderu z plikami pomocniczymi wskazanego w tym wyniku. ``` **GitHub CLI** Zainstaluj polecenia **Lagune** w swoim projekcie z terminala za pomocą [**GitHub CLI**](https://cli.github.com/) w wersji 2.90.0 lub nowszej: ```bash gh skill install wellwelwel/lagune --all --scope project ``` Albo wklej ten prompt swojemu agentowi: ```md Uruchom `gh skill install wellwelwel/lagune --all --scope project` i przeczytaj cały wynik polecenia, w razie potrzeby najpierw przekierowując go do pliku tymczasowego. ``` ## Aktualizacja **skills.sh** Aby zaktualizować polecenia **Lagune**, uruchom: ```bash npx skills update ``` Albo wklej ten prompt swojemu agentowi: ```md Uruchom `npx --yes skills update -y` i przeczytaj cały wynik polecenia, w razie potrzeby najpierw przekierowując go do pliku tymczasowego. ``` **GitHub CLI** Aby zaktualizować polecenia **Lagune**, uruchom: ```bash gh skill update --all ``` Albo wklej ten prompt swojemu agentowi: ```md Uruchom `gh skill update --all` i przeczytaj cały wynik polecenia, w razie potrzeby najpierw przekierowując go do pliku tymczasowego. ``` --- **Sandbox** W sandboxie bez dostępu do sieci polecenia nie mogą pobrać silnika. Zainstaluj go w swoim projekcie z własnego terminala, raz, a potem po każdej aktualizacji: ```bash npm i -D lagune@0.18.1 ``` ## Najczęściej zadawane pytania ### Jak zainstalować polecenia Lagune w dowolnym agencie AI? W swoim projekcie uruchom npx skills add wellwelwel/lagune --skill '*' lub gh skill install wellwelwel/lagune --all --scope project albo wklej agentowi prompt instalacyjny. ### Jak zaktualizować polecenia Lagune w dowolnym agencie AI? Uruchom npx skills update, jeśli polecenia zainstalowano przez skills.sh, albo gh skill update --all, jeśli zainstalowano je przez GitHub CLI. Możesz też wkleić agentowi prompt aktualizacyjny. ### Czy mogę zainstalować polecenia Lagune na kilka sposobów jednocześnie? Nie. Przy dwóch instalacjach agent pokazuje każde polecenie dwa razy albo używa jednej kopii, a drugą ukrywa. --- # Skille bezpieczeństwa dla agentów AI > Skille, które twój agent AI zyskuje dzięki Lagune: audyt istniejącego projektu albo zabezpieczanie nowej pracy na bieżąco, zawsze zgodnie z zasadami bezpieczeństwa. Adres kanoniczny: https://lagune.ai/pl-PL/docs/get-started/commands Język: pl-PL Oryginał: https://lagune.ai/docs/get-started/commands Ostatnia aktualizacja: 2026-11-09 Po [instalacji](https://lagune.ai/pl-PL/docs) **Lagune** twój agent **AI** zyskuje zestaw skilli. Możesz z nich korzystać na dwa sposoby, a oba podlegają twoim **zasadom bezpieczeństwa**: zabezpieczać nową pracę na bieżąco albo uruchomić pełny audyt projektu. **⌨️ Budowanie / programowanie** Nie musisz kończyć pracy, żeby ją zabezpieczyć. Używaj polecenia [**`/lagune`**](https://lagune.ai/pl-PL/docs/commands/lagune) do pracy, którą piszesz **właśnie teraz**: | Skill | Co dla ciebie robi | | --------------------------------------------- | ----------------------------------------------------------------------------------------------- | | [**/lagune-charter**](https://lagune.ai/pl-PL/docs/commands/charter) | Ustala zasady bezpieczeństwa twojego projektu, podstawę, na której buduje `/lagune` | | [**/lagune**](https://lagune.ai/pl-PL/docs/commands/lagune) | Buduje to, o co prosisz, i utwardza kod w trakcie pisania, kierując się zasadami bezpieczeństwa | **Używaj go w każdej chwili** Polecenie [**`/lagune`**](https://lagune.ai/pl-PL/docs/commands/lagune) przestrzega twoich zasad bezpieczeństwa przy każdym uruchomieniu. Przyjmuje dowolny prompt, buduje to, o co prosisz, i od razu utwardza wynik bezpiecznymi ustawieniami domyślnymi, a nie później. --- #### Skille specjalne | Skill | Co robi | | --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | | [**/lagune-specialize**](https://lagune.ai/pl-PL/docs/commands/specialize) | Poszerza wiedzę **Lagune** o nową specjalizację bezpieczeństwa na podstawie artykułów, exploitów lub tematów | **🔬 Audyt: przepływ pracy Blue Team** Pełny **przepływ pracy Blue Team** sprawdza, co robi projekt, mapuje jego ryzyka i je zamyka. Każdy krok opiera się na poprzednim, więc wystarczy przejść listę od góry do dołu: | # | Skill | Co dla ciebie robi | | --- | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | | 1 | [**/lagune-charter**](https://lagune.ai/pl-PL/docs/commands/charter) | Ustala zasady bezpieczeństwa twojego projektu, zaproponowane dla ciebie albo ukształtowane według twoich wskazówek | | 2 | [**/lagune-detect**](https://lagune.ai/pl-PL/docs/commands/detect) | Czyta twój kod i mapuje, co robi system i gdzie leżą ryzyka | | 3 | [**/lagune-plan**](https://lagune.ai/pl-PL/docs/commands/plan) | Zamienia to, co znalazła faza detect, w plan obrony z poprawką do każdego ustalenia | | 4 | [**/lagune-harden**](https://lagune.ai/pl-PL/docs/commands/harden) | Wdraża poprawki z planu w twoim kodzie, bezpiecznie i po jednej naraz | | 5 | [**/lagune-verify**](https://lagune.ai/pl-PL/docs/commands/verify) | Wykazuje, że każda wdrożona poprawka działa, i zamyka te, które przejdą weryfikację | --- #### Skille specjalne | Skill | Co robi | | --------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | [**/lagune-specialize**](https://lagune.ai/pl-PL/docs/commands/specialize) | Poszerza wiedzę **Lagune** o nową specjalizację bezpieczeństwa na podstawie artykułów, exploitów lub tematów | | [**/lagune-prove**](https://lagune.ai/pl-PL/docs/commands/prove) | Zamienia każde wykryte ustalenie w wyłącznie defensywne wykazanie, które da się uruchomić, na potrzeby odpowiedzialnego ujawniania | --- #### Skille wewnętrzne | Skill | Co robi | | ------------------------------------------- | ---------------------------------------- | | [**/lagune-repair**](https://lagune.ai/pl-PL/docs/commands/repair) | Naprawia wewnętrzne śledzenie **Lagune** | **Wskazówka** Bezpieczeństwo to nie koszt, tylko inwestycja: to, co włożysz w nie na początku, zaoszczędzisz wielokrotnie na incydentach, które nigdy się nie wydarzą 🙋🏻‍♂️ ## Najczęściej zadawane pytania ### Jakie skille dodaje Lagune? /lagune do utwardzania pracy na bieżąco oraz pięciofazowy przepływ pracy audytu Blue Team: /lagune-charter, /lagune-detect, /lagune-plan, /lagune-harden, /lagune-verify. Do tego /lagune-specialize i /lagune-prove. ### Czym jest przepływ pracy Blue Team w Lagune? To pięciofazowy audyt: charter (ustalenie zasad), detect (mapowanie ryzyk), plan (ocena i zaplanowanie poprawek), harden (wdrożenie poprawek), verify (wykazanie, że działają, i ich zamknięcie). ### Czym różni się /lagune od przepływu pracy audytu? /lagune zabezpiecza nową pracę na bieżąco, w trakcie pisania, bez przepływu pracy, którego trzeba by się trzymać. Przepływ pracy audytu uruchamia pięć faz po kolei na istniejącym projekcie. --- # Dashboard > Przeglądaj zasady bezpieczeństwa, ustalenia i katalog swojego projektu w lokalnym podglądzie na żywo, który otwierasz jednym poleceniem. Adres kanoniczny: https://lagune.ai/pl-PL/docs/get-started/dashboard Język: pl-PL Oryginał: https://lagune.ai/docs/get-started/dashboard Ostatnia aktualizacja: 2026-11-09 Uruchom **Lagune** bezpośrednio, bez podpolecenia, aby otworzyć interaktywny podgląd na żywo folderu `.lagune/`. Polecenie uruchamia dashboard i otwiera go na losowym porcie: ```bash npx lagune ``` - [x] **Odświeżanie na żywo** - [x] **Prywatny** i **lokalny** - [x] Pokazuje wszystko, co zawiera folder `.lagune/`, począwszy od pierwszych zasad bezpieczeństwa - [x] **Zarządzaj** kategoriami projektu i tym, co przeszukują jego hooki, bezpośrednio w przeglądarce - [x] Nie wymaga folderu `node_modules` ani pliku `package.json` 📦 ![Zasady bezpieczeństwa w dashboardzie Lagune](https://lagune.ai/img/dashboard/02.webp) ![Ustalenia w dashboardzie Lagune](https://lagune.ai/img/dashboard/03.webp) ![Side quests w dashboardzie Lagune](https://lagune.ai/img/dashboard/04.webp) ![Szczegóły ustalenia w dashboardzie Lagune](https://lagune.ai/img/dashboard/05.webp) ![Katalog w dashboardzie Lagune](https://lagune.ai/img/dashboard/06.webp) **Wskazówka** - 🚪 Użyj opcji `--port`, aby ustawić własny port. - ⏏️ Naciśnij `Ctrl+C`, aby go zatrzymać. ## Najczęściej zadawane pytania ### Jak otworzyć dashboard Lagune? Uruchom npx lagune bez podpolecenia w głównym folderze projektu. Polecenie udostępnia podgląd na żywo folderu .lagune/ na losowym porcie i otwiera go w przeglądarce. ### Czy dashboard jest prywatny? Tak. Działa wyłącznie na twoim komputerze, pod lokalnym adresem, do którego nie dotrze żaden inny komputer. ### Czy mogę zmieniać projekt z poziomu dashboardu? Tylko jego kategorie i to, co pomijają jego hooki, z poziomu przeglądarki. Wszystko inne w dashboardzie jest tylko do odczytu. --- # /lagune: Bezpieczny kod już wtedy, gdy pisze go AI > Buduje to, o co prosisz, i utwardza kod w trakcie pisania, kierując się zasadami bezpieczeństwa, bez przepływu pracy, którego trzeba się trzymać. Adres kanoniczny: https://lagune.ai/pl-PL/docs/commands/lagune Język: pl-PL Oryginał: https://lagune.ai/docs/commands/lagune Ostatnia aktualizacja: 2026-11-09 ⌨️ Praca, o którą prosisz, wykonana i zabezpieczona już w trakcie pisania. **`/lagune`** przyjmuje dowolny prompt na każdym etapie, buduje to, czego potrzebujesz, i utwardza wynik bezpiecznymi ustawieniami domyślnymi, zanim ci go odda. ## Użycie Oznacz dowolny prompt poleceniem **`/lagune`** i opisz zadanie tak jak zawsze. **📘 Instrukcje dla agentów** ```md # Instrukcje mojego projektu dla agentów ## Bezpieczeństwo - Używaj skilla `/lagune` zawsze, gdy tworzysz lub zmieniasz kod, aby domyślnie zwiększał bezpieczeństwo. ``` - Na przykład: **AGENTS.md**, **CLAUDE.md**, **.github/copilot-instructions.md**, **.cursorrules** itp. **💬 Nowa funkcja** ```prompt /lagune pozwól użytkownikom przesyłać własne zdjęcie profilowe. ``` **💬 Poprawka błędu** ```prompt /lagune nic się nie dzieje, gdy użytkownik wysyła formularz. Sprawdź, co może być przyczyną, i to napraw. ``` **💬 Refaktoryzacja** ```prompt /lagune rozdziel zależności i usprawnij logikę payloadu ``` **Zasady opcjonalne, ale warto je mieć** **`/lagune`** działa z zasadami bezpieczeństwa lub bez nich. Jeśli je masz, wszystko, co powstaje, kształtują własne reguły twojego projektu. Ustal je raz poleceniem [`/lagune-charter`](https://lagune.ai/pl-PL/docs/commands/charter). ## Jak to działa Polecenie prowadzi pracę w trzech krokach, nie zapisując niczego w pamięci Lagune: 1. Wczytuje twoje zasady bezpieczeństwa, jeśli istnieją, i to one kierują całą pracą. Jeśli jeszcze ich nie masz, opiera się na domyślnie bezpiecznej podstawie. 2. Przegląda [katalog](https://lagune.ai/pl-PL/docs/catalog) twojego projektu i wczytuje tylko te specjalizacje, których dotyczy twoja praca, czyli tę samą wiedzę na żądanie, z której korzysta przepływ pracy audytu. 3. Wdraża obronę już podczas pisania kodu, a potem ponownie czyta własny wynik, aby potwierdzić, że zabezpieczenia faktycznie działają, zanim odda ci pracę. Efektem jest działający kod w twoim projekcie, bezpieczny od pierwszej linii. **Używaj go w każdej chwili** Bez fazy detect, bez fazy plan, bez sprzątania na koniec. **`/lagune`** sprawdza się równie dobrze przy świeżym szkielecie projektu, jak przy zmianie w dojrzałej bazie kodu, i utwardza pracę na bieżąco, a nie później. ## Czego nie robi - Niczego nie zapisuje w folderze `.lagune`: żadnych artefaktów ani śledzenia, więc jedyne, co powstaje, to utwardzony kod, o który prosisz. - Nie osłabia żadnej reguły, żeby spełnić prompt, więc jeśli twoja prośba naruszałaby którąś z zasad bezpieczeństwa, zatrzymuje się i najpierw ci o tym mówi, zamiast od razu zbudować to w niebezpieczny sposób. ## Najczęściej zadawane pytania ### Co robi /lagune? Przyjmuje dowolny prompt na każdym etapie, buduje to, o co prosisz, i utwardza wynik bezpiecznymi ustawieniami domyślnymi, zanim ci go odda. Obronę wdraża już podczas pisania kodu, a nie później. ### Czy do używania /lagune potrzebuję zasad bezpieczeństwa? Nie. Polecenie działa z nimi lub bez nich. Gdy je masz, wszystko, co powstaje, kształtują własne reguły twojego projektu. Bez nich opiera się na domyślnie bezpiecznej podstawie. ### Czym różni się /lagune od przepływu pracy Blue Team? /lagune zabezpiecza nową pracę na bieżąco, w trakcie pisania, bez przepływu pracy, którego trzeba by się trzymać. Przepływ pracy Blue Team uruchamia pięć faz audytu po kolei na istniejącym projekcie. ### Czy /lagune śledzi ustalenia albo zapisuje artefakty? Nie. Niczego nie zapisuje w folderze .lagune: żadnych artefaktów ani śledzenia. Jedyne, co powstaje, to utwardzony kod, o który prosisz. ### Jak sprawić, żeby agent automatycznie używał /lagune? Dodaj do pliku instrukcji swojego agenta (AGENTS.md, CLAUDE.md, .cursorrules i podobnych) wskazówkę, by używał skilla /lagune zawsze, gdy tworzy lub zmienia kod. --- # /lagune-charter: Ustal swoje zasady bezpieczeństwa > Ustal zasady bezpieczeństwa projektu, czyli reguły, których przestrzega każda kolejna faza, i zapisz kategorie specjalizacji, za którymi przemawia analiza projektu. Adres kanoniczny: https://lagune.ai/pl-PL/docs/commands/charter Język: pl-PL Oryginał: https://lagune.ai/docs/commands/charter Ostatnia aktualizacja: 2026-11-09 🧬 Opisz swój projekt, a **Lagune** zamieni ten opis w twoje reguły bezpieczeństwa (a jeśli go nie podasz, wywnioskuje je z samego projektu). Zasady bezpieczeństwa tworzą warstwę nadrzędną: zestaw reguł stawiających bezpieczeństwo na pierwszym miejscu, których musi przestrzegać każda kolejna faza. Traktuj je jak kontrolę na etapie kompilacji, która pilnuje poziomu bezpieczeństwa twojego projektu. ## Użycie **Opisz projekt** ```prompt /lagune-charter Mój projekt to sklep internetowy z grami wideo. Klienci dodają produkty do koszyka i płacą kartą kredytową lub przelewem. Widzą swoje zamówienia i status każdego z nich. ``` **Niech Lagune zaproponuje** ```prompt /lagune-charter ``` > _Widzę bibliotekę płatności, konfigurację logowania i model zamówienia powiązany z klientem. Wygląda to na sklep internetowy, który coś sprzedaje. Klienci płacą i śledzą własne zamówienia..._ ☁️ ## Jakie wnioski wyciąga **Lagune** traktuje twój opis lub dokument **PRD** jako kierunek, ustala, co z niego wynika dla bezpieczeństwa, a potem czyta projekt, aby wyjść poza to, co podajesz. Na przykład: - Koszyk przechowujący zamówienia oznacza, że istnieje **baza danych**: - np. `"Gdzie są przechowywane dane?"`, `"Kto ma do nich dostęp?"`, `"Czy dane wyciekają?"`. - To, że klienci widzą własne zamówienia, oznacza, że istnieje jakiś rodzaj **logowania lub kontroli dostępu**: - np. `"Czy jeden klient może dostać się do zamówień innego?"`, `"Czy sesje są chronione?"`. - Przyjmowanie płatności kartą i przelewem oznacza, że **w grę wchodzą pieniądze i dane wrażliwe**: - np. `"Czy dane kart są przechowywane?"`, `"Czy płatności są weryfikowane?"`. Twój opis i projekt się uzupełniają: opis wyznacza intencję, a lektura zależności, pliku README i konfiguracji ujawnia to, o czym opis milczy. Jeśli coś ważnego nadal jest niejasne, **Lagune** zadaje krótkie, proste pytanie, zamiast zgadywać. Na tej podstawie **Lagune** tworzy zestaw reguł bezpieczeństwa dopasowanych do projektu, które możesz przejrzeć i zmienić, kiedy tylko potrzebujesz. **Jak wycisnąć z tego maksimum** - Możesz też zdefiniować własne reguły bezpieczeństwa dla projektu. - Im więcej istotnych szczegółów podasz, tym lepszy będzie raport końcowy: - Wyjaśnij, czym jest projekt, jak działa i co dzieje się pod maską. - Kto jest użytkownikiem końcowym? Co użytkownicy mogą robić, a czego nie? - Szczegóły dotyczące zachowania są równie cenne jak szczegóły techniczne. - Pamięć fazy charter znajduje się w pliku `.lagune/memory/charter.md`. ## Zapisywane kategorie Specjalizacje, czyli wiedza o bezpieczeństwie, którą kolejne fazy wczytują na żądanie, trafiają do [katalogu](https://lagune.ai/pl-PL/docs/catalog) twojego projektu według [kategorii](https://lagune.ai/pl-PL/docs/categories). Dopóki twój projekt nie ma zapisanej żadnej kategorii, faza charter zapisuje każdą, za którą przemawia jej analiza, na przykład język twojego projektu, wywołania modelu LLM czy kontenery, i wymienia je w swoim podsumowaniu. Gdy kategorie są już zapisane, faza charter zostawia je bez zmian i wymienia tylko te kategorie, których twój projekt jeszcze nie używa. Możesz je zmienić samodzielnie w każdej chwili: ```bash npx lagune write add --categories python npx lagune write remove --categories python ``` ## Foldery, które proponuje pominąć Gdy analiza fazy charter znajdzie w repozytorium foldery, które nie są kodem twojego projektu do obrony, na przykład fixtury testowe celowo napisane tak, by wyglądały na podatne, wymienia je z numerami na końcu podsumowania. Nigdy nie pomija żadnego z nich samodzielnie, bo złośliwe repozytorium może upodobnić swój kod do fixtur, więc zapisywane są tylko numery, które podasz w odpowiedzi. [Konfiguracja hooków](https://lagune.ai/pl-PL/docs/hooks/configure) pokazuje, jak zmienić je samodzielnie. ## Co dalej Gdy reguły są już ustalone, zmapuj, co twój system faktycznie robi: [`/lagune-detect`](https://lagune.ai/pl-PL/docs/commands/detect). ## Najczęściej zadawane pytania ### Czym są zasady bezpieczeństwa (charter) w Lagune? Zasady bezpieczeństwa to warstwa nadrzędna Lagune: zestaw reguł stawiających bezpieczeństwo na pierwszym miejscu, których musi przestrzegać każda kolejna faza. Traktuj je jak kontrolę na etapie kompilacji, która pilnuje poziomu bezpieczeństwa twojego projektu. ### Gdzie są przechowywane zasady bezpieczeństwa? W pliku .lagune/memory/charter.md. ### Czy mogę napisać własne zasady bezpieczeństwa? Tak. Lagune proponuje reguły na podstawie twojego opisu i kodu, a ty możesz je przeformułować, usunąć, dodać nowe lub zawęzić ich zakres. ### Czy faza charter wybiera za mnie kategorie specjalizacji? Tylko dopóki żadna nie jest zapisana. Wtedy zapisuje każdą kategorię, za którą przemawia jej analiza, na przykład twój język programowania albo wywołania modelu LLM. Gdy kategorie są już zapisane, nigdy ich nie zmienia. --- # /lagune-detect: Zmapuj swój system i jego ryzyka > Przeanalizuj kod i zmapuj, co robi twój system oraz gdzie kryją się ryzyka. Adres kanoniczny: https://lagune.ai/pl-PL/docs/commands/detect Język: pl-PL Oryginał: https://lagune.ai/docs/commands/detect Ostatnia aktualizacja: 2026-11-09 🔬 Sprawdź, co naprawdę robi twój system i gdzie kryją się ryzyka. Faza detect czyta kod i zapisuje tylko to, co rzeczywiście w nim znajdzie, razem z dowodami potrzebnymi kolejnym fazom. Jej nadrzędna zasada brzmi: wykrywać, nie wymyślać. ## Użycie **Pełne skanowanie** ```prompt /lagune-detect ``` **Wskaż ścieżki** ```prompt /lagune-detect src/routes/ src/auth.ts ``` **Opisz zagadnienie** ```prompt /lagune-detect upewnij się, że dane klientów nigdy nie są ujawniane ``` ## Co mapuje **Lagune** czyta kod i mapuje to, co w nim znajdzie. Każde ustalenie mówi, czego dotyczy, dlaczego ma znaczenie i na jakim dowodzie się opiera. Na przykład: - **Przesyłanie plików**, system przyjmuje pliki od użytkowników: - _Dlaczego to ważne:_ plik podszywający się pod obraz może ukrywać złośliwy kod. - _Dowód:_ handler `POST /upload` ufa typowi MIME podanemu przez klienta i nie sprawdza rzeczywistego typu pliku. - **Logowanie i sesje**, użytkownicy logują się, aby dostać się do swojego konta: - _Dlaczego to ważne:_ słaba obsługa sesji pozwala przejąć cudze konto. - _Dowód:_ logika wydawania sesji, która wydaje sesje bez ustawionego czasu wygaśnięcia. Przy okazji faza detect wydaje werdykt dla każdej specjalizacji z [katalogu](https://lagune.ai/pl-PL/docs/catalog) twojego projektu, zestawiając ją z kodem, stosuje te, których kontekst występuje w projekcie, i zapisuje je w sekcji **Applied specializations**, czyli na liście, z której korzystają potem fazy harden i verify. W efekcie masz przejrzystą mapę tego, co robi twój system i gdzie kryją się ryzyka, gotową do dalszych kroków. **Wskazówka** - Ponowne uruchomienie aktualizuje mapę: rozwiązane ustalenia znikają, nowe się pojawiają. - Mapa wykrywania znajduje się w pliku `.lagune/memory/detect.md`. ## Co dalej Zamień mapę w plan: [`/lagune-plan`](https://lagune.ai/pl-PL/docs/commands/plan). ## Najczęściej zadawane pytania ### Co robi /lagune-detect? Czyta twój kod i mapuje, co robi twój system oraz gdzie kryją się ryzyka, zapisując tylko to, co rzeczywiście znajdzie. Jego zasada brzmi: wykrywać, nie wymyślać. ### Czym jest ustalenie w Lagune? Ustalenie to jedno wykryte ryzyko, które mówi, czego dotyczy, dlaczego ma znaczenie i na jakim dowodzie w kodzie się opiera. To śledzona jednostka, którą dalej przejmują fazy plan, harden i verify. ### Gdzie jest zapisana mapa wykrywania? W pliku .lagune/memory/detect.md. ### Z jakich specjalizacji korzysta detect? Każda specjalizacja z katalogu twojego projektu dostaje werdykt po zestawieniu z kodem. Detect stosuje te, których kontekst występuje w projekcie, i zapisuje je w sekcji Applied specializations. --- # /lagune-plan: Oceń ustalenia i zaplanuj poprawki > Zamień to, co wykryła faza detect, w plan obrony, oceniając każde ustalenie kategorią i wynikiem CVSS v4.0 oraz dobierając do niego poprawkę. Adres kanoniczny: https://lagune.ai/pl-PL/docs/commands/plan Język: pl-PL Oryginał: https://lagune.ai/docs/commands/plan Ostatnia aktualizacja: 2026-11-09 🛡️ Zamień to, co wykryła faza detect, w plan obrony: oceń każde ustalenie kategorią i wynikiem CVSS v4.0, a potem dobierz do niego poprawkę do wdrożenia. ## Użycie **Zaplanuj wszystko** ```prompt /lagune-plan ``` **Wskaż ścieżki** ```prompt /lagune-plan src/routes/upload.ts ``` **Skup się na obawie** ```prompt /lagune-plan gdzie mogą wyciec wrażliwe dane ``` ## Jak to działa Ta faza kontynuuje pracę fazy detect. Detect ustaliła już, co robi twój system i jakie ryzyko niesie każdy jego element, więc plan nie powtarza opisu ryzyka, tylko ocenia, jak jest poważne, i decyduje, co z nim zrobić. Plan nigdy nie czyta kodu, dzięki czemu każda poprawka musi wskazywać coś, co detect rzeczywiście wykryła. Każde ustalenie ocenia metodą CVSS v4.0: przypisuje mu kategorię, wektor CVSS v4.0 wyprowadzony z tego, co zarejestrowały fazy detect i charter, z wynikiem obliczonym przez [hook `cvss`](https://lagune.ai/pl-PL/docs/hooks/cvss), oraz poziom priorytetu, do którego ten wynik należy. Każda poprawka wskazuje też zasadę bezpieczeństwa, którą chroni. Na przykład: - **Przesyłanie plików** (priorytet: **Critical**) - _Kategoria:_ nieograniczone przesyłanie plików (CWE-434). - _CVSS:_ CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N (9.3, Critical). - _Dlaczego taki priorytet:_ każdy może dotrzeć do przesyłania plików przez internet, a działa ono na serwerze, który przechowuje pliki klientów. - _Chroni zasadę:_ III. Wszystkie dane wejściowe są niezaufane, dopóki nie przejdą walidacji. - _Poprawka:_ sprawdzać rzeczywisty typ i rozmiar pliku, zmieniać jego nazwę przy zapisie i przechowywać przesłane pliki tam, gdzie nie da się ich uruchomić jako kodu. W efekcie masz ocenioną listę poprawek uporządkowaną według priorytetu, w której każda poprawka jest powiązana z ustaleniem i gotowa do wdrożenia w kolejnej fazie. Wynik jest obliczany, nigdy szacowany: wektor ujmuje ekspozycję projektu i stawkę jako metryki Environmental, a każdy może wkleić go do kalkulatora FIRST lub NVD i otrzymać ten sam wynik. **Wskazówka** - Faza opiera się w całości na fazie detect. Jeśli wskażesz plik lub obawę, których nigdy nie zmapowano, każe ci najpierw uruchomić dla nich polecenie `/lagune-detect`. - Ponowne uruchomienie aktualizuje plan: ukończone poprawki znikają, nowe się pojawiają. - Plan obrony znajduje się w pliku `.lagune/memory/plan.md`. **Zależy od fazy detect** Plan działa wyłącznie na tym, co polecenie [`/lagune-detect`](https://lagune.ai/pl-PL/docs/commands/detect) już zmapowało, więc najpierw uruchom detect. ## Co dalej Wdróż plan: [`/lagune-harden`](https://lagune.ai/pl-PL/docs/commands/harden). ## Najczęściej zadawane pytania ### Jak Lagune ustala priorytety podatności? /lagune-plan ocenia każde ustalenie kategorią i wynikiem CVSS v4.0 obliczonym przez hook cvss, a potem dobiera do niego poprawkę do wdrożenia. ### Czy Lagune korzysta z CVSS v4.0? Tak. Każde ustalenie dostaje wektor i wynik CVSS v4.0, które hook cvss oblicza według tej samej arytmetyki co kalkulator FIRST, więc każdy może wkleić tam wektor i samodzielnie odtworzyć wynik. ### Czy faza plan czyta mój kod? Nie. Plan nigdy nie czyta kodu, dzięki czemu każda poprawka musi wskazywać coś, co detect rzeczywiście wykryła. --- # /lagune-harden: Wdróż poprawki bezpieczeństwa w swoim kodzie > Wdróż poprawki z planu w swoim kodzie, bezpiecznie i po jednej naraz. Adres kanoniczny: https://lagune.ai/pl-PL/docs/commands/harden Język: pl-PL Oryginał: https://lagune.ai/docs/commands/harden Ostatnia aktualizacja: 2026-11-09 🔧 Wdróż poprawki z planu w swoim kodzie, bezpiecznie i po jednej naraz. ## Użycie **Wdróż wszystko** ```prompt /lagune-harden ``` **Wskaż ścieżki** ```prompt /lagune-harden src/routes/upload.ts ``` **Według priorytetu** ```prompt /lagune-harden priorytet krytyczny i wysoki ``` ## Jak to działa Plan rozstrzygnął już każdą poprawkę, więc harden po prostu ją wdraża. Ponieważ to jedyna faza, która zmienia twój kod, działa ostrożnie: wdraża jedną poprawkę naraz, aby każdą zmianę dało się łatwo przejrzeć, i nigdy nie osłabia zabezpieczenia tylko po to, żeby poprawka pasowała. Na przykład poprawka przesyłania plików: - **Przesyłanie plików** (status: **Applied**) - _Co się zmieniło:_ sprawdza rzeczywisty typ i rozmiar pliku, odrzuca wszystko, co nieoczekiwane, zmienia nazwę pliku przy zapisie i przechowuje go tam, gdzie nie da się go uruchomić jako kodu. - _Gdzie:_ funkcja `handleUpload` oraz wywoływana przez nią funkcja pomocnicza do zapisu. Jeśli poprawki nie da się wdrożyć w całości, harden robi to, co może bezpiecznie zrobić, a resztę oznacza jako **Partial** lub **Blocked** i zostawia otwartą. **Wdrożona nie znaczy zweryfikowana** Applied nie oznacza jeszcze, że działanie poprawki zostało wykazane. Od tego jest faza [verify](https://lagune.ai/pl-PL/docs/commands/verify). **Wskazówka** - Faza opiera się w całości na planie. Jeśli wskażesz poprawkę lub plik, których nigdy nie zaplanowano, każe ci najpierw uruchomić dla nich polecenie `/lagune-plan`. - Ponowne uruchomienie uzgadnia rejestr: wycofane zmiany znikają, nowo wdrożone poprawki się pojawiają. - Rejestr utwardzania znajduje się w pliku `.lagune/memory/harden.md`. **Zależy od fazy plan i zmienia twój kod** Harden opiera się na poleceniu [`/lagune-plan`](https://lagune.ai/pl-PL/docs/commands/plan). To jedyna faza, która zmienia twój kod. ## Co dalej Wykaż, że każda poprawka działa: [`/lagune-verify`](https://lagune.ai/pl-PL/docs/commands/verify). ## Najczęściej zadawane pytania ### Czy /lagune-harden zmienia mój kod? Tak. To jedyna faza, która zmienia twój kod, wdrażając poprawki z planu po jednej naraz. ### Co oznaczają statusy Applied, Partial i Blocked? To status, który Lagune zapisuje dla każdej poprawki. Applied oznacza, że poprawkę wdrożono, Partial, że wdrożono tylko jej część, a Blocked, że nie dało się jej wdrożyć. Applied nie oznacza jeszcze, że działanie poprawki zostało wykazane. ### Czy Lagune wdraża poprawki bez pytania? O tym, czy zmiana wymaga twojej zgody, decyduje twój agent i tryb uprawnień, w którym go uruchamiasz, a nie Lagune: Lagune nie dodaje własnego etapu potwierdzania. Mimo to nigdy nie osłabia zabezpieczenia na potrzeby poprawki, a jeśli poprawka naruszałaby którąś z zasad bezpieczeństwa, najpierw się zatrzymuje i ci o tym mówi. --- # /lagune-verify: Wykaż, że zabezpieczenia działają > Wykaż, że każda wdrożona poprawka działa, i zamknij te, które przejdą weryfikację. Adres kanoniczny: https://lagune.ai/pl-PL/docs/commands/verify Język: pl-PL Oryginał: https://lagune.ai/docs/commands/verify Ostatnia aktualizacja: 2026-11-09 ⚖️ Wykaż, że każda wdrożona poprawka działa, czytając kod i zestawiając go z tym, co zapisała faza harden, a potem zamknij te, które przejdą weryfikację. ## Użycie **Zweryfikuj wszystko** ```prompt /lagune-verify ``` **Wskaż ścieżki** ```prompt /lagune-verify src/routes/upload.ts ``` **Według priorytetu** ```prompt /lagune-verify priorytet krytyczny i wysoki ``` ## Jak to działa Faza verify czyta kod w każdym miejscu zapisanym przez fazę harden i potwierdza, że kod naprawdę odpowiada zapisanej deklaracji. Wykazaniem jest właśnie to zestawienie kodu z rejestrem. Każde zabezpieczenie dostaje jeden z trzech werdyktów: | Werdykt | Znaczenie | | ---------------------------- | -------------------------------------------------------------------------- | | ✅ Risk closed | Kod robi dokładnie to, co deklaruje rejestr. | | ❌ Risk not closed | Zabezpieczenie wciąż jest otwarte. Verify odsyła cię z powrotem do harden. | | ❓ Cannot tell from the code | Dowodu nie widać w samym kodzie. | Ryzyko, którego zamknięcie wykazano, zostaje następnie, za twoim potwierdzeniem, wycofane z łańcucha. Na przykład: - **Przesyłanie plików** (werdykt: **✅ Risk closed**) - _Jak wykazano:_ verify przeczytała handler przesyłania i stwierdziła, że rozpoznaje on rzeczywisty typ pliku na podstawie jego zawartości, egzekwuje limit rozmiaru i odrzuca wszystko inne, dokładnie tak, jak deklaruje rejestr. - _Dowód:_ funkcja `handleUpload`, która rozpoznaje rzeczywisty typ pliku na podstawie zawartości. Jeśli ryzyko nie zostało zamknięte, verify mówi to wprost i odsyła cię z powrotem do polecenia [`/lagune-harden`](https://lagune.ai/pl-PL/docs/commands/harden), bo poprawka wciąż jest otwarta. **Wskazówka** - Faza opiera się w całości na rejestrze utwardzania. - Czyta twój kod wyłącznie po to, aby go ocenić, i nigdy nie osłabia zabezpieczenia ani nie przepisuje kodu, żeby werdykt wypadł pozytywnie. - Ponowne uruchomienie uzgadnia werdykty: nieaktualne znikają, a ryzyko, które przestało być zamknięte, zostaje ponownie zgłoszone. - Gdy wykaże, że ryzyko jest zamknięte, pyta raz, a potem usuwa to ustalenie z całego łańcucha (detect, plan, harden i śledzenie). - Nie pisze własnego raportu: każdy werdykt trafia do bloku swojego zabezpieczenia w pliku `.lagune/memory/harden.md`, gdzie harden odczytuje go przy następnym uruchomieniu. **Zależy od fazy harden** Verify opiera się na poleceniu [`/lagune-harden`](https://lagune.ai/pl-PL/docs/commands/harden). ## Cykl się zamyka Gdy wszystko w zakresie zostanie wycofane, cykl przechodzi w stan spoczynku. Otwiera się ponownie dopiero wtedy, gdy zmieni się kod. Bezpieczeństwo jest możliwe do zamknięcia, więc przepływ pracy ma stan końcowy, a nie nieskończoną pętlę. ## Najczęściej zadawane pytania ### Jak Lagune weryfikuje poprawkę? /lagune-verify czyta kod, zestawia go z tym, co zapisała faza harden, i zwraca jeden z trzech werdyktów: Risk closed, Risk not closed albo Cannot tell from the code. ### Co oznacza wycofanie ustalenia? Gdy verify wykaże, że ryzyko jest zamknięte, ustalenie zostaje wycofane: za twoim potwierdzeniem znika z całego łańcucha, więc nie jest już przetwarzane od nowa. ### Czy pracę nad bezpieczeństwem da się kiedyś zakończyć? Tak. W SDH bezpieczeństwo jest możliwe do zamknięcia: ustalenie, którego zamknięcie wykazano, zostaje wycofane, więc przepływ pracy ma stan końcowy, a nie nieskończoną pętlę. --- # Kategorie > Kategorie specjalizacji, z których może korzystać projekt Lagune, od OWASP po utwardzanie dla konkretnych języków, takich jak JavaScript, Python, Go i Rust, oraz sposób ich zmiany. Adres kanoniczny: https://lagune.ai/pl-PL/docs/categories Język: pl-PL Oryginał: https://lagune.ai/docs/categories Ostatnia aktualizacja: 2026-11-09 **Lagune** grupuje swoje wbudowane [**specjalizacje**](https://lagune.ai/pl-PL/docs/catalog) w **13 kategorii**. Kategorie, z których korzysta projekt, decydują o tym, które wbudowane specjalizacje trafią do jego [**katalogu**](https://lagune.ai/pl-PL/docs/catalog), i dzielą się na dwie grupy: to, co robi system, i to, w czym jest napisany. Dopóki nie zapisano żadnej kategorii, projekt korzysta tylko z `owasp`. Polecenie [`/lagune-charter`](https://lagune.ai/pl-PL/docs/commands/charter) zapisuje każdą kategorię, którą uzasadnia jego analiza projektu, a ty w każdej chwili możesz je zmienić samodzielnie. ## Co robi system | Kategoria | Klucz | Co utwardza | | -------------- | --------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | OWASP | `owasp` | Ryzyka bezpieczeństwa aplikacji, które śledzi OWASP: wstrzykiwanie, błędna kontrola dostępu, błędy uwierzytelniania i kryptografii | | Infrastruktura | `infra` | Konfiguracja kontenerów, obciążeń i usług serverless: Dockerfile, Compose, bezpieczeństwo podów, IAM i wyzwalacze FaaS | | AI / LLM | `ai` | Integracje AI i LLM: ochrona przed prompt injection i niebezpiecznym podłączaniem narzędzi, agentów, mechanizmów retrieval i MCP | | Lovable | `lovable` | Aplikacje Supabase generowane przez AI (Lovable i podobne): luki w RLS, wycieki kluczy `service_role` i niebezpieczne ustawienia domyślne | ## W czym jest napisany | Kategoria | Klucz | Co utwardza | | ---------- | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------- | | JavaScript | `javascript` | RCE przez `eval` i `child_process`, path traversal i prototype pollution we wszystkich jego środowiskach uruchomieniowych | | Python | `python` | RCE przez deserializację `pickle` i YAML, string traversal przez `str.format` i class pollution | | Rust | `rust` | Niepoprawne (unsound) API z `unsafe`, nadużycia `transmute`, przepełnienia liczb całkowitych i niezdefiniowane zachowanie na granicy FFI | | C / C++ | `c-cpp` | Błędy ciągów formatujących, przepełnienia bufora i zapisy poza zakresem, które umożliwiają wykonanie kodu | | PHP | `php` | Obejście uwierzytelniania przez type juggling, łańcuchy gadżetów do object injection i niebezpieczne domyślne ustawienia konfiguracji | | Go | `go` | Błędy interfejsów z typed nil, data races między gorutynami i niebezpieczna współbieżność na ścieżkach krytycznych dla bezpieczeństwa | | Java | `java` | Łańcuchy gadżetów przy deserializacji przez `ObjectInputStream`, które kończą się zdalnym wykonaniem kodu | | Ruby | `ruby` | Łańcuchy gadżetów przy deserializacji przez `Marshal.load` i YAML, które prowadzą do zdalnego wykonania kodu | | .NET / C# | `dotnet` | RCE przez deserializację `BinaryFormatter` i obejścia enkoderów, które prowadzą do XSS | **Wskazówka** **Lagune** działa z każdym językiem: cały przepływ pracy czyta projekt, w czymkolwiek jest napisany, a te kategorie tylko pogłębiają analizę pułapek typowych dla jednego języka. ## Dodawaj i usuwaj w każdej chwili Kategoria to punkt wyjścia, a nie zobowiązanie. Używaj tych, które pasują do projektu teraz, i zmieniaj je w każdej chwili po kluczu, poleceniami `write add` i `write remove`. Opcja `--categories` bez wartości otwiera w terminalu interaktywny wybór (spacja zaznacza, Enter zatwierdza, pusty wybór pomija). Poza terminalem podaj kategorie zaraz po tej opcji. **Dodaj** ```bash npx lagune write add --categories # interactive npx lagune write add --categories owasp npx lagune write add --categories owasp rust ``` **Usuń** ```bash npx lagune write remove --categories # interactive npx lagune write remove --categories owasp npx lagune write remove --categories owasp rust ``` Pierwsze wywołanie `write add` lub `write remove` wychodzi od `owasp`, więc usunięcie wszystkich kategorii zostawia pustą listę, nigdy wartość domyślną. Każda zmiana trafia do pliku `.lagune/configs.json`, dzięki czemu cały zespół pracuje z tym samym zestawem. ## Sprawdź, z czego korzysta projekt Polecenie `read list --categories` pokazuje każdą kategorię i to, czy projekt z niej korzysta: ```bash npx lagune read list --categories # Categories # • owasp [used] Harden against the application security risks OWASP tracks # • javascript [available] Harden JavaScript and its runtimes # • php [available] Harden PHP against type-juggling auth bypass # • go [available] Harden Go against typed-nil interface bugs # ... # # No category is recorded yet, so this project uses the default: owasp. ``` Jakie specjalizacje zawiera każda kategoria, sprawdzisz w [**Katalogu**](https://lagune.ai/pl-PL/docs/catalog). Twoje własne specjalizacje, napisane poleceniem [`/lagune-specialize`](https://lagune.ai/pl-PL/docs/commands/specialize), trafiają do katalogu niezależnie od kategorii. ## Najczęściej zadawane pytania ### Jak dodać kategorię? Przekaż klucz kategorii do opcji --categories, na przykład npx lagune write add --categories javascript. Dopóki nie zapisano żadnej kategorii, faza charter również zapisuje te, które uzasadnia jej analiza projektu. ### Czy mogę używać więcej niż jednej kategorii? Tak. Wymień je w tym samym wierszu, jedną po drugiej. ### Jaką kategorię wybrać dla projektu? Zacznij od owasp, czyli kategorii domyślnej, a potem dodaj tę dla swojego języka lub stosu. Specjalizacje ładują się tylko na żądanie, więc kategoria nic nie kosztuje, dopóki któraś faza nie będzie potrzebować jednej z jej specjalizacji. --- # Katalog: Specjalizacje bezpieczeństwa na żądanie > Jak ładowane są specjalizacje z katalogu twojego projektu: na żądanie przez fazę albo bezpośrednio przez ciebie. Adres kanoniczny: https://lagune.ai/pl-PL/docs/catalog Język: pl-PL Oryginał: https://lagune.ai/docs/catalog Ostatnia aktualizacja: 2026-11-09 🧠 Specjalizacje **Lagune** to skupione na jednym zagadnieniu, niezależne od języka programowania moduły wiedzy o bezpieczeństwie, ładowane tylko na żądanie, nigdy domyślnie. Nie są poleceniami. Katalog twojego projektu to zestaw, z którego projekt korzysta: wbudowane specjalizacje jego [kategorii](https://lagune.ai/pl-PL/docs/categories) oraz jego własne. Fazy detect i verify sięgają po nie w trakcie działania, a ty możesz w każdej chwili załadować dowolną z nich bezpośrednio. **Przegląd** *Interaktywny przegląd katalogu znajdziesz na stronie internetowej. Wszystkie wbudowane specjalizacje są w tabeli poniżej.* **Jak to działa** ## Samodzielne użycie Aby użyć specjalizacji bezpośrednio, poproś agenta, żeby załadował ją poleceniem `read catalog `, i opisz zadanie w tym samym prompcie. Agent stosuje wtedy tę wiedzę do tego, o co prosisz. Działa to w każdym prompcie, nawet niezwiązanym z przepływem pracy **Lagune**. Na przykład bezpośredni prompt w dowolnej formie, który generuje bezpieczny zbiór wyrażeń **RegExp** w języku **Python**: ```prompt Załaduj specjalizację regex poleceniem `npx lagune read catalog regex`, a potem utwórz w @src/utils/regex.py zbiór wyrażeń regularnych do walidacji adresów e-mail i nazw użytkowników. ``` Agent korzysta przy tym z deterministycznego hooka, który testuje każde wyrażenie **RegExp** pod kątem **ReDoS**, zachowuje bezpieczne i daje mniej więcej taki wynik: ```python import re EMAIL = re.compile(r"^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$") USERNAME = re.compile(r"^[a-zA-Z0-9_]{3,20}$") def is_email(value: str) -> bool: return EMAIL.match(value) is not None def is_username(value: str) -> bool: return USERNAME.match(value) is not None ``` **Wypróbuj narzędzie do wykrywania ReDoS** Przetestuj wzorzec samodzielnie na stronie [**devina.io/redos-checker**](https://devina.io/redos-checker). ## Wbudowane specjalizacje Wbudowane specjalizacje są pogrupowane w [**kategorie**](https://lagune.ai/pl-PL/docs/categories). Oto zestaw, który **Lagune** dostarcza w standardzie: | Specjalizacja | Kategoria | Obszar | | --------------------- | --------------------------- | ------------------------------------------------------------------------------------------------------ | | `regex` | `owasp` | **ReDoS:** wzorce, których czas dopasowania gwałtownie rośnie przy spreparowanych danych wejściowych. | | `network` | `owasp` | **SSRF i przekierowania:** adresy pobierania lub przekierowań podawane przez użytkownika. | | `interpreter` | `owasp`, `lovable` | **Wstrzykiwanie kodu:** `eval`, dynamiczne dołączanie plików, wywoływanie po nazwie. | | `sql` | `owasp` | **Relacyjne bazy danych:** wstrzykiwanie SQL, surowe wywołania ORM, uprawnienia, zasięg silnika bazy. | | `path` | `owasp` | **Ścieżki w systemie plików:** path traversal, bajt zerowy, strumienie NTFS, podkładanie plików. | | `upload` | `owasp` | **Przesyłanie plików:** typ i sygnatura, złośliwa zawartość, przechowywanie, limity. | | `access-control` | `owasp`, `lovable` | **Uwierzytelnianie, autoryzacja, sesja:** IDOR, mass assignment, tenanci, sesje. | | `credential-endpoint` | `owasp`, `lovable` | **Zgadywanie haseł i boty:** brute force, password spraying, credential stuffing, ograniczanie prób. | | `federation` | `owasp` | **Zaufanie do tokenów:** OAuth/OIDC, SAML, walidacja JWT, logowanie kodem QR. | | `http-request` | `owasp` | **Pochodzenie żądań:** CSRF, błędna konfiguracja CORS, sfałszowany adres IP klienta. | | `transport` | `owasp` | **Bezpieczeństwo kanału:** konfiguracja TLS, HTTPS i tekst jawny, HSTS, pinning. | | `crypto` | `owasp`, `lovable` | **Kryptografia danych w spoczynku:** słabe lub własne algorytmy, CSPRNG, zarządzanie kluczami. | | `secrets` | `owasp`, `lovable` | **Dane uwierzytelniające zapisane na sztywno w kodzie:** klucze, tokeny, hasła wpisane w kod źródłowy. | | `api-endpoint` | `owasp` | **Interfejsy inne niż REST:** GraphQL, gRPC, autoryzacja WebSocket, DoS, schemat. | | `payment` | `owasp`, `lovable` | **Proces płatności:** weryfikacja w bramce po stronie serwera, podpisane callbacki, idempotentność. | | `xml` | `owasp` | **Parsowanie XML:** XXE, encje zewnętrzne, ekspansja typu billion laughs. | | `csv` | `owasp` | **Wstrzykiwanie formuł:** komórki arkusza zaczynające się od `=`/`+`/`-`/`@`. | | `container` | `owasp`, `infra` | **Konfiguracja kontenerów:** root, capabilities, montowanie gniazda, utwardzanie obrazu. | | `infra` | `infra` | **Infrastruktura jako kod:** Terraform, Dockerfile, GitHub Actions. | | `serverless` | `owasp`, `infra`, `lovable` | **Funkcje FaaS:** IAM z minimalnymi uprawnieniami, dane wejściowe zdarzeń, kontekst, sekrety. | | `llm` | `ai`, `lovable` | **Ryzyka AI i LLM:** prompt injection, autonomia agenta, RAG, MCP, dane wyjściowe. | | `supabase` | `lovable` | **Backend Supabase:** RLS domyślnie wyłączone, błędne polityki generowane przez AI, model kluczy. | | `browser` | `javascript`, `lovable` | **Ryzyka po stronie klienta:** XSS, CSP, osadzanie w ramkach, przechowywanie danych itp. | | `javascript` | `javascript` | **Ryzyka na poziomie języka:** RCE, prototype pollution itp. | | `python` | `python` | **Ryzyka na poziomie języka:** RCE przez `pickle`, class pollution, `-O` itp. | | `rust` | `rust` | **Poprawność `unsafe`:** UB wywołane z bezpiecznego kodu, `transmute`, przepełnienia. | | `java` | `java` | **Deserializacja i kod mobilny:** łańcuchy `readObject`, przejmowanie obiektów. | | `ruby` | `ruby` | **Deserializacja i `open`:** odtwarzanie obiektów przez `Marshal`/YAML, pułapka z potokiem. | | `php` | `php` | **Type juggling i `unserialize`:** magic hashes, łańcuchy POP. | | `go` | `go` | **Typed nil i data races:** `nil != nil`, gorutyny ze współdzieloną pamięcią. | | `c-cpp` | `c-cpp` | **Ciągi formatujące:** `printf(user_input)`, zapis write-what-where przez `%n`. | | `dotnet` | `dotnet` | **Ryzyka na poziomie platformy:** RCE przez `BinaryFormatter`, `@Html.Raw`, luki w enumach. | Większość wbudowanej wiedzy jest destylowana z OWASP. Pełne przyporządkowanie każdej specjalizacji do kanonicznych stron OWASP, czyli opisów ataków i Cheat Sheets, znajdziesz w sekcji [**Źródła OWASP**](https://lagune.ai/pl-PL/docs/references/owasp-sources). Kilka modułów związanych z konkretnym stosem opiera się zamiast tego na wytycznych samego dostawcy: na przykład `supabase` pochodzi z dokumentacji Supabase i CVE-2025-48757. ## Twoje własne specjalizacje Zestaw wbudowanych specjalizacji rośnie o jeden plik z wiedzą i jeden wiersz w indeksie, nigdy o nowe polecenie. Własne dodajesz tak samo, poleceniem [`/lagune-specialize`](https://lagune.ai/pl-PL/docs/commands/specialize): wskaż mu artykuł lub temat, a wydestyluje z niego nową specjalizację w twoim projekcie, czyli plik w `.lagune/catalog/` i jej wpis w `.lagune/configs.json`. Twoje własne specjalizacje zawsze należą do katalogu, niezależnie od jego kategorii, a twoja specjalizacja przesłania wbudowaną o tej samej nazwie. **Wewnętrznie Lagune ładuje specjalizacje automatycznie, na żądanie** Gdy faza detect lub verify trafia na kontekst, który obejmuje któraś specjalizacja, sama ładuje ją poleceniem `read catalog `. Dzieje się to automatycznie, w ramach fazy. Nie musisz niczego robić ręcznie, żeby to działało. ## Sprawdź, co jest dostępne Tak wyświetlisz w terminalu katalog swojego projektu, po jednej specjalizacji na wiersz, wraz z jej tagami: ```bash npx lagune read catalog # regex: Regular Expression [required] # network: Requests, Webhook, URL Fetch, Socket, IMDS, Redirect # interpreter: Evaluator, Sink, Shell, Dynamic Execution # ... ``` Specjalizacja oznaczona `[required]` obowiązuje zawsze, niezależnie od zadania. To, które wbudowane specjalizacje znajdą się na liście, zależy od [**kategorii**](https://lagune.ai/pl-PL/docs/categories) twojego projektu. **Specjalizacje nie są ładowane domyślnie** Zamiast domyślnie uruchamiać każde sprawdzenie, **Lagune** sięga tylko po wiedzę dopasowaną do tego, czym projekt faktycznie jest. ## Najczęściej zadawane pytania ### Czym jest specjalizacja Lagune? To skupiony na jednym zagadnieniu, niezależny od języka programowania moduł wiedzy o bezpieczeństwie, ładowany tylko na żądanie, nigdy domyślnie. W odróżnieniu od skilli agenta nie jest poleceniem. ### Czym jest katalog projektu? To specjalizacje, z których korzysta projekt: wbudowane specjalizacje jego kategorii oraz jego własne. Dopóki nie zapisano żadnej kategorii, projekt korzysta tylko z OWASP. ### Czy specjalizacje są ładowane domyślnie? Nie. Ładują się tylko na żądanie, zgodnie z tym, czym projekt faktycznie jest. ### Jak bezpośrednio załadować specjalizację? W tym samym prompcie co zadanie poproś agenta, żeby uruchomił npx lagune read catalog . --- # /lagune-specialize: Wytrenuj specjalizację bezpieczeństwa zwykłym tekstem > Destyluj wskazane źródło lub temat z zakresu bezpieczeństwa do postaci nowej specjalizacji ładowanej na żądanie. Adres kanoniczny: https://lagune.ai/pl-PL/docs/commands/specialize Język: pl-PL Oryginał: https://lagune.ai/docs/commands/specialize Ostatnia aktualizacja: 2026-11-09 🎓 Niech **Lagune** nauczy się nowej specjalizacji ze źródła lub tematu, które wskażesz. Polecenie czyta materiał i destyluje go do postaci ukierunkowanej, wyłącznie defensywnej specjalizacji o dokładnie takiej samej budowie jak [wbudowane](https://lagune.ai/pl-PL/docs/catalog), dzięki czemu fazy detect i verify ładują ją potem jak każdą inną. Wyłącznie audytuje i wyjaśnia: nigdy nie pisze danych wejściowych do ataku ani exploitów i nigdy nie zmienia twojego kodu. **Z artykułu** ```prompt # Link lub odwołanie: Lagune destyluje z niego obronę /lagune-specialize https://owasp.org/www-community/attacks/SQL_Injection ``` **Z exploita** ```prompt # Atak jako źródło: specjalizacja i tak opisuje obronę /lagune-specialize "' OR 1=1 -- dokleja SQL do treści zapytania" ``` **Z tematu** ```prompt # Albo po prostu nazwij, co ma objąć /lagune-specialize SQL injection ``` **Atak może być źródłem, nigdy wynikiem** Wskazanie ataku jest w porządku, gdy celem jest obrona przed nim: opis exploita to materiał do nauki, z którego polecenie destyluje obronę. Specjalizacja, którą tworzy, zawsze audytuje i wyjaśnia, nigdy nie dostarcza działającego exploita, payloadu ani sposobu na obejście zabezpieczeń. ## Co zapisuje Wynikiem są dwa pliki w twoim projekcie, które trafiają do commita razem z twoim kodem i można je przejrzeć: - Specjalizacja w pliku `.lagune/catalog/.md`, zbudowana tak jak [wbudowane](https://lagune.ai/pl-PL/docs/catalog). - Jej wpis w pliku `.lagune/configs.json`, w którym projekt indeksuje własne specjalizacje, aby katalog mógł połączyć je z wbudowanymi. Następnie polecenie wyświetla katalog, aby potwierdzić, że nowy wpis się w nim znalazł. Twoje własne specjalizacje zawsze są w katalogu, niezależnie od jego kategorii. Nigdy nie dodajesz polecenia ani nie zmieniasz pakietu: nowa specjalność to jeden plik z wiedzą i jeden wpis w indeksie, zapisane w twoim własnym projekcie. ## Udoskonalaj, nigdy nie nadpisuj Gdy specjalizujesz nazwę, która już istnieje, czy to wbudowaną, taką jak `regex`, czy własną, utworzoną wcześniej, polecenie **uzgadnia** bieżący plik zamiast go zastępować. Czyta to, co w nim jest, wplata nową wiedzę, zachowuje to, co nadal obowiązuje, i przepisuje to, co się zmieniło. Nic nie zostaje odrzucone bez przejrzenia. Twoja specjalizacja przesłania wbudowaną o tej samej nazwie, więc możesz dopracować wbudowaną specjalizację na potrzeby swojego projektu, nie tracąc jej. **Wskazówka** - Nowa specjalizacja ładuje się dokładnie tak jak wbudowana: fazy detect i verify sięgają po nią na żądanie, możesz też załadować ją samodzielnie poleceniem `npx lagune read catalog ` i zlecić jej zadanie. - Gdy materiał ma rozpoznawalne pochodzenie (artykuł, autor, link, standard), specjalizacja podaje je jako źródło. Sam temat nie ma źródła. **Notatka** **Działa tylko wtedy, gdy je wywołasz:** agent nigdy nie uruchamia go z własnej inicjatywy. ## Najczęściej zadawane pytania ### Jak dodać własną specjalizację bezpieczeństwa? Uruchom /lagune-specialize ze źródłem lub tematem. Polecenie destyluje je do postaci wyłącznie defensywnej specjalizacji, zapisanej w .lagune/catalog/.md, i dodaje jej wpis w .lagune/configs.json. ### Czy Lagune może się uczyć z opisu exploita? Tak, jako źródło, nigdy jako wynik. Atak może być źródłem, nigdy produktem. Specialize nigdy nie pisze danych wejściowych do ataku ani exploitów. ### Czy specialize nadpisuje wbudowane specjalizacje? Nie. Udoskonala je, nigdy nie nadpisuje. --- # /lagune-prove: Wyłącznie defensywny Proof of Concept > Zamień każde wykryte ustalenie w gotowy do uruchomienia, wyłącznie defensywny Proof of Concept (PoC) z biuletynem bezpieczeństwa do odpowiedzialnego ujawniania. Adres kanoniczny: https://lagune.ai/pl-PL/docs/commands/prove Język: pl-PL Oryginał: https://lagune.ai/docs/commands/prove Ostatnia aktualizacja: 2026-11-09 🧪 Zamień każde wykryte ustalenie w gotowe do uruchomienia, wyłącznie defensywne dowody do odpowiedzialnego ujawniania. Dla każdego ustalenia z mapy wykrywania polecenie pisze samodzielny biuletyn bezpieczeństwa i test, który sprawdza **bezpieczną ścieżkę**. Dzięki temu test nie przechodzi, dopóki problem istnieje, i przechodzi, gdy tylko kod zostanie poprawiony. **Wskazówka** Testy **Lagune** są odizolowane w folderze `.lagune/`, z dala od twoich własnych testów. ## Użycie **Każde ustalenie** ```prompt /lagune-prove ``` **Wybrane ustalenie** Wyświetl nazwy ustaleń, które są już śledzone: ```prompt npx lagune read list --findings # Findings # ... # • SQL injection w wyszukiwaniu użytkownika # ... ``` ```prompt # Potem wykaż jedno z nich /lagune-prove SQL injection w wyszukiwaniu użytkownika ``` ## Jak to działa Polecenie czyta kod źródłowy, na który wskazuje każde ustalenie, i dla każdego wykazanego ustalenia tworzy w `.lagune/proofs/` osobny folder z dokładnie dwoma plikami: | Plik | Czym jest | | ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | `report.test.mjs` (lub `.cjs`) | Test. Uruchamia się w Poku, jeśli twój projekt już go używa, a w przeciwnym razie w natywnym runnerze testów Node.js, więc niczego nie trzeba instalować. | | `report.md` | Samodzielny biuletyn bezpieczeństwa: poziom zagrożenia, skutki, sposób odtworzenia problemu i polecenie uruchomienia, zrozumiały bez dodatkowego kontekstu. | Wykazania są zawsze napisane w JavaScripcie, więc pozostają przenośne niezależnie od języka twojego projektu. Indeks `README.md` linkuje do każdego wykazania i podaje jedno polecenie, które uruchamia je wszystkie. **Wskazówka** - Polecenie jest **opcjonalne i autonomiczne**: nie należy do pięciu faz ani do łańcucha śledzenia. - Zapisuje wyłącznie w `.lagune/proofs/` i nigdy nie zmienia artefaktów faz ani twojego kodu, który tylko czyta. - Ustalenie, którego test nie odtwarza problemu, nie dostaje wykazania, a polecenie każe ci uruchomić [`/lagune-detect`](https://lagune.ai/pl-PL/docs/commands/detect) dla tego miejsca, aby uzgodnić stan. - Ponowne uruchomienie uzgadnia wykazania: jeśli ustalenie zniknęło albo problemu nie da się już odtworzyć, jego folder zostaje usunięty. **Notatka** **Działa tylko wtedy, gdy je wywołasz:** agent nigdy nie uruchamia go z własnej inicjatywy. **Opiera się na fazie detect** Prove czyta mapę wykrywania z polecenia [`/lagune-detect`](https://lagune.ai/pl-PL/docs/commands/detect), więc najpierw uruchom detect. ## Wyłącznie defensywnie i za zgodą Zanim cokolwiek wygeneruje, polecenie upewnia się, że masz uprawnienia do testowania celu, i odrzuca każdą prośbę o działający exploit, payload ataku lub sposób na uniknięcie wykrycia. Wykazanie pokazuje bezpieczne zachowanie i nigdy nie generuje danych wejściowych do ataku. ## Od wykazania do ujawnienia Aby zgłosić podatność, udostępnij oba pliki wykazanego ustalenia razem przez **prywatny GitHub Gist**. Są dowodem istniejącego, jeszcze nieujawnionego problemu, dlatego plik `.gitignore` w `.lagune/proofs/` trzyma je z dala od każdego commita: udostępniaj je wyłącznie przez ten Gist, dopóki opiekunowie projektu nie rozwiążą problemu. Zamykanie ustalenia w łańcuchu **Lagune** pozostaje zadaniem poleceń [`/lagune-harden`](https://lagune.ai/pl-PL/docs/commands/harden) i [`/lagune-verify`](https://lagune.ai/pl-PL/docs/commands/verify): prove dostarcza dowody, ale niczego nie zamyka. ## Najczęściej zadawane pytania ### Czy Lagune generuje exploity? Nie. /lagune-prove tworzy wyłącznie defensywne dowody: test, który sprawdza bezpieczną ścieżkę, więc nie przechodzi, dopóki problem istnieje, i przechodzi, gdy tylko kod zostanie poprawiony, a do tego biuletyn bezpieczeństwa do odpowiedzialnego ujawniania. ### Co tworzy prove? Dwa pliki na każde ustalenie: test (report.test.mjs lub .cjs) i biuletyn bezpieczeństwa (report.md). ### Jak odpowiedzialnie zgłosić błąd znaleziony przez Lagune? Prove tworzy samodzielny biuletyn bezpieczeństwa, który możesz udostępnić prywatnym kanałem, na przykład przez prywatny GitHub Gist, zgodnie z zasadami odpowiedzialnego ujawniania. --- # Konfiguracja hooków: Wybierz, co przeszukują > Wybierz, co pomijają hooki przeszukujące pliki, wszystkie naraz albo pojedynczy hook. Adres kanoniczny: https://lagune.ai/pl-PL/docs/hooks/configure Język: pl-PL Oryginał: https://lagune.ai/docs/hooks/configure Ostatnia aktualizacja: 2026-11-09 Blok `checkers` w pliku `.lagune/configs.json` określa, co pomijają hooki przeszukujące pliki, wszystkie naraz albo pojedynczy hook. ## Konfiguracja Dodawaj i usuwaj ścieżki oraz wzorce z wiersza poleceń, a wzorzec ujmuj w cudzysłów, żeby powłoka zostawiła go bez zmian: ```bash npx lagune write add --ignore test/fixtures npx lagune write add --ignore 'packages/*/dist' --checker secrets npx lagune write remove --ignore test/fixtures ``` Możesz też wybrać je w sekcji Settings [dashboardu](https://lagune.ai/pl-PL/docs/get-started/dashboard) albo ustawić w pliku: ```json { "checkers": { "ignore": ["test/fixtures"], "secrets": { "gitignore": false, "ignore": ["test/fixtures", "temp"] } } } ``` ### Ustawienia | Klucz | Wartość | Domyślnie | Opis | | ----------- | ----------------------------------------------------- | --------- | -------------------------------------------------------------------------------------------------- | | `gitignore` | `true` lub `false` | `true` | Pomija to, co **Git** ignoruje. Plik, który **Git** śledzi, jest przeszukiwany w każdym przypadku. | | `ignore` | ścieżki lub wzorce względem głównego folderu projektu | `[]` | Pomija to, do czego pasuje każdy wpis, wraz z całą zawartością, nawet plik, który **Git** śledzi. | Na najwyższym poziomie bloku `checkers` klucz dotyczy wszystkich narzędzi sprawdzających. Pod nazwą konkretnego narzędzia dotyczy tylko jego i zastępuje klucz wspólny, więc w przykładzie narzędzie `secrets` przeszukuje to, co **Git** ignoruje, i pomija `test/fixtures` oraz `temp`. Gdy polecenie `write add --ignore` nadaje narzędziu pierwszą własną listę, lista ta powstaje jako kopia listy wspólnej. ### Wzorce Wzorzec zaczyna się od głównego folderu projektu, więc `*.generated.ts` obejmuje tylko pliki w tym folderze, a `**/*.generated.ts` obejmuje je na dowolnej głębokości. Nazwy muszą pasować dokładnie, łącznie z wielkością liter. | Wzorzec | Pomija | | ------------------- | ------------------------------------------------------- | | `dist` | `dist` w głównym folderze projektu | | `packages/*/dist` | `dist` w każdym folderze wewnątrz `packages` | | `**/dist` | każdy `dist`, na dowolnej głębokości | | `**/*.generated.ts` | każdy plik, którego nazwa kończy się na `.generated.ts` | | `fixture-?` | `fixture-a`, `fixture-1` i podobne | | `[ab]-cache` | `a-cache` i `b-cache` | | `[*]x` | `*x`, z dosłowną gwiazdką `*` | ## Jak czytać wynik Raport kończy się informacją, ile ścieżek pominęło skanowanie, z podziałem według tego, co je ignoruje: ```text Skipped 25 paths that Git ignores and 3 paths that .lagune/configs.json ignores. Name one with --dir or --file to scan it. ``` Ścieżka wskazana opcją `--dir` lub `--file` jest przeszukiwana bez względu na ustawienia. Ustawienie, którego silnik nie potrafi odczytać, zatrzymuje narzędzie sprawdzające z błędem, który je wskazuje, na przykład wzorzec, który zaczyna się od `!` lub spacji, wychodzi poza projekt, zostawia otwarty nawias albo dopasowuje się zbyt długo. ## Najczęściej zadawane pytania ### Czy Lagune ustawia to za mnie? Nie. Faza charter wymienia foldery obecne w repozytorium, które według jej analizy nie należą do kodu, którego musisz bronić, na przykład fixtury testowe napisane tak, żeby wyglądały na podatne, i zapisuje tylko te, które wybierzesz numerem. ### Kiedy narzędzie sprawdzające powinno przeszukiwać to, co ignoruje Git? Gdy nie możesz ufać repozytorium, bo jego własne pliki .gitignore mogą ukrywać kod, albo gdy folder z buildem może zawierać klucz wstawiony podczas budowania. Ustaw gitignore na false dla wszystkich narzędzi sprawdzających albo dla jednego z nich. --- # Hook agent: Wykrywanie pętli agentów bez limitu > Przeszukaj bazę kodu pod kątem wywołań agentów i LLM bez limitu kroków lub czasu albo oceń pojedyncze wywołanie z wiersza poleceń. Adres kanoniczny: https://lagune.ai/pl-PL/docs/hooks/agent Język: pl-PL Oryginał: https://lagune.ai/docs/hooks/agent Ostatnia aktualizacja: 2026-11-09 Hook `agent` zgłasza **środowiska uruchomieniowe agentów, które działają w pętli bez limitu tur, budżetu lub czasu**, czyli lukę niekontrolowanej autonomii, przez którą spreparowane dane wejściowe prowadzą do nieograniczonych kosztów albo eskalacji przez prompt injection. **Rozpoznaje język** i obejmuje dwa ekosystemy frameworków agentowych: **JavaScript** (środowisko `query` z SDK agentów **Claude**) i **Python** (**LangChain**, **LangGraph**, **CrewAI**, **OpenAI Agents**). Jest deterministycznym silnikiem stojącym za [specjalizacją `llm`](https://lagune.ai/pl-PL/docs/catalog), a ty możesz go uruchomić samodzielnie w trybie **scan** lub **check**. ## Uruchamianie **Przeszukaj bazę kodu** ```bash npx lagune read agent # scans the whole project npx lagune read agent --dir src/ai # scans a directory npx lagune read agent --file chat.ts # scans a single file ``` **Sprawdź wywołanie** ```bash npx lagune read agent --lang javascript --pattern 'query({ prompt })' # => uncapped npx lagune read agent --lang javascript --pattern 'query({ prompt, options: { maxTurns: 5 } })' # => safe npx lagune read agent --lang python --pattern 'AgentExecutor(agent=a, max_iterations=None)' # => uncapped ``` Każdy wiersz pod nagłówkiem **Uncapped agent loops found** dotyczy pliku, który importuje SDK agentów, i wskazuje albo wywołanie środowiska `query` z SDK agentów Claude bez limitu tur, budżetu lub czasu (JavaScript, domyślnie bez ograniczeń), albo jawne zniesienie domyślnego limitu frameworka, takie jak `max_iterations=None` / `max_turns=None` (Python, domyślnie z limitem). W obu przypadkach hook kończy działanie z niezerowym kodem wyjścia. W Vercel AI SDK funkcje `generateText`/`streamText` domyślnie wykonują jeden krok (`stopWhen: stepCountIs(1)`), więc samo ich wywołanie nie może się zapętlić i nie jest zgłaszane, a zwykłego `db.query(...)` hook nigdy nie myli z wywołaniem agenta. Gdy nic nie znajdzie, wypisuje `no uncapped agent loops found`. ## Jak czytać werdykt | Werdykt | Znaczenie | | ---------- | ----------------------------------------------------------------------------------------------------------------- | | `uncapped` | Wywołanie środowiska `query` bez limitu (JS) albo jawne zniesienie limitu (`=None`, Py). | | `safe` | Wywołanie `query`, które ustawia limit, generowanie w jednym kroku albo wywołanie frameworka z domyślnym limitem. | | `invalid` | Fragment kodu nie zawiera rozpoznawalnego wywołania agenta, które można by ocenić. | ### Opcje CLI | Opcja | Wartość | Opis | | ----------- | ------------- | -------------------------------------------------------------------------------------------- | | `--pattern` | fragment kodu | Sprawdza jedno wywołanie. Powtórz opcję, aby sprawdzić kilka, po jednym werdykcie na wiersz. | | `--lang` | język | Wymagana z `--pattern`: `javascript` lub `python`. | | `--dir` | folder | Zawęża skanowanie do folderu. Można ją powtarzać i łączyć z `--file`. | | `--file` | plik | Zawęża skanowanie do jednego pliku. Można ją powtarzać i łączyć z `--dir`. | Bez żadnej opcji przeszukuje cały projekt. Opcja `--pattern` wymaga `--lang` i nie można jej łączyć z `--dir` ani `--file`. ### Wybierz, co przeszukuje Pomija to, co **Git** ignoruje. Aby pominąć więcej albo przeszukać to, co **Git** ignoruje, nadaj hookowi `agent` własne ustawienia: ```bash npx lagune write add --ignore test/fixtures --checker agent ``` ```json { "checkers": { "agent": { "gitignore": false, "ignore": ["test/fixtures"] } } } ``` Wszystkie ustawienia opisuje strona [Konfiguracja hooków](https://lagune.ai/pl-PL/docs/hooks/configure). **W miarę możliwości, bez gwarancji kompletności** Ręcznie napisana pętla agenta, w dowolnym języku, wykracza poza możliwości skanowania statycznego. Traktuj wynik jako solidne minimum, a nie pełną inwentaryzację. **Wskazówka** Hook rozstrzyga tylko kwestię limitu: zawężanie uprawnień agenta, mieszanie poziomów zaufania i autoryzacja wymagają oceny, którą nadal zapewnia [specjalizacja `llm`](https://lagune.ai/pl-PL/docs/catalog). ## Najczęściej zadawane pytania ### Po co ograniczać pętlę agenta? Agenta bez limitu można wciągnąć w niekończącą się rekurencję, nieograniczone koszty albo eskalację przez prompt injection. Ustawienie maxTurns/maxBudgetUsd/stopWhen/signal go ogranicza, a hook agent zgłasza każde wywołanie środowiska query, które nie ustawia żadnego z nich. --- # Hook cors: Audyt originów CORS > Przeszukaj kod źródłowy pod kątem listy dozwolonych originów CORS, którą da się obejść, albo oceń z wiersza poleceń, czy pojedyncza wartość originu nie daje zbyt szerokiego dostępu. Adres kanoniczny: https://lagune.ai/pl-PL/docs/hooks/cors Język: pl-PL Oryginał: https://lagune.ai/docs/hooks/cors Ostatnia aktualizacja: 2026-11-09 Hook `cors` jest deterministycznym silnikiem stojącym za [specjalizacją `http-request`](https://lagune.ai/pl-PL/docs/catalog), a ty możesz go uruchomić samodzielnie. Jedno polecenie działa w dwóch trybach: w trybie **scan** przeszukuje kod źródłowy w poszukiwaniu **listy dozwolonych originów, którą da się obejść** (wyrażenia regularnego walidującego hosta, przez które prześlizguje się host atakującego), a w trybie **score** ocenia pojedynczą wartość **originu CORS** jako `wildcard`, `null` lub `safe`. ## Skanowanie bazy kodu Bez żadnej opcji przeszukuje cały projekt. **Cały projekt** ```bash npx lagune read cors ``` **Folder** ```bash npx lagune read cors --dir src/server ``` **Pojedynczy plik** ```bash npx lagune read cors --file internal/auth/origin.go ``` Wypisuje każdą listę dozwolonych originów, którą da się obejść, pod jednym nagłówkiem, z podziałem na pliki. Walidator hosta, w którym `.+`/`.*` stoi w części authority przed sufiksem zaufanego hosta (`^https?://.+\.trusted\.com`), przepuszcza host atakującego, taki jak `your-site.com.attacker.com`. ```text Origin-allowlist patterns with a greedy wildcard (bypassable, review): internal/auth/origin.go ^https?://.+\.trusted\.com ``` To wskazówka do przeglądu, a nie zamknięte ustalenie: z samego tekstu nie da się rozstrzygnąć, czy wyrażenie regularne strzeże rzeczywistej decyzji o zaufaniu, więc skanowanie nigdy nie zmienia kodu wyjścia. Przejrzyj każde trafienie i upewnij się, że lista dozwolonych porównuje origin na zasadzie pełnej równości. Gdy nic nie znajdzie, wypisuje jeden wiersz. ```bash npx lagune read cors --dir src/clean # => no bypassable origin allowlist found ``` ## Ocena originu Podaj każdy origin w opcji `--origin`. Hook wypisuje jedno słowo na każdy origin i kończy działanie z niezerowym kodem wyjścia przy każdym `wildcard` lub `null`. **Jeden origin** ```bash npx lagune read cors --origin '*' # => wildcard npx lagune read cors --origin 'null' # => null npx lagune read cors --origin 'https://app.example.com' # => safe ``` **Kilka originów** Powtórz opcję `--origin`, aby jednym wywołaniem ocenić całą listę dozwolonych, po jednym werdykcie na wiersz, w tej samej kolejności. ```bash npx lagune read cors \ --origin 'https://app.example.com' \ --origin '*' \ --origin 'null' # => safe # => wildcard # => null ``` | Werdykt | Znaczenie | | ---------- | --------------------------------------------------------------------------------------------------------- | | `safe` | Nie jest to `*`, `null` ani glob z `*`. Nie gwarantuje to poprawnie zbudowanego originu. | | `wildcard` | `*` albo glob subdomeny, hosta lub portu: odpowiedź może odczytać dowolna strona (lub szeroki ich zbiór). | | `null` | Origin `null`, który mogą sfałszować ramki iframe w piaskownicy i przekierowania. | Tylko `safe` oznacza zezwolenie, a opcja `--origin` to wyrocznia wartości: ocenia wartość, a nie handler, więc handler sprawdź za pomocą specjalizacji `http-request`. ### Opcje CLI | Opcja | Wartość | Opis | | ---------- | ------- | ----------------------------------------------------------------------------------- | | `--origin` | origin | Ocenia jedną wartość originu. Powtórz opcję, aby ocenić kilka, po jednej na wiersz. | | `--dir` | folder | Zawęża skanowanie do folderu. Można ją powtarzać i łączyć z `--file`. | | `--file` | plik | Zawęża skanowanie do jednego pliku. Można ją powtarzać i łączyć z `--dir`. | Bez żadnej opcji przeszukuje cały projekt. Opcja `--origin` włącza tryb score i nie można jej łączyć z `--dir` ani `--file`. ### Wybierz, co przeszukuje Pomija to, co **Git** ignoruje. Aby pominąć więcej albo przeszukać to, co **Git** ignoruje, nadaj hookowi `cors` własne ustawienia: ```bash npx lagune write add --ignore test/fixtures --checker cors ``` ```json { "checkers": { "cors": { "gitignore": false, "ignore": ["test/fixtures"] } } } ``` Wszystkie ustawienia opisuje strona [Konfiguracja hooków](https://lagune.ai/pl-PL/docs/hooks/configure). **Czego nie obejmuje** Skanowanie rozpoznaje kształt **wyrażenia regularnego, które da się obejść**, a opcja `--origin` ocenia **wartości** originów. Dwa wzorce na poziomie kodu źródłowego pozostają poza ich zasięgiem: odbijanie nagłówka `Origin` z żądania (serwer odsyła przychodzący `Origin` z powrotem albo łączy go z danymi uwierzytelniającymi) oraz zbyt liberalna lista dozwolonych oparta na `endsWith` lub dopasowaniu podciągu. Rozpoznaj je w kodzie i postępuj z nimi tak, jak opisuje [specjalizacja `http-request`](https://lagune.ai/pl-PL/docs/catalog). ## Najczęściej zadawane pytania ### Dlaczego origin null w CORS jest niebezpieczny? Ramki iframe w piaskownicy i niektóre przekierowania wysyłają Origin: null, więc lista dozwolonych, która ufa null, daje tym kontekstom dostęp do odczytu. Hook cors zgłasza to razem z wildcardem. ### Jak wykryć listę dozwolonych originów CORS, którą da się obejść? Uruchom npx lagune read cors na bazie kodu. Hook zgłasza wyrażenie regularne walidujące hosta, którego zachłanny wildcard stoi przed zaufanym sufiksem, przez co host atakującego, taki jak your-site.com.attacker.com, prześlizguje się przez walidację. --- # Hook crypto: Wykrywanie słabej kryptografii > Przeszukaj bazę kodu pod kątem słabych prymitywów kryptograficznych albo oceń pojedynczy fragment kodu z wiersza poleceń. Adres kanoniczny: https://lagune.ai/pl-PL/docs/hooks/crypto Język: pl-PL Oryginał: https://lagune.ai/docs/hooks/crypto Ostatnia aktualizacja: 2026-11-09 Hook `crypto` zgłasza **słabe prymitywy kryptograficzne** bezpośrednio w miejscu wywołania: przestarzały szyfr, niebezpieczny tryb albo złamaną funkcję skrótu. **Rozpoznaje język** i czyta każdy plik według jego własnych reguł, więc nigdy nie zgłosi konstrukcji z Pythona w pliku napisanym w Rust. Jest deterministycznym silnikiem stojącym za [specjalizacją `crypto`](https://lagune.ai/pl-PL/docs/catalog), a ty możesz go uruchomić samodzielnie w trybie **scan** lub **check**. ## Uruchamianie **Przeszukaj bazę kodu** ```bash npx lagune read crypto # scans the whole project npx lagune read crypto --dir src # scans a directory npx lagune read crypto --file hash.ts # scans a single file ``` **Sprawdź fragment kodu** ```bash npx lagune read crypto --lang javascript --pattern 'createCipher("aes-256-cbc", k)' # => weak npx lagune read crypto --lang python --pattern 'hashlib.md5(data)' # => review npx lagune read crypto --lang go --pattern 'sha256.Sum256(data)' # => safe ``` Skanowanie wypisuje do dwóch sekcji. Sekcja **Weak cryptography found** zawiera ustalenia (DES/3DES/RC4/Blowfish/RC2, tryb ECB): każde z nich to złamany prymityw szyfrujący, więc hook kończy działanie z niezerowym kodem wyjścia. Sekcja **Cryptography to review manually** zawiera wskazówki, których hook nie potrafi ocenić sam: skrót MD5 lub SHA-1 (złamany do zastosowań związanych z bezpieczeństwem, ale uzasadniony jako zwykła suma kontrolna, więc decyduje intencja), niekryptograficzny generator liczb losowych w kontekście bezpieczeństwa albo porównanie podatne na ataki czasowe. Gdy nic nie znajdzie, wypisuje `no weak cryptography found`. ## Jak czytać werdykt | Werdykt | Znaczenie | | --------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | `weak` | Fragment kodu używa złamanego prymitywu szyfrującego (DES/3DES, RC4, Blowfish, RC2 lub trybu ECB). | | `review` | Prymityw, którego ocena zależy od intencji: skrót MD5 lub SHA-1 albo niekryptograficzny generator liczb losowych w kontekście bezpieczeństwa. | | `safe` | Fragment kodu korzysta z kryptografii i nie znaleziono w nim słabego prymitywu. | | `invalid` | Fragment kodu nie zawiera rozpoznawalnej konstrukcji kryptograficznej, którą można by ocenić. | ### Opcje CLI | Opcja | Wartość | Opis | | ----------- | ------------- | ------------------------------------------------------------------------------------------------------ | | `--pattern` | fragment kodu | Sprawdza jeden fragment kodu. Powtórz opcję, aby sprawdzić kilka, po jednym werdykcie na wiersz. | | `--lang` | język | Wymagana z `--pattern`: jeden z javascript, python, go, java, kotlin, php, ruby, rust, csharp, c, cpp. | | `--dir` | folder | Zawęża skanowanie do folderu. Można ją powtarzać i łączyć z `--file`. | | `--file` | plik | Zawęża skanowanie do jednego pliku. Można ją powtarzać i łączyć z `--dir`. | Bez żadnej opcji przeszukuje cały projekt. Opcja `--pattern` wymaga `--lang` i nie można jej łączyć z `--dir` ani `--file`. ### Wybierz, co przeszukuje Pomija to, co **Git** ignoruje. Aby pominąć więcej albo przeszukać to, co **Git** ignoruje, nadaj hookowi `crypto` własne ustawienia: ```bash npx lagune write add --ignore test/fixtures --checker crypto ``` ```json { "checkers": { "crypto": { "gitignore": false, "ignore": ["test/fixtures"] } } } ``` Wszystkie ustawienia opisuje strona [Konfiguracja hooków](https://lagune.ai/pl-PL/docs/hooks/configure). ### Obsługiwane języki Skanowanie czyta te języki, rozpoznając je po rozszerzeniu pliku, i sprawdza każdy pod kątem jego własnych API kryptograficznych. | Język | Słabe szyfry (ustalenie) oraz skróty i generatory liczb losowych (do przeglądu) | | --------------------------- | ------------------------------------------------------------------------------------------------------------------ | | **JavaScript / TypeScript** | `createCipher`, `CryptoJS.DES/RC4`, `*-ecb` w cudzysłowie; MD5/SHA-1 `createHash`/`subtle.digest`; `Math.random()` | | **Python** | pycryptodome `DES/ARC4/Blowfish.new`, `algorithms.TripleDES`, `MODE_ECB`; `hashlib.md5/sha1`; `random.*` | | **Go** | `des.NewCipher`, `rc4.NewCipher`, `blowfish.NewCipher`, `NewECBEncrypter`; `md5/sha1.Sum`; `math/rand` | | **Java / Kotlin** | `Cipher.getInstance("DES"/…/ECB")`; `MessageDigest.getInstance("MD5")`, `HmacMD5`; `java.util.Random` | | **PHP** | `openssl_encrypt("des-…"/"…-ecb")`, `mcrypt_*`; `md5()`/`sha1()`, `hash("md5", …)`; `rand()`/`mt_rand()` | | **Ruby** | `OpenSSL::Cipher.new("des-…")`, `:ECB`; `Digest::MD5/SHA1`; `rand()`/`Random` | | **Rust** | `Rc4::`, `Blowfish::`, `des::`, `ecb::`; `Md5::`, `Sha1::`, `Hmac`; `SmallRng`/`XorShiftRng` | | **C#** | `DES/TripleDES/RC2.Create`, `CipherMode.ECB`; `MD5/SHA1.Create`, `HMACMD5`; `new Random()` | | **C / C++** | OpenSSL `DES_*`/`RC4`/`EVP_des_*`, `EVP_*_ecb`; `MD5()`/`SHA1()`, `EVP_md5`; `rand()`/`random()` | **W miarę możliwości, bez gwarancji kompletności** Hook czyta kod źródłowy jako tekst, więc może przeoczyć prymityw składany w czasie działania programu, ukryty za aliasem albo zapisany w formie, której nie rozpoznaje. Traktuj tabelę jako solidny punkt wyjścia, a nie pełną inwentaryzację. **Wskazówka** Hook gwarantuje minimum (że te konstrukcje występują w kodzie): zarządzanie kluczami, ponowne użycie IV i padding RSA wymagają oceny, którą nadal zapewnia [specjalizacja `crypto`](https://lagune.ai/pl-PL/docs/catalog). ## Najczęściej zadawane pytania ### Jak przeszukać bazę kodu pod kątem słabej kryptografii? Uruchom hook crypto bez żadnej opcji. Złamane szyfry i tryb ECB to ustalenia, przy których hook kończy działanie z niezerowym kodem wyjścia. Skrót MD5 lub SHA-1 to wskazówka do przeglądu, bo jest złamany do zastosowań związanych z bezpieczeństwem, ale uzasadniony jako zwykła suma kontrolna. ### Czy hook crypto zgłasza Math.random()? Tylko jako wskazówkę do przeglądu w kontekście bezpieczeństwa, nigdy jako automatyczne ustalenie, bo losowość jest uzasadniona przy jitterze albo przy ustalaniu kolejności elementów w interfejsie. --- # Hook cvss: Ocena wektora CVSS v4.0 > Oceniaj jeden lub wiele wektorów CVSS v4.0 z wiersza poleceń, licząc tak samo jak kalkulator FIRST, i zobacz każdy z nich objaśniony prostymi słowami. Adres kanoniczny: https://lagune.ai/pl-PL/docs/hooks/cvss Język: pl-PL Oryginał: https://lagune.ai/docs/hooks/cvss Ostatnia aktualizacja: 2026-11-09 Hook `cvss` ocenia **wektor CVSS v4.0** i wypisuje jego wynik oraz przedział poziomu zagrożenia, czyli ocenę, którą polecenie [`/lagune-plan`](https://lagune.ai/pl-PL/docs/commands/plan) zapisuje przy każdej poprawce, a polecenie [`/lagune-prove`](https://lagune.ai/pl-PL/docs/commands/prove) przy każdym biuletynie bezpieczeństwa. To deterministyczny silnik stojący za tymi ocenami, który liczy dokładnie tak samo jak [kalkulator FIRST](https://www.first.org/cvss/calculator/4.0), i możesz uruchomić go samodzielnie. ## Uruchamianie Przekaż każdy wektor w opcji `--vector`. Hook wypisuje po jednej linii na wektor: jego wynik i przedział. **Jeden wektor** ```bash npx lagune read cvss --vector 'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N' # => 9.3, Critical ``` **Kilka wektorów** Powtórz `--vector`, aby ocenić kilka wektorów naraz, każdy w osobnej linii, w tej samej kolejności. ```bash npx lagune read cvss \ --vector 'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N' \ --vector 'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/MAV:A' # => 9.3, Critical # => 8.7, High ``` **Prostymi słowami** Dodaj `--explain`, aby zobaczyć każdą metrykę objaśnioną prostymi słowami. Gdy metryki Threat lub Environmental zmieniają wynik, najpierw pojawia się sam wynik Base. ```bash npx lagune read cvss --explain --vector 'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/MAV:A' # => 8.7, High # => Base metrics alone: 9.3, Critical # => Attack Vector: Network, modified to Adjacent # => Attack Complexity: Low # => ... ``` ## Jak odczytać wynik | Przedział | Wynik | | ---------- | -------------- | | `None` | 0.0 | | `Low` | od 0.1 do 3.9 | | `Medium` | od 4.0 do 6.9 | | `High` | od 7.0 do 8.9 | | `Critical` | od 9.0 do 10.0 | Wektor zawierający tylko metryki Base ocenia samą podatność i zakłada najgorszy przypadek: każde wymaganie bezpieczeństwa ma poziom High, a podatność jest aktywnie atakowana w praktyce. Metryki Environmental (`MAV` i pozostałe metryki zmodyfikowane oraz `CR`, `IR` i `AR`) dopasowują wynik do konkretnego wdrożenia, a metryka Threat (`E`) do tego, co wiadomo o wykorzystywaniu podatności. Dla nieprawidłowego wektora hook wypisuje `invalid vector:` wraz z opisem błędu i kończy działanie z niezerowym kodem wyjścia. ### Opcje CLI | Opcja | Wartość | Opis | | ----------- | ----------------- | ---------------------------------------------------------------------------------------------- | | `--vector` | wektor `CVSS:4.0` | Ocenia jeden wektor. Powtórz, aby ocenić kilka, każdy w osobnej linii, w tej samej kolejności. | | `--explain` | | Dodaje pod każdą linią z oceną objaśnienie każdej metryki prostymi słowami. | Wymagana jest co najmniej jedna opcja `--vector`. Wektor nigdy nie jest samodzielnym argumentem pozycyjnym, więc nie da się go pomylić z flagą. **Dlaczego wartość flagi** Każdy wektor trafia do hooka jako wartość flagi i nigdy nie jest wstawiany do polecenia. Wartość z cudzysłowami lub backtickami pozostaje nieszkodliwa i nie może niczego wstrzyknąć do powłoki. Zawsze ujmuj ją w apostrofy, aby powłoka nie rozwinęła jej wcześniej. **Czego nie obejmuje** Tylko CVSS v4.0: hook odrzuca wektor w wersji v2.0, v3.0 lub v3.1, zamiast go ocenić, bo **Lagune** ocenia każde ustalenie w wersji v4.0. **Wskazówka** Walidacja fazy plan powtarza te same obliczenia dla każdej linii CVSS, więc wynik, który rozminął się ze swoim wektorem, zostaje wychwycony, zanim plan zostanie zaakceptowany. ## Najczęściej zadawane pytania ### Jak Lagune oblicza wynik CVSS? Hook cvss liczy według referencyjnego kalkulatora FIRST dla CVSS v4.0, więc wektor otrzymuje dokładnie taki sam wynik jak na stronie FIRST. ### Czy mogę nim ocenić wektor CVSS v3.1? Nie. Lagune ocenia każde ustalenie w CVSS v4.0, a hook odrzuca każdą inną wersję, zamiast ją oceniać. ### Do czego służy flaga --explain? Objaśnia każdą metrykę prostymi słowami i pokazuje wynik Base obok wyniku ogólnego, dzięki czemu każdy widzi, co mówi wektor i jak kontekst projektu zmienił wynik. --- # Hook infra: Wykrywanie błędnej konfiguracji IaC > Przeszukuj Terraform, pliki Dockerfile i GitHub Actions pod kątem błędnej konfiguracji albo oceniaj pojedynczy fragment kodu z wiersza poleceń. Adres kanoniczny: https://lagune.ai/pl-PL/docs/hooks/infra Język: pl-PL Oryginał: https://lagune.ai/docs/hooks/infra Ostatnia aktualizacja: 2026-11-09 Hook `infra` zgłasza **błędną konfigurację infrastruktury jako kodu (IaC)**, którą da się rozstrzygnąć na podstawie samego pliku: sieć otwartą na cały świat, uprawnienie z symbolem wieloznacznym, sekret w manifeście, kontener działający jako root, niezaufaną wartość w powłoce CI. Czyta wyłącznie pliki IaC (`.tf`/`.tf.json`/`.hcl`, `Dockerfile*`, `.github/workflows/**`). To deterministyczny silnik stojący za [specjalizacją `infra`](https://lagune.ai/pl-PL/docs/catalog), działający w trybie **scan** lub **check**. ## Uruchamianie **Przeszukaj bazę kodu** ```bash npx lagune read infra # scans every IaC file npx lagune read infra --dir infra # scans a directory npx lagune read infra --file Dockerfile # scans a single file ``` **Sprawdź fragment kodu** Przekaż fragment kodu w opcji `--pattern`, a jego rodzaj w opcji `--kind` (`terraform`, `dockerfile` lub `github-actions`). ```bash npx lagune read infra --kind terraform --pattern 'actions = ["*"]' # => iam-wildcard npx lagune read infra --kind dockerfile --pattern 'FROM node:20' # => mutable-tag ``` Skanowanie wypisuje maksymalnie dwie sekcje. **Infrastructure risks found** zawiera rozstrzygalne usterki (regułę ingress dla `0.0.0.0/0` na wrażliwym porcie, instrukcję IAM z symbolem wieloznacznym, sekret w manifeście, `encrypted = false`, moduł git bez przypiętej wersji, obraz, który jawnie działa jako root, `curl | sh`, wstrzyknięcie skryptu w CI, `permissions: write-all`), a gdy się pojawi, hook kończy działanie z niezerowym kodem wyjścia. **Infrastructure hardening advisories** nie zmienia kodu wyjścia (zmienny tag obrazu bazowego, akcja przypięta tylko do tagu). Gdy nic nie znajdzie, hook wypisuje `no infrastructure risks found`. ## Jak odczytać werdykt Tryb check wypisuje dopasowany tag o najwyższym poziomie zagrożenia (na przykład `public-ingress`, `iam-wildcard`, `root-user`, `curl-pipe`, `script-injection`, `write-all`), tag zalecenia (`mutable-tag`, `unpinned-action`) albo `safe`. Niezerowy kod wyjścia daje tylko tag rangi ustalenia. ### Opcje CLI | Opcja | Wartość | Opis | | ----------- | ----------------------------------------------- | ---------------------------------------------------------------------------- | | `--pattern` | fragment kodu | Sprawdza jeden fragment kodu. Wymaga `--kind`. Powtórz, aby sprawdzić kilka. | | `--kind` | `terraform` \| `dockerfile` \| `github-actions` | Rodzaj pliku, według którego oceniany jest fragment. | | `--dir` | folder | Ogranicza skanowanie do folderu. Można powtarzać i łączyć z `--file`. | | `--file` | plik | Ogranicza skanowanie do jednego pliku. Można powtarzać i łączyć z `--dir`. | Bez żadnej opcji hook przeszukuje każdy plik IaC w projekcie. Opcji `--pattern` nie można łączyć z `--dir` ani `--file`. ### Wybierz, co hook przeszukuje Hook pomija to, co ignoruje **Git**. Aby pominąć więcej albo przeszukać to, co ignoruje **Git**, nadaj hookowi `infra` własne ustawienia: ```bash npx lagune write add --ignore examples --checker infra ``` ```json { "checkers": { "infra": { "gitignore": false, "ignore": ["examples"] } } } ``` [Konfiguracja hooków](https://lagune.ai/pl-PL/docs/hooks/configure) opisuje każde ustawienie. **Wskazówka** Hook wychwytuje oczywiste, rozstrzygalne przypadki: brak szyfrowania, ekspozycja przez `pull_request_target` i właściwy zakres IAM wymagają oceny, którą nadal zapewnia [specjalizacja `infra`](https://lagune.ai/pl-PL/docs/catalog). ## Najczęściej zadawane pytania ### Jakie pliki infrastruktury czyta hook infra? Terraform/HCL (.tf, .tf.json, .hcl), pliki Dockerfile oraz pliki YAML z workflowami i akcjami GitHub Actions w .github/. Hook dociera do tych plików, mimo że skanery kodu źródłowego je pomijają. --- # Hook interpreter: Zgłaszanie sinków dynamicznego wykonywania kodu > Przeszukuj bazę kodu w wielu językach pod kątem sinków dynamicznego wykonywania kodu albo oceniaj pojedynczy fragment kodu z wiersza poleceń. Adres kanoniczny: https://lagune.ai/pl-PL/docs/hooks/interpreter Język: pl-PL Oryginał: https://lagune.ai/docs/hooks/interpreter Ostatnia aktualizacja: 2026-11-09 Hook `interpreter` zgłasza **sinki dynamicznego wykonywania kodu**: konstrukcje, które zamieniają dane w uruchamiany kod albo przekazują je do powłoki, od `eval` po natywną deserializację. Rozpoznaje język i czyta każdy plik według jego własnych reguł. To deterministyczny silnik stojący za [specjalizacją `interpreter`](https://lagune.ai/pl-PL/docs/catalog), który możesz uruchomić samodzielnie w trybie **scan** lub **check**. ## Uruchamianie **Przeszukaj bazę kodu** ```bash npx lagune read interpreter # scans the whole project npx lagune read interpreter --dir src # scans a directory npx lagune read interpreter --file app.py # scans a single file ``` **Sprawdź fragment kodu** ```bash npx lagune read interpreter --lang javascript --pattern 'eval(x)' # => careful npx lagune read interpreter --lang python --pattern 'json.loads(x)' # => safe ``` Te sinki mają podwójne zastosowanie: statyczne skanowanie nie rozstrzygnie, czy docierają do nich dane wejściowe zależne od atakującego, więc każde dopasowanie jest **ostrzeżeniem do przejrzenia**, nigdy potwierdzonym ustaleniem. Skanowanie wypisuje jedną sekcję **Dynamic-execution sinks to review**, pogrupowaną według plików. Gdy nic nie znajdzie, hook wypisuje `no dynamic-execution sinks found`. **Czytaj zgłoszony kod, nigdy go nie uruchamiaj!** Analizuj każdy sink **statycznie**, śledząc, czy docierają do niego niezaufane dane wejściowe. Nigdy nie uruchamiaj zgłoszonego kodu, nie przekazuj go do `eval` i nie uruchamiaj żadnego zdalnego ani pobieranego w czasie działania kodu, który on dociąga, tylko po to, aby "przetestować", co robi. ## Jak odczytać werdykt | Werdykt | Znaczenie | | --------- | ------------------------------------------------------------------------------------------------------------------------------------- | | `careful` | Fragment kodu zawiera sink dynamicznego wykonywania typowy dla swojego języka. Przejrzyj go, czytając kod, nigdy go nie uruchamiając. | | `safe` | Nie znaleziono sinka dynamicznego wykonywania dla podanego języka. | ### Opcje CLI | Opcja | Wartość | Opis | | ----------- | ------------- | -------------------------------------------------------------------------------------------------------------------- | | `--pattern` | fragment kodu | Sprawdza jeden fragment kodu. Powtórz, aby sprawdzić kilka, po jednym werdykcie w linii. | | `--lang` | język | Wymagana razem z `--pattern`: jeden z języków javascript, python, php, ruby, java, kotlin, go, rust, c, cpp, csharp. | | `--dir` | folder | Ogranicza skanowanie do folderu. Można powtarzać i łączyć z `--file`. | | `--file` | plik | Ogranicza skanowanie do jednego pliku. Można powtarzać i łączyć z `--dir`. | Bez żadnej opcji hook przeszukuje cały projekt. Opcja `--pattern` wymaga `--lang` i nie można jej łączyć z `--dir` ani `--file`. ### Wybierz, co hook przeszukuje Hook pomija to, co ignoruje **Git**. Aby pominąć więcej albo przeszukać to, co ignoruje **Git**, nadaj hookowi `interpreter` własne ustawienia: ```bash npx lagune write add --ignore test/fixtures --checker interpreter ``` ```json { "checkers": { "interpreter": { "gitignore": false, "ignore": ["test/fixtures"] } } } ``` [Konfiguracja hooków](https://lagune.ai/pl-PL/docs/hooks/configure) opisuje każde ustawienie. ### Obsługiwane języki Skanowanie czyta poniższe języki, rozpoznając je po rozszerzeniu pliku, i każdy sprawdza pod kątem jego własnego zestawu sinków dynamicznego wykonywania. | # | Język | Rozszerzenia | Zgłaszane sinki | | --- | --------------------------- | ------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | **JavaScript / TypeScript** | `.js`, `.jsx`, `.mjs`, `.cjs`, `.ts`, `.tsx`, `.mts`, `.cts`, `.astro`, `.vue`, `.svelte`, `.marko`, `.riot` | `eval()`, konstruktor Function, `setTimeout`/`setInterval` z ciałem w postaci ciągu znaków, moduł `vm`, exec z `child_process`, dynamiczne `require()`, dynamiczny `import()` | | 2 | **Python** | `.py`, `.pyi` | `eval`/`exec`, `__import__()`, `os.system`/`os.popen`, `subprocess` `shell=True`, `pickle.load`/`loads`, `yaml.load` (niebezpieczne) | | 3 | **Ruby** | `.rb` | rodzina eval (`instance_eval`/`class_eval`/`module_eval`/`eval`), `system`/`exec`, backticki lub `%x`, `Kernel#open` / `IO.popen`/`read`/`binread` / `Open3`, `Process.spawn`, `Marshal.load` | | 4 | **Go** | `.go` | `exec.Command`/`exec.CommandContext`, `plugin.Open` | | 5 | **PHP** | `.php` | `eval()`, `assert()` na ciągu znaków, `create_function()`, wykonywanie w powłoce (`system`/`exec`/`shell_exec`/`passthru`/`popen`/`proc_open`), `call_user_func`/`call_user_func_array`, `include`/`require` ze ścieżką ustalaną w czasie działania | | 6 | **Rust** | `.rs` | `Command::new`, `process::Command` | | 7 | **Java** | `.java` | `Runtime.exec`, `ProcessBuilder`, `ScriptEngine`, `ObjectInputStream.readObject` | | 8 | **Kotlin** | `.kt`, `.kts` | Sinki JVM: `Runtime.exec`, `ProcessBuilder`, `ScriptEngine`, `ObjectInputStream.readObject` | | 9 | **C#** | `.cs` | `Process.Start` / `new Process`, `BinaryFormatter`, `Assembly.Load` | | 10 | **C** | `.c`, `.h` | `system()`, `popen()`, rodzina `exec*` (`execl`, `execve`, `execvp`, …) | | 11 | **C++** | `.cc`, `.cpp`, `.cxx`, `.hpp`, `.hh`, `.hxx` | `system()`, `popen()`, rodzina `exec*` (`execl`, `execve`, `execvp`, …) | **Staranny, ale niewyczerpujący** Hook czyta kod źródłowy jako tekst, więc może przeoczyć sink składany w czasie działania, ukryty za aliasem lub zapisany w formie, której nie rozpoznaje. Traktuj tabelę jako solidny punkt wyjścia, a nie pełny spis. **Wskazówka** Hook gwarantuje minimum (że te sinki istnieją i gdzie są): to, czy niezaufana wartość faktycznie do któregoś z nich dociera, wymaga oceny, którą zapewnia [specjalizacja `interpreter`](https://lagune.ai/pl-PL/docs/catalog). ## Najczęściej zadawane pytania ### Czy hook interpreter potwierdza podatność? Nie. Zgłasza sinki dynamicznego wykonywania jako ostrzeżenie do przejrzenia, nigdy jako potwierdzone ustalenie, bo statyczne skanowanie nie rozstrzygnie, czy dane wejściowe zależne od atakującego docierają do sinka. ### Jakie języki obsługuje hook interpreter? Czyta języki z tabeli "Obsługiwane języki", rozpoznając je po rozszerzeniu pliku, i każdy sprawdza pod kątem jego własnego zestawu sinków. W innych językach nie zgłasza żadnych sinków. --- # Hook jwt: Wykrywanie weryfikacji JWT bez przypiętego algorytmu > Przeszukuj bazę kodu pod kątem weryfikacji JWT bez przypiętego algorytmu albo oceniaj pojedyncze wywołanie z wiersza poleceń. Adres kanoniczny: https://lagune.ai/pl-PL/docs/hooks/jwt Język: pl-PL Oryginał: https://lagune.ai/docs/hooks/jwt Ostatnia aktualizacja: 2026-11-09 Hook `jwt` zgłasza **weryfikację JWT bez przypiętego algorytmu**, czyli lukę typu algorithm confusion, w której weryfikator ufa nagłówkowi `alg` samego tokena, oraz **całkowicie wyłączoną weryfikację**. **Rozpoznaje język** i czyta każdy plik zgodnie z regułami jego biblioteki JWT. To deterministyczny silnik stojący za [specjalizacją `federation`](https://lagune.ai/pl-PL/docs/catalog), który możesz uruchomić samodzielnie w trybie **scan** lub **check**. ## Uruchamianie **Przeszukaj bazę kodu** ```bash npx lagune read jwt # scans the whole project npx lagune read jwt --dir src # scans a directory npx lagune read jwt --file auth.ts # scans a single file ``` **Sprawdź wywołanie** ```bash npx lagune read jwt --lang javascript --pattern 'jwt.verify(token, secret)' # => unpinned npx lagune read jwt --lang python --pattern 'jwt.decode(t, k, options={"verify_signature": False})' # => unpinned npx lagune read jwt --lang python --pattern 'jwt.decode(t, k, algorithms=["HS256"])' # => safe ``` Każda linia w sekcji **Unpinned JWT verification found** to wywołanie weryfikujące, które nie ustawia listy dozwolonych `algorithms` (tam, gdzie biblioteka jej wymaga), akceptuje niebezpieczną listę (`none` albo algorytm asymetryczny zmieszany z HMAC) lub całkowicie wyłącza sprawdzanie podpisu, przez co ufa polu `alg` samego tokena. To potwierdzona ekspozycja, więc hook kończy działanie z niezerowym kodem wyjścia. Gdy nic nie znajdzie, wypisuje `no unpinned JWT verification found`. ## Jak odczytać werdykt | Werdykt | Znaczenie | | ---------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | `unpinned` | Wywołanie weryfikujące bez listy dozwolonych algorytmów (tam, gdzie jest potrzebna), z niebezpieczną listą albo z wyłączoną weryfikacją. | | `safe` | Wywołanie weryfikujące, które przypina bezpieczną listę dozwolonych algorytmów lub którego biblioteka przypina ją niejawnie. | | `invalid` | Fragment kodu nie zawiera rozpoznawalnego wywołania weryfikującego, które można by ocenić. | ### Opcje CLI | Opcja | Wartość | Opis | | ----------- | ------------- | ------------------------------------------------------------------------------------------------------------ | | `--pattern` | fragment kodu | Sprawdza jedno wywołanie. Powtórz, aby sprawdzić kilka, po jednym werdykcie w linii. | | `--lang` | język | Wymagana razem z `--pattern`: jeden z języków javascript, python, go, java, kotlin, php, ruby, rust, csharp. | | `--dir` | folder | Ogranicza skanowanie do folderu. Można powtarzać i łączyć z `--file`. | | `--file` | plik | Ogranicza skanowanie do jednego pliku. Można powtarzać i łączyć z `--dir`. | Bez żadnej opcji hook przeszukuje cały projekt. Opcja `--pattern` wymaga `--lang` i nie można jej łączyć z `--dir` ani `--file`. ### Wybierz, co hook przeszukuje Hook pomija to, co ignoruje **Git**. Aby pominąć więcej albo przeszukać to, co ignoruje **Git**, nadaj hookowi `jwt` własne ustawienia: ```bash npx lagune write add --ignore test/fixtures --checker jwt ``` ```json { "checkers": { "jwt": { "gitignore": false, "ignore": ["test/fixtures"] } } } ``` [Konfiguracja hooków](https://lagune.ai/pl-PL/docs/hooks/configure) opisuje każde ustawienie. ### Obsługiwane języki Skanowanie czyta poniższe biblioteki, rozpoznając je po rozszerzeniu pliku. Ponieważ niektóre przypinają algorytm niejawnie (brak jawnej listy jest wtedy poprawny), reguła "brak listy dozwolonych ⇒ unpinned" obowiązuje tylko tam, gdzie biblioteka oczekuje jawnej listy, więc hook nigdy nie zgłasza poprawnie skonfigurowanego wywołania. | Język | Biblioteka | Czy brak listy dozwolonych to unpinned? | Zawsze zgłasza | | --------------------------- | ----------------------- | ----------------------------------------------------------------------- | ------------------------------------------------- | | **JavaScript / TypeScript** | jsonwebtoken, jose | Tak | `none`, mieszankę algorytmu asymetrycznego i HMAC | | **Python** | PyJWT, python-jose | Tak (PyJWT jej wymaga, python-jose domyślnie ustawia `algorithms=None`) | `none`, `verify_signature: False` | | **Go** | golang-jwt | Tak (brak `WithValidMethods`) | `none`, `ParseUnverified` | | **Ruby** | ruby-jwt | Tak | `none`, `verify = false` | | **Java / Kotlin** | jjwt, nimbus | Nie (algorytm wynika z klucza) | `none`, parser bez podpisu lub `unsecured` | | **PHP** | firebase/php-jwt | Nie (`Key` określa algorytm) | `none` | | **Rust** | jsonwebtoken | Nie (`Validation` wymaga algorytmu) | `none`, `insecure_disable_signature_validation` | | **C#** | Microsoft.IdentityModel | Nie (parametry w wielu liniach) | `none`, `RequireSignedTokens = false` | **Wskazówka** Hook rozstrzyga tylko o przypięciu algorytmu: sprawdzanie claimów, kluczy i przepływów wymaga oceny, którą nadal zapewnia [specjalizacja `federation`](https://lagune.ai/pl-PL/docs/catalog). ## Najczęściej zadawane pytania ### Czym jest algorithm confusion w JWT? Weryfikator, który odczytuje algorytm z nagłówka tokena, pozwala atakującemu zamienić RS256 na HS256 i podpisać token kluczem publicznym. Zapobiega temu przypięta w kodzie bezpieczna lista dozwolonych algorytmów, a hook jwt zgłasza wywołanie weryfikujące, które nie ustawia żadnej listy albo ustawia niebezpieczną. --- # Hook network: Ocena adresów URL pod kątem SSRF > Oceniaj jeden lub wiele adresów docelowych żądań pod kątem SSRF, prosto z wiersza poleceń. Adres kanoniczny: https://lagune.ai/pl-PL/docs/hooks/network Język: pl-PL Oryginał: https://lagune.ai/docs/hooks/network Ostatnia aktualizacja: 2026-11-09 Hook `network` rozstrzyga, czy adres docelowy żądania wysyłanego przez serwer jest bezpieczny pod kątem **SSRF** (żądania, które można skierować do usług wewnętrznych, metadanych chmury lub prywatnych hostów). To deterministyczny silnik stojący za [specjalizacją `network`](https://lagune.ai/pl-PL/docs/catalog), który możesz uruchomić samodzielnie. ## Uruchamianie Przekaż każdy adres docelowy w opcji `--url`. Hook wypisuje po jednym słowie na adres, a ich znaczenie wyjaśnia tabela poniżej. **Jeden adres** ```bash npx lagune read network --url 'http://example.com/' # => safe npx lagune read network --url 'http://0x7f000001/' # => private-target ``` **Kilka adresów** Powtórz `--url`, aby w jednym wywołaniu ocenić całą listę dozwolonych lub zabronionych, po jednym werdykcie w linii, w tej samej kolejności. ```bash npx lagune read network \ --url 'http://example.com/' \ --url 'http://[::1]/' \ --url 'http://allowed.com@evil.example/' # => safe # => private-target # => parser-divergent ``` Hook odczytuje host tak, jak odczytuje go sieć, więc zakodowane zapisy adresu wewnętrznego się nie prześlizgną: zapis szesnastkowy, ósemkowy, dziesiętny bez kropek, skrócony, IPv6 i IPv4 mapowany na IPv6 dają wynik `private-target`. A tam, gdzie niedbały walidator i klient, który faktycznie pobiera dane, odczytałyby różne hosty, werdykt brzmi `parser-divergent`. ## Jak odczytać werdykt | Werdykt | Znaczenie | | ------------------ | ------------------------------------------------------------------------------------------------ | | `safe` | Adres docelowy prowadzi do publicznego hosta, a niedbały walidator odczytałby ten sam host. | | `private-target` | Host wskazuje na adres prywatny, loopback, link-local, nieokreślony lub adres metadanych chmury. | | `parser-divergent` | Niedbały walidator tekstowy odczytałby inny rzeczywisty host niż ten, z którym łączy się klient. | | `invalid url` | Ciągu znaków nie da się sparsować jako URL, więc nie ma czego pobrać. | Tylko `safe` oznacza zezwolenie. Wszystkie pozostałe werdykty, czyli `private-target`, `parser-divergent` i `invalid url`, traktuj jako blokadę. ### Opcje CLI | Opcja | Wartość | Opis | | ------- | ------------------ | ----------------------------------------------------------------------------------------- | | `--url` | adres URL lub host | Sprawdza jeden adres docelowy. Powtórz, aby sprawdzić kilka, po jednym werdykcie w linii. | Wymagana jest co najmniej jedna opcja `--url`. Adres docelowy nigdy nie jest samodzielnym argumentem pozycyjnym, więc nie da się go pomylić z flagą. **Dlaczego wartość flagi** Każdy adres docelowy trafia do hooka jako wartość flagi i nigdy nie jest wstawiany do polecenia. Wartość z cudzysłowami lub backtickami pozostaje nieszkodliwa i nie może niczego wstrzyknąć do powłoki. Zawsze ujmuj ją w apostrofy, aby powłoka nie rozwinęła jej wcześniej. **Czego nie obejmuje** Hook jest czystą funkcją i nigdy nie odpytuje DNS, więc dwie luki, które pojawiają się dopiero w czasie działania, są poza zakresem: **DNS rebinding** (nazwa, która przy sprawdzaniu wskazuje na adres publiczny, a przy pobieraniu na wewnętrzny) i **łańcuchy przekierowań** (pierwszy skok, który przechodzi sprawdzenie, a potem przekierowuje do wewnątrz). Zamknij je, rozwiązując nazwę raz i łącząc się ze zweryfikowanym adresem oraz odrzucając przekierowania. Zarezerwowane nazwy loopback (`localhost` i rodzinę `.localhost`) hook bez odpytywania DNS uznaje za wewnętrzne, ale każda inna nazwa DNS daje `safe`, bo stwierdzenie, że wskazuje do wewnątrz, wymagałoby rozwiązania nazwy: takie nazwy chroni lista dozwolonych i to właśnie ją sprawdza ten hook. **Wskazówka** To ta sama kontrola, którą uruchamia [specjalizacja `network`](https://lagune.ai/pl-PL/docs/catalog), aby wykazać, że filtr adresów docelowych działa. ## Najczęściej zadawane pytania ### Jak sprawdzić adres URL pod kątem SSRF? Uruchom hook network. Ocenia on adres docelowy żądania i zwraca safe, private-target, parser-divergent lub invalid url. Tylko safe oznacza zezwolenie. ### Co to jest URL typu parser-divergent? Adres URL, który różne parsery odczytują inaczej, co jest klasycznym sposobem obejścia ochrony przed SSRF. Hook network zgłasza go, zamiast go przepuścić. --- # Hook regex: Wykrywanie wzorców podatnych na ReDoS > Przeszukuj bazę kodu pod kątem wyrażeń regularnych podatnych na ReDoS albo oceniaj pojedynczy wzorzec z wiersza poleceń. Adres kanoniczny: https://lagune.ai/pl-PL/docs/hooks/regex Język: pl-PL Oryginał: https://lagune.ai/docs/hooks/regex Ostatnia aktualizacja: 2026-11-09 Hook `regex` to deterministyczny silnik bezpieczeństwa wyrażeń regularnych, z którego korzysta [specjalizacja `regex`](https://lagune.ai/pl-PL/docs/catalog), i możesz uruchomić go samodzielnie. Jedno polecenie działa w dwóch trybach: **scan** przeszukuje bazę kodu pod kątem wzorców podatnych na **ReDoS** i budowanych w czasie działania, a **check** ocenia pojedynczy wzorzec, który mu przekażesz. ## Przeszukaj bazę kodu Bez żadnej flagi hook przeszukuje cały projekt. Opcja `--dir` ogranicza skanowanie do folderu, a `--file` do jednego pliku. Obie można powtarzać i łączyć w jeden raport, w którym każdy plik pojawia się tylko raz, nawet jeśli obejmuje go więcej niż jeden cel. **Cały projekt** ```bash npx lagune read regex ``` **Folder** ```bash npx lagune read regex --dir src/services ``` **Jeden plik** ```bash npx lagune read regex --file bin/import.pl ``` **Kilka celów** ```bash npx lagune read regex --dir core --dir workers --file Sources/App/Router.swift ``` **Z limitem** `--limit` ustawia próg ReDoS dla skanowania (domyślnie 25), czyli ten sam limit, który przyjmuje tryb check. Im niższy limit, tym surowsza ocena. ```bash npx lagune read regex --dir src/services --limit 15 ``` Wynik to zwykły tekst, którego nagłówki mówią, jak czytać każdą sekcję. Sekcja pojawia się tylko wtedy, gdy zawiera ustalenia. ```text Vulnerable regular expressions found: cmd/server/main.go ([a-z]+)+$ (exponential, search) Dynamically built regular expressions (review manually by simulating a constructed regex): app/payments.php crates/parser/lexer.rs lib/validate.py Static regex wrapped in a constructor (use a literal instead): config/token.rb ``` Gdy nic nie znajdzie, hook wypisuje jedną linię. ```bash npx lagune read regex --dir src/clean # => no unsafe patterns found ``` ### Jak odczytać sekcje | Sekcja | Znaczenie | | ------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Vulnerable regular expressions found` | Wzorce podatne na ReDoS, pogrupowane według plików, każdy wzorzec z wcięciem pod nazwą pliku, a za nim w nawiasie powód, dla którego jest niebezpieczny, oraz, jeśli je ma, jego zakres i flagi. Każda linia jest niebezpieczna, więc werdykt się nie powtarza. | | `Regular expressions the analysis could not settle (review manually)` | Wzorce, których analiza nie zdołała rozstrzygnąć w ramach swojego limitu pracy, wypisane w ten sam sposób. | | `Dynamically built regular expressions (review manually by simulating a constructed regex)` | Pliki, które budują wyrażenie regularne ze zmiennej, konkatenacji lub interpolacji. | | `Static regex wrapped in a constructor (use a literal instead)` | Pliki, które przekazują zwykły literał tekstowy do konstruktora wyrażenia regularnego tam, gdzie literał wyrażenia regularnego jest prostszy i pozwala uniknąć kompilacji w czasie działania. | Pierwsza sekcja to ustalenie bezpieczeństwa. Druga i trzecia same w sobie nie są ustaleniami: wskazują kod, którego statyczne sprawdzenie nie rozstrzygnie, więc wymagają, aby przeczytał go człowiek. Czwarta to wskazówka dotycząca czytelności, a nie ustalenie bezpieczeństwa. ### Opcje CLI | Opcja | Wartość | Opis | | ----------- | ---------------------------- | ------------------------------------------------------------------------------------------------------------- | | `--pattern` | źródło wyrażenia regularnego | Sprawdza jeden wzorzec. Powtórz, aby sprawdzić kilka, po jednym werdykcie na wzorzec, w tej samej kolejności. | | `--flags` | flagi wyrażenia regularnego | Sprawdza każdy `--pattern` z tymi flagami, na przykład `im`. Dotyczy tylko trybu check. | | `--dir` | folder | Ogranicza skanowanie do folderu. Można powtarzać i łączyć z `--file`. | | `--file` | plik | Ogranicza skanowanie do jednego pliku. Można powtarzać i łączyć z `--dir`. | | `--limit` | nieujemna liczba całkowita | Ustawia limit powtórzeń ReDoS (domyślnie 25). Dotyczy obu trybów. Im niższy limit, tym surowsza ocena. | Bez żadnej opcji hook przeszukuje cały projekt. Opcja `--pattern` uruchamia tryb check i nie można jej łączyć z `--dir` ani `--file`. ### Wybierz, co hook przeszukuje Hook pomija to, co ignoruje **Git**. Aby pominąć więcej albo przeszukać to, co ignoruje **Git**, nadaj hookowi `regex` własne ustawienia: ```bash npx lagune write add --ignore test/fixtures --checker regex ``` ```json { "checkers": { "regex": { "gitignore": false, "ignore": ["test/fixtures"] } } } ``` [Konfiguracja hooków](https://lagune.ai/pl-PL/docs/hooks/configure) opisuje każde ustawienie. ### Obsługiwane języki Skanowanie czyta poniższe języki, rozpoznając je po rozszerzeniu pliku, każdy według jego własnych reguł, więc wzorca z jednego języka nigdy nie testuje według reguł innego. Wszystko inne pomija, zamiast skanować według niewłaściwych reguł. | # | Język | Rozszerzenia | | --- | --------------------------- | ------------------------------------------------------------------------------------------------------------ | | 1 | **JavaScript / TypeScript** | `.js`, `.jsx`, `.mjs`, `.cjs`, `.ts`, `.tsx`, `.mts`, `.cts`, `.astro`, `.vue`, `.svelte`, `.marko`, `.riot` | | 2 | **Python** | `.py`, `.pyi` | | 3 | **Ruby** | `.rb` | | 4 | **Go** | `.go` | | 5 | **PHP** | `.php` | | 6 | **Rust** | `.rs` | | 7 | **Java** | `.java` | | 8 | **C#** | `.cs` | | 9 | **C** | `.c`, `.h` | | 10 | **C++** | `.cc`, `.cpp`, `.cxx`, `.hpp`, `.hh`, `.hxx` | | 11 | **Kotlin** | `.kt`, `.kts` | | 12 | **Swift** | `.swift` | | 13 | **Scala** | `.scala`, `.sc` | | 14 | **Dart** | `.dart` | | 15 | **PowerShell** | `.ps1`, `.psm1`, `.psd1` | | 16 | **Elixir** | `.ex`, `.exs` | | 17 | **Objective-C** | `.m`, `.mm` | | 18 | **R** | `.r` | | 19 | **Julia** | `.jl` | | 20 | **Clojure** | `.clj`, `.cljs`, `.cljc`, `.edn` | | 21 | **Crystal** | `.cr` | | 22 | **Nim** | `.nim`, `.nims` | | 23 | **V** | `.v` | | 24 | **D** | `.d` | | 25 | **Perl** | `.pl`, `.pm` | **Staranny, ale niewyczerpujący** Hook czyta kod źródłowy jako tekst, więc nie oceni wzorca składanego w czasie działania, a wzorzec rozbity na kilka linii, ukryty za aliasem lub zapisany w formie, której nie rozpoznaje, może się prześlizgnąć. Traktuj sekcje jako solidny punkt wyjścia, a nie pełny spis, i nadal czytaj kod, aby wychwycić to, czego one nie obejmują. ## Sprawdź pojedynczy wzorzec Przekaż źródło wzorca w opcji `--pattern`, aby go ocenić. Hook wypisuje jedno słowo: `safe`, `unsafe`, `undetermined`, gdy analiza osiągnie limit pracy, zanim rozstrzygnie wzorzec, albo `invalid regex`. Powtórz `--pattern`, aby ocenić kilka wzorców naraz, po jednym werdykcie na wzorzec, w tej samej kolejności. **Jeden wzorzec** ```bash npx lagune read regex --pattern '(a+)+$' # => unsafe npx lagune read regex --pattern '^[a-z0-9_]{3,20}$' # => safe ``` **Kilka wzorców** ```bash npx lagune read regex --pattern '(a+)+$' --pattern '^[a-z]+$' # => unsafe # => safe ``` **Z flagami** `--flags` sprawdza każdy `--pattern` w wywołaniu z flagami, z którymi wzorzec jest uruchamiany, bo flaga zmienia, które znaki wzorzec dopasowuje. ```bash npx lagune read regex --pattern '^(?:a|A)+$' # => safe npx lagune read regex --pattern '^(?:a|A)+$' --flags 'i' # => unsafe ``` **Z limitem** `--limit` ustawia limit powtórzeń (domyślnie 25) i dotyczy każdego `--pattern` w wywołaniu. Im niższy limit, tym surowsza ocena. ```bash npx lagune read regex --pattern 'a?a?a?' --limit 2 # => unsafe ``` **Dlaczego argument w cudzysłowie** Każdy wzorzec trafia do hooka jako wartość flagi i nigdy nie jest wstawiany do polecenia. Wartość z cudzysłowami lub backtickami pozostaje nieszkodliwa i nie może niczego wstrzyknąć do powłoki. Zawsze ujmuj wzorzec w apostrofy, aby powłoka nie rozwinęła go wcześniej. **Wskazówka** To ten sam silnik, którego używa [specjalizacja `regex`](https://lagune.ai/pl-PL/docs/catalog): skanowanie otwiera przegląd pod kątem ReDoS, a sprawdzenie potwierdza wzorzec, który ten przegląd wychwyci. ## Najczęściej zadawane pytania ### Jak sprawdzić regex pod kątem ReDoS z poziomu CLI? Uruchom npx lagune read regex --pattern ''. Polecenie zwraca safe, unsafe, undetermined lub invalid regex. ### Jak przeskanować cały projekt w poszukiwaniu niebezpiecznych regexów? Uruchom hook regex w trybie scan na całej bazie kodu. Zgłasza wzorce podatne na ReDoS w 25 obsługiwanych językach. --- # Hook secrets: Wykrywanie sekretów zapisanych na sztywno w kodzie > Przeszukuj bazę kodu z wiersza poleceń pod kątem danych uwierzytelniających zapisanych na sztywno w kodzie. Adres kanoniczny: https://lagune.ai/pl-PL/docs/hooks/secrets Język: pl-PL Oryginał: https://lagune.ai/docs/hooks/secrets Ostatnia aktualizacja: 2026-11-09 Hook `secrets` zgłasza **dane uwierzytelniające wkompilowane w kod źródłowy**, a nie odczytywane ze środowiska. Opiera się na **pochodzeniu** wartości (literał czy odczyt ze środowiska), a nie na jej zawartości, więc nie potrzebuje wyczerpującej listy prefiksów dostawców i prawie nie zgłasza fałszywych alarmów. To deterministyczny silnik stojący za [specjalizacją `secrets`](https://lagune.ai/pl-PL/docs/catalog). Sygnatury w formatach dostawców, dane uwierzytelniające w ciągach połączenia i literał przypisany do identyfikatora o nazwie wskazującej na sekret są **niezależne od języka**: ten sam ciąg znaków znaczy to samo w każdym pliku. Dwie heurystyki zależne od składni, czyli odczyt ze środowiska z wartością domyślną zapisaną na sztywno w kodzie i sekret trafiający do sinka logów, **rozpoznają język**, więc hook nigdy nie szuka `console.log` z JavaScriptu w pliku Rusta, a `os.getenv("X", "default")` z Pythona rozpoznaje według reguł tego języka. ## Uruchamianie ```bash npx lagune read secrets # scans the whole project npx lagune read secrets --dir src # scans a directory npx lagune read secrets --file config.ts # scans a single file ``` Skanowanie wypisuje maksymalnie dwie sekcje. **Hardcoded secrets found** to zbiór ustaleń (wartość domyślna zapisana na sztywno dla zmiennej środowiskowej o nazwie wskazującej na sekret, dane uwierzytelniające osadzone w ciągu połączenia lub wartość pasująca do starannie dobranego formatu dostawcy), więc hook kończy działanie z niezerowym kodem wyjścia. **Secret handling to review manually** to zbiór tropów: zwykły literał przypisany do identyfikatora o nazwie wskazującej na sekret (jego pochodzenie da się rozstrzygnąć, ale to, czy wartość jest prawdziwym sekretem, już nie) oraz wartość o nazwie wskazującej na sekret, która trafia do sinka logów lub odpowiedzi. Gdy nic nie znajdzie, hook wypisuje `no hardcoded secrets found`. ### Opcje CLI | Opcja | Wartość | Opis | | -------- | ------- | -------------------------------------------------------------------------- | | `--dir` | folder | Ogranicza skanowanie do folderu. Można powtarzać i łączyć z `--file`. | | `--file` | plik | Ogranicza skanowanie do jednego pliku. Można powtarzać i łączyć z `--dir`. | Bez żadnej opcji hook przeszukuje cały projekt. ### Wybierz, co hook przeszukuje Hook pomija to, co ignoruje **Git**. Aby pominąć więcej albo przeszukać to, co ignoruje **Git**, nadaj hookowi `secrets` własne ustawienia: ```bash npx lagune write add --ignore test/fixtures --checker secrets ``` ```json { "checkers": { "secrets": { "gitignore": false, "ignore": ["test/fixtures"] } } } ``` [Konfiguracja hooków](https://lagune.ai/pl-PL/docs/hooks/configure) opisuje każde ustawienie. ### Obsługiwane języki Ustalenie dotyczące wartości domyślnej zmiennej środowiskowej i trop dotyczący sinka logów odczytują konstrukcje właściwe dla każdego języka, więc obejmują poniższe języki, a w pozostałych milczą. Pozostałe trzy sygnały działają na **każdym** pliku. | Sygnał | Języki | | --------------------------------------- | ------------------------------------------------------------------------------- | | Wartość domyślna zmiennej środowiskowej | JavaScript/TypeScript, Python, Ruby, PHP, Kotlin, Java, Go (`cmp.Or`), Rust, C# | | Sink logów lub odpowiedzi | JavaScript/TypeScript, Python, Ruby, PHP, Java, Kotlin, Go, Rust, C, C++, C# | **Czy to nie narusza zasad?** Nie. Wykrywanie formatu sekretu, aby ostrzec, że trafił do commita, to standardowa praktyka narzędzi defensywnych, ta sama operacja, którą wykonują gitleaks, trufflehog i funkcja push protection w GitHubie. Hook dostarcza sygnatury wykrywania (publiczne **formaty** tokenów), nigdy działający sekret, i audytuje oraz wyjaśnia, zamiast wykradać dane. ## Najczęściej zadawane pytania ### Jak hook secrets unika fałszywych alarmów? Opiera się na pochodzeniu wartości, a nie na jej zawartości. Formaty o wysokiej pewności (tokeny dostawców, wartości domyślne zmiennych środowiskowych, ciągi połączenia) to ustalenia, przy których hook kończy działanie z niezerowym kodem wyjścia. Zwykły literał przypisany do identyfikatora o nazwie wskazującej na sekret to trop do potwierdzenia, a ten sam identyfikator odczytany z process.env w ogóle nie jest zgłaszany. --- # Przykładowe prompty Lagune: Automatyzacja przepływu pracy Blue Team > Gotowe do skopiowania prompty Lagune: skanowanie tylko do odczytu, pełny przepływ pracy Blue Team i audyt Zero Trust, a także wykrywanie ograniczone do commita, diffu gałęzi lub PR albo rzeczywistego incydentu. Adres kanoniczny: https://lagune.ai/pl-PL/docs/examples/prompts Język: pl-PL Oryginał: https://lagune.ai/docs/examples/prompts Ostatnia aktualizacja: 2026-11-09 Gotowe do skopiowania prompty Lagune, które możesz wkleić prosto do swojego agenta AI. ## 💧 Płytkie skanowanie Skanowanie tylko do odczytu, w którym agent samodzielnie czyta kod i zgłasza każdą lukę razem z poprawką, bez uruchamiania przepływu pracy Blue Team i bez zapisywania czegokolwiek w śledzeniu Lagune. **Wskazówka** Działa lepiej w trybie planowania i ze zdefiniowanymi zasadami bezpieczeństwa (`/lagune-charter`). **🪼 Domyślnie** | Aspekt | Kompromis | Poziom | | ------------------- | --------------------------------------------------------------------- | ------------------- | | **Nakład pracy** | Jeden agent skanuje i raportuje, bez subagentów. | 1/5 | | **Czas** | Krótki. Jedno przejście tylko do odczytu, niczego nie wdraża. | 2/5 | | **Zużycie tokenów** | Umiarkowane, wspólne. Całe skanowanie odbywa się w jednym kontekście. | 2/5 | ```md /lagune Jesteś badaczem cyberbezpieczeństwa z głęboką wiedzą z zakresu bezpieczeństwa defensywnego i korzystasz z Lagune, aby poszerzyć swoją wiedzę i zwiększyć precyzję. Samodzielnie przeskanuj obszar roboczy i do każdej znalezionej luki dobierz konkretną poprawkę. To osobne skanowanie, a nie przepływ pracy Blue Team: nie uruchamiaj faz detect, plan, harden ani verify i niczego nie zapisuj w śledzeniu Lagune. Na koniec wypisz wszystkie znalezione luki, każdą z jej poziomem zagrożenia i konkretną poprawką. ``` **🐬 Wiele agentów** | Aspekt | Kompromis | Poziom | | ------------------- | ------------------------------------------------------------------------------------ | ------------------- | | **Nakład pracy** | Jeden subagent na plik, w liczbie dopasowanej do rozmiaru bazy kodu. | 2/5 | | **Czas** | Równolegle dla każdego pliku, potem scalanie w jeden raport. Nadal tylko do odczytu. | 3/5 | | **Zużycie tokenów** | Wyższe, ale izolowane. Każdy subagent skanuje we własnym kontekście. | 3/5 | ````md /lagune Jesteś orkiestratorem cyberbezpieczeństwa i korzystasz z Lagune, aby wyliczyć ścieżki, uruchomić po jednym subagencie na ścieżkę i scalić ich raporty (całą treść czytają subagenci). Musisz przekazać zadanie subagentom w zależności od rozmiaru bieżącego projektu: im większa baza kodu, tym więcej subagentów należy uruchomić, wszystkich równolegle, i każdemu przekazać poniższy prompt: ```prompt /lagune Jesteś badaczem cyberbezpieczeństwa z głęboką wiedzą z zakresu bezpieczeństwa defensywnego i korzystasz z Lagune, aby poszerzyć swoją wiedzę i zwiększyć precyzję. Samodzielnie przeskanuj i do każdej znalezionej luki dobierz konkretną poprawkę. To osobne skanowanie, a nie przepływ pracy Blue Team: nie uruchamiaj faz detect, plan, harden ani verify i niczego nie zapisuj w śledzeniu Lagune. Na koniec wypisz wszystkie luki w , każdą z jej poziomem zagrożenia i konkretną poprawką. ``` Na koniec scal raporty wszystkich subagentów w jedną listę luk i poprawek uporządkowaną według priorytetu. ```` **Ostrzeżenie** Szybkie skanowanie to jeden szeroki prompt bez zawężonego zakresu, więc niektórzy agenci częściej go odrzucają lub przerywają przed czasem. Jeśli twój agent się opiera, uruchom zamiast tego pełny **przepływ pracy Blue Team** opisany niżej: jego fazy, o wąskim zakresie i wykonywane krok po kroku, znacznie rzadziej są blokowane. --- ## 🌊 Automatyczny audyt w przepływie pracy Blue Team Uruchamia [pełny przepływ poleceń](https://lagune.ai/pl-PL/docs/get-started/commands) od początku do końca. **🪼 Domyślnie** | Aspekt | Kompromis | Poziom | | ------------------- | ---------------------------------------------------------------------------------------------------- | ------------------- | | **Nakład pracy** | Jeden agent, bez subagentów, niezależnie od rozmiaru bazy kodu. | 3/5 | | **Czas** | Średni, ale w dużych bazach kodu mniej dokładny. Każde polecenie uruchamia się raz, jedno po drugim. | 4/5 | | **Zużycie tokenów** | Niższe, ale z mniejszą izolacją. Wszystkie polecenia dzielą ten sam kontekst. | 4/5 | ```md Uruchom po kolei następujące polecenia: `/lagune-charter`, `/lagune-detect`, `/lagune-plan`, `/lagune-harden` i `/lagune-verify`. ## Pętla Gdy polecenie `/lagune-verify` odrzuci jedną lub więcej poprawek, powtarzaj `/lagune-harden`, a potem `/lagune-verify`, aż wszystkie ustalenia zostaną prawidłowo rozwiązane. ``` **🐋 Wiele agentów (głębokie skanowanie)** | Aspekt | Kompromis | Poziom | | ------------------- | -------------------------------------------------------------------------------------------------------------------- | ------------------- | | **Nakład pracy** | Liczba subagentów zależy od rozmiaru bazy kodu. | 5/5 | | **Czas** | Dłuższy, ale dokładniejszy. Uruchamia wielu subagentów, którzy równolegle wykrywają, planują i utwardzają ustalenia. | 5/5 | | **Zużycie tokenów** | Wyższe, ale bezpieczniejsze. Każdy subagent ma własny, izolowany kontekst, wolny od stronniczości. | 5/5 | ````md Przekaż każde z poniższych poleceń osobnemu subagentowi, po jednym naraz (bez backticków, samo polecenie): Prompt subagenta 1: `/lagune-charter` Prompt subagenta 2: `/lagune-detect` Prompt subagenta 3: `/lagune-plan` Prompt subagenta 4: `/lagune-harden` Prompt subagenta 5: `/lagune-verify` W poleceniach `/lagune-detect`, `/lagune-plan`, `/lagune-harden` i `/lagune-verify` musisz przekazywać zadanie subagentom w zależności od rozmiaru bieżącego projektu: im większa baza kodu, tym więcej subagentów należy uruchomić. Na przykład: ```prompt /lagune-detect ``` ```prompt /lagune-plan ``` ```prompt /lagune-harden ``` ```prompt /lagune-verify ``` - Wielu agentów dla tego samego polecenia uruchamiaj równolegle. - Gdy wszyscy subagenci polecenia `/lagune-detect` skończą pracę, wykonaj: ```prompt /lagune-detect scal równoważne ustalenia. Nie szukaj nowych ustaleń i nie skanuj ponownie bazy kodu. ``` ## Pętla Gdy polecenie `/lagune-verify` odrzuci jedną lub więcej poprawek, powtarzaj `/lagune-harden`, a potem `/lagune-verify`, aż wszystkie ustalenia zostaną prawidłowo rozwiązane. ```` --- ## 🪄 Wykrywanie w wybranym zakresie Skieruj polecenie [`/lagune-detect`](https://lagune.ai/pl-PL/docs/commands/detect) na wybrany fragment projektu zamiast na całość. Opisz zakres zwykłymi słowami (commit, pull request albo rzeczywistą sytuację), a polecenie zmapuje tylko ustalenia istotne dla bezpieczeństwa w tym zakresie. **Wskazówka** Wszystko, co tu wykryje, to zwykłe ustalenia, więc możesz przekazać je prosto do poleceń `/lagune-plan`, `/lagune-harden` i `/lagune-verify`, ograniczając zakres tylko do tych elementów. **📌 Od commita** Poddaj świeżą partię commitów osobnemu przeglądowi bezpieczeństwa, ograniczonemu do tego, co zmieniły, na przykład: ```prompt /lagune-detect Ogranicz wykrywanie do wszystkiego, co zmieniło się od commita `a1b2c3d`. ``` **🔀 Diff gałęzi lub PR** Sprawdź bezpieczeństwo pull requesta przed scaleniem, ograniczając się do jego diffu, na przykład: ```prompt /lagune-detect Ogranicz wykrywanie do zmian, które ta gałąź wprowadza względem `main`. ``` **⛑️ Po incydencie** Opisz własnymi słowami, co się stało. Lagune odczytuje sytuację, a nie flagę, i zamienia ją w ukierunkowane poszukiwania, na przykład: ```prompt /lagune-detect Kilka tygodni temu na naszej stronie doszło do wycieku danych. Nie wiem dokładnie, jak to się stało, i obawiam się, że wciąż jest otwarta jakaś furtka, przez którą dane mogą znowu wyciec. Dokładnie przejrzyj kod, skup się na wszystkich miejscach, w których wrażliwe dane są odczytywane, przechowywane lub ujawniane, i zmapuj wszystko, co wciąż może być drogą wycieku. Potraktuj to jak prawdziwy incydent, a nie ćwiczenia. ``` --- ## 🚨 Audyt Zero Trust Traktuje cały obszar roboczy i każdą zależność jako wrogie: szuka interpreterów, wywołań sieciowych, zakodowanych payloadów i kodu ukrytego w nieoczywistych miejscach tak, by umknął skanerom, a na koniec wydaje werdykt go/no-go, czy projekt jest bezpieczny w użyciu. Prompty ładują bezpośrednio specjalizacje, na których opiera się ten audyt, niezależnie od kategorii projektu. Aby polecenie `/lagune` dopasowało też resztę katalogu, upewnij się, że projekt korzysta z kategorii **OWASP**, **AI/LLM** oraz z kategorii swojego stosu technologicznego (np. **JavaScript**, **Python** itp.): ```bash npx lagune write add --categories owasp ai javascript ``` Własne pliki `.gitignore` i konfiguracje repozytorium mogą ukryć pliki przed narzędziami sprawdzającymi, dlatego ustaw blok `checkers` w pliku `.lagune/configs.json` tak, aby [skanować wszystko](https://lagune.ai/pl-PL/docs/hooks/configure), zastępując każdy blok dostarczony z repozytorium: ```json { "checkers": { "gitignore": false } } ``` **Niebezpieczeństwo** Zachowaj ostrożność, gdy uruchamiasz w środowisku lokalnym projekty z niezaufanych źródeł. Korzystaj z izolowanego środowiska, takiego jak **sandbox** (zalecane), **maszyna wirtualna** lub podobne, aby złośliwy kod nie zaszkodził twojemu systemowi. **🪼 Domyślnie** | Aspekt | Kompromis | Poziom | | ------------------- | ---------------------------------------------------------------------------------------- | ------------------- | | **Nakład pracy** | Jeden agent przeszukuje cały obszar roboczy, bez subagentów. | 2/5 | | **Czas** | Średni. Jeden agent przechodzi po kolei przez kod i jego zależności. | 3/5 | | **Zużycie tokenów** | Umiarkowane, ale wspólne. Specjalizacje, kod i zależności trafiają do jednego kontekstu. | 3/5 | ```md /lagune Jesteś badaczem cyberbezpieczeństwa z głęboką wiedzą z zakresu bezpieczeństwa defensywnego w modelu zero trust i korzystasz z Lagune, aby poszerzyć swoją wiedzę i zwiększyć precyzję. Zmapuj cały obszar roboczy jako niezaufane źródło i potencjalnie złośliwy zakres. Każdy interpreter, fetch, base64 i tym podobne uznaj za potencjalne zagrożenie. Rozszerz analizę na zależności i zależności podrzędne: projekt może próbować ukryć złośliwy kod w nieoczywistym miejscu, aby umknął skanerom. Obowiązkowe specjalizacje (ładuj je po jednej za pomocą `npx lagune read catalog `): - interpreter - secrets - llm - path Dla jasności: każdą zmapowaną podatność traktuj jako potencjalne zagrożenie, bez wyjątku. Na koniec wydaj werdykt, czy projekt jest na tyle bezpieczny i godny zaufania, że mogę z niego korzystać, czy nie. ``` **🐋 Wiele agentów (głębokie skanowanie)** | Aspekt | Kompromis | Poziom | | ------------------- | -------------------------------------------------------------------------------------------------------- | ------------------- | | **Nakład pracy** | Jeden subagent na plik, w liczbie dopasowanej do rozmiaru bazy kodu. | 5/5 | | **Czas** | Dłuższy, ale dokładniejszy. Pliki są przeszukiwane równolegle, a wyniki scalane w jeden werdykt. | 4/5 | | **Zużycie tokenów** | Najwyższe, ale najbezpieczniejsze. Każdy subagent czyta specjalizacje we własnym, izolowanym kontekście. | 5/5 | ````md /lagune Jesteś orkiestratorem cyberbezpieczeństwa i korzystasz z Lagune, aby wyliczyć pliki, uruchomić po jednym subagencie na plik i wygenerować raporty (całą treść czytają subagenci). Uruchom po jednym subagencie na plik, wszystkich równolegle, i każdemu przekaż poniższy prompt, ograniczony do jego pliku: ```prompt /lagune Jesteś badaczem cyberbezpieczeństwa z głęboką wiedzą z zakresu bezpieczeństwa defensywnego w modelu zero trust i korzystasz z Lagune, aby poszerzyć swoją wiedzę i zwiększyć precyzję. Potraktuj jako niezaufane źródło i potencjalnie złośliwy zakres. Każdy interpreter, fetch, base64 i tym podobne uznaj za potencjalne zagrożenie. Rozszerz analizę na wszystko, co importuje , w tym na zależności i zależności podrzędne, w których może ukrywać się złośliwy kod, aby umknąć skanerom. Obowiązkowe specjalizacje dla każdego subagenta (ładuj je po jednej za pomocą `npx lagune read catalog `): - interpreter - secrets - llm - path Dla jasności: każdą zmapowaną podatność traktuj jako potencjalne zagrożenie, bez wyjątku. Na koniec wydaj werdykt, czy projekt jest na tyle bezpieczny i godny zaufania, że mogę z niego korzystać, czy nie. ``` Na koniec scal raporty wszystkich subagentów w jeden ostateczny werdykt. ```` --- # Security-Driven Hardening: Konwencja na erę programowania wspieranego przez AI > Metodologia Security-Driven Hardening (SDH): dopasowana do kontekstu konwencja w duchu Blue Team do audytowania i utwardzania oprogramowania tworzonego z pomocą AI lub metodą vibe codingu. Adres kanoniczny: https://lagune.ai/pl-PL/docs/references/paper Język: pl-PL Oryginał: https://lagune.ai/docs/references/paper Ostatnia aktualizacja: 2026-11-09 - **Weslley Araújo** - **Artykuł metodologiczny, 2026.** --- ## Streszczenie Security-Driven Hardening (SDH) to ustrukturyzowana, prowadzona przez AI i wyłącznie defensywna metodologia bezpieczeństwa na czasy, w których oprogramowanie coraz częściej piszą agenci AI oraz ludzie niebędący specjalistami od bezpieczeństwa. Zamiast przechodzić przez ogólną listę kontrolną, SDH najpierw wykrywa, co system naprawdę robi (logowanie, przesyłanie plików, płatności, ujawnianie danych i tak dalej), a potem prowadzi prace nad bezpieczeństwem właściwe dla tego kontekstu. Kierują nią domyślnie bezpieczne zasady, jest w całości nastawiona na obronę i wyrażona prostym językiem, tak aby każdy użytkownik mógł na jej podstawie działać. Ten dokument przekonuje, że SDH jest brakującą konwencją, a nie pojedynczym narzędziem. Wiedza o bezpieczeństwie mieszka w metodologii i jej specjalizacjach wczytywanych na żądanie, czyli w podstawie, na której każdy użytkownik może budować, dzięki czemu ten sam przepływ pracy służy zarówno początkującemu, jak i ekspertowi. Od wcześniejszych podejść typu spec-first `[1]` odróżniają ją dwie własności. SDH jest **niezależna od stanu**: dopasowuje się do pustego folderu, projektu w toku, pojedynczego pull requesta czy dużej bazy kodu legacy, w dowolnym stosie technologicznym. SDH jest też **możliwa do zamknięcia**: ryzyko, którego zamknięcie zweryfikowano, zostaje wycofane z całego przepływu pracy, więc ustalenie przechodzi w stan spoczynku i otwiera się ponownie dopiero wtedy, gdy zmieni się kod. SDH nie zastępuje specjalistów od bezpieczeństwa ani wyspecjalizowanych narzędzi Blue Team. Rozszerza wiedzę samego programisty, a im lepiej programista rozumie bezpieczeństwo, tym precyzyjniej może nią kierować. **Lagune** to implementacja referencyjna, która pokazuje, że metodologię da się zbudować i przenieść. SDH jest proponowana jako konwencja, którą mogą przyjąć inni. > **Słowa kluczowe** > > Programowanie wspierane przez AI, bezpieczeństwo oprogramowania, bezpieczeństwo defensywne, spec-driven development, utwardzanie zabezpieczeń, przepływy pracy prowadzone przez agentów, zamykalność, bezpieczeństwo dopasowane do kontekstu, wiedza na żądanie, narzędzia niezależne od agenta. --- ## I. Wprowadzenie: luka w bezpieczeństwie, którą otworzyło programowanie wspierane przez AI Oprogramowanie coraz częściej dostarczają ludzie, a także agenci AI, którzy nie potrafią niezawodnie rozpoznać niebezpiecznego wzorca: wycieku sekretu, braku sprawdzenia autoryzacji, zapytania podatnego na wstrzyknięcie. Nie są to egzotyczne ryzyka. Należą do klas ryzyka, które dominują w prawdziwych incydentach i od lat są opisywane w publicznych źródłach `[6]`, `[7]`, a najnowsze badania pokazują, że znacząca część kodu generowanego przez AI trafia do użytku właśnie z takimi wadami `[8]`. Asystenci AI do programowania zaostrzyli ten problem, bo pozwolili osobom, które nie są programistami, dostarczać prawdziwe oprogramowanie, ale luka jest szersza niż jakakolwiek pojedyncza grupa odbiorców. Większość projektów nigdy nie przechodzi przeglądu bezpieczeństwa dopasowanego do tego, co faktycznie robi. Ekosystem staje się bardziej kruchy z każdą przedwczesną decyzją w stylu "działa, wypuszczamy". Ogólne porady dotyczące bezpieczeństwa nie zamykają tej luki. Statyczna lista kontrolna nie jest dopasowana do tego, co robi system, więc zalewa mały projekt nieistotnymi punktami, a mimo to pomija ryzyko, które w tym jednym projekcie ma znaczenie. Problemem nie jest niedobór wiedzy o bezpieczeństwie na świecie. Problemem jest dopasowanie właściwej wiedzy do systemu, który użytkownik faktycznie ma przed sobą, i to dla kogoś, kto może nie wiedzieć, o co zapytać. SDH odpowiada na to jednym odwróceniem: **wiedza o bezpieczeństwie mieszka w specyfikacji i jej specjalizacjach wczytywanych na żądanie, czyli w podstawie, na której każdy użytkownik może budować**. Metodologia wykrywa kontekst, przeprowadza triaż ryzyk, które ten kontekst niesie, i prowadzi poprawki, więc programista i osoba, która nie programuje, korzystają z tego samego przepływu pracy. Ustalenia i rekomendacje pozostają w prostym języku, aby dało się na ich podstawie działać niezależnie od wiedzy technicznej czytelnika. Ekspert nie jest tym ograniczony, lecz wzmocniony, a tę dwoistość rozwijamy w `§VI`. > **Kluczowy wniosek** > > **Główne odwrócenie:** Wiedza o bezpieczeństwie mieszka w specyfikacji i jej specjalizacjach wczytywanych na żądanie, czyli w podstawie, na której każdy użytkownik może budować. Metodologia poznaje, co robi system, dopasowuje do tego prace nad bezpieczeństwem i rozszerza wszystko, co użytkownik już wie. Weźmy programistę, który mówi asystentowi AI: "moja aplikacja pozwala użytkownikom przesłać zdjęcie profilowe". Bez przeglądu bezpieczeństwa asystent tworzy działający kod, który po cichu ufa wszystkiemu, co przyśle klient: zadeklarowanemu typowi pliku, nazwie pliku, rozmiarowi. Funkcja przesyłania trafia na produkcję, a plik podszywający się pod obraz może zawierać kod, spreparowana nazwa może wyjść poza ścieżkę zapisu, a zbyt duży plik może wyczerpać zasoby serwera. Nic z tego nie widać na demonstracji, więc trafia to na produkcję. Ten sam kod przepuszczony przez SDH zachowuje się inaczej. Metodologia wykrywa, że system przyjmuje pliki z zewnątrz (wykrywanie), przekłada to na ryzyka, które niesie przesyłanie plików (triaż), proponuje sprawdzanie rzeczywistego typu i rozmiaru pliku, zmianę nazwy przy zapisie i przechowywanie tam, gdzie kod nie może się uruchomić (naprawa), a potem czyta wynik i potwierdza, że każde zabezpieczenie rzeczywiście działa (weryfikacja). Programista nigdy nie musiał znać wyrażenia "nieograniczone przesyłanie plików". Metodologia dostarczyła je za niego. Ten dokument wnosi następujący wkład: - Precyzyjną definicję SDH jako metodologii, niezależną od jakiejkolwiek implementacji, wraz z jej zasadami projektowymi (`§III`). - Pięciofazowy defensywny cykl życia, w którym wkładem jest sam podział obowiązków: wykrywanie nigdy niczego nie wymyśla, planowanie nigdy nie czyta kodu, tylko jedna faza zmienia kod, a weryfikacja nigdy nie łagodzi swojej oceny (`§IV`). - **Zamykalność** jako postawę metodologiczną: pojedyncze ustalenie ma stan końcowy, a nie nieskończoną pętlę (`§V`). - Dwoistość **rozszerzania wiedzy programisty**: jeden przepływ pracy, który chroni początkującego i wzmacnia eksperta (`§VI`). - **Niewywoływalne specjalizacje i prompt na żądanie**: skupioną wiedzę o bezpieczeństwie, którą agent wczytuje, gdy wymaga tego kontekst projektu, nigdy domyślnie (`§VII`). - **Niezależność od stanu** i **nienarzucającą adaptacyjność**: SDH pasuje do każdego etapu rozwoju projektu i dopasowuje się do scenariusza, zamiast narzucać stały zakres (`§VIII`). - **Tryb prewencyjny**: tę samą obronę uruchamianą podczas zwykłej pracy, aby kod od razu powstawał domyślnie bezpieczny, a fazy miały mniej do poprawiania (`§IX`). - Osobne porównanie ze Spec-Driven Development, nurtem, z którego SDH wyrosła, a potem się od niego oddzieliła (`§X`). - Dyscypliny inżynierskie, dzięki którym metodologia przetrwa refaktoryzacje i pozostaje niezależna od agenta: śledzenie z tożsamością opartą na nazwie (`§XI`) oraz nośnik niezależny od agenta (`§XII`). --- ## II. Tło i prace pokrewne SDH opiera się na wcześniejszych pracach. Dziedziczy sprawdzoną strukturę z programowania typu spec-first prowadzonego przez agentów `[1]`, `[2]`, `[3]`: szablony, polecenia z ukośnikiem, z których korzysta agent, dokument nadrzędny i agenta, który uruchamia fazy. Odtwarza tę strukturę w celu defensywnym. To pochodzenie jest zamierzone, a jedna z zasad pracy SDH nazywa je wprost: zbuduj przepływ pracy na sprawdzonej strukturze, a potem nastaw go na bezpieczeństwo. SDH nie jest statyczną listą kontrolną ogólnych rekomendacji. Lista kontrolna wie bardzo dużo o bezpieczeństwie w ogóle i nic o projekcie, który ma przed sobą. SDH odwraca te proporcje. Pierwszy wysiłek wkłada w wykrywanie, czyli w poznanie tego, co robi system, i dopiero potem sięga po wiedzę, którą wykrywanie uczyniło istotną. SDH nie zastępuje też specjalistów od bezpieczeństwa ani wyspecjalizowanych narzędzi Blue Team. Rozszerza wiedzę programisty (`§VI`). Zespół z własnym działem bezpieczeństwa powinien go zachować. SDH daje takiemu zespołowi ustrukturyzowany nośnik, a zespołowi bez takiego działu solidną podstawę. SDH działa też obok deterministycznych skanerów bezpieczeństwa (analiza statyczna, lintery) `[4]`, `[5]`. Te narzędzia są cenne właśnie dlatego, że są deterministyczne i powtarzalne. SDH opiera się głównie na rozumowaniu agenta, co oznacza wymianę ścisłego determinizmu na dopasowanie do kontekstu. Metodologia nie udaje, że jest inaczej. Tam, gdzie determinizm ma znaczenie, osadza w rozumowaniu deterministyczny silnik (`§VII`): agent decyduje, czy dane wejściowe warto sprawdzić, a deterministyczny program decyduje, czy są niebezpieczne. Najbliższym wcześniejszym rozwiązaniem jest Spec-Driven Development (SDD), rodzina metodologii typu spec-first, które prowadzą budowę naprzód na podstawie wykonywalnej specyfikacji. Traktujemy SDD jako klasę. Jej najjaśniejszym ujęciem jako metodologii praktycznej jest raport Piskali `[1]`, jej najbardziej widocznym zestawem narzędzi dla agentów jest Spec Kit firmy GitHub `[2]`, a OpenSpec `[3]` to drugie narzędzie z tej samej rodziny. To one stanowią kanoniczne odniesienia dla porównania w `§X`. --- ## III. SDH: definicja i zasady projektowe **Security-Driven Hardening** to ustrukturyzowana, prowadzona przez AI metodologia bezpieczeństwa, która czyni bazę kodu bezpieczniejszą, kierując pracą na podstawie specyfikacji uruchamianej przez agenta, a nie doraźnych poprawek. Nazwa nawiązuje do zespołów **Blue Team**, czyli obrońców w świecie bezpieczeństwa. SDH dotyczy obrony, utwardzania i weryfikacji, nigdy ataku. > **Definicja** > > **Security-Driven Hardening (SDH):** Ustrukturyzowana, prowadzona przez AI, wyłącznie defensywna metodologia bezpieczeństwa, która najpierw wykrywa, co system naprawdę robi, a potem prowadzi prace nad bezpieczeństwem właściwe dla kontekstu, w ramach domyślnie bezpiecznych zasad i w prostym języku. SDH definiuje zestaw wiążących zasad. Każda z nich jest regułą i każda daje użytkownikowi określoną gwarancję. | Zasada | Reguła | Co gwarantuje użytkownikowi | | ------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Domyślnie bezpiecznie, prostym językiem, dla wszystkich na równi | Każde ustawienie domyślne, komunikat i poprawka są bezpieczne od razu i zrozumiałe dla każdego czytelnika, programisty czy nie. Żadna grupa użytkowników nie jest uprzywilejowana. | Początkujący dostaje bezpieczną podstawę, nie prosząc o nią, i rozumie wynik we własnych kategoriach. | | Dopasowanie do kontekstu zamiast ogólników | Każda faza zaczyna od kontekstu wykrytego w fazie detect i działa na tym, co system faktycznie robi. | Rekomendacje pasują do projektu, a nie do listy kontrolnej. Wiedza o bezpieczeństwie mieszka w specyfikacji i jej specjalizacjach wczytywanych na żądanie i rozszerza wszystko, co wnosi użytkownik. | | Elastyczność zamiast sztywności | Zasady, wymagania i rekomendacje są punktami wyjścia. Użytkownik może dowolny element przeformułować, usunąć, dodać lub zawęzić. | Metodologia dopasowuje się do projektu i użytkownika i nigdy nie jest surowsza, niż chce użytkownik. Elastyczność nigdy nie osłabia domyślnie bezpiecznej podstawy. | | Uzgadnianie zamiast samego dopisywania | Artefakty są żywymi dokumentami, a nie logami. Każde uruchomienie ponownie sprawdza każdy wpis: zachowuje to, co aktualne, przepisuje to, co się zmieniło, usuwa to, co przestało obowiązywać. | Zapis zawsze odzwierciedla teraźniejszość, więc nigdy nie zamienia się w nieaktualny backlog. | | Wyłącznie obrona | SDH audytuje, utwardza i weryfikuje. Nigdy nie tworzy narzędzi ofensywnych, exploitów do złośliwego użycia ani technik unikania wykrycia w celu wyrządzenia szkody. | Metodologii nie da się zamienić w broń. Treści o podwójnym zastosowaniu pojawiają się wyłącznie w jednoznacznie defensywnym ujęciu. | | Najpierw specyfikacja, prowadzenie przez agenta, nastawienie na bezpieczeństwo | Przepływ pracy składa się z szablonów, poleceń, nadrzędnych zasad bezpieczeństwa i agenta, który uruchamia fazy. | Sprawdzona struktura programistyczna, przystosowana tak, aby to agent wykonywał zasadniczą pracę nad bezpieczeństwem. | **Tabela 1.** Zasady projektowe SDH i gwarancja, jaką każda z nich daje użytkownikowi. Te zasady nie są ozdobnikiem. To ograniczenia, których musi przestrzegać każda z opisanych dalej faz, a dyskusja w `§XV` wraca do nich, aby wyznaczyć granice metodologii. Dalsza część dokumentu rozwija dziewięć nazwanych filarów. To elementy, które czytelnik powinien zapamiętać, i elementy, które inny zespół musiałby odtworzyć, aby móc twierdzić, że stosuje SDH. | Filar | Co zapewnia | Sekcja | | ---------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | | Odwrócenie oparte na kontekście | Wiedza o bezpieczeństwie mieszka w specyfikacji i jej specjalizacjach wczytywanych na żądanie, więc początkujący i ekspert korzystają z jednego przepływu pracy. | `§I`, `§VI` | | Pięciofazowy defensywny cykl życia | Podział obowiązków: polityka, wykrywanie, triaż, naprawa, weryfikacja, każda faza z jednym zadaniem. | `§IV` | | Zamykalność | Ustalenie ma stan końcowy, a nie nieskończoną pętlę. Zamknięta praca zostaje wycofana. | `§V` | | Dwoistość rozszerzania wiedzy programisty | Jeden przepływ pracy, który chroni początkującego i wzmacnia eksperta, nie zastępując żadnego z nich. | `§VI` | | Prompt na żądanie, niewywoływalna wiedza | Istotna wiedza o bezpieczeństwie jest wczytywana pod kątem tego, czym jest projekt, nigdy domyślnie. | `§VII` | | Niezależność od stanu i nienarzucająca adaptacyjność | Pasuje do każdego etapu rozwoju i każdego stosu technologicznego oraz dopasowuje się do scenariusza, zamiast narzucać zakres. | `§VIII` | | Tryb prewencyjny | Ta sama obrona działa podczas tworzenia nowej pracy, więc kod od razu powstaje domyślnie bezpieczny. | `§IX` | | Śledzenie z tożsamością opartą na nazwie | Ustalenie pozostaje jednym elementem we wszystkich fazach, a zmiana nazwy zrywa powiązanie tylko w jednym miejscu. | `§XI` | | Nośnik niezależny od agenta | Wartość bezpieczeństwa powstaje raz i nie zależy od żadnego agenta ani stosu. | `§XII` | **Tabela 2.** Dziewięć nazwanych filarów SDH i miejsca, w których każdy z nich jest rozwinięty. --- ## IV. Przepływ pracy Blue Team w 5 fazach SDH porządkuje pracę w pięciofazowy defensywny cykl życia (Rysunek 1). Każda faza jest nastawiona na obronę, każda opiera się na poprzedniej, a fazy odpowiadają rzeczywistej pracy zespołu Blue Team: określenie polityki, wykrywanie, triaż, naprawa, weryfikacja. ```mermaid flowchart TB charter["1 · charter (polityka)
czyta: projekt oraz opis użytkownika, jeśli go podano
zapisuje: zasady bezpieczeństwa
każda zasada opisuje prostym językiem ryzyko, któremu zapobiega"] detect["2 · detect (wykrywanie)
czyta: kod użytkownika
zapisuje: mapę wykrywania
wykrywać, nie wymyślać: zapisuj tylko to, co potwierdza kod"] plan["3 · plan (triaż)
czyta: mapę wykrywania, nigdy kodu
zapisuje: plan obrony
każda poprawka wskazuje coś, co detect faktycznie zmapowała"] harden["4 · harden (naprawa)
czyta: plan obrony oraz kod, którego dotyczy
zapisuje: kod oraz rejestr utwardzania
jedyna faza, która zmienia kod, jedna poprawka naraz, najmniejsza zmiana, która działa"] verify["5 · verify (weryfikacja)
czyta: kod oraz rejestr utwardzania
zapisuje: każdy otwarty werdykt w rejestrze utwardzania
zestawienie kodu z rejestrem, statyczne, nigdy złagodzone"] charter --> detect --> plan --> harden --> verify verify -.->|"odrzucenie: ponownie otwarta praca dla harden,
wdrożona jeszcze raz zgodnie z zapisanym powodem"| harden verify -.->|"zamknięcie: to, czego zamknięcie wykazała,
wycofuje z całego łańcucha,
jedna linijka w historii"| detect ``` **Rysunek 1.** Pięciofazowy przepływ pracy: co czyta każda faza, co zapisuje i jaki jest jej kluczowy niezmiennik. Verify steruje oboma powrotami: odrzucone zabezpieczenie ponownie otwiera harden, a ustalenie, którego zamknięcie wykazano, zostaje wycofane z łańcucha, z jedną linijką w historii. Wkładem jest podział obowiązków. Ponieważ każda faza ma jedno zadanie, każdy rodzaj awarii pozostaje ograniczony do jednego miejsca, a czytelnik może ufać temu, co deklaruje każdy artefakt. > **Kluczowy wniosek** > > **Applied nie znaczy zweryfikowane:** Faza harden zapisuje, że poprawkę wdrożono. Faza verify weryfikuje to, zestawiając kod z tym rejestrem, a werdykt nigdy nie jest łagodzony, aby pasował do rejestru. Zabezpieczenie może być obecne w kodzie, a ryzyko wciąż osiągalne, i wtedy uczciwy werdykt brzmi "Risk not closed". ### charter (polityka) Faza charter ustala zasady bezpieczeństwa projektu, czyli reguły, których musi przestrzegać każda kolejna faza. To warstwa nadrzędna, rodzaj kontroli na etapie kompilacji dla poziomu bezpieczeństwa projektu. Każda zasada ma jasną nazwę, niepodlegającą negocjacjom regułę, którą da się sprawdzić w kodzie, oraz wiersz `Why:` opisujący ryzyko, któremu zapobiega, a nie tylko poprawkę. Faza charter zawsze czyta sam projekt (jego manifesty, strukturę i zależności), a opis użytkownika, jeśli został podany, wyznacza kierunek, który ta lektura potem poszerza poza to, co użytkownik wymienił. Bez opisu projekt jest jedynym źródłem. Oba źródła się sumują, zamiast konkurować, a zasady bezpieczeństwa zapisują politykę, której projekt powinien się trzymać, a nie stan jego kodu. Osoba, która nie programuje, powinna móc je przeczytać i zrozumieć zarówno regułę, jak i ryzyko. ### detect (wykrywanie) Faza detect czyta kod i mapuje to, co system faktycznie robi i co ma znaczenie dla bezpieczeństwa. Nadrzędna instrukcja brzmi "wykrywać, nie wymyślać": zapisuj tylko to, co potwierdza kod, wraz z dowodami potrzebnymi kolejnym fazom. Detect jest neutralna. Nie dopasowuje na siłę swoich ustaleń do zasad bezpieczeństwa, bo dopasowywanie ryzyk do reguł zawartych w zasadach bezpieczeństwa to zadanie fazy plan. Każde ustalenie składa się z trzech części: czym jest (opis prostym językiem), dlaczego ma znaczenie (ryzyko, a nie tylko fakt) i dowodu (funkcja lub trasa, w której się znajduje). Dowód nie zawiera ścieżki pliku. Ścieżka znajduje się wyłącznie w mapie śledzenia (`§XI`), więc tekst nigdy nie przechowuje ścieżki, która może się zdezaktualizować. ### plan (triaż) Faza plan zamienia każde ustalenie w poprawkę, nazwaną według klasy ryzyka (z odwołaniem do uznanych źródeł, CWE i OWASP, tam gdzie je uzasadniają) i powiązaną z zasadą bezpieczeństwa, którą poprawka chroni. Priorytet (krytyczny, wysoki, średni, niski) nie jest kwestią swobodnego wyboru: plan ocenia każde ustalenie metodą CVSS v4.0 z metrykami Base i Environmental, więc poziom priorytetu to wynik wyrażony prostymi słowami, uzasadniony jednym zrozumiałym zdaniem o ekspozycji i stawce, a dwa uruchomienia dają tę samą kolejność. Wektor jest precyzyjnym punktem odniesienia dla eksperta, a poziom wraz z uzasadnieniem to ta sama ocena w formie, którą każdy może prześledzić. Plan pracuje wyłącznie na mapie wykrywania i nigdy nie czyta kodu. To celowe ograniczenie, a nie słabość: zmusza każdą poprawkę do wskazania czegoś, co detect faktycznie wykryła. Jeśli jakiś zakres nigdy nie został zmapowany, plan się zatrzymuje i odsyła użytkownika z powrotem do fazy detect, zamiast zgadywać. ### harden (naprawa) Harden to jedyna faza, która zmienia kod, więc postępuje ostrożnie. To, czy edycja wymaga zgody użytkownika, zależy od agenta i trybu uprawnień, w którym działa, więc harden nie dodaje własnego kroku potwierdzenia. Wdraża jedną poprawkę naraz, najpierw zależności, potem najwyższy priorytet, aby każda zmiana pozostała mała, łatwa do przejrzenia i łatwa do cofnięcia. Nigdy nie osłabia istniejącego zabezpieczenia, aby nowa poprawka pasowała, i nigdy nie łamie żadnej zasady bezpieczeństwa. Jeśli poprawka kolidowałaby z którąś zasadą, harden się zatrzymuje i ujawnia konflikt, zamiast ją wdrażać. Każdy blok jest zapisywany jako Applied, Partial lub Blocked. "Applied nie znaczy jeszcze zweryfikowane", i tym właśnie zajmuje się kolejna faza. ### verify (weryfikacja) Verify weryfikuje każde wdrożone zabezpieczenie, czytając kod i zestawiając go z tym, co zapisała faza harden. Weryfikacja to właśnie to zestawienie, kod z rejestrem, i jest statyczna: potwierdza, że zabezpieczenie jest obecne i poprawne w kodzie, a nie że wytrzyma atak na działającym systemie. Taka kontrola w czasie działania, czyli przeprowadzanie prawdziwych lub symulowanych ataków na działający system, jest celowo poza zakresem. Verify zwraca jeden z trzech werdyktów: Risk closed, Risk not closed albo Cannot tell from the code. Nie tworzy własnego artefaktu: harden i verify współdzielą rejestr utwardzania, przy czym harden odpowiada za to, co zrobiono, a verify za werdykt i jego uzasadnienie, i żadna z nich nigdy nie zapisuje pól drugiej. Odrzucone zabezpieczenie to ponownie otwarta praca dla harden, która przy następnym uruchomieniu stawia werdykt ponad własną lekturą kodu i wdraża poprawkę jeszcze raz, celując dokładnie w lukę wskazaną w uzasadnieniu. Verify ufa kodowi bardziej niż rejestrowi, bo rejestr może deklarować więcej, niż kod faktycznie zapewnia. Kod użytkownika tylko czyta i nigdy nie łagodzi werdyktu, aby pasował do rejestru. Zabezpieczenie może być obecne, a ryzyko nadal osiągalne inną drogą, i w takim przypadku uczciwy werdykt brzmi "Risk not closed". Jeśli podczas lektury verify zauważy problem bezpieczeństwa, którego mapa wykrywania nigdy nie objęła, nie wymyśla dla niego werdyktu, bo wykrywanie to zadanie fazy detect: zgłasza problem i odsyła użytkownika z powrotem do detect, aby ustalenie weszło tym samym przepływem pracy, zamiast go omijać. > **Przykład przewodni: przesyłanie plików.** Jedno ustalenie pokazuje cały kręgosłup przepływu pracy od początku do końca. > > - **detect** je znajduje: system przyjmuje pliki od użytkowników, a handler przesyłania ufa typowi MIME podanemu przez klienta, nie sprawdzając rzeczywistego typu pliku. _Dlaczego to ważne:_ plik podszywający się pod obraz może ukrywać złośliwy kod. > - **plan** wybiera poprawkę, priorytet **krytyczny**, w obronie zasady "Wszystkie dane wejściowe są niezaufane, dopóki nie przejdą walidacji": sprawdzać rzeczywisty typ i rozmiar pliku, zmieniać jego nazwę przy zapisie i przechowywać przesłane pliki tam, gdzie nie da się ich uruchomić jako kodu. > - **harden** ją wdraża, status **Applied**: handler rozpoznaje teraz rzeczywisty typ na podstawie zawartości, egzekwuje limit rozmiaru, odrzuca wszystko, co nieoczekiwane, zmienia nazwę przy zapisie i przechowuje pliki tam, gdzie kod nie może się uruchomić. > - **verify** czyta handler, zestawia go z rejestrem i zwraca **Risk closed**: kod robi dokładnie to, co deklaruje rejestr. > > Ta sama nazwa ustalenia przechodzi przez mapę wykrywania, plan i rejestr utwardzania, a verify działa na tym rejestrze pod tą samą nazwą: otwarty werdykt trafia do bloku ustalenia, a ustalenie, którego zamknięcie wykazano, zostaje wycofane (`§V`). Ta wspólna nazwa jest jego tożsamością (`§XI`). --- ## V. Zamykalność: ustalenie ma stan końcowy Większość narzędzi bezpieczeństwa zostawia użytkownika z backlogiem, który tylko rośnie. SDH przyjmuje inne stanowisko: **ustalenie jest możliwe do zamknięcia, więc ma stan końcowy, zamiast żyć w nieskończonym backlogu** (Rysunek 2). Wynika to bezpośrednio z zasady uzgadniania. > **Definicja** > > **Zamykalność:** Ryzyko, którego zamknięcie zweryfikowano, zostaje wycofane z całego przepływu pracy, więc ustalenie przechodzi w stan spoczynku i otwiera się ponownie dopiero wtedy, gdy zmieni się kod. Ustalenie ma stan końcowy, choć sam program bezpieczeństwa pozostaje ciągły. Artefakty SDH są żywymi dokumentami, a nie logami. Za każdym razem, gdy faza uruchamia się ponownie, sprawdza każdy istniejący wpis względem aktualnego stanu i robi jedną z trzech rzeczy: zachowuje to, co nadal obowiązuje, przepisuje to, co się zmieniło, albo usuwa to, co przestało mieć zastosowanie. Ustalenie, które według kodu zostało już rozwiązane, jest po prostu usuwane. Roboczy zapis odzwierciedla teraźniejszość, a nie przeszłość. Zamknięcie jest tym samym uzgadnianiem, doprowadzonym do końca. Gdy verify zweryfikuje, że ryzyko jest zamknięte, wycofuje ustalenie z całego przepływu pracy: z mapy wykrywania, planu, rejestru utwardzania i mapy śledzenia. Dlatego verify jest jedyną fazą, która zapisuje artefakty innych faz: to ona zamyka pętlę. Gdy ustalenie opuszcza łańcuch, wycofanie destyluje je do krótkiego wpisu w historii, która leży poza roboczym łańcuchem i nigdy nie jest ponownie przetwarzana. Na tym polega granica między zniknięciem a zamknięciem: ustalenie, które uzgadnianie usunęło, bo przestało być prawdziwe, nie zostawia po sobie śladu, a ustalenie, którego zamknięcie wykazano, zasługuje na swoją linijkę w historii. Wycofanego ustalenia nie ma potem w żadnym artefakcie roboczym, a ten brak jest oczekiwany i nie oznacza zerwanego łańcucha. ```mermaid stateDiagram-v2 direction TB [*] --> OPEN: detect wykrywa OPEN --> Plan: plan Plan --> Harden: harden Harden --> Verify: verify Verify --> StoodDown: Risk closed StoodDown --> SETTLED SETTLED --> OPEN: zmiana kodu ponownie otwiera ustalenie Plan: plan Harden: harden Verify: verify StoodDown: STOOD DOWN · jedna linijka w historii ``` **Rysunek 2.** Maszyna stanów zamykalności. Ustalenie przechodzi przez stany OPEN → STOOD DOWN → SETTLED i otwiera się ponownie dopiero wtedy, gdy zmieni się kod. Gdy wszystko w zakresie zostanie wycofane, cykl przechodzi w stan spoczynku, a ten stan ma konkretną postać: artefakt, którego ostatnie ustalenie zostało zamknięte, jest usuwany w całości, więc w pełni zamknięty łańcuch zostawia tylko zasady bezpieczeństwa i historię, czyli politykę i dowody. Cykl otwiera się ponownie dopiero wtedy, gdy zmieni się kod. Metodologia daje każdemu ustaleniu wyraźny koniec, a tego właśnie nieskończony backlog dać nie może. --- ## VI. Dwoistość rozszerzania wiedzy programisty SDH nie zastępuje ludzi ani wyspecjalizowanych narzędzi Blue Team. **Rozszerza wiedzę samego programisty**. Im lepiej programista rozumie bezpieczeństwo, tym precyzyjniej może sterować przepływem pracy i tym większą ma autonomię. Programista, który rozumie niewiele, i tak otrzymuje bezpieczny wynik, bo chroni go tryb automatyczny. Odwrócenie z `§I`, zgodnie z którym wiedza o bezpieczeństwie mieszka w specyfikacji, działa w obu kierunkach. Dla początkującego oznacza ochronę: nie musi wiedzieć, o co zapytać, bo specyfikacja sama proponuje. Dla eksperta oznacza wzmocnienie: ta sama specyfikacja pozwala mu precyzyjnie nakierować przepływ pracy, zamiast zmagać się ze sztywną listą kontrolną. Każda faza niesie tę dwoistość w swoim własnym działaniu (Rysunek 3). Uruchomiona bez danych wejściowych działa na całym zakresie w imieniu użytkownika. Gdy dostanie wskazówki, ta sama faza zawęża się dokładnie do tego, na co wskazał użytkownik. ```mermaid flowchart TB inversion["jedno odwrócenie, dwa kierunki:
wiedza o bezpieczeństwie mieszka w specyfikacji"] inversion --> auto["tryb automatyczny (bez danych wejściowych)
faza proponuje i działa
na całym zakresie"] inversion --> directed["tryb ukierunkowany (z danymi wejściowymi)
faza zawęża się dokładnie
do tego, na co wskazał użytkownik"] auto --> novice["początkujący, chroniony:
bezpieczny wynik bez
wiedzy, o co zapytać"] directed --> expert["ekspert, wzmocniony:
przepływ pracy precyzyjnie nakierowany,
a nie sztywna lista kontrolna"] novice -.-> phases["te same pięć faz służy obu:
charter · detect · plan · harden · verify"] expert -.-> phases ``` **Rysunek 3.** Dwoistość rozszerzania wiedzy programisty. Jedno odwrócenie służy dwóm grupom odbiorców: tryb automatyczny chroni początkującego, a tryb ukierunkowany wzmacnia eksperta, przez te same pięć faz. Specjalizacje wczytywane na żądanie (`§VII`) wyrażają tę dwoistość wprost we własnej treści. Każda mówi agentowi, że jej wiedza "rozszerza twój osąd", i każe mu rozumować dalej, poza to, co zapewnia specjalizacja. Ta wiedza jest podłogą, a nie sufitem. To właśnie służy obu grupom odbiorców w równowadze, do której dąży dokument: społeczność programistów zyskuje solidne narzędzie, a praktyk Blue Team zyskuje ustrukturyzowany nośnik, który nie udaje, że wykona za niego jego pracę. --- ## VII. Niewywoływalne specjalizacje i prompt na żądanie To najbardziej nowatorski wzorzec metodologii. SDH przechowuje skupioną wiedzę o bezpieczeństwie w postaci specjalizacji, które wczytują się **wyłącznie na żądanie**, a o tym, które wczytać, decyduje sam agent, dopasowując je do kontekstu projektu. Nazywamy to **promptem na żądanie**: sposobem, w jaki agent wybiera, którą wiedzę aktywować, na podstawie zakresu projektu, w którym się znajduje, zamiast domyślnie uruchamiać każdą kontrolę. Specjalizacje ewoluują, a każda z nich może się zmienić lub zostać zastąpiona w dowolnym momencie. Wkładem jest wzorzec, a nie same specjalizacje. > **Definicja** > > **Prompt na żądanie:** Agent wybiera, którą wiedzę o bezpieczeństwie aktywować, dopasowując ją do zakresu projektu, który ma przed sobą, więc istotna wiedza jest wczytywana pod kątem tego, czym projekt faktycznie jest, zamiast domyślnego uruchamiania każdej kontroli. > **Definicja** > > **Niewywoływalna specjalizacja:** Skupiona, niezależna od języka jednostka wiedzy o bezpieczeństwie dla jednego kontekstu, na przykład przesyłania plików albo kodu działającego w przeglądarce. Audytuje i wyjaśnia, nigdy nie przepisuje kodu i nigdy nie tworzy danych wejściowych do ataku. Nie jest poleceniem: wczytuje się, gdy kontekst, który obejmuje, znajduje się w zakresie, albo gdy prompt poprosi o nią po nazwie. Każda specjalizacja wskazuje bezpieczniejsze rozwiązania dla ryzyk, które obejmuje, i mówi agentowi, jak postąpić z ustaleniem w każdej fazie, która z niej korzysta: jak je ocenić przy wykrywaniu, jak bezpiecznie wdrożyć poprawkę przy naprawie i jak wykazać jej działanie przy weryfikacji. Cechą definiującą jest to, że specjalizacji **nie da się wywołać samodzielnie**: nie jest poleceniem, a w obrębie przepływu pracy wczytuje ją dopasowanie. Faza wykrywania raz pobiera listę katalogu, dopasowuje kontekst projektu do tego, co obejmuje każdy wpis, i wczytuje tylko specjalizacje, których kontekst występuje w zakresie. Późniejsze fazy korzystają z tej listy dopasowań, zamiast tworzyć ją od nowa, więc jedno dopasowanie służy całemu łańcuchowi, a tryb prewencyjny (`§IX`) przeprowadza to samo dopasowanie dla pracy, która ma dopiero powstać. Specjalizacja, której kontekstu brak, zostaje pominięta, a pominięcie podlega takiemu samemu rozliczeniu jak wczytanie: każdy wpis w katalogu dostaje jednoznaczny werdykt, zastosowana albo pominięta, z uzasadnieniem odczytanym z kodu, więc mgliste poczucie, że coś jest nieistotne, nigdy nie zastępuje faktycznego braku. Brak jakiejkolwiek pasującej specjalizacji to prawidłowy wynik. Katalog to dane, a jego rozbudowa to jeden plik wiedzy i jeden wiersz katalogu, nigdy nowe polecenie. Wbudowane specjalizacje są pogrupowane w kategorie, takie jak OWASP, język programowania czy integracje z AI, a katalog, z którego korzysta projekt, zawiera wbudowane specjalizacje z wybranych przez niego kategorii oraz jego własne specjalizacje. Projekt zapisuje ten wybór razem z resztą swojego stanu, więc cały zespół dopasowuje względem tego samego katalogu. To ta sama zasada dopasowania do kontekstu co w fazach, zastosowana do wiedzy: istotna wiedza jest wczytywana pod kątem tego, czym projekt faktycznie jest, zamiast domyślnego uruchamiania każdej kontroli. Ta sama właściwość pozwala rozbudowywać katalog użytkownikowi, a nie tylko opiekunowi projektu: źródło lub temat z dziedziny bezpieczeństwa, które dostarczy użytkownik, zostaje zdestylowane do nowej specjalizacji należącej do projektu, która trafia do jego katalogu niezależnie od kategorii i wczytuje się dokładnie tak jak wbudowana, zastępując wbudowaną o tej samej nazwie. Tworzenie specjalizacji również jest wyłącznie defensywne i podlega tej samej granicy, której pilnują specjalizacje: opis ataku może być źródłem, ale powstała z niego specjalizacja audytuje i wyjaśnia, nigdy nie tworzy działającego exploita. W ten sposób odwrócenie z `§I`, czyli inteligencja mieszkająca w specyfikacji, obejmuje sam katalog, który użytkownik może pogłębiać dla własnego kontekstu bez pisania kodu. Krótki przykład ilustruje prompt na żądanie. Faza detect czyta folder z kodem działającym w przeglądarce. Dopasowuje ten kontekst w katalogu, wczytuje specjalizację, która go obejmuje, i zgłasza ustalenie po stronie klienta w ramach zwykłych kroków fazy detect. Specjalizacje, których kontekstu brak w tym zakresie, nie pasują, więc nigdy się nie wczytują, a każda zostaje zapisana jako pominięta. To projekt zdecydował, która wiedza jest istotna, a nie stała konfiguracja. Determinizm pojawia się dokładnie tam, gdzie ma znaczenie. Specjalizacja może zawierać deterministyczne narzędzie sprawdzające, a nie tylko tekst: tam, gdzie klasa ryzyka ma jasną procedurę decyzyjną, mały program zwraca stały werdykt dla danych wejściowych, na przykład jedno z krótkiej listy słów, takich jak `safe`, `unsafe` czy `invalid input`. Niektóre klasy ryzyka da się rozstrzygać deterministycznie właśnie w ten sposób, a za procedurą decyzyjną stoi dorobek wcześniejszych prac `[9]`, `[10]`, `[11]`. Narzędzie sprawdzające albo ocenia kandydatów dostarczonych przez agenta, albo samo przeszukuje zakres, aby ich znaleźć, i w obu przypadkach werdykt zwraca narzędzie sprawdzające, a nie agent. Wystarczająco uniwersalną specjalizację można oznaczyć w katalogu jako wymaganą. Wtedy jest stosowana zawsze, a jej narzędzie sprawdzające działa na całym zakresie. To jedyny przypadek, w którym wiedza wczytuje się bez dopasowania kontekstu, i deklarują go dane katalogu, nigdy doraźna decyzja agenta. W tym miejscu SDH osadza rozumowanie agenta w czymś powtarzalnym, nie udając, że cały przepływ pracy jest deterministyczny. Wreszcie specjalizacje są **odłączalne**. Ponieważ wiedza jest samodzielna, użytkownik może uruchomić jedną z nich bezpośrednio w prompcie, który nie ma nic wspólnego z pełnym przepływem pracy SDH, i w ten sposób dbać o bezpieczeństwo przy zwykłej pracy programistycznej. Specjalizacja z deterministycznym narzędziem sprawdzającym może na przykład sprawdzać każdego kandydata powstałego podczas zwykłego programowania i zostawiać tylko bezpieczne. Ta odłączalność jest jednym z powodów, dla których SDH dopasowuje się do tak wielu sytuacji, o czym mówi `§VIII`, a pełny wyraz znajduje w trybie prewencyjnym (`§IX`), w którym ta sama wiedza chroni zwykłą pracę programistyczną od początku do końca. --- ## VIII. Niezależność od stanu i nienarzucająca adaptacyjność Dwie własności odróżniają SDH od sztywnych metodologii opartych na specyfikacji. ### Niezależność od stanu > **Definicja** > > **Niezależność od stanu:** Metodologia nie zależy od etapu rozwoju projektu. Pasuje do pustego folderu, projektu w toku, pojedynczego pull requesta czy dużej bazy kodu legacy, w dowolnym stosie technologicznym, bo punkt wyjścia poznaje, czytając go. Każda faza działa tak samo niezależnie od tego, czy projekt jest zupełnie nowy, czy już istnieje. Faza charter wyprowadza zasady z kodu, który akurat jest. Faza detect mapuje kod, który jest na miejscu, nawet jeśli jest go bardzo mało. Nie ma założonego punktu wyjścia. ### Nienarzucająca adaptacyjność > **Definicja** > > **Nienarzucająca adaptacyjność:** Metodologia dopasowuje się do scenariusza, zamiast narzucać stały zakres, którego użytkownik musi się trzymać. Gdy użytkownik nie wie, co powiedzieć, czyta środowisko, w którym ją wywołano, tworzy kontekst i zadaje pytania, które kształtują jej następne kroki. Tryb proponowania fazy charter to najwyraźniejszy przykład: SDH, analizując projekt, wyprowadza domyślnie bezpieczny zestaw zasad, pyta użytkownika tylko wtedy, gdy luka faktycznie zmienia wynik, a potem go zapisuje i przedstawia każdą zasadę prostym językiem wraz z ryzykiem, któremu zapobiega. Zasady bezpieczeństwa to żywy dokument, który użytkownik przerabia, uruchamiając fazę ponownie, a nie umowa zablokowana za prośbą o zatwierdzenie, więc nigdy nie wymagają od użytkownika wiedzy, o co zapytać. Ta adaptacyjność przejawia się wrażliwością na kształt danych wejściowych: ta sama faza czyta to, co otrzymała, i wybiera tryb (Rysunek 4). Plik w prompcie, ustalenie z listy, obawa, ukierunkowana misja wymierzona w znany słaby punkt albo prośba o pełne skanowanie metodą brute force: każde z nich odpowiada potrzebie użytkownika, bo przepływ pracy z założenia niczego nie narzuca. Nic z tego nie osłabia domyślnie bezpiecznej podstawy. Elastyczność kształtuje sposób stosowania podstawy, nigdy jej nie obniża. ```mermaid flowchart TB shape["faza czyta kształt
tego, co otrzymała"] shape --> none["brak danych wejściowych"] shape --> paths["jedna lub więcej ścieżek"] shape --> concern["opisane zagadnienie"] shape --> finding["wskazane ustalenie"] shape --> band["poziom priorytetu"] none --> auto["tryb automatyczny:
zaproponuj albo przeszukaj
cały zakres"] paths --> focus["skup się tylko na tych
plikach lub folderach"] concern --> scoped["zawęź do tego
jednego zagadnienia"] finding --> item["działaj na tym jednym
śledzonym elemencie"] band --> priority["działaj tylko na priorytecie krytycznym,
wysokim, średnim lub niskim"] ``` **Rysunek 4.** Nienarzucająca adaptacyjność. Ta sama faza czyta kształt swoich danych wejściowych i wybiera tryb, więc zakres zawsze należy do użytkownika i nigdy nie jest narzucony. --- ## IX. Uniwersalny tryb prewencyjny: ta sama obrona w trakcie tworzenia SDH ma jeden tryb uzupełniający: zwykłą pracę programistyczną wykonywaną przy aktywnej tej samej obronie, w trakcie pisania kodu. Użytkownik prosi o samą pracę, stronę logowania, przesyłanie plików, endpoint, a metodologia pilnuje budowy na bieżąco, więc wynik jest domyślnie bezpieczny w chwili, gdy powstaje, a nie dopiero po późniejszym utwardzaniu. > **Definicja** > > **Tryb prewencyjny:** zwykła praca programistyczna prowadzona w ramach warstwy nadrzędnej i wiedzy SDH. Zasady bezpieczeństwa wiążą budowę, specjalizacje istotne dla tego, co ma powstać, wczytują się na żądanie, a zanim praca zostanie uznana za skończoną, wynik jest zestawiany dokładnie z tą obroną, której użyto. Ten tryb wykorzystuje każdy element, który fazy już mają, skierowany na kod, który jeszcze nie istnieje. Wykrywanie kontekstu przenosi się z kodu na intencję: agent przemyśla, co ma zbudować i jakie granice ta praca przekracza (logowanie oznacza dane uwierzytelniające, sesję i dane wejściowe z zewnątrz), i to właśnie te przemyślenia są dopasowywane do katalogu wiedzy. Prompt na żądanie (`§VII`) zostaje tu uogólniony: kontekst można wykryć w planie kodu, a nie tylko w istniejącym kodzie. Zasady bezpieczeństwa obowiązują jak zawsze, a prośba, która złamałaby którąś zasadę, zostaje zgłoszona jako konflikt i nigdy nie jest realizowana. Obrona jest stosowana na bieżąco, w chwili pisania każdego elementu, z walidacją na granicy i bezpieczną konstrukcją użytą od pierwszego razu, więc działająca, ale niebezpieczna wersja w ogóle nie powstaje i nie trzeba jej poprawiać. Tryb kończy się tak, jak zaczyna się faza verify. Zanim praca zostanie uznana za skończoną, ten, kto ją zbudował, zestawia własny wynik z obroną, której użył: zabezpieczenie musi leżeć na drodze ryzyka, a nie obok niej, musi być kompletne, a tam, gdzie specjalizacja zawiera deterministyczne narzędzie sprawdzające, jego werdykt ma pierwszeństwo przed własną lekturą agenta. Luka znaleziona na tym etapie zostaje zamknięta w ramach tej samej pracy, bo dokończyć pracę znaczy dokończyć ją bezpiecznie. To, czego tryb odmawia, jest równie przemyślane jak to, co robi. Buduje tylko to, o co poproszono, i niczego wokół nie audytuje: audyt tego, co istnieje, należy do faz. Nie zapisuje żadnego artefaktu i nie śledzi żadnego ustalenia, bo ustalenie to ryzyko wykryte w tym, co istnieje, a celem tego trybu jest to, aby niebezpieczna wersja w ogóle nie powstała. Oba kierunki się uzupełniają: fazy zamykają to, co już jest (`§V`), a tryb prewencyjny nie pozwala, aby nowa praca otworzyła to ponownie. Łańcuch w stanie spoczynku pozostaje w stanie spoczynku nie dlatego, że rozwój się zatrzymał, ale dlatego, że to, co powstaje w tym czasie, powstaje już chronione. --- ## X. Security-Driven Hardening a Spec-Driven Development Security-Driven Hardening (SDH) wyrosła z podstaw Spec-Driven Development (SDD), a potem wyraźnie się od nich oddzieliła. Strukturalne dziedzictwo jest rzeczywiste i uznane: podejście spec-first, prowadzenie przez agenta, dokument nadrzędny i zestaw poleceń podzielonych na fazy, które uruchamia agent. SDH świadomie wykorzystuje tę strukturę. Różnią się cel, model autorytetu, zakładany stan i warunek zakończenia. Traktujemy SDD jako klasę, przyjmując raport Piskali `[1]` za kanoniczne ujęcie metodologii, Spec Kit firmy GitHub `[2]` za kanoniczny zestaw narzędzi dla agentów, a OpenSpec `[3]` za drugie narzędzie z tej samej rodziny. SDD odwraca tradycyjne programowanie, czyniąc specyfikacje wykonywalnymi: specyfikacja bezpośrednio generuje działającą implementację, zamiast tylko nią kierować `[1]`. Jej zestaw faz prowadzi budowę naprzód `[2]` (ustal zasady nadrzędne, określ, co zbudować, zaplanuj stos technologiczny, podziel plan na zadania, a potem zaimplementuj). Jej dokument nadrzędny, konstytucja złożona z zasad, jest fundamentem, którego agent musi przestrzegać przez cały czas. To sedno różnicy. W SDD autorytet płynie od specyfikacji do budowy, a od implementacji oczekuje się, że będzie za nią podążać. SDH odwraca niemal każdą oś tej umowy (Tabela 3). > **Kluczowy wniosek** > > **Zasadnicza różnica:** W SDD autorytet płynie od specyfikacji do budowy, a od implementacji oczekuje się, że będzie za nią podążać. SDH niczego nie narzuca i płynie w przeciwną stronę, do wewnątrz, od wykrytego kontekstu systemu, utwardzając to, co już istnieje. | Oś | SDD | SDH | | --------------------- | --------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | Cel | Dostarczanie funkcji. Specyfikacja staje się działającą implementacją. | Utwardzanie tego, co istnieje lub właśnie powstaje. Każda faza jest nastawiona na obronę. | | Model autorytetu | Narzucający. Specyfikacja i konstytucja zamykają budowę w zakresie, którego musi się trzymać. | Nienarzucający. SDH dopasowuje się do scenariusza, a użytkownik może przeformułować, usunąć lub zawęzić. | | Założenie co do stanu | Budowa naprzód na podstawie specyfikacji. | Niezależność od stanu: pusty folder, projekt w toku, pojedynczy PR albo legacy. | | Warunek zakończenia | Kończy się, gdy funkcja zostanie zbudowana. | Zamykalność. Ustalenie przechodzi w stan spoczynku i otwiera się ponownie dopiero wtedy, gdy zmieni się kod. | | Dokument nadrzędny | Konstytucja złożona z zasad, których agent musi przestrzegać. | Zasady bezpieczeństwa ujęte od strony ryzyka (każda z wierszem `Why:`), wprost niebędące stałą umową. | | Jak rośnie wiedza | Dodanie polecenia (lub rozszerzenie zestawu faz). | Dodanie niewywoływalnej specjalizacji, którą agent wczytuje na żądanie: jeden plik i jeden wiersz katalogu, bez nowego polecenia. | | Komu służy | Osobie budującej, która rozwija funkcję. | Każdemu użytkownikowi, programiście czy nie, w ramach tego samego przepływu pracy. | | Co zmienia kod | Faza implementacji generuje budowę. | Kod zmienia tylko faza harden, jedna poprawka naraz. | **Tabela 3.** SDD i SDH w ośmiu osiach. Zapożyczona struktura, odwrócona umowa. Gwoli sprawiedliwości wobec tego rodowodu: SDD to sprawdzone wcześniejsze rozwiązanie, któremu SDH zawdzięcza strukturę, na której działa. Rozbieżność nie jest krytyką SDD, która dobrze rozwiązuje inny problem (budowę naprzód). SDH bierze tę samą sprawdzoną maszynerię i kieruje ją na obronę, adaptacyjność i zamknięcie. OpenSpec `[3]`, zorganizowany wokół propozycji zmian, list zadań i specyfikacji dla poszczególnych zmian, potwierdza ten wzorzec: ta rodzina prowadzi budowę naprzód na podstawie specyfikacji, podczas gdy SDH utwardza system do wewnątrz, od jego wykrytego kontekstu. Nawet tryb prewencyjny SDH (`§IX`), jedyne miejsce, w którym towarzyszy ona budowie naprzód, zachowuje odwróconą umowę: określa, jak praca powstaje, i nigdy nie decyduje, co ma powstać. --- ## XI. Rygor inżynierski: dyscyplina śledzenia Dyscyplina uzgadniania zamiast dopisywania (`§V`) potrzebuje podłoża, które przetrwa refaktoryzacje. Ustalenie musi pozostać jednym elementem w każdej fazie, która go dotyka, a plik o zmienionej nazwie lub przeniesiony nie może zerwać łańcucha. SDH rozwiązuje to dzięki **tożsamości opartej na nazwie** i **ścieżkom przechowywanym wyłącznie w śledzeniu**. > **Definicja** > > **Tożsamość oparta na nazwie:** Tożsamością ustalenia jest jego nazwa, zapisana identycznie w każdym artefakcie. Tekst zawiera nazwę, nigdy ścieżkę. Ścieżki plików znajdują się wyłącznie w mapie śledzenia, więc zmiana nazwy lub przeniesienie pliku zrywa powiązanie dokładnie w jednym miejscu. Każde ustalenie fazy detect to jeden śledzony element. Jego tożsamością jest **nazwa**, czyli tytuł sekcji, zapisany identycznie w mapie wykrywania, planie i rejestrze utwardzania. Późniejsze fazy używają tej nazwy dosłownie, działając na tym samym elemencie, a verify zapisuje swój werdykt w rejestrze utwardzania pod tą samą nazwą. Mapa śledzenia przechowuje śledzenie i nic poza nim, jeden wpis na element: ```json { "name": "File uploads", "paths": ["src/routes/upload.ts"] } ``` Mapa nie zapisuje tekstu, adnotacji, osobnego identyfikatora ani fazy. Artefakty tekstowe niosą treść, a mapa wyłącznie tożsamość i ścieżki. Ścieżki plików są jedynym zmiennym elementem i znajdują się tylko tutaj. Zmiana nazwy lub przeniesienie pliku może zerwać powiązanie dokładnie w jednym miejscu, nigdy w dwóch rozbieżnych kopiach. ```mermaid flowchart TB detect["mapa wykrywania"] --> name plan["plan obrony"] --> name harden["rejestr utwardzania
tu verify zapisuje swój werdykt"] --> name name["name = "File uploads"
tekst zawiera nazwę, nigdy ścieżkę"] name -.-> tracking tracking["mapa śledzenia
{ name: "File uploads",
paths: ["src/routes/upload.ts"] }
ścieżka jest tylko tutaj, więc zmiana nazwy poprawia tylko ten wpis"] ``` **Rysunek 5.** Taśmociąg tożsamości. Jedna nazwa ustalenia przechodzi przez każdy artefakt, a jej ścieżka znajduje się tylko w mapie śledzenia, więc zmianę nazwy poprawia się w jednym miejscu. Mapę w normalnym przepływie pracy utrzymują dwie czynności, a trzecia stoi z boku jako konserwacja. **Track** to rejestracja przyrostowa: faza zgłasza ustalenia, które zapisała, a silnik rejestruje nowe i podąża za zmienioną ścieżką w przypadku pozostałych, klasyfikując każde jako nowe, przeniesione lub niezmienione. Nigdy nie usuwa niczego, czego faza nie zgłosiła. **Untrack** wycofuje ustalenia zamknięte przez verify: w jednym deterministycznym przebiegu destyluje każde do jego wpisu w historii, usuwa całą jego sekcję z artefaktów, kasuje artefakt, którego ostatnie ustalenie zniknęło, i usuwa jego wpis śledzenia, więc agent nie robi niczego z tego ręcznie. Tam, gdzie deterministyczny przebieg nie może bezpiecznie dotrzeć, na przykład gdy nazwa wycofanego ustalenia wciąż jest cytowana w tekście innego ustalenia, zgłasza to miejsce agentowi, zamiast zgadywać edycję. Te dwie czynności wywołują fazy w trakcie pracy. **Repair** to czynność konserwacyjna: faza przekazuje jej pracę automatycznie, gdy jej własne uzgadnianie wykryje niespójność śledzenia (zapisaną ścieżkę, która już nie istnieje), a poza tym uruchamia się ją na żądanie. Wyrównuje całą mapę naraz, czytając każdy artefakt i bieżący kod, poprawiając ścieżki każdego elementu i ujawniając to, czego nie może rozstrzygnąć sama: sierotę (śledzony element, którego nie wymienia już żaden artefakt) albo kandydata na zmianę nazwy (element, którego ścieżki pasują do innej zgłoszonej nazwy). Repair to konserwacja, a nie szósta faza. Nie dotyka ani kodu użytkownika, ani artefaktów tekstowych, tylko śledzenia. Czyta kod źródłowy użytkownika z jednego jedynego powodu, aby poznać nową ścieżkę pliku o zmienionej nazwie, i nigdy nie tworzy treści dotyczących bezpieczeństwa. Ostatecznym arbitrem jest człowiek w tej jednej kwestii, której silnik odmawia zgadywać: czy element, który zniknął, został rozwiązany, czy tylko przemianowany. Lepiej zapytać niż zgadywać, bo błędnie usunięty element zrywa łańcuch. Metodologia stosuje własną dyscyplinę obronną wobec samej siebie. Deterministyczne silniki są wywoływane jako programy wiersza poleceń, a każde wejście jest przekazywane jako osobny argument procesu, co czyni je nieszkodliwym, więc wartość z cudzysłowami lub grawisami nigdy nie wstrzyknie się do polecenia. Nieznana kontrola kończy się błędem, zamiast odpowiadać, więc kontrola z literówką nigdy nie zostanie odczytana jako czysty wynik. SDH nie zwalnia własnej infrastruktury z zasady domyślnego bezpieczeństwa. --- ## XII. Nośnik: architektura niezależna od agenta jako dowód przenośności Aby SDH mogła być konwencją, którą przyjmują inni, nie może być związana z jednym agentem ani jednym stosem, dlatego jej nośnik rozdziela trzy obszary odpowiedzialności (Rysunek 6). Lagune pokazuje, że da się to osiągnąć. **Wartość bezpieczeństwa** powstaje raz i nie wie nic o tym, który agent ją uruchamia: to instrukcje faz i szablony, które wypełniają, katalog wiedzy oraz deterministyczne silniki. **Dostarczanie** to cienka warstwa: jej jedynym zadaniem jest przekazanie tej wartości danemu agentowi w formie i miejscu, których agent oczekuje, i nie zawiera własnej logiki bezpieczeństwa. **Stan projektu** należy do projektu: zasady bezpieczeństwa, artefakty faz, mapa śledzenia, wybrane kategorie i własne specjalizacje, commitowane i przeglądane jak każda inna część jego kodu. ```mermaid flowchart TB value["wartość bezpieczeństwa, napisana raz
instrukcje faz · szablony · katalog wiedzy · deterministyczne silniki
nie wie, który agent ją uruchamia"] delivery["dostarczanie
przekazuje tę wartość każdemu agentowi w oczekiwanej przez niego formie
nie zawiera logiki bezpieczeństwa"] agent["agent
uruchamia fazy"] project["stan projektu
commitowany razem z jego kodem
zasady bezpieczeństwa · artefakty faz · śledzenie · kategorie · własne specjalizacje"] value --> delivery --> agent agent -->|"czyta i zapisuje"| project ``` **Rysunek 6.** Nośnik niezależny od agenta. Wartość bezpieczeństwa powstaje raz, cienka warstwa dostarczania przekazuje ją każdemu agentowi, a stan pozostaje własnością projektu. Ponieważ dostarczanie nie zawiera logiki bezpieczeństwa, sposób jego budowy niczego w SDH nie zmienia. Nośnik może zbudować dostarczanie samodzielnie albo powierzyć je ekosystemowi, który już dystrybuuje skille dla agentów, tak jak robi to implementacja referencyjna, a fazy, ich artefakty i gwarancje pozostają takie same. Nic z tego nie jest też związane z konkretnym językiem ani środowiskiem uruchomieniowym. Implementacja referencyjna akurat powstała w jednym stosie technologicznym, ale metodologią jest granica między tymi obszarami odpowiedzialności, a nie narzędzia, którymi się je buduje. Ten sam projekt architektury można by odtworzyć w zupełnie innym języku, nie zmieniając tego, czym jest SDH. --- ## XIII. Studium przypadku: SDH od początku do końca > **Studium przypadku** > > **Defensywne utwardzanie funkcji przesyłania plików i panelu administracyjnego.** > **Kontekst:** mała aplikacja, która przyjmuje pliki przesyłane przez użytkowników i wyświetla ich listę na stronie administracyjnej. > **Wzorzec:** charter → detect (z wiedzą wczytywaną na żądanie, aktywowaną przez kontekst) → plan → harden → verify, z jednym zamknięciem i jedną rzeczywistą porażką. > **Wynik (możliwości):** jedno ryzyko zweryfikowane jako zamknięte i wycofane z łańcucha oraz jedno zabezpieczenie zweryfikowane jako _niezamknięte_ i odesłane do harden. Werdykt odzwierciedla kod, a nie rejestr. _To poglądowy przykład mechaniki metodologii, a nie badanie z pomiarami w terenie, i nie podaje żadnych wskaźników skuteczności._ Jeden ciągły przebieg pokazuje metodologię w działaniu, a nie tylko jej części. Rozszerzamy przykład przesyłania plików z `§IV` o aktywację wiedzy na żądanie i zamknięcie, a także uwzględniamy jedną rzeczywistą porażkę. 1. **charter** proponuje zasadę "Wszystkie dane wejściowe są niezaufane, dopóki nie przejdą walidacji" wraz z jej ryzykiem opisanym prostym językiem: niesprawdzone dane wejściowe to najczęstszy sposób na złamanie systemu. 2. **detect** skanuje trasę przesyłania i małą stronę administracyjną, która wyświetla listę przesłanych plików. Wykrywa ustalenie dotyczące przesyłania (handler ufa typowi MIME podanemu przez klienta). Strona administracyjna działa w przeglądarce, a ten kontekst rozpoznaje prompt na żądanie (`§VII`), więc detect wczytuje specjalizację dla tego kontekstu i zgłasza drugie ustalenie: miejsce, w którym nazwa pliku trafia na stronę jako znaczniki, a nie jako tekst, więc spreparowana nazwa może zostać wykonana jako skrypt w przeglądarce odwiedzającego. Specjalizacje, których kontekstu brak w tym zakresie, nigdy się nie wczytują, a każde pominięcie zostaje zapisane wraz z brakiem odczytanym z kodu. 3. **plan** nadaje poprawce przesyłania priorytet krytyczny i wiąże ją z zasadą: sprawdzać rzeczywisty typ i rozmiar pliku, zmieniać nazwę przy zapisie, przechowywać tam, gdzie kod nie może się uruchomić. Drugiej poprawce nadaje priorytet wysoki: wyświetlać nazwę pliku jako tekst, a nie jako znaczniki. 4. **harden** najpierw wdraża poprawkę przesyłania (najwyższy priorytet) i zapisuje ją jako Applied, a następnie drugą, również jako Applied. 5. **verify** czyta każde miejsce i zestawia kod z rejestrem. Zabezpieczenie przesyłania działa: handler rozpoznaje rzeczywisty typ na podstawie zawartości, egzekwuje limit rozmiaru i odrzuca resztę. Werdykt: Risk closed. Verify wycofuje ustalenie dotyczące przesyłania z całego łańcucha, a jego zdestylowane podsumowanie trafia do historii. Teraz rzeczywista porażka. Załóżmy, że druga poprawka fazy harden dodała bezpieczną funkcję pomocniczą do wyświetlania tekstu, ale pozostawiła stare wywołanie zapisujące znaczniki, wciąż osiągalne inną ścieżką kodu. Verify czyta stronę, widzi bezpieczną funkcję pomocniczą i widzi też, że niebezpieczna ścieżka nadal działa. Zabezpieczenie jest obecne, ale ryzyko nie jest zamknięte. Verify odmawia złagodzenia werdyktu, aby pasował do rejestru. Zwraca "Risk not closed", zapisuje lukę i odsyła z powrotem do harden. Zabezpieczenie, które nie usuwa ryzyka w pełni, nie przechodzi weryfikacji. To charakter metodologii w jednym przykładzie: wykrywanie dopasowane do kontekstu, uszeregowane według priorytetu poprawki powiązane z zasadami, staranne wdrażanie i weryfikacja, która raportuje rzeczywisty stan kodu niezależnie od rejestru. --- ## XIV. Kiedy stosować SDH i jakie ma granice SDH rzadko okazuje się nieproporcjonalnie ciężka, jak bywa z rozbudowanymi procesami, bo jest niezależna od stanu i możliwa do zamknięcia: skaluje się w dół do pojedynczego pliku i pojedynczego zagadnienia, a zamiast zostawiać stałe obciążenie, osiąga stan spoczynku. Jej granicą nie jest rozmiar projektu, lecz **głębokość zapewnienia bezpieczeństwa**. ```mermaid flowchart TB q1{"Czy kod robi cokolwiek istotnego dla bezpieczeństwa?
(dane wejściowe, uwierzytelnianie, dane, sekrety, wywołania zewnętrzne)"} q1 -->|nie| little["Tu SDH wnosi niewiele."] q1 -->|tak| q2{"Uruchom SDH. Czy obowiązują wymogi zgodności
albo istnieje osobny dział bezpieczeństwa?"} q2 -->|nie| baseline["SDH stanowi solidną podstawę."] q2 -->|tak| carrier["SDH jest ustrukturyzowanym nośnikiem:
wspiera przegląd i audyt ekspertów,
nie zastępuje ich."] ``` **Rysunek 7.** Kiedy stosować SDH. Rozgałęzienie zależy najpierw od znaczenia dla bezpieczeństwa, potem od głębokości zapewnienia bezpieczeństwa, nigdy od rozmiaru projektu. Gdzie SDH dochodzi do swojej granicy: zachowanie, które ujawnia się dopiero podczas działania systemu (verify czyta kod, nie uruchamia systemu), ryzyko zależne od konfiguracji lub środowiska, których agent nie może przeczytać, oraz konteksty o wysokiej stawce, w których przegląd ekspercki jest wymagany niezależnie od wszystkiego. W każdym z tych przypadków SDH nadal wnosi wartość jako ustrukturyzowany pierwszy przebieg, ale jest podłogą, a nie sufitem. > **Kluczowy wniosek** > > **Granica:** Granicą SDH jest głębokość zapewnienia bezpieczeństwa, a nie rozmiar projektu. Może służyć jako solidna podstawa niemal wszędzie i wspiera przegląd ekspercki tam, gdzie wymaga tego stawka, ale nie zastępuje testów działającego systemu ani osądu specjalisty od bezpieczeństwa. --- ## XV. Dyskusja: miejsce SDH, ograniczenia i to, czego SDH nie twierdzi SDH precyzyjnie określa swoje granice. ### Rozszerza, nie zastępuje SDH nie zastępuje specjalistów od bezpieczeństwa ani wyspecjalizowanych narzędzi Blue Team. Rozszerza wiedzę programisty (`§VI`). Właściwe jest wyważone twierdzenie: dobrze stosowana SDH **może** skutecznie zamykać rzeczywiste ryzyka, zwłaszcza w projektach, które w przeciwnym razie nie przeszłyby żadnego przeglądu bezpieczeństwa. Nie jest gwarancją i nie zastępuje przeglądu eksperckiego tam, gdzie wymaga go stawka. ### Wyłącznie obrona, z samej konstrukcji SDH audytuje, utwardza i weryfikuje. Nigdy nie tworzy narzędzi ofensywnych, exploitów ani technik unikania wykrycia w celu wyrządzenia szkody. Treści bezpieczeństwa o podwójnym zastosowaniu są dopuszczalne wyłącznie w jednoznacznie defensywnym, autoryzowanym ujęciu. To twarda granica, a nie preferencja. ### Weryfikacja jest merytoryczna, a nie na pokaz Verify weryfikuje, czytając kod i zestawiając go z rejestrem, a nie uruchamiając system. To weryfikacja statyczna: potwierdza, że zabezpieczenie jest obecne i poprawne w kodzie, i nie wykazuje, że wytrzyma atak w czasie działania. Dlatego "Cannot tell from the code" to uprawniony werdykt, a nie porażka ukryta za pozytywnym wynikiem. Gdy dowodu nie ma w kodzie (bo zależy od konfiguracji albo od ścieżki, której agent nie może przeczytać), SDH mówi to wprost, zamiast zgadywać. ### Determinizm ma określony zakres i jest nazwany Większość SDH opiera się na rozumowaniu agenta i to właśnie umożliwia dopasowanie do kontekstu. Determinizm jest zarezerwowany dla deterministycznych silników: narzędzi sprawdzających, które może zawierać specjalizacja (`§VII`), oraz silnika śledzenia (`§XI`). Dokument nie zaciera tej granicy. Tam, gdzie wynik jest deterministyczny, jest wynikiem programu. Tam, gdzie wynika z rozumowania, jest lekturą kodu dokonaną przez agenta, a ostatecznym arbitrem pozostaje użytkownik. ### Koszt i skala Pełne skanowanie zużywa dużo tokenów. Tryby ręczne (`§VI`, `§VIII`) istnieją między innymi po to, aby koszt był proporcjonalny do zagadnienia. ### Ostatecznym arbitrem jest użytkownik SDH prosi człowieka o rozstrzygnięcie, czy element zmienił nazwę, czy został rozwiązany, a zatwierdzanie zmian w kodzie pozostaje tam, gdzie użytkownik już sprawuje kontrolę nad swoim agentem: w trybie uprawnień, w którym go uruchamia. Metodologia proponuje i weryfikuje. Nie podważa decyzji człowieka. ### Zastrzeżenia i odpowiedzi Uczciwy sceptyk zgłosi kilka zastrzeżeń. Te merytoryczne warto przytoczyć w ich własnym brzmieniu. **"Czy to nie jest po prostu analizator statyczny z doczepionym modelem LLM?"** Nie. Analizator statyczny domyślnie uruchamia każdą regułę, jaką ma. SDH najpierw wykrywa, czym jest system, potem sięga po istotną wiedzę (`§II`, `§VII`) i _osadza_ deterministyczne narzędzie sprawdzające tylko tam, gdzie klasa ryzyka ma jasną procedurę decyzyjną. Rozumowanie wychodzi od kontekstu, a determinizm jest celowany. **"Czy to nie jest po prostu lista kontrolna bezpieczeństwa?"** Nie. SDH odwraca listę kontrolną: wykrywanie jest pierwsze, a wiedza jest wczytywana pod kątem tego, co projekt faktycznie robi (`§II`, `§VII`). **"Czy to nie jest po prostu SDD z nową etykietą dla bezpieczeństwa?"** Nie. SDH zapożycza strukturę SDD i odwraca jej umowę: autorytet, założenie co do stanu, warunek zakończenia i to, komu służy, są inne (`§X`). Ta sama maszyneria, przeciwny kierunek. **"Czy metoda oparta na rozumowaniu AI nie halucynuje po prostu ustaleń?"** Projekt metodologii ogranicza wymyślanie, zamiast ufać, że model będzie się dobrze zachowywał. Faza detect zapisuje tylko to, co potwierdza kod ("wykrywać, nie wymyślać", `§IV`), verify zestawia kod z rejestrem i może odpowiedzieć "Cannot tell from the code" (`§XV`), deterministyczne narzędzia sprawdzające ugruntowują przypadki rozstrzygalne (`§VII`), a ostatecznym arbitrem jest użytkownik. Nie czyni to agenta nieomylnym, ale czyni jego twierdzenia sprawdzalnymi. Uwaga o pozycjonowaniu. SDH jest tu zdefiniowana niezależnie od swojej implementacji referencyjnej. Pięć faz, zasady bezpieczeństwa ujęte od strony ryzyka, uzgadnianie zamiast dopisywania wraz z zamykalnością, wiedza w modelu promptu na żądanie, tryb prewencyjny, śledzenie z tożsamością opartą na nazwie i granica działania wyłącznie defensywnego stanowią metodologię. Inny zespół mógłby zaimplementować je w innym stosie i innym ekosystemie agentów, a wynik nadal byłby SDH. Lagune jest jej potwierdzeniem, a nie definicją. --- ## XVI. Pułapki i jak SDH strukturalnie ich unika Metodologie z tej rodziny mają wspólny, znany zestaw trybów awarii. Odpowiedź SDH na większość z nich jest strukturalna, wbudowana w przepływ pracy, a nie pozostawiona dyscyplinie. | Pułapka | Awaria | Strukturalna odpowiedź SDH | | ----------------------------------------- | -------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | | Gnijąca specyfikacja, nieaktualny backlog | Artefakty gromadzą martwe wpisy, którym nikt nie ufa | Uzgadnianie zamiast dopisywania (`§V`): każde uruchomienie ponownie sprawdza każdy wpis i usuwa to, co rozwiązane | | Fałszywa pewność, pozorny sukces | Zakłada się, że obecne zabezpieczenie zamyka ryzyko | Verify zestawia kod z rejestrem, więc "Risk not closed" i "Cannot tell" to pełnoprawne werdykty (`§IV`, `§XV`) | | Zalew listy kontrolnej | Ogólne punkty przesłaniają to jedno ryzyko, które ma znaczenie | Dopasowanie do kontekstu zamiast ogólników, z promptem na żądanie, który wczytuje tylko to, czego wymaga zakres (`§VII`) | | Uzależnienie od narzędzi | Metoda jest przyspawana do jednego dostawcy lub agenta | Nośnik niezależny od agenta: wartość bezpieczeństwa powstaje raz, a jej dostarczanie do każdego agenta nie zawiera logiki bezpieczeństwa (`§XII`) | | Nieskończona pętla | Backlog nigdy się nie zamyka, praca nigdy nie odpoczywa | Zamykalność i stan spoczynku (`§V`) | **Tabela 4.** Znane pułapki w tej rodzinie metodologii i strukturalna odpowiedź SDH na każdą z nich. Właśnie o to chodzi: nazwać pułapkę i wskazać mechanizm. To nie są ostrzeżenia, by uważać, tylko właściwości przepływu pracy. --- ## XVII. Dalsze prace Metodologia i jej implementacja referencyjna mają jasno określone kolejne kroki. - **Rozbudowa katalogu wiedzy:** Każde uzupełnienie zachowuje kształt z `§VII`: plik wiedzy i wiersz katalogu, bez nowego polecenia. Ścieżka po stronie użytkownika już tam istnieje: użytkownik destyluje własne specjalizacje na żądanie. Kolejne wbudowane języki, środowiska uruchomieniowe i klasy ryzyka, każde dołączające do jakiejś kategorii, to kierunek po stronie opiekunów projektu, a specjalizacje będą zapewne ewoluować. - **Więcej deterministycznych narzędzi sprawdzających:** Tam, gdzie klasa ryzyka ma jasną procedurę decyzyjną, specjalizacja może zawierać deterministyczne narzędzie sprawdzające, które osadza rozumowanie agenta w powtarzalnym werdykcie. Naturalnym kierunkiem jest objęcie tym kolejnych klas ryzyka. - **Ewaluacja empiryczna:** Najważniejszym otwartym pytaniem jest zmierzona skuteczność: jakość zamknięć i odsetek błędnych werdyktów w rzeczywistych bazach kodu. Badanie efektów SDH dla bezpieczeństwa to zadanie na przyszłość, a twierdzenia w tym dokumencie mają odpowiednio ograniczony zakres. --- ## XVIII. Podsumowanie Programowanie wspierane przez AI otworzyło lukę w bezpieczeństwie, której nie wypełnią ogólne listy kontrolne, bo ryzyko, które ma znaczenie, zależy od tego, co system faktycznie robi, a osoba, która go dostarcza, może nie wiedzieć, o co zapytać. SDH zamyka tę lukę dzięki dopasowanemu do kontekstu, wyłącznie defensywnemu i możliwemu do zamknięcia przepływowi pracy, w którym wiedza o bezpieczeństwie mieszka w metodologii i jej specjalizacjach wczytywanych na żądanie, czyli w podstawie, na której każdy użytkownik może budować. Wykrywa rzeczywisty kontekst systemu, przeprowadza triaż ryzyk, które ten kontekst niesie, starannie wdraża poprawki i weryfikuje każdą z nich, a potem wycofuje to, co zamknęła, więc każde ustalenie osiąga stan końcowy. Ta sama obrona działa też prewencyjnie podczas tworzenia nowej pracy, więc to, co przepływ pracy zamknął, pozostaje zamknięte. SDH dopasowuje się do każdego etapu rozwoju projektu w dowolnym stosie technologicznym i rozszerza wiedzę programisty, zamiast zastępować ludzi i narzędzia, które już tę pracę wykonują. Lagune stanowi jej potwierdzenie, ale wkładem jest konwencja. SDH jest proponowana jako podstawowy przepływ pracy bezpieczeństwa na erę programowania z AI, aby inni mogli ją przyjmować, udoskonalać i wdrażać we własnych stosach technologicznych. --- ## Bibliografia **[1]** D. B. Piskala, "Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants," arXiv preprint arXiv:2602.00180v1 [cs.SE], Jan. 2026. (Submitted to AIWare 2026.) [Online]. Available: https://arxiv.org/abs/2602.00180 **[2]** GitHub, "Spec Kit: Toolkit for Spec-Driven Development." [Online]. Available: https://github.com/github/spec-kit. Accessed: 2026. **[3]** Fission AI, "OpenSpec: Spec-Driven Development for AI Coding Assistants." [Online]. Available: https://github.com/Fission-AI/OpenSpec. Accessed: 2026. **[4]** B. Chess and G. McGraw, "Static Analysis for Security," IEEE Security & Privacy, vol. 2, no. 6, pp. 76-79, 2004, doi: 10.1109/MSP.2004.111. **[5]** OWASP Foundation, "Source Code Analysis Tools." [Online]. Available: https://owasp.org/www-community/Source_Code_Analysis_Tools. Accessed: 2026. **[6]** OWASP Foundation, "OWASP Top 10:2021." [Online]. Available: https://owasp.org/Top10/. Accessed: 2026. **[7]** MITRE, "Common Weakness Enumeration (CWE)." [Online]. Available: https://cwe.mitre.org/. Accessed: 2026. **[8]** N. Perry, M. Srivastava, D. Kumar, and D. Boneh, "Do Users Write More Insecure Code with AI Assistants?," in Proc. ACM SIGSAC Conf. on Computer and Communications Security (CCS '23), 2023, pp. 2785-2799, doi: 10.1145/3576915.3623157. [Online]. Available: https://arxiv.org/abs/2211.03622 **[9]** J. Davis and contributors, "safe-regex: Detect Possibly Catastrophic, Exponential-Time Regular Expressions." [Online]. Available: https://github.com/davisjam/safe-regex. Accessed: 2026. **[10]** D. Soshnikov, "regexp-tree: Regular Expressions Processor in JavaScript." [Online]. Available: https://github.com/DmitrySoshnikov/regexp-tree. Accessed: 2026. **[11]** T. Jenkinson, "redos-detector: A CLI and Library to Score How Vulnerable a Regex Pattern Is to ReDoS Attacks." [Online]. Available: https://github.com/tjenkinson/redos-detector. Accessed: 2026. --- ## Dodatek A: zasady w dosłownym brzmieniu 1. **Domyślnie bezpiecznie, prostym językiem, dla wszystkich na równi:** Każde ustawienie domyślne, komunikat i poprawka muszą być bezpieczne od razu i zrozumiałe dla każdego użytkownika, programisty czy nie. Żadna grupa użytkowników nie jest uprzywilejowana względem innej. 2. **Dopasowanie do kontekstu zamiast ogólników:** Każda faza musi zaczynać od kontekstu wykrytego w fazie detect i działać na tym, co system faktycznie robi. Przedkładaj rekomendacje właściwe dla tego kontekstu nad ogólne listy kontrolne. Wiedza o bezpieczeństwie mieszka w specyfikacji i jej specjalizacjach wczytywanych na żądanie i rozszerza wszystko, co wnosi użytkownik. 3. **Elastyczność zamiast sztywności:** SDH dopasowuje się do projektu i użytkownika. Zasady, wymagania i rekomendacje są punktami wyjścia, a nie stałą umową. Pozwól użytkownikowi dowolny element przeformułować, usunąć, dodać lub zawęzić. Elastyczność nigdy nie osłabia domyślnie bezpiecznej podstawy, pozwala jedynie użytkownikowi kształtować sposób jej stosowania. 4. **Uzgadnianie zamiast samego dopisywania:** Artefakty są żywymi dokumentami, a nie logami. Gdy faza uruchamia się ponownie, uzgadniaj każdy istniejący wpis z aktualnym stanem: zachowaj to, co nadal obowiązuje, przepisz to, co się zmieniło, i usuń to, co przestało mieć zastosowanie. Zamknięcie jest tym samym uzgadnianiem, doprowadzonym do końca. 5. **Wyłącznie obrona:** SDH audytuje, utwardza i weryfikuje. Nigdy nie tworzy narzędzi ofensywnych, exploitów do złośliwego użycia ani technik unikania wykrycia w celu wyrządzenia szkody. Treści bezpieczeństwa o podwójnym zastosowaniu są dopuszczalne wyłącznie w jednoznacznie defensywnym, autoryzowanym ujęciu. 6. **Najpierw specyfikacja, prowadzenie przez agenta, nastawienie na bezpieczeństwo:** Zbuduj przepływ pracy na sprawdzonej strukturze: szablony, polecenia, nadrzędne zasady bezpieczeństwa i agent, który uruchamia fazy. Odtwórz tę strukturę w celu defensywnym. --- # Słownik pojęć Lagune: SDH, charter, ustalenia i zabezpieczenia > Proste definicje wszystkich pojęć Lagune i metodologii Security-Driven Hardening: SDH, charter, detect, ustalenie, zabezpieczenie, harden, verify, wycofanie, zamykalność, specjalizacje, kategorie i katalog. Adres kanoniczny: https://lagune.ai/pl-PL/docs/references/glossary Język: pl-PL Oryginał: https://lagune.ai/docs/references/glossary Ostatnia aktualizacja: 2026-11-09 Wszystkie kluczowe pojęcia Lagune i metodologii Security-Driven Hardening, każde zdefiniowane raz, prostym językiem. ### Security-Driven Hardening (SDH) Metodologia, którą realizuje Lagune: dopasowana do kontekstu konwencja Blue Team, która wykrywa kontekst systemu, ustala priorytety ryzyk, jakie ten kontekst niesie, i prowadzi przez poprawki. Wiedza o bezpieczeństwie znajduje się w specyfikacji i jej specjalizacjach ładowanych na żądanie, więc programista i osoba, która nie programuje, korzystają z tego samego przepływu pracy. ### Lagune Referencyjna implementacja SDH: dziewięć poleceń, każde z szablonem, który wypełnia, za pomocą których agent AI utwardza bazę kodu. Każdy agent instaluje je własnym instalatorem wtyczek lub przez [**skills.sh**](https://www.skills.sh/wellwelwel/lagune), jak pokazuje [strona instalacji](https://lagune.ai/pl-PL/docs), a każdy deterministyczny krok wykonują za pomocą silnika Lagune. ### Charter Warstwa nadrzędna Lagune: zestaw reguł stawiających bezpieczeństwo na pierwszym miejscu, których musi przestrzegać każda kolejna faza. Traktuj je jak kontrolę na etapie kompilacji, która pilnuje poziomu bezpieczeństwa projektu. Są zapisane w pliku `.lagune/memory/charter.md`. ### Proces deweloperski Uniwersalne polecenie `/lagune`, które utwardza kod już w trakcie pisania. Przyjmuje dowolny prompt na dowolnym etapie, buduje to, o co prosisz, i zanim odda wynik, utwardza go bezpiecznymi ustawieniami domyślnymi, kierując się zasadami bezpieczeństwa, jeśli istnieją. Niczego nie zapisuje w śledzeniu Lagune, więc jego jedynym produktem jest utwardzony kod. Razem z fazą charter (przed nim) i przepływem pracy Blue Team (po nim) tworzy sposób, w jaki Lagune chroni projekt podczas jego budowania. ### Przepływ pracy Blue Team Pięciofazowy audyt stanowiący rdzeń Lagune: charter, detect, plan, harden, verify. Każda faza opiera się na poprzedniej. "Blue Team" to w bezpieczeństwie tradycja obrońców, w przeciwieństwie do ofensywnego zespołu Red Team. ### Ustalenie Jedno wykryte ryzyko. Każde ustalenie mówi, czego dotyczy, dlaczego ma znaczenie i na jakim dowodzie w kodzie się opiera. Ustalenie to pojedyncza śledzona jednostka, którą dalej przejmują fazy plan, harden i verify, rozpoznawana po nazwie w każdym artefakcie. ### Zabezpieczenie Środek bezpieczeństwa wdrożony, aby zamknąć ryzyko. Faza harden wdraża zabezpieczenia, a verify wykazuje, że działają. Lagune nigdy nie osłabia zabezpieczenia tylko dlatego, że prosi o to prompt. ### Detect Faza, która czyta kod i mapuje, co robi system oraz gdzie kryją się ryzyka. Jej nadrzędna zasada brzmi: wykrywać, nie wymyślać. Zapisuje tylko to, co znajduje potwierdzenie w kodzie. ### Harden Jedyna faza, która zmienia twój kod. Wdraża poprawki z planu po jednej i zapisuje każdą jako Applied, Partial lub Blocked. Applied nie oznacza jeszcze, że działanie poprawki wykazano. ### Verify Faza, która wykazuje, że każda wdrożona poprawka działa, czytając kod i zestawiając go z tym, co zapisała faza harden. Zwraca jeden z trzech werdyktów: Risk closed, Risk not closed albo Cannot tell from the code. ### Wycofanie Gdy verify wykaże, że ryzyko jest zamknięte, ustalenie zostaje wycofane: za twoim potwierdzeniem znika z całego łańcucha, więc nie jest już przetwarzane od nowa. ### Zamykalność Właściwość, dzięki której praca nad bezpieczeństwem ma stan końcowy. Ponieważ ustalenie, którego zamknięcie wykazano, zostaje wycofane, przepływ pracy może przejść w stan spoczynku i otwiera się ponownie dopiero wtedy, gdy zmieni się kod. W SDH bezpieczeństwo jest możliwe do zamknięcia, a nie stanowi nieskończonej pętli. ### Silnik Pakiet `lagune` w **npm**, za pomocą którego polecenia wykonują przez `npx` każdy deterministyczny krok: hooki, katalog i kategorie. ### Specjalizacja Skoncentrowany, niezależny od języka moduł wiedzy o bezpieczeństwie, ładowany tylko na żądanie, nigdy domyślnie. Specjalizacja nie jest poleceniem. Załaduj ją do dowolnego promptu poleceniem silnika `read catalog `, na przykład `npx lagune read catalog regex`. ### Kategoria Nazwana grupa wbudowanych specjalizacji, od `owasp` po te dla konkretnych języków, takie jak `javascript`, `python`, `go` i `rust`. Kategorie, z których korzysta projekt, zapisane w pliku `.lagune/configs.json`, decydują o tym, które wbudowane specjalizacje trafiają do jego katalogu. Dopóki żadna nie jest zapisana, projekt korzysta tylko z kategorii `owasp`. ### Katalog Zbiór specjalizacji, z których korzysta projekt: wbudowane specjalizacje jego kategorii oraz jego własne, napisane za pomocą polecenia `/lagune-specialize`. Polecenie silnika `read catalog` je wypisuje, a fazy dopasowują je do kodu. ### Prompt na żądanie Zasada, zgodnie z którą odpowiednią wiedzę o bezpieczeństwie dobiera się do tego, czym projekt faktycznie jest, zamiast domyślnie uruchamiać każdą kontrolę. ### Tożsamość oparta na nazwie Model śledzenia w Lagune: nazwa każdego ustalenia, zapisana identycznie jako tytuł sekcji w każdym artefakcie, jest jego tożsamością w całym łańcuchu. Mapa śledzenia (`.lagune/tracking.json`) przechowuje wyłącznie dane śledzenia, nigdy tekst opisowy. ## Najczęściej zadawane pytania ### Czym jest Security-Driven Hardening (SDH)? SDH to dopasowana do kontekstu metodologia bezpieczeństwa w duchu Blue Team. Wykrywa kontekst systemu, ustala priorytety ryzyk, jakie ten kontekst niesie, i prowadzi przez poprawki, opisując każde ustalenie prostym językiem. Lagune jest jej referencyjną implementacją. ### Czym są zasady bezpieczeństwa (charter) w Lagune? Zasady bezpieczeństwa (charter) to warstwa nadrzędna Lagune: reguły stawiające bezpieczeństwo na pierwszym miejscu, których musi przestrzegać każda kolejna faza. Są zapisane w pliku .lagune/memory/charter.md. ### Co oznacza wycofanie ustalenia? Gdy verify wykaże, że ryzyko jest zamknięte, ustalenie zostaje wycofane: za twoim potwierdzeniem znika z całego łańcucha, więc nie jest już przetwarzane od nowa. --- # Schemat konfiguracji > JSON Schema konfiguracji projektu Lagune do autouzupełniania i walidacji w edytorze, zgodny z aktualną wersją Lagune albo przypięty do konkretnej wersji. Adres kanoniczny: https://lagune.ai/pl-PL/docs/references/configs-schema Język: pl-PL Oryginał: https://lagune.ai/docs/references/configs-schema Ostatnia aktualizacja: 2026-11-09 Plik `.lagune/configs.json` zapisuje [**kategorie**](https://lagune.ai/pl-PL/docs/categories), z których korzysta projekt, indeksuje jego własne [**specjalizacje**](https://lagune.ai/pl-PL/docs/catalog) i określa, co pomijają [**narzędzia sprawdzające**](https://lagune.ai/pl-PL/docs/hooks/configure). Dzięki jego schematowi JSON Schema edytor podpowiada każde pole i zgłasza literówkę lub nieznaną kategorię, gdy edytujesz plik. ## Aktualny schemat Za każdym razem, gdy **Lagune** zapisuje plik i nie znajduje w nim `$schema`, ustawia w nim adres aktualnego schematu: ```json { "$schema": "https://lagune.ai/schemas/configs.json", "categories": ["owasp", "javascript"] } ``` Ten adres zawsze odpowiada aktualnej wersji **Lagune**. Plik zapisany przed wersją **Lagune** 0.16.0 dostanie go przy najbliższej zmianie, a do tego czasu każda faza zwraca na to uwagę. ## Przypinanie wersji Każde wydanie **Lagune** od wersji 0.16.0 zawiera schemat w takiej postaci, jaką miał w tej wersji, opublikowany w **npm** i udostępniany przez **jsDelivr**. Aby przypiąć wersję, wpisz ją po `lagune@` w adresie `$schema`: ```json { "$schema": "https://cdn.jsdelivr.net/npm/lagune@0.16.0/schemas/configs.json" } ``` Jako wersję możesz podać dowolny zakres semver: | Wersja | Schemat | | ------------------- | -------------------------------- | | `0.16.0` | Z wersji 0.16.0 | | `0.16.x` lub `0.16` | Z najnowszego wydania serii 0.16 | | `0.x` lub `0` | Z najnowszego wydania serii 0.x | | `latest` | Z najnowszego wydania | ## Najczęściej zadawane pytania ### Czy Lagune potrzebuje schematu? Nie. Schemat pomaga tylko edytorowi, a Lagune czyta plik tak samo z $schema i bez niego. ### Czy Lagune nadpisze przypięty schemat? Nie. Lagune zapisuje $schema tylko wtedy, gdy plik go nie zawiera, i zachowuje każdy adres, który ustawisz. ### Kiedy warto przypiąć wersję? Gdy projekt korzysta z konkretnej wersji Lagune, aby edytor walidował plik zgodnie z tym, co akceptuje ta wersja. --- # Lagune vs. Deepsec: Dwa podejścia do bezpieczeństwa oparte na AI w bezpośrednim porównaniu > Porównanie Lagune i Deepsec firmy Vercel: sposób działania, cykl życia, wykrywanie, koszty, ustalenia i zamykanie. Adres kanoniczny: https://lagune.ai/pl-PL/docs/references/deepsec Język: pl-PL Oryginał: https://lagune.ai/docs/references/deepsec Ostatnia aktualizacja: 2026-11-09 [Lagune](https://github.com/wellwelwel/lagune) i [Deepsec](https://github.com/vercel-labs/deepsec) (`v2.2.1`) to dwie defensywne odpowiedzi na ten sam problem: bezpieczeństwo w erze programowania wspomaganego przez AI. Ich założenia, początek, środek i koniec oraz sposób, w jaki każde z nich prezentuje się użytkownikowi, celowo się różnią, nawet tam, gdzie ich mechanika się pokrywa. **Wskazówka** Czy Deepsec był inspiracją dla Lagune? Nie. Lagune napisano od zera, a inspiracją były Spec-Driven Development i Security Hardening. Oba projekty rozwijano niezależnie, a to porównanie ma pomóc użytkownikom zrozumieć różnice między nimi. ## W skrócie | Aspekt | Lagune | Deepsec | | ------------------------- | ---------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | | Rodzaj | Metodologia (SDH) z referencyjną implementacją | Produkt: skaner podatności oparty na agentach AI | | Środek ciężkości | Zasady bezpieczeństwa i wiedza ładowana na żądanie kierują agentem, a oparciem są deterministyczne hooki | Szeroka sieć wyrażeń regularnych zasila obowiązkowe dochodzenie AI | | Co powstaje | Utwardzony kod, wykazania i śledzony łańcuch ustaleń | Raport z ustaleniami po selekcji, uporządkowany według poziomu zagrożenia | | Zmienia twój kod | Tak: `harden` edytuje twój kod | Nie: tylko analiza statyczna, zwraca ustalenia i tekst rekomendacji | | Środowisko uruchomieniowe | Działa na agencie i modelu, z których już korzystasz, w dowolnej klasie modeli | Uruchamia własny potok modeli, domyślnie z modelem klasy frontier | | Pierwsze kroki | Jedna instalacja wtyczki lub `npx skills add`, potem sterowanie zwykłym językiem, bez stawiania nowego narzędzia | Utworzenie obszaru roboczego `.deepsec/`, instalacja zależności i dodanie klucza do modelu | ## Jak to działa Lagune stawia na pierwszym miejscu agenta: to on kieruje pracą, pobiera na żądanie wiedzę dopasowaną do tego, czym jest kod, i przekazuje deterministycznym hookom tę część pracy, którą da się rozstrzygnąć. Deepsec stawia na pierwszym miejscu determinizm: szerokie skanowanie zgłasza kandydatów, którzy wskazują obowiązkowemu modelowi, co ma zbadać i ocenić. | Aspekt | Lagune | Deepsec | | ------------------- | ------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- | | Kolejność | Zasady bezpieczeństwa i dopasowana wiedza kierują agentem, który deleguje zadania hookom, a resztę ocenia sam | Matchery zgłaszają kandydatów, a model bada i ocenia każdego z nich | | Rola determinizmu | Hooki dla wielu języków, które zwracają werdykt lub naprowadzają agenta, połączone z wiedzą z kategorii | Matchery zgłaszające kandydatów do oceny przez obowiązkowy model | | Proces deweloperski | `/lagune` buduje bezpiecznie na bieżąco, w trakcie pisania kodu | Przegląda kod, ale go nie pisze | | Przepływ audytu | `charter` → `detect` → `plan` → `harden` → `verify` | `scan` → `process` → `triage` → `revalidate` → `report` | | Zadanie AI | Wnioskować na podstawie wiedzy, wdrożyć poprawkę i wykazać, że działa | Zbadać każdego kandydata i zgłosić ustalenia | ## Cykl życia Lagune działa przed napisaniem kodu, w trakcie i po nim. Deepsec przegląda repozytorium, gdy kod już istnieje. | Moment | Lagune | Deepsec | | --------------------- | ------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | Zanim powstanie kod | `charter` tworzy politykę bezpieczeństwa na podstawie deklarowanych zamiarów | Zaczyna od istniejącego kodu: `init` wymaga folderu | | Podczas budowania | `/lagune` buduje na bieżąco, domyślnie bezpiecznie, nie zostawiając żadnego artefaktu | Przegląda po zbudowaniu, nie w trakcie | | Na istniejącym kodzie | `detect` → `plan` → `harden` → `verify` | `scan` → `process`, główny przepływ | | Ciągły przegląd | Ponowne uruchamianie faz dla danego zakresu, bez gotowej bramki CI | Przyrostowe ponowne skanowanie, `process --diff` jako bramka CI oparta na kodzie wyjścia | ## Warstwa wykrywania Obie deterministyczne warstwy są swoimi przeciwieństwami: jedna rozstrzyga, druga zgłasza. | Aspekt | Lagune | Deepsec | | --------------- | -------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | | Grupowanie | Hooki i specjalizacje pogrupowane w kategorie | Matchery dla poszczególnych wzorców lub frameworków | | Wyjście | Dosłowny werdykt (finding / review / advisory) i etykieta klasyfikacji | Kandydat bez werdyktu (slug, linie, fragment kodu, dopasowany wzorzec) | | Dostrojenie | Precyzja: rozpoznaje komentarze, ma osłony dla symboli zastępczych i okna wyszukiwania | Czułość (recall): szerokie sieci, a AI odsiewa potem fałszywe alarmy | | Głębokość | Głębsza w klasach podatności wspólnych dla obu | Szersza, ale płytsza w klasach podatności wspólnych dla obu | | Fałszywe alarmy | Ograniczane już u źródła, potem oceniane w kontekście | Celowo generowane w nadmiarze, potem odsiewane przez przebieg `revalidate` | ## Wiedza i ocena Oba narzędzia niosą wiedzę o bezpieczeństwie, której nie oddadzą same wyrażenia regularne. Różnią się tym, gdzie ta wiedza się znajduje i kto może ją kształtować. | Aspekt | Lagune | Deepsec | | ------------------ | ----------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | | Forma | Edytowalne moduły w Markdownie, z których kilka wspiera deterministyczny hook | Krótki prompt i wskazówki dla poszczególnych technologii, oparte na własnej wiedzy modelu | | Dobór | Dopasowana do kodu, ładowana tylko wtedy, gdy występuje jej kontekst | Trafia do każdej partii AI, a do tego dochodzą wskazówki dla wykrytej technologii | | Kto ją tworzy | Użytkownik edytuje moduły i dodaje nowe za pomocą `specialize` | Opiekun projektu odpowiada za prompt, a użytkownik wypełnia plik `INFO.md` | | Gdzie zapada ocena | Hooki rozstrzygają poziom bazowy, a resztę agent ocenia na podstawie wiedzy | Centralnie: jeden procesor AI ocenia każdego kandydata | | Ponowne użycie | Jeden moduł kieruje zarówno fazą `detect`, jak i `verify` | Jeden prompt steruje jedynym etapem `process` | ## Ustalenia i zamykanie Najbardziej różnią się tym, czym staje się ustalenie po rozwiązaniu. | Aspekt | Lagune | Deepsec | | ---------------------- | --------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | | Poziom zagrożenia | Wynik CVSS v4.0 skorygowany o ekspozycję i stawkę | Poziom zagrożenia nadany przez AI oraz selekcja P0 / P1 / P2 według możliwości wykorzystania i skutków | | Werdykty | Risk closed, Risk not closed lub Cannot tell from the code | true-positive, false-positive, fixed, uncertain, accepted-risk, duplicate | | Trwałość | Łańcuch roboczy jest uzgadniany, a zamknięte ustalenia są destylowane do historii | Rekordy dla poszczególnych plików, wyłącznie dopisywane, nic nie jest usuwane | | Stan końcowy | Możliwy do zamknięcia: wykazane ustalenie zostaje wycofane, a łańcuch może przejść w stan spoczynku | Każde ustalenie zostaje na zawsze, a po rozwiązaniu znika z widoków | | Szczegółowość historii | Zwięzłe podsumowanie tego, czym było ryzyko | Pełny ślad werdyktów, łącznie z tym, jak je naprawiono | ## Koszt | Aspekt | Lagune | Deepsec | | ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Deterministyczna podstawa | Bezpłatna: hooki działają bez AI i bez klucza, a mimo to zwracają werdykty | Bezpłatna: `scan` działa bez AI, ale sam nie zwraca werdyktów | | Typowy rachunek | Wliczony w agenta, z którego już korzystasz: nawet 0 USD przy modelu lokalnym, w cenie planu, który już masz, albo za iterację przy korzystaniu przez API | [Od około 25 do 1200 USD za uruchomienie dla 100 do 2000 plików, więcej przy większej skali](https://github.com/vercel-labs/deepsec/blob/f75a16803ec5250938bacfe41571d929e8564f45/docs/getting-started.md#run-the-ai-investigation) | | Najtańsza droga | Każdy model, także darmowy lokalny, domyka cykl | Istnieją tańsze płatne klasy modeli, ale ustalenia wymagają płatnego etapu AI | ## Rozszerzalność i zarządzanie Każde z nich otwiera warstwę, którą drugie trzyma zamkniętą. | Aspekt | Lagune | Deepsec | | ---------------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------------- | | Co rozszerzasz | Edytujesz moduły lub dodajesz nowe przez `specialize` | Dodajesz matchery, agentów, powiadomienia i przypisanie odpowiedzialności | | Warstwa zasad | Zasady bezpieczeństwa obowiązują w każdej fazie i są wersjonowane | Konfiguracja jest operacyjna (matchery, modele, ścieżki) | | Nadpisywanie po nazwie | Dopracowany moduł przesłania wbudowany | Przy kolizji slugów matcherów wygrywa twój matcher | ## Interfejsy Deepsec dostarcza materiały dla zespołu bezpieczeństwa. Lagune pokazuje podgląd na żywo osobie, która z niego korzysta. | Aspekt | Lagune | Deepsec | | --------------------- | ----------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | | Interfejs dla ludzi | Lokalny dashboard na żywo z całym łańcuchem, w prostym języku | Pliki z raportem, eksportem, metrykami i komentarzami do PR, a do tego strona z dokumentacją | | Rozliczalność | Pokazuje pliki i zastosowane specjalizacje | Wskazuje sugerowaną osobę odpowiedzialną: dyżurnego, menedżera lub autora commita | | Odtwarzalne wykazanie | `prove` pisze uruchamialne testy i biuletyn bezpieczeństwa do odpowiedzialnego ujawnienia | Z założenia pozostaje statyczny i nigdy nie uruchamia badanego kodu | | Samoobrona narzędzia | Utwardza lokalne API zapisu w dashboardzie | Utwardza własne wykonywanie AI przed niezaufanym kodem badanego projektu | ## Skala i wdrożenie | Aspekt | Lagune | Deepsec | | ------------------- | -------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- | | Instalacja | Dziewięć poleceń z wtyczki twojego agenta lub z CLI **skills**, bez generowania czegokolwiek w projekcie | Obszar roboczy `.deepsec/` z własnym pakietem i zależnościami | | Kierunek skalowania | Zawęża się do dowolnego wycinka, kontekstu, od jednego pliku po cały projekt | Przeszukuje całe repozytoria, aż po duże monorepozytoria | | Dystrybucja | Tylko lokalnie, jedyny serwer nasłuchuje na interfejsie loopback | Opcjonalny podział pracy między maszyny wirtualne workerów Vercel Sandbox | ## Doświadczenie użytkownika Jak każde z nich traktuje osobę, która z niego korzysta: czego wymaga pierwsze uruchomienie i jak operator nim kieruje. ### Pierwsze uruchomienie Lagune działa przez agenta, którego masz już otwartego. Deepsec najpierw przygotowuje własny obszar roboczy i dostęp do modelu. | Aspekt | Lagune | Deepsec | | ---------------------- | ---------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | | Pierwsze polecenie | Instalacja wtyczki lub `npx skills add wellwelwel/lagune`, a potem `/lagune-*` w agencie | `npx deepsec init`, potem `cd .deepsec`, `pnpm install`, `scan`, `process` | | Dane uwierzytelniające | Bez osobnego klucza, korzysta z twojego obecnego agenta | Klucz do modelu (np. AI Gateway, 12-godzinny token OIDC Vercel albo token Anthropic) | ### Sterowanie Oba przyjmują wskazówki. Lagune w każdej fazie odczytuje, jaką formę mają dane wejściowe. Deepsec zawęża zbiór plików, na którym przebiega to samo dochodzenie. | Aspekt | Lagune | Deepsec | | -------------------- | ------------------------------------------------------------------------------------------------ | ------------------------------------------------------------ | | Cały projekt | Faza bez danych wejściowych skanuje cały zakres | `scan` i `process` przeszukują repozytorium | | Wycinek | Każdą fazę można zawęzić do wskazanych plików lub folderów | `--files`, `--files-from` lub `--diff` zawężają uruchomienie | | Zagadnienie | Fazę można zawęzić do opisanego problemu | Prompt dochodzenia jest stały | | Przedział priorytetu | Fazy `harden` i `verify` można zawęzić do poziomu krytycznego, wysokiego, średniego lub niskiego | Ustalenia są oznaczane po uruchomieniu | | Pojedyncza wartość | Hook ocenia bezpośrednio jeden fragment kodu, wzorzec lub adres URL (`--pattern`, `--url`) | Jednostką pracy jest plik | ## Najczęściej zadawane pytania ### Czym Lagune różni się od Deepsec? Lagune stawia na pierwszym miejscu agenta i działa przed napisaniem kodu, w trakcie i po nim: ustala zasady, zanim powstanie kod, utwardza go na bieżąco podczas budowania oraz audytuje, utwardza i weryfikuje kod, który już istnieje. Deepsec stawia na pierwszym miejscu determinizm: szerokie skanowanie wyrażeniami regularnymi zasila obowiązkowe dochodzenie prowadzone przez model klasy frontier, które przegląda istniejący kod i zgłasza ustalenia, nie zmieniając go. ### Czy z któregoś z nich można korzystać za darmo? Cały przepływ pracy Lagune może działać za 0 USD na darmowym modelu lokalnym, a jego deterministyczne hooki zwracają werdykty zupełnie bez AI. Skanowanie Deepsec jest bezpłatne, ale nie zwraca werdyktów, więc każde ustalenie wymaga płatnego etapu AI. ### Czy któreś z nich zmienia mój kod? Lagune tak: faza harden wdraża poprawki w twoim kodzie. Deepsec nie: wykonuje wyłącznie analizę statyczną i zwraca ustalenia oraz tekst rekomendacji, które osoba lub agent wdraża osobno. --- # Źródła OWASP > Skąd pochodzi wiedza wbudowanych specjalizacji OWASP, przyporządkowana do kanonicznych stron OWASP z opisami ataków i Cheat Sheets. Adres kanoniczny: https://lagune.ai/pl-PL/docs/references/owasp-sources Język: pl-PL Oryginał: https://lagune.ai/docs/references/owasp-sources Ostatnia aktualizacja: 2026-11-09 Ten dokument przyporządkowuje każdy **atak** (`www-community`) i każdy **Cheat Sheet** (`CheatSheetSeries`) OWASP do kategorii bezpieczeństwa, z linkiem do jego kanonicznej, publicznej strony. W obrębie kategorii równoważne pozycje dzielą jeden wiersz listy kontrolnej: ataki i Cheat Sheets dotyczące tego samego ryzyka stoją obok siebie, rozdzielone przecinkami. Pozycje bez bezpośredniego odpowiednika mają własny wiersz. - Wszystkie zasługi należą do OWASP. Ataki znajdziesz pod adresem `https://owasp.org/www-community/attacks/`, a Cheat Sheets pod adresem `https://cheatsheetseries.owasp.org/cheatsheets/.html`. --- ## 1. Ataki typu injection (ogólne) - [x] [Code Injection](https://owasp.org/www-community/attacks/Code_Injection), [Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html), [Injection Prevention in Java](https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_in_Java_Cheat_Sheet.html) (interpreter) - [x] [Direct Dynamic Code Evaluation (Eval Injection)](https://owasp.org/www-community/attacks/Direct_Dynamic_Code_Evaluation_Eval_Injection) (interpreter) - [x] [Function Injection](https://owasp.org/www-community/attacks/Function_Injection) (interpreter) - [x] [Resource Injection](https://owasp.org/www-community/attacks/Resource_Injection) (network) - [x] [Special Element Injection](https://owasp.org/www-community/attacks/Special_Element_Injection) (interpreter) - [x] [Custom Special Character Injection](https://owasp.org/www-community/attacks/Custom_Special_Character_Injection) (interpreter) - [x] [Comment Injection Attack](https://owasp.org/www-community/attacks/Comment_Injection_Attack) (interpreter) - [x] [Parameter Delimiter](https://owasp.org/www-community/attacks/Parameter_Delimiter) (interpreter) - [x] [Server-Side Includes (SSI) Injection](https://owasp.org/www-community/attacks/Server-Side_Includes_%28SSI%29_Injection) (interpreter) - [x] [Input Validation](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html), [Bean Validation](https://cheatsheetseries.owasp.org/cheatsheets/Bean_Validation_Cheat_Sheet.html) (interpreter) --- ## 2. Injection w SQL i bazach danych - [x] [SQL Injection](https://owasp.org/www-community/attacks/SQL_Injection), [SQL Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html), [Query Parameterization](https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html) (sql) - [x] [Blind SQL Injection](https://owasp.org/www-community/attacks/Blind_SQL_Injection) (sql) - [x] [SQL Injection Bypassing WAF](https://owasp.org/www-community/attacks/SQL_Injection_Bypassing_WAF) (sql) - [x] [RSQL Injection](https://owasp.org/www-community/attacks/RSQL_Injection) (interpreter) - [x] [Database Security](https://cheatsheetseries.owasp.org/cheatsheets/Database_Security_Cheat_Sheet.html) (sql) - [x] [NoSQL Security](https://cheatsheetseries.owasp.org/cheatsheets/NoSQL_Security_Cheat_Sheet.html) (interpreter) --- ## 3. Command injection w systemie operacyjnym - [x] [Command Injection](https://owasp.org/www-community/attacks/Command_Injection), [OS Command Injection Defense](https://cheatsheetseries.owasp.org/cheatsheets/OS_Command_Injection_Defense_Cheat_Sheet.html) (interpreter) --- ## 4. Injection w LDAP, XPath i XML - [x] [LDAP Injection](https://owasp.org/www-community/attacks/LDAP_Injection), [LDAP Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.html) (interpreter) - [x] [XPATH Injection](https://owasp.org/www-community/attacks/XPATH_Injection) (interpreter) - [x] [Blind XPath Injection](https://owasp.org/www-community/attacks/Blind_XPath_Injection) (interpreter) - [x] [XML External Entity (XXE) Prevention](https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html), [XML Security](https://cheatsheetseries.owasp.org/cheatsheets/XML_Security_Cheat_Sheet.html) (xml) --- ## 5. Cross-Site Scripting (XSS) - [x] [Cross Site Scripting (XSS)](https://owasp.org/www-community/attacks/Cross-site-Scripting-%28XSS%29), [Cross Site Scripting Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html), [XSS Filter Evasion](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html) (browser) - [x] [DOM Based XSS](https://owasp.org/www-community/attacks/DOM_Based_XSS), [DOM based XSS Prevention](https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html), [DOM Clobbering Prevention](https://cheatsheetseries.owasp.org/cheatsheets/DOM_Clobbering_Prevention_Cheat_Sheet.html) (browser) - [x] [Reflected DOM Injection](https://owasp.org/www-community/attacks/Reflected_DOM_Injection) (browser) - [x] [XSS in Converting File Content to Text](https://owasp.org/www-community/attacks/XSS_in_Converting_File_Content_to_Text) (browser) - [x] [XSS in subtitle](https://owasp.org/www-community/attacks/Xss_in_subtitle) (browser) - [x] [Cross Frame Scripting](https://owasp.org/www-community/attacks/Cross_Frame_Scripting) (browser) - [x] [Cross Site Tracing](https://owasp.org/www-community/attacks/Cross_Site_Tracing) (browser) - [x] [Content Security Policy](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html) (browser) --- ## 6. Cross-Site Request Forgery (CSRF) i clickjacking - [x] [Cross Site Request Forgery (CSRF)](https://owasp.org/www-community/attacks/cross-site-request-forgery), [XSRF](https://owasp.org/www-community/attacks/XSRF), [Cross-Site Request Forgery Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html) (http-request) - [x] [Clickjacking](https://owasp.org/www-community/attacks/Clickjacking), [Clickjacking Defense](https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet.html) (browser) - [x] [Cross Site History Manipulation (XSHM)](https://owasp.org/www-community/attacks/Cross_Site_History_Manipulation_%28XSHM%29) (browser) - [x] [Form action hijacking](https://owasp.org/www-community/attacks/Form_action_hijacking) (network) - [x] [Reverse Tabnabbing](https://owasp.org/www-community/attacks/Reverse_Tabnabbing) (browser) --- ## 7. Przekierowania i przekazywanie żądań - [x] [Open Redirect](https://owasp.org/www-community/attacks/open_redirect), [Unvalidated Redirects and Forwards](https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html) (network) - [x] [Execution After Redirect (EAR)](https://owasp.org/www-community/attacks/Execution_After_Redirect_%28EAR%29) (browser) --- ## 8. Kontrola dostępu i autoryzacja - [x] [Insecure Direct Object Reference (IDOR)](https://owasp.org/www-community/attacks/insecure_direct_object_reference), [Insecure Direct Object Reference Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html) (access-control) - [x] [Forced browsing](https://owasp.org/www-community/attacks/Forced_browsing) (access-control) - [x] [Web Parameter Tampering](https://owasp.org/www-community/attacks/Web_Parameter_Tampering) (access-control) - [x] [Setting Manipulation](https://owasp.org/www-community/attacks/Setting_Manipulation) (access-control) - [x] [Authorization](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) (access-control) - [x] [Transaction Authorization](https://cheatsheetseries.owasp.org/cheatsheets/Transaction_Authorization_Cheat_Sheet.html) (access-control) - [x] [Mass Assignment](https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html) (access-control) - [x] [Multi-Tenant Application Security](https://cheatsheetseries.owasp.org/cheatsheets/Multi_Tenant_Security_Cheat_Sheet.html) (access-control) --- ## 9. Uwierzytelnianie i dane uwierzytelniające - [x] [Brute Force Attack](https://owasp.org/www-community/attacks/Brute_force_attack), [Password Spraying Attack](https://owasp.org/www-community/attacks/Password_Spraying_Attack), [Bot Management and Anti-Automation](https://cheatsheetseries.owasp.org/cheatsheets/Bot_Management_and_Anti-Automation_Cheat_Sheet.html) (credential-endpoint) - [x] [Credential stuffing](https://owasp.org/www-community/attacks/Credential_stuffing), [Credential Stuffing Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.html) (credential-endpoint) - [x] [Qrljacking](https://owasp.org/www-community/attacks/Qrljacking) (federation) - [x] [Authentication](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html), [Multifactor Authentication](https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html) (access-control) - [x] [Password Storage](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) (access-control) - [x] [Forgot Password](https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html), [Choosing and Using Security Questions](https://cheatsheetseries.owasp.org/cheatsheets/Choosing_and_Using_Security_Questions_Cheat_Sheet.html) (access-control) - [x] [Email Validation and Verification in Identity Systems](https://cheatsheetseries.owasp.org/cheatsheets/Email_Validation_and_Verification_Cheat_Sheet.html) (access-control) --- ## 10. Zarządzanie sesją - [x] [Session fixation](https://owasp.org/www-community/attacks/Session_fixation), [Session hijacking attack](https://owasp.org/www-community/attacks/Session_hijacking_attack), [Session Prediction](https://owasp.org/www-community/attacks/Session_Prediction), [Session Management](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html) (access-control) - [x] [Cookie Theft Mitigation](https://cheatsheetseries.owasp.org/cheatsheets/Cookie_Theft_Mitigation_Cheat_Sheet.html) (access-control) --- ## 11. Federacja tożsamości (OAuth, SAML i JWT) - [x] [OAuth 2.0 Protocol](https://cheatsheetseries.owasp.org/cheatsheets/OAuth2_Cheat_Sheet.html) (federation) - [x] [SAML Security](https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html) (federation) - [x] [JSON Web Token for Java](https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html) (federation) --- ## 12. Kryptografia i bezpieczeństwo transportu - [x] [Cryptanalysis](https://owasp.org/www-community/attacks/Cryptanalysis), [Cryptographic Storage](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html), [Key Management](https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html) (crypto) - [x] [Manipulator-in-the-Middle (MITM)](https://owasp.org/www-community/attacks/Man-in-the-middle_attack), [Transport Layer Security](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html) (transport) - [x] [HTTP Strict Transport Security](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html) (transport) - [x] [Pinning](https://cheatsheetseries.owasp.org/cheatsheets/Pinning_Cheat_Sheet.html) (transport) --- ## 13. Server-Side Request Forgery (SSRF) - [x] [Server Side Request Forgery](https://owasp.org/www-community/attacks/Server_Side_Request_Forgery), [Server-Side Request Forgery Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html) (network) --- ## 14. Path traversal i obsługa plików - [x] [Path Traversal](https://owasp.org/www-community/attacks/Path_Traversal) (path) - [x] [Binary Planting](https://owasp.org/www-community/attacks/Binary_planting) (path) - [x] [Windows ::DATA Alternate Data Stream](https://owasp.org/www-community/attacks/Windows_DATA_alternate_data_stream) (path) - [x] [Embedding Null Code](https://owasp.org/www-community/attacks/Embedding_Null_Code) (path) - [x] [File Upload](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html) (upload) --- ## 15. Nadużycia protokołu HTTP (nagłówki, cache, splitting) - [x] [HTTP Response Splitting](https://owasp.org/www-community/attacks/HTTP_Response_Splitting), [Cross-User Defacement](https://owasp.org/www-community/attacks/Cross-User_Defacement) (interpreter) - [x] [HTTP Security Response Headers](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html) (podzielone między browser, transport, http-request i access-control) - [x] [Cache Poisoning](https://owasp.org/www-community/attacks/Cache_Poisoning) (interpreter) - [x] [IP Spoofing via HTTP Headers](https://owasp.org/www-community/attacks/ip_spoofing_via_http_headers) (http-request) --- ## 16. Kodowanie i content spoofing - [x] [Unicode Encoding](https://owasp.org/www-community/attacks/Unicode_Encoding) (interpreter) - [x] [Double Encoding](https://owasp.org/www-community/Double_Encoding) (interpreter) - [x] [Content Spoofing](https://owasp.org/www-community/attacks/Content_Spoofing) (browser) --- ## 17. Injection w plikach CSV i arkuszach kalkulacyjnych - [x] [CSV Injection](https://owasp.org/www-community/attacks/CSV_Injection) (csv) --- ## 18. CORS (Cross-Origin Resource Sharing) - [x] [CORS OriginHeaderScrutiny](https://owasp.org/www-community/attacks/CORS_OriginHeaderScrutiny) (http-request) - [x] [CORS RequestPreflightScrutiny](https://owasp.org/www-community/attacks/CORS_RequestPreflightScrutiny) (http-request) --- ## 19. Odmowa usługi (DoS) - [x] [Regular expression Denial of Service (ReDoS)](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS) (regex) --- ## 20. Bezpieczeństwo pamięci i kod natywny - [x] [Buffer Overflow Attack](https://owasp.org/www-community/attacks/Buffer_overflow_attack), [Buffer Overflow via Environment Variables](https://owasp.org/www-community/attacks/Buffer_Overflow_via_Environment_Variables) (c-cpp) - [x] [Format string attack](https://owasp.org/www-community/attacks/Format_string_attack) (c-cpp) --- ## 21. Mobile code i wykonywanie niezaufanego kodu - [x] [Mobile code invoking untrusted mobile code](https://owasp.org/www-community/attacks/Mobile_code_invoking_untrusted_mobile_code) (interpreter) - [x] [Mobile code non-final public field](https://owasp.org/www-community/attacks/Mobile_code_non-final_public_field) (java) - [x] [Mobile code object hijack](https://owasp.org/www-community/attacks/Mobile_code_object_hijack) (java) --- ## 22. Deserializacja - [x] [Deserialization](https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html) (podzielone między python, ruby, php, java i dotnet) --- ## 23. Złośliwe oprogramowanie i zagrożenia po stronie klienta - [x] [Man-in-the-browser attack](https://owasp.org/www-community/attacks/Man-in-the-browser_attack), [Browser Extension Security Vulnerabilities](https://cheatsheetseries.owasp.org/cheatsheets/Browser_Extension_Vulnerabilities_Cheat_Sheet.html) (browser) - [x] [Third Party JavaScript Management](https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.html) (browser) --- ## 24. Logi, wypieranie się działań i obsługa błędów - [x] [Log Injection](https://owasp.org/www-community/attacks/Log_Injection), [Logging](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html), [Application Logging Vocabulary](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Vocabulary_Cheat_Sheet.html) (interpreter) - [x] [Repudiation Attack](https://owasp.org/www-community/attacks/Repudiation_Attack) (interpreter) --- ## 25. Logika biznesowa i nadużywanie funkcjonalności Logika biznesowa i nadużywanie funkcjonalności nie mają jednej powierzchni ataku w kodzie, której mogłaby bronić specjalizacja poświęcona jednej powierzchni: obroną jest projekt dopasowany do konkretnej aplikacji, oparty na tym samym rozumowaniu, które prowadzi modelowanie zagrożeń w projekcie. Przeniesione do sekcji "Poza zakresem". --- ## 26. Bezpieczeństwo AI, LLM i agentów - [x] [Prompt Injection](https://owasp.org/www-community/attacks/prompt-injection), [LLM Prompt Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) (llm) - [x] [MCP Tool Poisoning](https://owasp.org/www-community/attacks/MCP_Tool_Poisoning), [MCP (Model Context Protocol) Security](https://cheatsheetseries.owasp.org/cheatsheets/MCP_Security_Cheat_Sheet.html) (llm) - [x] [HITL Dialog Forging (Lies-in-the-Loop)](https://owasp.org/www-community/attacks/lies-in-the-loop) (llm) - [x] [AI Agent Security](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html), [Secure Coding with AI](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Coding_with_AI_Cheat_Sheet.html) (llm) - [x] [Retrieval-Augmented Generation (RAG) Security](https://cheatsheetseries.owasp.org/cheatsheets/RAG_Security_Cheat_Sheet.html) (llm) - [x] [Secure AI/ML Model Ops](https://cheatsheetseries.owasp.org/cheatsheets/Secure_AI_Model_Ops_Cheat_Sheet.html) (llm) - [x] [AML and Sanctions Compliance for AI Agent Payments](https://cheatsheetseries.owasp.org/cheatsheets/AML_Sanctions_AI_Agent_Payments_Cheat_Sheet.html) (llm) --- ## 27. Prototype pollution i cross-site leaks - [x] [Prototype Pollution Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Prototype_Pollution_Prevention_Cheat_Sheet.html) (javascript) - [x] [Cross-site leaks (XS-Leaks)](https://cheatsheetseries.owasp.org/cheatsheets/XS_Leaks_Cheat_Sheet.html) (browser) --- ## 28. Frameworki i platformy językowe - [x] [Django Security](https://cheatsheetseries.owasp.org/cheatsheets/Django_Security_Cheat_Sheet.html), [Django REST Framework](https://cheatsheetseries.owasp.org/cheatsheets/Django_REST_Framework_Cheat_Sheet.html) (python) - [x] [Ruby on Rails](https://cheatsheetseries.owasp.org/cheatsheets/Ruby_on_Rails_Cheat_Sheet.html) (ruby) - [x] [Laravel](https://cheatsheetseries.owasp.org/cheatsheets/Laravel_Cheat_Sheet.html) (php) - [x] [Symfony](https://cheatsheetseries.owasp.org/cheatsheets/Symfony_Cheat_Sheet.html) (php) - [x] [Java Security](https://cheatsheetseries.owasp.org/cheatsheets/Java_Security_Cheat_Sheet.html) (java) - [x] [DotNet Security](https://cheatsheetseries.owasp.org/cheatsheets/DotNet_Security_Cheat_Sheet.html) (dotnet) - [x] [NodeJS Security](https://cheatsheetseries.owasp.org/cheatsheets/Nodejs_Security_Cheat_Sheet.html) (javascript) - [x] [PHP Configuration](https://cheatsheetseries.owasp.org/cheatsheets/PHP_Configuration_Cheat_Sheet.html) (php) --- ## 29. Frontend webowy i przeglądarka - [x] [HTML5 Security](https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet.html) (browser) - [x] [AJAX Security](https://cheatsheetseries.owasp.org/cheatsheets/AJAX_Security_Cheat_Sheet.html) (browser) - [x] [Securing Cascading Style Sheets](https://cheatsheetseries.owasp.org/cheatsheets/Securing_Cascading_Style_Sheets_Cheat_Sheet.html) (podzielone między access-control i browser) --- ## 30. API i usługi - [x] [GraphQL](https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html) (api-endpoint) - [x] [gRPC Security](https://cheatsheetseries.owasp.org/cheatsheets/gRPC_Security_Cheat_Sheet.html) (api-endpoint) - [x] [WebSocket Security](https://cheatsheetseries.owasp.org/cheatsheets/WebSocket_Security_Cheat_Sheet.html) (api-endpoint) --- ## 31. Chmura, kontenery i infrastruktura Konfiguracja kontenerów i obciążeń to configuration as code, którą deweloper dostarcza razem z aplikacją (`Dockerfile`, Compose, `securityContext` poda), czyli realna powierzchnia ataku, na której `harden` wdraża poprawki, a `verify` wykazuje, że działają, dlatego należy do zakresu. Administracja klastrem (RBAC, etcd, serwer API, admission, segmentacja sieci) to domena operatora i pozostaje poza zakresem. - [x] [Docker Security](https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html), [Node.js Docker](https://cheatsheetseries.owasp.org/cheatsheets/NodeJS_Docker_Cheat_Sheet.html) (container) - [x] [Kubernetes Security](https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet.html) (container: część dotycząca obciążeń i podów. Administracja klastrem pozostaje poza zakresem) - [x] [Serverless / FaaS Security](https://cheatsheetseries.owasp.org/cheatsheets/Serverless_FaaS_Security_Cheat_Sheet.html) (serverless) --- ## 32. Łańcuch dostaw i CI/CD - [x] [NPM Security](https://cheatsheetseries.owasp.org/cheatsheets/NPM_Security_Cheat_Sheet.html) (interpreter) - [x] [Dependency Graph & SBOM Best Practices](https://cheatsheetseries.owasp.org/cheatsheets/Dependency_Graph_SBOM_Cheat_Sheet.html), [Vulnerable Dependency Management](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html) (interpreter) --- ## 33. Sekrety i konfiguracja Zarządzanie sekretami to kwestia operacyjna: sejfy na sekrety, CI/CD, konfiguracja chmury, rotacja. Jedyny aspekt na poziomie kodu (sekret zapisany na sztywno w kodzie źródłowym) wymaga deterministycznego skanowania, a nie specjalizacji poświęconej ryzyku. Przeniesione do sekcji "Poza zakresem". --- ## 34. Procesy, projektowanie i governance Ochrona prywatności użytkowników to kwestia polityk i projektowania (minimalizacja danych, przejrzystość, retencja), a nie powierzchnia ataku w kodzie, której broni specjalizacja. Przeniesione do sekcji "Poza zakresem". --- ## 35. Płatności i zgodność z regulacjami - [x] [Secure Integration of Third-Party Payment Gateways](https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Payment_Gateway_Integration_Cheat_Sheet.html) (payment) --- ## 36. Systemy wbudowane, IoT i dziedziny specjalistyczne Bezpieczeństwo pojazdów i dronów to domena systemów wbudowanych (magistrala CAN, firmware OTA, integralność czujników i łączności radiowej, dostęp fizyczny), a nie kod źródłowy aplikacji webowych i API, który audytuje Lagune. Przeniesione do sekcji "Poza zakresem". --- ## Poza zakresem (brak powierzchni ataku w kodzie) Te pozycje nie są obszarem działania specjalizacji i nie mają pola wyboru: dotyczą governance, procesów, utwardzania operacyjnego albo korzystania z frameworków i nie mają jednej powierzchni ataku w kodzie, której mogłaby bronić specjalizacja poświęcona jednej powierzchni. Ich wartość dla bezpieczeństwa jest realna, ale leży w procesach i architekturze (albo, w przypadku frameworka, we własnym skillu danego języka), a nie w obronie, którą dostarcza ten katalog. Wymieniamy je jako punkt odniesienia, a nie jako zadania do wykonania. - [Authorization Regression Testing](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Regression_Testing_Cheat_Sheet.html), [Authorization Testing Automation](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Testing_Automation_Cheat_Sheet.html) - [JAAS](https://cheatsheetseries.owasp.org/cheatsheets/JAAS_Cheat_Sheet.html) - [Denial of Service](https://owasp.org/www-community/attacks/Denial_of_Service), [Denial of Service](https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet.html) - [HTTP/2 Reset Attack](https://owasp.org/www-community/attacks/HTTP2_Reset_Attack) - [Traffic flood](https://owasp.org/www-community/attacks/Traffic_flood) - [Web Service Amplification Attack](https://owasp.org/www-community/attacks/web_service_amplificaiton) (amplifikacja przez SOAP/WS-Addressing, operacyjny wariant DoS bez powierzchni ataku w kodzie) - [Cash Overflow](https://owasp.org/www-community/attacks/Cash_Overflow) - [Spyware](https://owasp.org/www-community/attacks/Spyware), [Trojan Horse](https://owasp.org/www-community/attacks/Trojan_Horse) (złośliwe oprogramowanie na urządzeniach użytkowników końcowych, a nie powierzchnia ataku w kodzie audytowanego projektu. Aspekt dostarczania przez przeglądarkę należy do `browser`) - [REST Security](https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html), [REST Assessment](https://cheatsheetseries.owasp.org/cheatsheets/REST_Assessment_Cheat_Sheet.html) - [Web Service Security](https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html) - [Cloud Architecture Security](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Cloud_Architecture_Cheat_Sheet.html) (projektowanie i kompromisy: IAM a podpisane adresy URL, publiczne i prywatne VPC, granice zaufania, model współdzielonej odpowiedzialności. W odróżnieniu od `container` nie zawiera konkretnej konfiguracji, którą sprawdzałaby specjalizacja) - [Infrastructure as Code Security](https://cheatsheetseries.owasp.org/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet.html) (wbrew nazwie dotyczy procesów SDLC i narzędzi do _zarządzania_ IaC: wtyczek IDE, analizy statycznej, skanowania obrazów, CI/CD, podpisywania. Nie pokazuje w żadnym pliku Terraform ani CloudFormation drogi od niebezpiecznego wzorca do bezpiecznej postaci) - [Kubernetes Security](https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet.html) (_tylko część dotycząca administracji klastrem_: RBAC, etcd, serwer API, admission. Część dotycząca obciążeń i podów należy do zakresu w ramach `container`) - [Network Segmentation](https://cheatsheetseries.owasp.org/cheatsheets/Network_Segmentation_Cheat_Sheet.html) (architektura sieci i polityka firewalla) - [Subdomain Takeover Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Subdomain_Takeover_Prevention_Cheat_Sheet.html) (cykl życia i monitorowanie DNS, a nie kod) - [Secrets Management](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) (sejfy na sekrety, CI/CD, rotacja. Aspekt sekretów zapisanych na sztywno w kodzie wymaga deterministycznego skanowania, a nie specjalizacji poświęconej ryzyku) - [C-Based Toolchain Hardening](https://cheatsheetseries.owasp.org/cheatsheets/C-Based_Toolchain_Hardening_Cheat_Sheet.html) (flagi kompilatora, linkera i budowania, bez sinka w kodzie źródłowym) - [Microservices Security](https://cheatsheetseries.owasp.org/cheatsheets/Microservices_Security_Cheat_Sheet.html), [Microservices based Security Arch Doc](https://cheatsheetseries.owasp.org/cheatsheets/Microservices_based_Security_Arch_Doc_Cheat_Sheet.html) - [Zero Trust Architecture](https://cheatsheetseries.owasp.org/cheatsheets/Zero_Trust_Architecture_Cheat_Sheet.html) - [CI/CD Security](https://cheatsheetseries.owasp.org/cheatsheets/CI_CD_Security_Cheat_Sheet.html), [GitHub Actions Security](https://cheatsheetseries.owasp.org/cheatsheets/GitHub_Actions_Security_Cheat_Sheet.html) - [Software Supply Chain Security](https://cheatsheetseries.owasp.org/cheatsheets/Software_Supply_Chain_Security_Cheat_Sheet.html) - [Error Handling](https://cheatsheetseries.owasp.org/cheatsheets/Error_Handling_Cheat_Sheet.html), [Full Path Disclosure](https://owasp.org/www-community/attacks/Full_Path_Disclosure) (globalna konfiguracja obsługi błędów w danym stosie. Wyciek to ta sama ekspozycja danych, którą już reguluje obsługa błędów) - [Abuse of Functionality](https://owasp.org/www-community/attacks/Abuse_of_Functionality), [Business Logic Security](https://cheatsheetseries.owasp.org/cheatsheets/Business_Logic_Security_Cheat_Sheet.html), [Abuse Case _(historyczny)_](https://cheatsheetseries.owasp.org/cheatsheets/Abuse_Case_Cheat_Sheet.html) (projekt dopasowany do konkretnej aplikacji, bez jednego sinka w kodzie) - [User Privacy Protection](https://cheatsheetseries.owasp.org/cheatsheets/User_Privacy_Protection_Cheat_Sheet.html) (minimalizacja danych, przejrzystość, polityka retencji) - [Top 10 Automotive Security Vulnerabilities](https://cheatsheetseries.owasp.org/cheatsheets/Automotive_Security_Cheat_Sheet.html), [Drone Security](https://cheatsheetseries.owasp.org/cheatsheets/Drone_Security_Cheat_Sheet.html) (domeny systemów wbudowanych: magistrala CAN, firmware OTA, integralność czujników i łączności radiowej, a nie kod źródłowy aplikacji webowych i API) - [Mobile Application Security](https://cheatsheetseries.owasp.org/cheatsheets/Mobile_Application_Security_Cheat_Sheet.html) (utwardzanie platform Android i iOS: przechowywanie danych, biometria, pinning, dane osobowe. Nie ma jednej powierzchni ataku w kodzie, a aspekt ładowania niezaufanego kodu trafił do `interpreter`) - [Threat Modeling](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html), [Threat Modeling _(strona społeczności)_](https://owasp.org/www-community/Threat_Modeling) - [Attack Surface Analysis](https://cheatsheetseries.owasp.org/cheatsheets/Attack_Surface_Analysis_Cheat_Sheet.html) - [Secure Product Design](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet.html) - [Secure Code Review](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html) - [Virtual Patching](https://cheatsheetseries.owasp.org/cheatsheets/Virtual_Patching_Cheat_Sheet.html) - [Vulnerability Disclosure](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html) - [Legacy Application Management](https://cheatsheetseries.owasp.org/cheatsheets/Legacy_Application_Management_Cheat_Sheet.html) - [Security Terminology](https://cheatsheetseries.owasp.org/cheatsheets/Security_Terminology_Cheat_Sheet.html) --- # /lagune-repair: Napraw zepsute śledzenie ustaleń > Napraw łańcuch, gdy zmiana nazwy lub przeniesienie pliku zaburzy śledzenie w Lagune. Adres kanoniczny: https://lagune.ai/pl-PL/docs/commands/repair Język: pl-PL Oryginał: https://lagune.ai/docs/commands/repair Ostatnia aktualizacja: 2026-11-09 🧰 Napraw łańcuch, gdy zmiana nazwy lub przeniesienie pliku go zaburzy. **Wewnętrzna konserwacja, nie faza bezpieczeństwa** Repair nie jest szóstą fazą liniowego przepływu pracy. Jego zadaniem jest utrzymanie spójności śledzenia. ```prompt # Nie przyjmuje żadnych argumentów: zawsze naprawia cały łańcuch /lagune-repair ``` ## Jak to działa Każde ustalenie z fazy detect to jeden śledzony element, który przejmują dalej fazy plan, harden i verify. Każda z nich na nim działa i ponownie wymienia go z nazwy. Ta nazwa, zapisana identycznie jako tytuł sekcji w każdym artefakcie, przez cały czas stanowi jego tożsamość. Jedyna zmienna informacja, jaką przechowuje śledzenie, to ścieżki plików, na które wskazuje element. Te ścieżki nie występują nigdzie indziej, więc zmiana nazwy lub przeniesienie pliku może zerwać powiązanie tylko w tym jednym miejscu, nigdy w dwóch rozbieżnych kopiach. Gdy tak się stanie, repair poprawia mapę (`.lagune/tracking.json`), aby tożsamość przetrwała zmianę nazwy. Czyta artefakty i mapę śledzenia, twój kod źródłowy czyta tylko po to, aby poznać nową ścieżkę pliku o zmienionej nazwie, i nigdy nie tworzy treści dotyczących bezpieczeństwa. W tym samym przebiegu sprawdza każdy artefakt pamięci względem jego szablonu i zgłasza rozbieżności, wskazując przy każdej fazę, która ją naprawia. **Wskazówka** - Nie zmienia ani twojego kodu, ani artefaktów tekstowych, tylko śledzenie. - Rzadko uruchamiasz to polecenie ręcznie. Gdy jakaś faza zauważy, że łańcuch jest niespójny, sama uruchamia repair i kontynuuje pracę. - Śledzenie, które utrzymuje, znajduje się w pliku `.lagune/tracking.json`. To wewnętrzny stan, którego nigdy nie edytujesz ręcznie. --- # Migrate: Przenieś projekt Lagune oparty na manifeście na skille i wtyczki > Przenieś projekt Lagune oparty na manifeście na wersję Lagune opartą na skillach, zachowując zasady bezpieczeństwa, artefakty, śledzenie i własne specjalizacje. Adres kanoniczny: https://lagune.ai/pl-PL/docs/commands/migrate Język: pl-PL Oryginał: https://lagune.ai/docs/commands/migrate Ostatnia aktualizacja: 2026-11-09 🔀 Przenieś projekt **Lagune** oparty na manifeście na wersję **Lagune** opartą na skillach, zachowując całą swoją dotychczasową pracę. **Rozwiązanie przestarzałe** Projekt z manifestem działa bez zmian aż do `v1.x`: `npx lagune` przekazuje `init`, `pull`, `update`, `add`, `remove`, `list` i dashboard do `lagune@0.15.0`, ostatniej wersji opartej na manifeście. ## Migracja 1. Upewnij się, że bieżąca praca jest zapisana w commicie, a potem uruchom migrate w głównym folderze projektu: ```bash npx lagune migrate ``` 2. Zrób commit wyłącznie ze zmianami wprowadzonymi przez migrate, aby przeniesienie pozostało jedną zmianą, łatwą do przejrzenia. 3. Zainstaluj polecenia dla swojego agenta, jak pokazuje [strona instalacji](https://lagune.ai/pl-PL/docs). 4. Jeśli projekt ma już artefakt fazy detect, plan lub harden, użyj polecenia [`/lagune-repair`](https://lagune.ai/pl-PL/docs/commands/repair), aby uzgodnić stare odwołania w tych artefaktach i w twoich własnych specjalizacjach: ```prompt /lagune-repair Uzgodnij zastosowane specjalizacje (wcześniej sub-skille) w artefaktach w `.lagune/memory/` (`detect.md`, `plan.md` i `harden.md`) z nazwami, które wymienia nowy katalog, i zamień każde wywołanie starych hooków z `.lagune/hooks/` w moich własnych specjalizacjach w `.lagune/catalog/` na wywołanie narzędzia `lagune_read` lub `lagune_write`. ``` ## Co się zmienia | Przed | Po | | --------------------------------------------------------------------- | -------------------------------------------------------------------------------- | | `.lagune/templates/`, `.lagune/hooks/` i `.lagune/specializations.md` | Usunięte: każdy skill zawiera swój szablon, a hooki uruchamia silnik | | Kopie wbudowanych specjalizacji w `.lagune/skills/` | Usunięte: wbudowane specjalizacje dostarcza silnik | | Twoje własne specjalizacje w `.lagune/skills/` | Przeniesione do `.lagune/catalog/` | | `.lagune/skills.json`, indeks twoich własnych specjalizacji | Scalony z `.lagune/configs.json` | | Kategorie z manifestu | Zapisane w `.lagune/configs.json` | | Stare polecenia agenta, takie jak `/lagune.detect` | Usunięte: [instalacja **Lagune**](https://lagune.ai/pl-PL/docs) dodaje nowe, takie jak `/lagune-detect` | | Blok **Lagune** w `.gitignore` | Usunięty, razem z plikiem, jeśli nie zawierał nic więcej | | `.lagune/proofs/`, ignorowany przez ten blok | Trzymany z dala od commitów przez własny plik `.gitignore` | | `.lagune/manifest.json` | Usunięty na samym końcu | Twoja praca nad bezpieczeństwem zostaje bez zmian: zasady bezpieczeństwa, artefakt utworzony przez każdą fazę i mapa śledzenia ze ścieżkami, na które wskazuje każde ustalenie. ## Najczęściej zadawane pytania ### Czy muszę przeprowadzić migrację? Tak. Projekty oparte na manifeście są przestarzałe i działają tylko do v1.x, więc uruchom npx lagune migrate, aby przenieść swój projekt. ### Co zachowuje migrate? Twoje zasady bezpieczeństwa, każdy artefakt faz, mapę śledzenia, twoje kategorie i twoje własne specjalizacje. Specjalizacje trafiają do .lagune/catalog/, a ich indeks dołącza do twoich kategorii w .lagune/configs.json. ### Kiedy zainstalować nowe polecenia? Po migracji, jak pokazuje strona instalacji dla twojego agenta. Instalacja przed migracją też zadziała, bo migrate zachowuje nowe polecenie /lagune. ### Ktoś z zespołu już przeprowadził migrację. Co mam uruchomić? Pobierz zmiany z migracją przez pull, a potem raz uruchom npx lagune migrate. Polecenie usunie to, co wersja Lagune oparta na manifeście zostawiła w twoim klonie repozytorium, a czego system kontroli wersji nigdy nie przechowywał, i zadba, żeby twoje wykazania nie trafiały do commitów.