Security by design należy do backlogu

Security to praca

Większość zespołów nie ignoruje security dlatego, że go nie lubi. Ignoruje je, bo strukturalnie ono w ich świecie nie istnieje. Nie ma na nie ticketu, właściciela, definicji ukończenia. Żyje w dokumencie polityki, którego nikt nie otwiera, i w przedwdrożeniowej checkliście, której wszyscy nie znoszą.

Tymczasem realna praca security — testy autoryzacji, rotacja sekretów, higiena zależności, ślady audytowe, rate limity — to zwykła praca inżynierska. Ma zakres, ma kryteria akceptacji, da się ją wycenić, zreviewować i dowieźć. W momencie, w którym przyjmiesz tę ramę, security przestaje być rytuałem compliance i staje się czymś, co zespół dostarczający może naprawdę posiadać.

Dlaczego późna checklista zawodzi

Typowe podejście to bramka na końcu: pentest przed startem, checklista przed dużym wydaniem, coroczny audyt. Siedziałem po obu stronach takich przeglądów i wzorzec jest stały — znajdują realne problemy w momencie, w którym ich naprawa jest najdroższa.

• Architektura jest już zamrożona. Brakująca granica tenanta odkryta tydzień przed startem to nie bugfix, tylko przeprojektowanie, na które nikt nie ma czasu. Więc jedzie na produkcję z kontrolą kompensacyjną i obietnicą.
• Wiedza się nie transferuje. Zewnętrzny raport ląduje jako PDF ze znaleziskami. Zespół łata konkretne wystąpienia i nie uczy się niczego strukturalnego, więc kod z następnego kwartału powtarza tę samą klasę błędu.
• Motywacją jest zaliczyć, nie poprawić. Gdy security jest bramką, racjonalny ruch to zaspokoić bramkę minimalną zmianą. Gdy jest pracą w backlogu, racjonalny ruch to realnie obniżyć ryzyko — bo to zamyka ticket.

Nic z tego nie jest argumentem przeciw pentestom czy audytom — to cenna weryfikacja. To argument przeciw używaniu ich jako mechanizmu podstawowego, bo weryfikacja nie zrekompensuje nieistniejącej pracy projektowej.

Threat modeling, który da się dowieźć

Threat modeling ma opinię ciężkiego: warsztaty, macierze STRIDE, diagramy dłuższe niż sama funkcja. To, co realnie robię w zespołach produkcyjnych, jest dużo mniejsze — i przeżywa właśnie dlatego, że jest małe. Dla każdego projektu dotykającego pieniędzy, tożsamości, danych osobowych albo granicy zaufania odpowiadamy pisemnie na cztery pytania:

1. Co budujemy — jeden akapit i jeden diagram?
2. Co może tu pójść źle? (Dziesięć minut uczciwej burzy mózgów bije pustą macierz.)
3. Co robimy z tym, co może pójść źle?
4. Czy zapisaliśmy odpowiedzi tam, gdzie żyje ticket?

Wynik to notatka threat model przypięta do designu albo epika — pół strony, nie dokument. Jej prawdziwą wartością nie jest kompletność, tylko to, że ryzyka mają teraz nazwy — a nazwane ryzyka mogą stać się ticketami.

Zamień ryzyka w elementy backlogu

Użyteczny backlog security mapuje konkretne ryzyka na konkretną pracę inżynierską. Nie „popraw bezpieczeństwo" — to życzenie, nie ticket. Mapowanie, którego używam, wiąże każde ryzyko z kontrolą, sygnałem i mechanizmem przeglądu:

ryzyko: dostęp do danych między tenantami
kontrola: zapytania scope'owane per tenant + testy autoryzacji na każdej ścieżce odczytu
sygnał: audit event dla uprzywilejowanych odczytów, alert na kształt zapytania cross-tenant
przegląd: punkt w checkliście PR + notatka threat model podlinkowana w epiku

ryzyko: wyciek poświadczeń usługi
kontrola: sekrety w zarządzanym vaulcie, zero sekretów w plikach env i logach CI
sygnał: skan sekretów w CI, log audytowy dostępu do vaulta
przegląd: runbook rotacji testowany co kwartał

ryzyko: zależność ze znanym CVE trafia na produkcję
kontrola: lockfile + automatyczny skan zależności blokujący na poziomie critical
sygnał: raport skanera w każdym przebiegu pipeline'u
przegląd: cotygodniowy triage znalezisk nieblokujących

