Sesja za Tobą. Tablica pełna karteczek, na każdej jakieś zagrożenie. Ktoś podsumowuje: „spoko, wrzucimy do backloga” — i… nic. Po miesiącu te same zagrożenia wracają na kolejnej sesji.
„Wrzucimy do backloga” jest za ogólne. To nie akcja, to obietnica akcji. A obietnica nie powstrzyma ataku.
W tym wpisie pokazujemy 5 formatów przełożenia zagrożenia na zadanie, każdy z przykładem roboczym. Po drodze: dlaczego modelowanie zagrożeń (ang. threat modeling) zwykle nie wymaga nowego procesu, i co z formalnym modelem (bo to zależy od poziomu).
Skąd się biorą te wyniki: krok „co z tym zrobimy”
Sesja przebiega przez cztery pytania: co budujemy, co może pójść źle, co z tym zrobimy, czy zrobiliśmy to wystarczająco dobrze. Cały przebieg rozkładamy krok po kroku w osobnym wpisie. Tu interesuje nas pytanie trzecie: to ono zamienia tablicę w realną robotę.
Cel tego kroku NIE jest domknięcie wszystkich zagrożeń na sesji. Jedna sesja daje częściowy widok, i to jest w porządku. Omawiamy top-N najważniejszych, resztę zostawiamy w rejestrze. Cel jeden: zamienić omówione zagrożenia w akcje, które ktoś zrobi.
Andrzej podczas prezentacji na THS 2024 ujął to tak: „To trochę jak automatyzować narzędzia w CI/CD, ale nic nie robić z alertami — może lepiej w ogóle ich nie mieć, żeby nie patrzeć na te czerwone.” Jeśli nie domkniesz kroku „co z tym zrobimy”, cały wysiłek sesji idzie na marne.
Wynikiem sesji nie powinna być goła lista zagrożeń, lecz lista akcji.
„Wrzucimy do backloga” — i dlaczego to za mało
Problem w tym, że samo „do backloga” nie mówi w jakiej formie, kto to weźmie, kiedy ani po czym poznamy, że zrobione. Zagrożenie wrzucone bez formatu to notatka, nie zadanie. A notatki świetnie się pomija, robiąc miejsce dla „ważniejszych” ticketów.
Modelowanie zagrożeń niekoniecznie wymaga nowego procesu. Zwykle może wpiąć się w to, co już macie. Nie musisz zakładać osobnego „rejestru zagrożeń”. Wynik możesz wrzucić do backloga, zaplanować w sprincie, wpisać do Definition of Done albo do kryteriów akceptacji. Użyjesz tego, z czego już korzystasz.
Dobre porównanie: modelowanie zagrożeń to taka retrospekcja. Z retro też nie wychodzisz z listą problemów przyklejoną do ściany. Wychodzisz z action itemami, które ktoś bierze na konkretny sprint, z konkretnym „zrobione”.
Każde zagrożenie, które chcecie zaadresować, wychodzi z sesji (albo powinno wyjść) w jednym z 5 formatów. Nie jako „do backloga”.
5 formatów akcji (z przykładem roboczym)
Mamy 5 formatów. Po kolei: co to jest, kiedy po niego sięgasz i jak wygląda w praktyce.
Żebyś widział, że to jeden i ten sam materiał przełożony na różne formy, prowadzimy wszystkie pięć przykładów na jednym zagrożeniu. Bierzemy klasykę: endpoint logowania /login bez ograniczania liczby prób (ang. rate-limiting). Otwiera to drzwi atakom typu brute-force i credential stuffing (czyli upychaniu wykradzionych skądinąd par login-hasło): atakujący w spokoju przemiela tysiące prób. To samo zagrożenie, pięć różnych form akcji.
1. Tech Debt (dług technologiczny)
Tech Debt, czyli świadomie zarejestrowany kompromis, który spłacamy później.
Kiedy sięgasz? Gdy zagrożenie dotyczy istniejącego kodu, nie blokuje najbliższego wydania, ale chcesz je udokumentować i zaplanować spłatę. To nie jest zamiatanie pod dywan, to świadome „akceptujemy ryzyko, ale z terminem”.
Przykład roboczy:
Dług: endpoint
/loginbez rate-limitingu. Ryzyko: brute-force / credential stuffing. Decyzja: ryzyko akceptowane do końca Q3. Spłata: limiter na bramie API, najpóźniej w sprincie zamykającym kwartał.
To dojrzałe „margines, który świadomie akceptujemy” zamiast sztywnej bramki „zero podatności albo nie wydajemy”. Z terminem i właścicielem, nie z dobrą intencją.
2. Kryteria akceptacji (Acceptance Criteria, GIVEN / WHEN / THEN)
Kryteria akceptacji, czyli warunki, które historyjka musi spełnić, żeby uznać ją za zrobioną.
Kiedy sięgasz? Gdy zagrożenie dotyczy funkcjonalności, którą i tak właśnie budujesz. Nie tworzysz osobnego zadania, tylko dopinasz bezpieczeństwo do istniejącej user story.
Przykład roboczy:
GIVEN niezalogowany użytkownik WHEN wyśle 10 nieudanych prób logowania z tego samego IP w ciągu minuty THEN kolejne próby z tego IP są blokowane na 15 minut, a zdarzenie trafia do logów.
To najczystsze „wpięcie w to, co macie” z całej piątki: bezpieczeństwo staje się częścią definicji funkcji. Skoro budujesz logowanie, to odporność na nadużycie po prostu należy do tego, co znaczy „logowanie gotowe”.
3. Definition of Done (DoD)
Definition of Done, czyli wspólna, stała definicja „ukończone” dla wszystkich historyjek w zespole.
Kiedy sięgasz? Gdy zagrożenie jest powtarzalne, przekrojowe i nie chcesz pisać tego samego kryterium akceptacji przy każdej kolejnej historyjce. Zamiast tego raz podnosisz poprzeczkę dla całego zespołu.
Przykład roboczy — dodajesz do DoD pozycję:
Każdy nowy endpoint zmieniający stan ma kontrolę nadużycia (rate-limiting / throttling) albo świadomie udokumentowany jej brak.
I tu rzecz, którą warto zapamiętać: kryteria akceptacji to per historyjka; Definition of Done to dla wszystkich historyjek naraz. AC dopinasz do tej jednej funkcji logowania; DoD sprawia, że już nigdy żaden nowy endpoint nie wyjdzie bez przemyślanej ochrony, bo inaczej z definicji nie jest „zrobiony”.
4. Timeboxed Spike
Spike, czyli krótkie, ograniczone w czasie (ang. *timeboxed) zadanie badawcze: nie wytwarzamy, tylko odpowiadamy na jedno pytanie.*
Kiedy sięgasz? Gdy zagrożenie jest realne, ale jeszcze nie wiesz, jak je rozwiązać (albo czy w ogóle Cię dotyczy). Najpierw kupujesz wiedzę, a dopiero potem planujesz robotę.
Przykład roboczy:
Spike (max 1 dzień): sprawdzić, czy nasza brama API daje rate-limiting out-of-the-box. Jeśli tak: oszacować koszt włączenia. Jeśli nie: przygotować 2 warianty implementacji. Wynik: rekomendacja + estymata.
Spike chroni Cię przed wrzucaniem do backloga zadań, których nikt nie umie wycenić. A takie umierają najszybciej, bo nikt nie wie, od czego je ugryźć.
To zresztą jeden z najczęstszych momentów na sesjach, zwłaszcza w większych organizacjach z silnym podziałem na zespoły. W pewnym momencie pada pytanie „a czy my już to robimy?” (na przykład „czy mamy WAF na tej bramie?”) i nikt na sali nie potrafi odpowiedzieć: trzeba dopytać kogoś z infrastruktury. To nie porażka, to normalka, i właśnie po to jest spike. Przekuwasz „nie wiem” w konkretne zadanie badawcze, które jednoznacznie rozstrzygnie, czy dane zagrożenie realnie Cię dotyczy. W praktyce taki moment wychodzi w pierwszych 5–10 minutach niemal każdej pierwszej sesji z nowym zespołem.
5. Epic (AS A / WE NEED / SO THAT)
Epic, czyli duża inicjatywa spinająca wiele historyjek pod jednym celem.
Kiedy sięgasz? Gdy zagrożenie jest systemowe i nie zmieści się ani w jednym sprincie, ani w jednej historyjce. Potrzebujesz parasola, pod który podepniesz wiele mniejszych zadań.
Przykład roboczy:
AS A zespół platformy WE NEED spójny mechanizm ochrony przed nadużyciem na wszystkich publicznych endpointach SO THAT ograniczamy całą klasę ataków automatycznych (brute-force, scraping, enumeracja) w całym produkcie.
Pod taki epic trafiają potem konkretne historyjki, już z kryteriami akceptacji w stylu GIVEN/WHEN/THEN. /login jest wtedy pierwszym z wielu endpointów, a nie wyjątkiem łatanym ad hoc.
Ściąga: 5 formatów na jednym ekranie
| Format | Kiedy sięgasz | Zakres | Przykład (1 linia) |
|---|---|---|---|
| Tech Debt | istniejący kod, świadomy kompromis na później | punktowy | „/login bez rate-limitingu → spłata Q3" |
| Kryteria akceptacji (GIVEN/WHEN/THEN) | budujesz właśnie tę funkcję — dopnij bezpieczeństwo | per historyjka | „WHEN 10 nieudanych prób → blokada IP na 15 min" |
| Definition of Done | zagrożenie powtarzalne / przekrojowe | wszystkie historyjki naraz | „każdy nowy endpoint ma kontrolę nadużycia" |
| Timeboxed Spike | masz przeczucie, że problem jest; nie wiesz jak go rozwiązać | badawczy, ograniczony w czasie | „1 dzień: czy brama daje rate-limiting?" |
| Epic (AS A / WE NEED / SO THAT) | zagrożenie systemowe, > 1 sprint | parasol nad wieloma historyjkami | „spójna ochrona przed nadużyciem na wszystkich endpointach" |
Który format kiedy? Szybka heurystyka
Nie chcemy zostawić Cię z piątką formatów i samotnym „to zależy”. Oto ścieżka decyzyjna w pięciu pytaniach:
- Budujesz tę funkcję właśnie teraz? → kryteria akceptacji (dopnij bezpieczeństwo do tej historyjki).
- To się powtarza w wielu historyjkach? → Definition of Done (podnieś poprzeczkę raz, dla wszystkich).
- To istniejący kod i świadomie odkładasz naprawę? → Tech Debt (z terminem i właścicielem).
- Nie wiesz jeszcze, jak to rozwiązać? → Spike (najpierw kup wiedzę).
- To za duże na jeden sprint? → Epic, a pod niego historyjki z kryteriami akceptacji.
Te formaty się nie wykluczają. Jedno zagrożenie potrafi przejść całą drogę: Spike (czy brama API daje rate-limiting?) → Epic (ochrona na wszystkich endpointach) → kryteria akceptacji w poszczególnych historyjkach. Sztuka polega na tym, żeby zawsze wybrać któryś — nigdy nie zostawać przy „wrzucimy do backloga”.
A formalny model zagrożeń? Zależy od poziomu
W tym momencie pojawia się sensowne pytanie: „skoro wynikiem są wpisy do backloga, to gdzie jest ten słynny formalny model zagrożeń?”
Odpowiedź: te 5 formatów to output akcji, a nie formalny artefakt. Czy obok nich powstaje formalny model, zależy od poziomu, na którym modelujesz. Rozkładamy te poziomy w przewodniku poziomy modelowania zagrożeń: kto, co i czym modeluje; tutaj wystarczy gradient artefaktów:
- Organizacja → model formalny → wkładka do analizy ryzyka i ciągłości działania (ang. business continuity). Odbiorca: zarząd.
- System → model formalny → wkładka do oceny bezpieczeństwa: pentest, ocena podatności. Odbiorca: testerzy bezpieczeństwa.
- Aplikacja → model niekoniecznie formalny (często wystarczy zdjęcie tablicy z karteczkami) → akcje do backloga.
- Funkcjonalność → często BEZ formalnego modelu → TYLKO te formaty: kryteria akceptacji, DoD, wpisy do backloga.
Akcje do backloga to naturalny wynik niskich poziomów. Na poziomie aplikacji i funkcjonalności praca jest tak blisko developmentu, że formalny dokument zabrałby czas i dał małą wartość. Na wyższych poziomach artefakt jest formalny i trafia do innych odbiorców: zarządu, testerów bezpieczeństwa. Te wpisy do backloga nie są „modelem zagrożeń” — są śladem tego, co z modelu wynika.
Im bliżej pojedynczej funkcjonalności, tym mniej formalnego dokumentu, a więcej zwykłych wpisów do backloga. I tak ma być.
Domknięcie pętli: kto pilnuje, żeby akcje nie umarły
Akcja w backlogu to jeszcze nie koniec. Czwarte pytanie sesji („czy zrobiliśmy wystarczająco dobrze?”) domyka przegląd backloga po 30 dniach, nie sama sesja. Bez niego ładnie sformatowane zadania potrafią cicho zniknąć. Pilnuje tego zwykle Security Champion: osoba blisko zespołu, która dba, żeby wpisy z modelowania nie przepadły (o tym piszemy osobno przy wdrożeniu).
Format zamienia zagrożenie w zadanie; przegląd po 30 dniach zamienia zadanie w zrobione.
Co robić, jak żyć?
Po najbliższej sesji:
- Dla każdego omówionego zagrożenia wybierz format z piątki — nigdy nie kończ na „do backloga”.
- Zapisz w narzędziu, którego już używasz (Jira, GitHub Issues, tablica). Bez osobnego rejestru zagrożeń na start.
- Użyj heurystyki z sekcji wyżej: pięć pytań, pięć ścieżek.
- Na poziomie funkcjonalności nie wymuszaj formalnego modelu. Wystarczą kryteria akceptacji, DoD, wpisy do backloga.
- Wpisz przegląd po 30 dniach do kalendarza i daj Security Championowi mandat, żeby go pilnował.
Referencje: Scrum Guide; OWASP; ThoughtWorks (Agile threat modeling jako ogólny koncept branżowy). Kryteria akceptacji, Definition of Done, Spike i Epic to standardowe pojęcia z praktyki agile, nie nasze nazewnictwo.
Damy Ci znać, gdy opublikujemy coś nowego.
Artykuł albo odcinek podcastu. Bez spamu. W każdej chwili możesz się wypisać.
Zapisując się, akceptujesz politykę prywatności.