Audyt bezpieczeństwa Twojego kodu. Jedną komendą.

/security-audit

Nowość: działa też w Codex CLI i w OpenCode, z modelem od wybranego dostawcy.

Skill do Claude Code, OpenCode i Codex CLI, który sprawdza Twoją aplikację i oddaje raport: co naprawić, co jest dobrze i czego nie dało się sprawdzić. Każde znalezisko ma plik, linię i opis skutku.

16/16ukrytych błędów w naszej aplikacji testowej
0/8pułapek wziętych za błąd
32 minod komendy do raportu, aplikacja z 45 wejściami

Zainstaluj za darmo Zobacz przykładowy raport

Open source na licencji MIT. Dla tych, którzy budują z agentami AI i wdrażają na produkcję. Kod na GitHubie.

.security-audit/report.htmlaplikacja testowa

Ledgerly

27 issues to fix (2 critical, 14 high, 8 medium, 3 low).

23 areas verified safe · 7 checks not assessed

2 critical
14 high
8 medium
3 low
23 verified safe
7 not assessed

Fix first

Public project pages let any account read and overwrite other organizations' datacritical · code reading only · src/app/p/[slug]/page.tsx:7
next 16.3.0 has an unauthenticated RCE advisory reachable through image configcritical · code reading only · pnpm-lock.yaml:238
Admin stats API has no authenticationhigh · failing test · src/app/api/admin/stats/route.ts:5

Fragment prawdziwego raportu z aplikacji testowej z 16 celowo ukrytymi błędami. Raporty są po angielsku, jak kod.

Audyt z opiekunem projektu

Skill jest darmowy i open source. Jeśli chcesz, żeby jego autor przeszedł nim Twój kod i podpisał się pod wynikiem, napisz.

Można zacząć od części kodu zamiast całości, np. od logowania, płatności i webhooków albo od kilkunastu najbardziej ryzykownych wejść.

Cena zależy od wielkości kodu i stacku, ustalamy ją po rozmowie. Zakres to przegląd kodu, bez testów na systemach produkcyjnych.

Napisz: bartek@devince.dev

W mailu przydadzą się: repozytorium i stack, wielkość kodu, zakres i termin.

Administrator danych: devince. Dane z maila służą tylko do odpowiedzi na zapytanie; bez umowy usuwamy je po 90 dniach.

Raport, z którego wiadomo, co robić

Trzy listy zamiast ściany tekstu. Każda pozycja prowadzi do pliku i linii.

Do naprawy: Od najpoważniejszych. Na wierzchu instrukcja naprawy, pod spodem skutek i dowód. Przy poważnych znaleziskach etykieta: test, który dziś nie przechodzi, albo czytanie kodu.
Jest dobrze: Obszary sprawdzone i bezpieczne. Każdy wskazuje zabezpieczenie w kodzie, które go chroni, z plikiem i linią.
Nie sprawdzone: To, czego audyt nie mógł ocenić, na przykład ustawienia produkcji. Brak znalezisk nie udaje tu bezpieczeństwa.

Do tego zależności ze znanymi podatnościami, sekrety znalezione w historii gita i lista zgłoszeń odrzuconych jako fałszywe alarmy.

Otwórz pełny raport

.security-audit/report.htmlpodgląd

Jak przebiega audyt

Pięć faz, każda zostawia pliki, z których składa się raport. Obok zapis prawdziwego przebiegu: 32 minuty w niecałe dwie.

00
Wstępny skan
Lista miejsc dostępnych z zewnątrz i ranking ryzyka. Zależności sprawdzane w publicznej bazie znanych podatności (CVE), sekrety szukane w całej historii gita.
01
Mapa aplikacji
Stack, punkty wejścia i gdzie naprawdę sprawdzane są uprawnienia. Każdy wpis to twierdzenie do zweryfikowania w kodzie.
02
Audyt po obszarach
Równolegle, 12 obszarów i 90 punktów kontrolnych, od najbardziej ryzykownych miejsc. Każdy punkt kończy się znaleziskiem, obszarem bezpiecznym z dowodem albo wpisem „nie sprawdzone”.
03
Niezależna weryfikacja
Osobny przebieg czyta kod drugi raz, śledzi dane od wejścia do użycia, odrzuca fałszywe alarmy i łączy znaleziska w łańcuchy. Przy poważnych pisze test regresji, który dziś nie przechodzi.
04
Raport i testy
Ocena testów projektu, lista działań w kolejności i raport HTML: do naprawy, bezpieczne z dowodem, nie sprawdzone.

Aplikacja testowa z 16 ukrytymi błędami. Nagranie przyspieszone, bez cięć w treści. Pełna wersja niżej.

