O czym jest ten film
- Październik przeszedł w branży pod nazwą „Breach October” — w ciągu 40 godzin odnotowano ponad 27 poważnych incydentów bezpieczeństwa w produktach takich jak PHP, Node.js, Java, GitLab, Signal czy WordPress.
- Autor wiąże tę falę z rozpowszechnieniem modeli o otwartych wagach: są na tyle sprawne, że atakujący wykorzystują je do włamań w cudze systemy.
- Główny temat: skill „security audit” od Cloudflare dla Claude Code, który w aplikacji autora — rozwijanej od ponad pół roku, z prawdziwymi użytkownikami — wykrył realne luki.
- Instalacja to pojedyncza komenda, globalnie albo per projekt przez symlink; instalator dopytuje m.in. o wybór agenta.
- Audyt uruchamia zwykły prompt lub komenda
/security-audit; w tle równolegle pracuje kilka podagentów. - Raport obejmował 26 problemów; po weryfikacji podagentami na tymczasowej bazie danych 21 się potwierdziło, 3 odrzucono, 2 pozostały nieprzejrzane. Najczulsze obszary: klucze bezpieczeństwa, darmowe kredyty i dane zespołu.
- Skill Wayfinder z kolekcji Mapokor rozbija raport na 18 biletów na tablicy Kanbana, ułożonych według wagi.
- Fabryka oprogramowania autora — z agentem Codex na pokładzie, bo kończył się limit Claude — przepuszcza bilety przez obieg builder → QA → reviewer i scala wszystko do produkcji.
- Kontrolny audyt po wdrożeniu wykrył już tylko dwa drobne błędy — obieg naprawy został domknięty.
- Porównanie dwóch narzędzi: skill Cloudflare skanuje całą bazę kodu i nadaje się do okresowych audytów, a skill „security review” od Anthropic patrzy na ostatnie zmiany — idealny do uruchomienia po każdym pull requeście.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Najpierw rotacja kluczy i bezpieczeństwo, dopiero potem nowe funkcje
Na czym polega: Aplikacja autora po sześciu miesiącach pracy, z żywymi użytkownikami, skrywała luki, o których nie miał pojęcia — między innymi odsłonięty główny klucz rozliczeniowy. Dlatego zamiast dobudowywać kolejne funkcje, zaczął od audytu i wymiany sekretów.
Jak stosować: Jeśli podejrzewasz u siebie podatności, unieważnij i wygeneruj na nowo klucze API oraz sekrety natychmiast — to pierwszy krok, przed planowaniem jakichkolwiek napraw czy rozwoju.
Na co uważać: Rotacja bez naprawienia luki, która klucz ujawniała, nic nie daje — sekret po prostu wycieknie ponownie.
2.Każdy raport z audytu potwierdź drugim przebiegiem
Na czym polega: Autor zlecił podagentom sprawdzenie całego raportu na tymczasowej bazie danych. Z 26 zgłoszeń 21 się potwierdziło, 3 okazały się fałszywe, a 2 czekały jeszcze na przegląd.
Jak stosować: Oddziel etap „potwierdzić” od etapu „naprawić”. Replikuj zgłoszone luki w odizolowanym środowisku i dopiero potwierdzone kieruj na tablicę zadań.
Na co uważać: Nieprzejrzane pozycje najłatwiej zignorować — a to właśnie tam mogą czaić się najpoważniejsze problemy. Wracaj do nich po głównej fali napraw.
3.Raport zamień na bilety i ułóż je według wagi problemu
Na czym polega: Skill Wayfinder przekładał raport z audytu na pojedyncze zadania; na tablicy Kanbana znalazło się 18 biletów, posortowanych według zagrożenia.
Jak stosować: Zautomatyzuj przejście od raportu do zadań: jedna luka, jeden bilet, jeden jasny priorytet. Zacznij od tego, co realnie zagraża danym i pieniądzom użytkowników.
Na co uważać: Sortowanie „od najgłośniejszego” zamiast „od najgroźniejszego” sprawia, że krytyczne luki czekają w kolejce za błahostkami.
4.Naprawy zlecaj agentom równolegle — ale z etapem QA i review
Na czym polega: Bilety przechodziły przez obieg z trzema rolami: builder naprawiał, QA testował, reviewer sprawdzał kod. Każde zadanie kończyło się scaleniem do produkcji.
Jak stosować: Jeśli automatyzujesz naprawy, ustaw przepływ tak, aby jeden agent pisał poprawkę, drugi ją testował, a trzeci robił przegląd — i dopiero wtedy zamykał bilet.
Na co uważać: Równoległość nie zwalnia z kontroli. Bez etapów testów i przeglądu poprawki pisane przez agentów potrafią wprowadzić nowe luki.
5.Po scaleniu zmian powtórz cały audyt
Na czym polega: Gdy wszystkie bilety (16 plus kilka dodatkowych, łącznie około 18) trafiły do produkcji, autor jeszcze raz odpalił pełny skan. Zostały tylko dwa drobne błędy — nic w skali wcześniejszych znalezisk.
Jak stosować: Kontrolny audyt traktuj jako warunek zamknięcia tematu. Dopiero wynik po naprawach — czysty albo akceptowalny — oznacza „gotowe”.
Na co uważać: Pojedyncze drobiazgi po pierwszej fali poprawek to norma. Trzeba je dopchnąć w drugiej iteracji, a nie uznać, że skan się mylił.
6.Dwa skille, dwa rytmy: cały kod raz na sprint, zmiany po każdym PR
Na czym polega: Skill audytowy od Cloudflare przeszukuje całą bazę kodu — pasuje do uruchamiania raz na miesiąc albo raz na dwutygodniowy sprint. Skill „security review” od Anthropic analizuje ostatnie zmiany i kod w ich sąsiedztwie — stworzony pod uruchamianie po każdym pull requeście.
Jak stosować: Wpleć oba w rytm zespołu: pełny skan na koniec sprintu, przegląd zmian jako stały krok przy każdym mergu.
Na co uważać: Sam przegląd zmian nie wyłapie starych luk w kodzie, którego nikt od miesięcy nie ruszał. Bez okresowego pełnego audytu pozostaną niewidoczne.
7.Otwarte modele podniosły stawkę dla wszystkich
Na czym polega: Autor wiąże falę incydentów z coraz sprawniejszymi modelami o otwartych wagach, które atakujący mogą uruchomić u siebie i skierować na cudze systemy.
Jak stosować: Załóż, że Twoje luki ktoś znajdzie — lepiej, żebyś zrobił to pierwszy. Regularne audyty własnego kodu i zależności to dziś element higieny pracy, nie luksus.
Na co uważać: Nie patrz wyłącznie na własny kod. Lista zaatakowanych projektów (PHP, Node.js, GitLab) pokazuje, że wektorem ataku bywają zależności i infrastruktura.
8.Buduj proces niezależny od jednego dostawcy
Na czym polega: Gdy autor zbliżał się do limitu użycia Claude, przeniósł przetwarzanie biletów do Codexa — fabryka dalej działała bez przestoju.
Jak stosować: Jeśli automatyzujesz naprawy, zadbaj o to, żeby agenta wykonawczego dało się podmienić w trakcie cyklu bez przepisywania całego procesu.
Na co uważać: Różne agenty różnie radzą sobie z zadaniami. Etap weryfikacji i przeglądu warto zostawić narzędziu, które w Twoim projekcie daje najlepszą jakość, a nie temu, który ma akurat wolny limit.
9.Wywołanie skilla to jedna komenda — nie ma wymówki
Na czym polega: Instalacja sprowadza się do pojedynczej komendy (globalnie albo per projekt przez symlink), a audyt uruchamia zwykły prompt — „zrób przegląd bezpieczeństwa tej bazy kodu” — albo komenda /security-audit.
Jak stosować: Wpisz wywołanie skilla do check-listy na koniec iteracji. Próg wejścia jest na tyle niski, że odkładanie audytu trudno uzasadnić.
Na co uważać: Pierwszy pełny skan dojrzałego projektu trwa i generuje lawinę zgłoszeń — zarezerwuj czas na ich przesianie, zanim zaczniesz cokolwiek naprawiać.
10.„Działa” nie znaczy „bezpieczne”
Na czym polega: Większość twórców skupia się na budowaniu funkcji. Aplikacja autora działała i miała użytkowników, a mimo to każdy nowy użytkownik mógł sięgnąć do wrażliwych danych.
Jak stosować: Przy każdym większym kamieniu milowym — publikacji, pierwszej fali użytkowników — uruchom audyt, zanim wystawisz produkt na szerszy świat.
Na co uważać: Jeden czysty skan nie zamyka tematu na zawsze. Kod rośnie, więc ryzyko wraca razem z każdą nową funkcją.
Redakcyjne tłumaczenie
„Breach October”: miesiąc, w którym włamano się do fundamentów
Kończy się październik, ale w branży_security krąży już pod inną nazwą — „Breach October”. W ciągu zaledwie czterdziestu godzin odnotowano ponad 27 poważnych incydentów bezpieczeństwa w produktach takich jak PHP, Node.js, Java czy GitLab, a także w Signal, WordPressie i wielu innych. To narzędzia, z których codziennie korzystają miliony ludzi — i właśnie one stają się celem ataków przeprowadzanych z pomocą sztucznej inteligencji.
(Informacja dodatkowa: „Breach October” to potoczne określenie fali włamań i prób przejęcia popularnych narzędzi open source, które zbiegły się w październiku.)
Dlaczego właśnie teraz: modele w rękach drugiej strony
Powód jest prosty. Mamy dziś mnóstwo modeli o otwartych wagach, które robią się naprawdę sprytne — i nic nie stoi na przeszkodzie, żeby sięgały po nie druga strona, do włamywania się w cudze systemy.
Właśnie dlatego w tym materiale pokazuję narzędzie, które uważam za numer jeden, jeśli chodzi o bezpieczeństwo: skill „security audit” od Cloudflare. Skill to nic innego jak rozszerzenie dodające agentowi nową umiejętność. Ten konkretny pomógł mi odkryć całą masę luk w aplikacji, nad którą siedzę od ponad pół roku i w której są już prawdziwi użytkownicy — a o istnieniu tych luk nie miałem pojęcia. Pokażę, jak przeprowadziłem nim pełny przegląd, jak naprawiłem znalezione problemy i jak sprawdziłem, że poprawki faktycznie zadziałały.
I od razu rada: jeśli podejrzewasz, że Twoja aplikacja ma poważne dziury, zacznij od wymiany kluczy. Bezpieczeństwo ogarniamy w pierwszej kolejności, nowe funkcje w drugiej.
Instalacja: globalnie albo per projekt
Na stronie skilla wszystko jest wypisane. Można go zainstalować globalnie — jedną komendą — albo tylko dla konkretnego projektu, kopiując drugą komendę z dokumentacji. Ja wchodzę w terminal w katalogu projektu, odpalam instalację i po chwili rozpoczyna się kilka pytań konfiguracyjnych.
Instalator dopytuje, z jakiego agenta korzystamy — wybieram Claude Code. Potem zgadzam się na instalację per projekt przez symlink, potwierdzam kontynuację i przyjmuję jeszcze doinstalowanie towarzyszącego komponentu. Po kilku chwilach wszystko siedzi na miejscu.
Pierwszy przebieg: pełny raport luk
Wystarczy teraz uruchomić Claude Code i poprosić: „zrób przegląd bezpieczeństwa tej bazy kodu”. Kto woli wywołać skill wprost, ma do dyspozycji komendę z ukośnikiem — /security-audit — widoczną na liście dostępnych umiejętności.
Wklejam pierwszy prompt, startuję sesję i czekam. Skan chwilę trwa; po drodze widać, że równolegle pracuje kilka podagentów nad audytem całości. Czekam, aż wszystkie skończą.
Po jakimś czasie dostaję pełny raport: gdzie są luki i jakie. Na szczycie listy trzy obszary: klucze bezpieczeństwa, darmowe kredyty i dane zespołu. W samej aplikacji wylądowało tego sporo.
Drugi przebieg: weryfikacja zgłoszeń
Do raportu podpiąłem jeszcze jednego podagenta, którego zadaniem było sprawdzenie całości: odpala kolejne podagenty i testuje, czy zgłoszone luki są prawdziwe — na tymczasowej bazie danych, więc bez ryzyka dla produkcji.
Bilans wyszedł taki: z 26 problemów 21 się potwierdziło, 3 okazały się fałszywe, a 2 jeszcze nie zostały przejrzone.
Na tablicy zebrało się 18 biletów w kolumnie „gotowe do pracy”, ułożonych według wagi zagrożenia. Spójrzcie na przykłady: nowy użytkownik mógł odczytać główny klucz rozliczeniowy — to nie jest dobry znak. Każdy mógł podejrzeć zmiany na liście darmowych kredytów. Właśnie takie rzeczy trzeba w aplikacji naprawić.
Większość programistów skupia się na budowaniu — bezpieczeństwo schodzi na dalszy plan. I właśnie dlatego taki skill jest bezcenny: wyłapuje słabe punkty wcześnie, zanim aplikacja realnie wystawi bok.
Od raportu do biletów na tablicy
Sam raport niczego nie naprawi, więc całość sprowadziłem do konkretów. Użyłem skilla Wayfinder z kolekcji Mapokor: bierze taki raport i rozbija go na osobne zadania. Tak powstało 18 biletów na tablicy Kanbana.
(Informacja dodatkowa: Mapokor to znana społecznościowa kolekcja skilli dla Claude Code, a Wayfinder służy m.in. do przekładania dużych dokumentów i planów na konkretne ticket’y.)
Fabryka oprogramowania przejmuje bilety
Następnie uruchomiłem swoją „super tablicę”, czyli moją fabrykę oprogramowania, i kazałem jej przejrzeć całą tablicę projektu. Tym razem agentem wykonawczym jest Codex — z prostego powodu: kończył mi się limit użycia Claude. Warto mieć taką furtkę.
Bilety rozdzielone między agenty, w obiegu trzy role: builder, QA i reviewer. Każde zadanie przechodzi przez cały ten ciąg. Agenty biorą się do biletów, a my wracamy, gdy wszystkie będą domknięte.
Scalone i domknięte
Po przetworzeniu całej kolejki wszystkie poprawki zostały scalone do produkcji. Zamkniętych biletów: 16 plus kilka dodatkowych, o których wspomnieliśmy po drodze — łącznie około 18. Na tablicy zero w kolumnie „ready”, zero u buildera, w QA i w review. Wszystko w „done”.
I najważniejszy krok całego procesu: po scaleniu zmian odpaliłem pełny audyt od nowa. Tym razem wyszły tylko dwa drobne błędy — nic w skali tego, co widzieliśmy na początku. Właśnie tak domyka się obieg: przegląd → naprawa → kontrolny przegląd, który potwierdza, że podatności faktycznie zniknęły.
W całym łańcuchu może pracować to, co masz pod ręką: skill audytowy, Wayfinder albo dowolny inny skill do developmentu sterowanego specyfikacją, potem podagenty dłubiące nad biletami równolegle, scalanie i łatanie. A na końcu zawsze audyt kontrolny — i ewentualna kolejna runda drobnych poprawek.
Dwa skille, dwa różne zadania
Ktoś mógłby zauważyć: przecież istnieje jeszcze skill „Claude Code security review”. Sprawdziłem to — to dwa różne narzędzia. Jedno przeszukuje całą bazę kodu w poszukiwaniu luk. Drugie patrzy na ostatnie zmiany i na kod w ich pobliżu.
To drugie świetnie nadaje się do automatyzacji: składasz pull request, a po nim uruchamiasz skilla, który kontroluje wyłącznie to, co ten PR wprowadził. Natomiast skill od Cloudflare to raczej rytuał raz na miesiąc albo raz na dwutygodniowy sprint — kontrola, czy w całym projekcie nie zostały dziury, które mogły umknąć uwadze agentów.
Czyli praktycznie: nigdy nie robiłeś żadnego przeglądu bezpieczeństwa? Zacznij od skilla Cloudflare. Chcesz kontrolę przy każdym pull requeście? Sięgnij po security review od Anthropic.
Na koniec
Jeśli materiał był dla Ciebie pomocny, zostaw łapkę w górę. A jeśli ciekawi Cię, jak moja fabryka oprogrammowania sama wysyła produkty i funkcje na rynek, zajrzyj do filmu podlinkowanego obok. Do zobaczenia następnym razem.