# SecurityCheck i jego reguły

Zanim Speedwave uruchomi kontener, renderuje plik compose i przekazuje go do SecurityCheck. SecurityCheck parsuje ten YAML, sprawdza go pod kątem ustalonego zestawu reguł i weryfikuje stan systemu plików na twoim hoście. Jeśli cokolwiek zawiedzie, kontenery się nie uruchamiają.

Ta brama wymusza granice opisane na stronie [izolacji](/pl/docs/security/isolation/): blokuje start Speedwave, gdy wyrenderowany plik compose albo stan twojego hosta nie spełnia tych granic.

## Fail-closed, bez wyjątków

Jedno naruszenie reguły blokuje start i nie da się tego obejść. `speedwave check` i `speedwave` wymuszają to z poziomu CLI; Desktop zamiast tego pokazuje blokującą nakładkę. Pełną listę poleceń znajdziesz w [dokumentacji CLI](/pl/docs/reference/cli-commands/).

Samo `speedwave check` tylko zgłasza naruszenia. Normalne ścieżki startowe najpierw same naprawiają błędne uprawnienia. Problemy z właścicielem pliku nigdy nie są naprawiane automatycznie, bo wymaga to uprawnień roota, więc zamiast tego dostajesz kroki do ręcznej naprawy. Błąd parsowania YAML zatrzymuje proces z jednym komunikatem błędu.

## Co sprawdza

Poniższe reguły obejmują te same granice dla danych uwierzytelniających, co opisano w [obsłudze danych uwierzytelniających](/pl/docs/security/credentials/). Uruchamiane są wszystkie reguły, a ty dostajesz wszystkie naruszenia na jednej liście.

| Grupa | Co obejmuje |
| --- | --- |
| Zabezpieczanie kontenera | Wszystkie uprawnienia Linuksa odebrane, eskalacja uprawnień zablokowana, `claude`/`mcp-hub`/`proxy` tylko do odczytu z niewykonywalnym `/tmp` |
| Tokeny i sekrety | `claude` i `mcp-hub` blokują zmienne środowiskowe przypominające dane uwierzytelniające poza małym dozwolonym zestawem; w `claude` nie mogą znaleźć się klucze zewnętrznych dostawców LLM |
| Sieć | Porty nasłuchują wyłącznie na `127.0.0.1`, `claude` nigdy nie montuje gniazda silnika kontenerów, wbudowane workery MCP nie wystawiają żadnych portów |
| Tożsamość kontenera | Kontenery działają jako ustalony użytkownik spoza roota |
| Punkty montowania proxy | Wolumeny kontenera proxy danego projektu odpowiadają dokładnie przypiętemu profilowi |
| Wtyczki | Brak trybu uprzywilejowanego, brak dostępu do sieci hosta, obecny manifest, punkty montowania wolumenów zgodne z dokładnym dozwolonym zestawem |
| SharePoint i Slack | Każda integracja trzyma się własnego profilu wolumenów: poprawne ścieżki, tryby dostępu i brak dodatkowych punktów montowania |
| System plików hosta (tylko Unix) | Katalogi i pliki pod `~/.speedwave/` mają oczekiwane uprawnienia i właściciela |

Na Windowsie sprawdzanie systemu plików hosta jest pomijane. Odczytuje metadane plików bez podążania za dowiązaniami symbolicznymi, więc podstawiony symlink zostaje pominięty.

## Co się dzieje przy naruszeniu

Przy każdym naruszeniu widzisz kontener, regułę, która zawiodła, komunikat i sposób naprawy, z poziomu CLI albo z blokującej nakładki w Desktop. Osobne sprawdzenie wymagań systemowych (WSL2 na Windows) blokuje start w ten sam sposób.

## Czego nie obejmuje

SecurityCheck sprawdza wyrenderowany plik compose i stan systemu plików hosta pod `~/.speedwave/`. Pomija własne komendy Desktop dotyczące procesów na hoście, takie jak walidacja adresów URL wychodzących, audio hosta czy piaskownica egzekutora. Są opisane gdzie indziej.