Czym różni się od zwykłego promptu

Claude poproszony o „sprawdź bezpieczeństwo” też coś znajdzie. Różnica jest w tym, czemu możesz zaufać.

Dowód zamiast przypuszczeń. Każde znalezisko ma plik, linię i opis skutku: kto może zrobić to, czego nie powinien. Przy poważnych powstaje test regresji, który dziś nie przechodzi, a raport mówi, które potwierdzono testem, a które czytaniem kodu.
Fałszywe alarmy odpadają przed raportem. Każde zgłoszenie jest sprawdzane w kodzie drugi raz. W przebiegu z karty odpadło 6, a żadna z 8 pułapek (bezpieczny kod, który wygląda podejrzanie) nie trafiła do raportu.
Wiesz, czego nie sprawdzono. Zamiast „wygląda dobrze” dostajesz listę rzeczy, których audyt nie mógł ocenić. W przebiegu z karty było ich 7; na projekcie produkcyjnym ze 160 wejściami było ich 43, głównie ustawienia produkcji.

projekt: Ledgerly, aplikacja testowa z 16 ukrytymi błędami
model: Opus 5.5, effort xhigh
ukryte błędy znalezione: 16 z 16
pułapki wzięte za błąd: 0 z 8
potwierdzone problemy: 27
w tym: 2 krytyczne · 14 wysokich · 8 średnich · 3 niskie
z testem regresji, który dziś nie przechodzi: 16
obszary bezpieczne, z dowodem: 23
fałszywe alarmy odfiltrowane przed raportem: 6
czas: 32 min
tokeny / koszt w cenach API: 23,8 mln (96% z cache) / ok. 11,70 USD

Jeden pełny przebieg, ten sam, który widzisz na nagraniu. Skill rozwijaliśmy z tą aplikacją w ręku, więc wynik pokazuje, że te klasy błędów są pokryte, a nie ile znajdzie w dowolnym kodzie. Aplikacja i klucz odpowiedzi są w repozytorium, więc wynik sprawdzisz u siebie.

Na tej samej aplikacji: Security Audit i darmowa wtyczka Claude Security od Anthropic

	Security Audit	Claude Security (bezpłatna)
Ukryte błędy znalezione	16 z 16	15 z 16 (bez podatnej wersji Next.js)
Pułapki wzięte za błąd	0 z 8	0 z 8
Czas	32 min	13 min
Koszt w cenach API	ok. 11,70 USD	ok. 12,70 USD
Dowód przy poważnych	testy regresji, które dziś nie przechodzą	czytanie kodu, ocena pewności
Tylko tutaj	podatności w zależnościach, lista miejsc bezpiecznych z dowodem, ocena testów projektu	SARIF, skan zmian w gałęzi, gotowe patche

Po jednym przebiegu każdego narzędzia, 3 października 2026, ten sam model i effort. Różnicy jednego błędu nie traktujemy jako twardej. Możesz używać obu. Pełne porównanie i zastrzeżenia.

Na prawdziwych podatnościach

Aplikację testową z sekcji wyżej pisaliśmy razem ze skillem. Tu jest kod, którego nie pisaliśmy: moduł Drupala miniorange_saml („SAML SSO - Service Provider”) w wersji 3.1.3, dla której drupal.org opublikował advisory, i w wersji 3.2.0, która je naprawia. Skill dostał tylko polecenie /security-audit.

Wersja podatna

wersja: 3.1.3 (25 lutego 2026), podatna na wszystkie advisory z tabeli
polecenie: /security-audit, bez informacji o advisory
model: Opus 5.5
advisory znalezione: 4 z 11
najwyżej w raporcie: SA-CONTRIB-2026-031, krytyczne
znalezione, odrzucone przy weryfikacji: 2
fałszywe alarmy: 0
tokeny / koszt / czas: 3,25 mln / 2,37 USD / 6 min

Najwyżej w raporcie stoi SA-CONTRIB-2026-031 (CVE-2026-5343): weryfikacja podpisu SAML zgłasza błąd, ale nie przerywa logowania. Scorer liczy też dodatkowe miejsca znaleziska, więc XSS atrybutów SAML (SA-147), wskazany jako drugie miejsce innego znaleziska, jest liczony jako trafiony.

Wersja naprawiona (kontrola)

wersja: 3.2.0 (9 września 2026), z poprawkami wszystkich advisory
naprawione advisory zgłoszone ponownie: 0
trafienia w pułapkę: 1, w przeglądzie
tokeny / koszt / czas: 4,28 mln / 3,15 USD / 8 min