Zapisana w ten sposób praca security jest wycenialna i priorytetyzowalna obok pracy funkcjonalnej — i o to dokładnie chodzi. Product owner może zważyć „audit eventy dla akcji uprzywilejowanych" przeciw funkcji, bo obie rzeczy są teraz czytelnymi jednostkami pracy o widocznej wartości.

Security definition of done

Backlog obsługuje znane ryzyka. Definicja ukończenia obsługuje domyślną postawę — kontrole, które dotyczą normalnej pracy bez konieczności pamiętania o nich. Musi być na tyle krótka, żeby zmieścić się w realnym dostarczaniu; lista na dwadzieścia pozycji będzie ignorowana od trzeciego tygodnia.

• Ścieżka autoryzacji pokryta testami — łącznie z przypadkiem negatywnym, nie tylko happy path.
• Nowe sekrety opisane, trzymane w vaulcie i rotowalne bez deployu.
• Audit event emitowany dla każdej akcji uprzywilejowanej lub destrukcyjnej.
• Wejście na granicach zaufania walidowane i z limitem rozmiaru.
• Dashboard operacyjny albo alert zaktualizowany, gdy zmiana wprowadza ryzykowny przepływ.

Pięć punktów. Wszystko powyżej awansuje do backlogu jako jawna praca. Z mojego doświadczenia: krótka lista jest stosowana konsekwentnie, a konsekwencja bije pokrycie — skromna kontrola stosowana zawsze wygrywa z gruntowną stosowaną czasami.

Kontrole, które żyją w pipeline

Wszystko, co da się sprawdzić mechanicznie, powinno być sprawdzane mechanicznie — bo kontrole w pipeline jako jedyne nie gniją, gdy zespół jest zajęty. Baza, którą ustawiam na nowych platformach:

• Skan sekretów przy każdym pushu — tani, wysoki sygnał, łapie najbardziej wstydliwą klasę incydentów, zanim powstanie.
• Skan zależności z progiem blokującym dla podatności krytycznych i rytmem triage dla reszty. Skaner bez triage produkuje tylko szum, który ludzie uczą się ignorować.
• Analiza statyczna dostrojona do reguł, na których zespołowi naprawdę zależy. Pięćdziesiąt ostrzeżeń, których nikt nie czyta, jest gorsze niż pięć blokujących merge.
• Review infrastruktury jako kodu — security groups, uprawnienia IAM i publiczne buckety przeglądane jak kod aplikacji, bo są kodem aplikacji.

Kompromis to tarcie kontra gnicie. Każda kontrola blokująca dodaje tarcia; każda doradcza zamienia się w tapetę. Wybieram: mało, blokująco i dobrze dostrojone — a potem rozszerzam powoli, w miarę jak rośnie tolerancja zespołu.

Uwagi z produkcji

• Audit eventy potrzebują czytelnika. Emitowanie to połowa pracy; druga połowa to miejsce, w którym ktoś realnie zapyta „kto czytał ten rekord w marcu". Ścieżkę zapytań projektuj razem ze zdarzeniem.
• Rotacja, której nikt nie przećwiczył, nie istnieje. Sekret jest rotowalny wtedy, gdy rotacja została wykonana, zmierzona i opisana — a nie wtedy, gdy architektura teoretycznie na nią pozwala.
• Rate limity to decyzja produktowa. Ustalaj je z produktem, publikuj w dokumentacji API i alarmuj, zanim użytkownicy w nie uderzą — inaczej pierwszym znakiem działania Twojej ochrony będzie eskalacja w supporcie.
• Incydenty zasilają backlog. Każdy incydent związany z bezpieczeństwem powinien kończyć się co najmniej jednym elementem backlogu, który usuwa klasę błędu, nie tylko wystąpienie. Ta pętla czyni cały system samodoskonalącym.

Podsumowanie

• Security zawodzi strukturalnie, nie moralnie — daj mu właścicieli, tickety i kryteria akceptacji.
• Późne bramki znajdują problemy w najdroższym momencie; praca na etapie projektowania usuwa klasę błędu, nie wystąpienie.
• Threat modeling w czterech pytaniach, pół strony, przypięte do epika.
• Każde ryzyko mapuj na kontrolę, sygnał i mechanizm przeglądu — ten kształt czyni je wycenialnym.
• Security definition of done trzymaj na pięciu punktach; konsekwencja bije pokrycie.
• Mechaniczne kontrole pchaj do pipeline'u: mało, blokująco, dobrze dostrojone.