Żadne z naprawionych advisory nie wróciło w raporcie.

11 advisory na wersji 3.1.3

Advisory	Ryzyko wg drupal.org	Czego dotyczy	Wynik
SA-CONTRIB-2026-031 CVE-2026-5343	krytyczne 19/25	nieudana weryfikacja podpisu SAML nie przerywa logowania (obejście uwierzytelnienia)	znalezione, pierwsze w raporcie
SA-CONTRIB-2026-141 CVE-2026-87943	krytyczne 18/25	trasy dostępne dla każdego prowadzą do funkcji administracyjnych	znalezione, odrzucone przy weryfikacji
SA-CONTRIB-2026-143 CVE-2026-87945	krytyczne 16/25	RelayState jako przekierowanie po logowaniu (open redirect)	znalezione
SA-CONTRIB-2026-142 CVE-2026-87944	krytyczne 15/25	wyłączona weryfikacja certyfikatu TLS w połączeniach wychodzących	znalezione
SA-CONTRIB-2026-144 CVE-2026-87946	krytyczne 15/25	porównanie HMAC zależne od czasu, przewidywalne identyfikatory żądań	nie
SA-CONTRIB-2026-145 CVE-2026-87947	umiarkowanie krytyczne 14/25	algorytm podpisu wybierany przez odpowiedź SAML	nie
SA-CONTRIB-2026-148 CVE-2026-87950	umiarkowanie krytyczne 13/25	dane uwierzytelniające dostawcy zaszyte w kodzie	znalezione, odrzucone przy weryfikacji
SA-CONTRIB-2026-147 CVE-2026-87949	umiarkowanie krytyczne 12/25	atrybuty SAML wypisywane do HTML (XSS)	znalezione jako drugie miejsce innego XSS
SA-CONTRIB-2026-149 CVE-2026-87951	umiarkowanie krytyczne 12/25	hasło do konta dostawcy zapisane w konfiguracji	nie
SA-CONTRIB-2026-151 CVE-2026-87953	umiarkowanie krytyczne 11/25	adres metadanych IdP pobierany bez sprawdzenia (SSRF, tylko administrator)	nie
SA-CONTRIB-2026-150 CVE-2026-87952	umiarkowanie krytyczne 10/25	brak ochrony przed ponownym użyciem odpowiedzi SAML	nie

Przebiegi z 19 października 2026, Opus 5.5, po jednym na wersję. Zastrzeżenia: to jeden moduł i jedna rodzina błędów, głównie obsługa odpowiedzi SAML. SA-CONTRIB-2026-031 jest z kwietnia 2026 i może być w danych treningowych modelu; paczka z września raczej nie. Przebiegi LLM się różnią: powtórki na 3.1.3 są na stronie Przebiegi. Znalezienie publicznego, już naprawionego błędu to dolna granica tego, co skill robi na nieznanym kodzie, a nie górna, i nie dowód, że znalazłby go pierwszy.

Sprawdź u siebie. Moduł nie jest kopiowany do repozytorium: skrypt pobiera wydanie z drupal.org, sprawdza sumę sha256 i przygotowuje katalog do audytu, a klucz odpowiedzi ocenia wynik. Instrukcja, klucze i tabela wyników.

Wszystkie przebiegi →

Jak tego używasz

Jedna komenda, potem raport. Bez konfiguracji i bez konta w kolejnym serwisie.

Uruchamiasz
W swoim projekcie wpisujesz jedną komendę w Claude Code, OpenCode albo Codex CLI. Audytujesz cały projekt albo wybrany obszar.
Audyt pracuje sam
Nie musisz niczego pilnować. Duży projekt zajmuje około dwóch godzin, mały projekt albo wybrany obszar krócej.
Naprawiasz od góry
Otwierasz raport. Każde znalezisko ma instrukcję naprawy, a po poprawkach sprawdzasz stan jeszcze raz.

> /security-audit                     cały projekt
> /security-audit --scope auth        logowanie, sesje, uprawnienia
> /security-audit --scope payments    płatności
> /security-audit --scope src/api     wybrany katalog
> /security-audit --scope top20       20 najbardziej ryzykownych miejsc
> /security-audit --verify-fixes      sprawdź, co już naprawione

Zakres wybierasz sam. Przy dużym projekcie warto zacząć od jednego obszaru.

Co sprawdza, a czego nie

12 obszarów i 90 punktów kontrolnych. Każdy punkt kończy się znaleziskiem, obszarem bezpiecznym z dowodem albo wpisem „nie sprawdzone”.

Przy każdym audycie

znane podatności w zależnościach
sekrety w całej historii gita
lista miejsc, od których warto zacząć

Stack, który zna najlepiej

Next.js App Router
tRPC
Hono
Drizzle
Better-Auth
AI SDK
Node bez frameworka

Python, PHP, Go, Ruby i Java działają na regułach ogólnych, mniej precyzyjnie.

W przygotowaniu

profile dla PHP, Pythona, Go i Rusta
wykrywanie stacku i flaga --stack
więcej sprawdzeń dla CSRF, CI/CD i Dockera

Bez terminów. Pełna lista z kryterium gotowości: roadmapa. Zmiany śledzisz na GitHubie, aktualizujesz przez git pull.

Uwierzytelnianie i autoryzacja16
Wstrzyknięcia (SQL, XSS, SSTI, polecenia)16
Kryptografia i tokeny12
Upload plików8
Logika biznesowa7
Zależności6
Współbieżność i wyścigi6
Ekspozycja danych i sekrety5
Nagłówki, CORS, transport4
Limity i nadużycia4
Logowanie i monitoring4
Zgodność dokumentacji z kodem2

Czego nie robi

Lepiej wiedzieć to przed pierwszym audytem.

Nie zastępuje pentestu. Czyta kod i uruchamia testy lokalnie. Nie symuluje ataków, nie dotyka produkcji i nie sprawdza infrastruktury.
Nie daje gwarancji. Brak znalezisk nie znaczy, że podatności nie ma. Dlatego raport ma listę „nie sprawdzone”.
Nie zna Twojej produkcji. Limity, proxy i zmienne środowiskowe wypisuje jako rzeczy do sprawdzenia po Twojej stronie.
Może zostać zatrzymany. Modele mają własne mechanizmy bezpieczeństwa. Pełny przebieg testowy przeszedł w całości na Opus 5.5, częściowy na Fable 5.1, ale nie gwarantujemy, że każdy przebieg przejdzie bez zatrzymania. Gdy agent zostanie zatrzymany, skill kończy pozostałe pliki w trybie samej weryfikacji.
Ma słabsze miejsca. CSRF, CI/CD i Docker mają dziś niewiele własnych punktów kontrolnych.

Pełny przebieg w pięć minut

Ten sam audyt co wyżej, w całości: 5 minut zamiast 32. Bez komentarza, bez cięć w treści.

Jak powstaje skill, pokazujemy w krótkich standupach na YouTube.

Komenda i wstępny skan
Mapa aplikacji i audyt po obszarach
Dwóch weryfikatorów równolegle
Łańcuchy znalezisk i jakość testów
Raport w przeglądarce

Za darmo, open source

Licencja MIT. Używasz we własnych projektach, w pracy i u klientów, możesz go zmieniać i rozwijać. Tokeny Claude zużywasz na własnym koncie.

Repozytorium na GitHubie Roadmapa

Aktualizacja: git -C ~/.claude/skills/security-audit pull. Wymagania: Claude Code, Node 20+, opcjonalnie docker albo osv-scanner i gitleaks. Testowane na Linuksie.

Zainstaluj skill

> git clone https://github.com/bartek-filipiuk/security-audit-skill ~/.claude/skills/security-audit

Sprawdź skrypty (kilka sekund, bez tokenów)

> cd ~/.claude/skills/security-audit && node --test scripts/

Opcjonalnie: panel postępu na żywo

> cp -r ~/.claude/skills/security-audit/audit-live ~/.claude/skills/

W swoim projekcie, w Claude Code
```
> /security-audit --scope top20
```

W OpenCode

Ten sam audyt jako agenci OpenCode (2.1+), z modelem od dowolnego dostawcy. Zasady są tu wymuszone uprawnieniami: audyt pisze tylko do .security-audit/, nie czyta .env i nie wychodzi do sieci.

Weryfikatorowi daj najmocniejszy model, jaki masz, najlepiej od innego dostawcy niż audytorzy. Względem Claude Code nie ma naprawiania (Faza 6), --mutation ani panelu na żywo. Szczegóły: opencode/README.md. Jak wypadają różne modele: benchmarki.

Pobierz repozytorium

> git clone https://github.com/bartek-filipiuk/security-audit-skill && cd security-audit-skill

Zbuduj i zainstaluj agentów, z modelami od wybranego dostawcy

> node opencode/build.mjs && node dist/opencode/install.mjs --auditor-model <dostawca/model> --verifier-model <dostawca/model>

W swoim projekcie, w OpenCode
```
> /security-audit --scope top20
```

W Codex CLI

Ten sam audyt jako skill Codex CLI (0.155+), z subagentami Codexa. Sandbox Codexa pozwala pisać tylko w projekcie i odcina sieć, a hook pilnuje reszty zasad: zapis tylko do .security-audit/ i .gitignore, bez czytania .env i plików spoza projektu. Hook działa tylko w sesji zaczętej od $security-audit.

Bez sieci skan zależności i skanery z dockera wypisują się jako niezrobione. Względem Claude Code nie ma naprawiania (Faza 6), --mutation ani panelu na żywo. Szczegóły: codex/README.md. Wyniki: benchmarki.

Pobierz repozytorium

> git clone https://github.com/bartek-filipiuk/security-audit-skill && cd security-audit-skill

Zainstaluj skill i strażnika (hook)
```
> node codex/install.mjs
```
Raz zaufaj hookom: codex, potem /hooks
```
> codex --sandbox workspace-write
```
W swoim projekcie, w Codex CLI
```
> $security-audit --scope top20
```

Pytania

Czego potrzebuję, żeby to uruchomić?

Claude Code z płatnym planem albo kluczem API (albo OpenCode 2.1+ z kluczem do wybranego dostawcy modeli), Node 20 lub nowszy i docker do skanu zależności i sekretów. Bez dockera audyt też działa, a raport wypisze te dwa sprawdzenia jako niezrobione.

Ile kosztuje jeden audyt w tokenach?

Tokeny zużywasz na własnym koncie Claude. Pełny audyt aplikacji testowej (45 wejść) trwał 32 minuty: 23,8 mln tokenów, w cenach API około 11,70 USD, a na planie Max 20x licznik tygodniowy przesunął się o jeden punkt. Duży projekt (160 wejść) trwał 2 godziny 11 minut. Na planie Pro nie mierzyliśmy, więc zacznij od --scope top20, czyli 20 najbardziej ryzykownych miejsc.

Czy mój kod gdzieś wychodzi?

Skill działa w Twoim Claude Code, na takich samych zasadach jak każda inna praca z kodem. Skan sekretów działa lokalnie i maskuje wartości. Skan zależności wysyła do publicznej bazy podatności nazwy i wersje pakietów. Wyniki trafiają do katalogu .security-audit/, który skill sam dopisuje do .gitignore. W OpenCode kod trafia do dostawcy modelu, którego wybierzesz: darmowe i testowe modele mogą go przechowywać albo na nim trenować, więc nie audytuj tam kodu, którego nie możesz mu udostępnić.

Jak zainstalować i aktualizować?

Sklonuj repozytorium do ~/.claude/skills/security-audit (komenda jest w sekcji Instalacja) i aktualizuj przez git pull. Panel postępu na żywo to osobny, opcjonalny mod: kopiujesz jeden folder. Pomoc i rozmowy o wynikach: kanał #security-audit-skill na serwerze społeczności WrocDevs (zaproszenie). Jedna zasada: nie wklejamy fragmentów raportów z niepoprawionymi słabościami ani sekretów.

Czy modele nie blokują takiego audytu?

Audyt nie symuluje ataków: czyta kod, opisuje skutek i pisze testy regresji. Pełny przebieg testowy przeszedł w całości na Opus 5.5, częściowy na Fable 5.1. Nie gwarantujemy, że każdy przebieg przejdzie bez zatrzymania; gdy agent zostanie zatrzymany, skill kończy pozostałe pliki w trybie samej weryfikacji, a raport mówi, co się stało.

Czym różni się od darmowej wtyczki Claude Security od Anthropic?

Na tej samej aplikacji testowej obie znalazły prawie wszystkie ukryte błędy (my 16 z 16, wtyczka 15 z 16), bez fałszywych alarmów, a wtyczka była szybsza. Security Audit dokłada skan znanych podatności w zależnościach, sekrety w całej historii gita, testy regresji jako dowód, listę bezpiecznych miejsc z dowodem i ocenę testów projektu. Wtyczka daje SARIF, skan zmian w gałęzi i gotowe patche. Możesz używać obu; szczegóły i zastrzeżenia są w porównaniu w repozytorium.

Dlaczego za darmo i jak mogę pomóc?

Bo bezpieczny kod powinien być normą, a darmowe narzędzie Anthropic robi już dużą część tej pracy. Najbardziej pomagają zgłoszenia na GitHubie: fałszywy alarm, przeoczony błąd, stack, który działa słabo. Pull requesty mile widziane; zasady są w AGENTS.md, a słabość w samym skillu zgłaszasz prywatnie według SECURITY.md.

Czy mogę używać go w pracy i u klientów?

Tak. Licencja MIT: używasz, zmieniasz i rozwijasz, także komercyjnie. Zostaw tylko informację o licencji w kopiach kodu.