CyberShieldON » DevSecOps w praktyce: ludzie i procesy

Wiele organizacji wdraża DevSecOps tak samo, jak kupuje nowe narzędzia – zamawia platformę, spina ją z CI/CD i zakłada, że „bezpieczeństwo się zrobi”. Przez pierwsze miesiące wszystko wygląda dobrze: raporty są, alerty się generują, na prezentacjach pojawia się modne hasło Secure by Design. Problem wraca przy pierwszym poważniejszym incydencie. Okazuje się, że nikt nie jest właścicielem całego procesu, zespoły nie rozumieją priorytetów ryzyka, a metryki bezpieczeństwa nie mają żadnego przełożenia na decyzje biznesowe.

W tej części serii pokazujemy DevSecOps od strony, o której najrzadziej mówią vendorzy: ludzi i procesów. Narzędzia są ważne, ale bez jasnych ról i odpowiedzialności tylko kolejną warstwą hałasu.

Model odpowiedzialności DevSecOps: strategiczny, taktyczny i operacyjny

DevSecOps to system odpowiedzialności, który działa na trzech poziomach: strategicznym, taktycznym i operacyjnym. Bez tego podziału organizacje powielają chaos decyzyjny – narzędzia istnieją, ale nikt realnie nie odpowiada za całość procesu, od decyzji zarządu po codzienną pracę zespołów developerskich.

W praktyce wygląda to tak: Zarząd ustala apetyt na ryzyko i budżet, AppSec projektuje „jak to zrobić”, a zespoły developerskie codziennie podejmują dziesiątki mikrodecyzji w kodzie i w PR-ach. Jeśli choć jeden z tych poziomów „wysiądzie”, DevSecOps zamienia się w patchwork – dużo raportów i mało realnie zredukowanego ryzyka.

Poziom strategiczny: zarząd, CTO, CISO

Na poziomie strategicznym zapadają decyzje, które determinują skuteczność całego programu. Zarząd definiuje apetyt na ryzyko, ustala standardy zgodności oraz nadaje priorytet inicjatywom AppSec. CTO i CISO odpowiadają za to, by DevSecOps był programem organizacyjnym, a nie „projektem działu bezpieczeństwa”. Bez jednoznacznych sponsorów na tym poziomie Security Champions, Agile Security i metryki pozostaną teorią lub lokalnymi eksperymentami w pojedynczych zespołach.

Poziom taktyczny: AppSec i Security Engineering

Na poziomie taktycznym kształtuje się architektura procesów: dobór narzędzi, polityki kodowania, standardy pracy w pipeline’ach oraz zasady priorytetyzacji podatności. To tutaj powstają wytyczne, które mają być zrozumiałe dla zespołów devowych, a jednocześnie spójne z regulacjami i standardami bezpieczeństwa. Ten poziom odpowiada także za szkolenia i komunikację – wyznacza rytm współpracy między zespołami developmentu i bezpieczeństwa.

Jeśli AppSec działa jak „policja” albo „gatekeeper”, a nie jak partner, organizacja będzie miała DevSecOps tylko z nazwy.

Poziom operacyjny: developerzy i Security Champions

Poziom operacyjny to codzienna praca w backlogu, kodzie i pipeline’ach. Tu zapadają decyzje, które w największym stopniu wpływają na ryzyko: sposób tworzenia kodu, reakcja na alerty, jakość PR-ów, dyscyplina pracy z zależnościami. Bez klarownej odpowiedzialności operacyjnej – zwłaszcza bez Security Champions – zespoły nie są w stanie utrzymać jakości bezpieczeństwa na poziomie dziennej pracy.

W efekcie DevSecOps kończy jako „słowo-klucz” w prezentacji, nie jako praktyka.

Security Champions: jak działa program, który ma sens

Skoro na poziomie operacyjnym to zespoły developerskie biorą na siebie codzienne decyzje o ryzyku, potrzebują wzmocnienia w postaci roli, która spina świat AppSec z realiami sprintów i backlogu. Tę funkcję pełnią Security Champions (SC).
Większość firm wdrażających Security Champions kończy z listą „entuzjastów bezpieczeństwa”, którzy nie mają ani czasu, ani mocy decyzyjnej. To naturalny efekt, jeśli rola SC nie jest wbudowana w strukturę pracy zespołu i pozostaje dodatkiem do „normalnych obowiązków”.

Dobry program SC działa inaczej – wzmacnia autonomię zespołów i skraca ścieżkę decyzyjną między AppSec a developmentem.
W dojrzałych organizacjach Security Champion opiekuje się zwykle jednym lub kilkoma zespołami developerskimi i ma formalnie zarezerwowaną część czasu (np. 10–20%) na zadania związane z bezpieczeństwem. To nie „mini-pentester”, tylko łącznik: rozumie ryzyka, zna kontekst produktu i potrafi przełożyć wymagania AppSec na realne decyzje w backlogu – które podatności łatać w tym sprincie, jak zmienić Definition of Done, jakie testy dołożyć do pipeline’a.

Typowy rytm pracy SC wygląda następująco: raz w sprincie przegląd alertów bezpieczeństwa i ustalenie priorytetów z Product Ownerem, raz w miesiącu krótka sesja „lessons learned” po błędach bezpieczeństwa, a raz na kwartał aktualizacja standardów secure codingu z zespołem. To przykład, jak kultura bezpieczeństwa może wyrastać z codziennej pracy, a nie tylko z jednorazowych szkoleń.

Jak mierzyć skuteczność programu SC

Bez metryk program Security Champions łatwo degeneruje się do roli „szkolenia raz na kwartał”. Warto mierzyć przede wszystkim:
► spadek liczby błędów bezpieczeństwa na PR,
► skrócenie czasu remediacji podatności w zespołach,
► liczbę zamkniętych ticketów bezpieczeństwa
► poprawę wskaźnika test coverage w obszarze bezpieczeństwa (np. pokrycie krytycznych endpointów API testami automatycznymi).

Jeśli te liczby idą w dobrą stronę, widać, że rola SC realnie wpływa na jakość produktu.

DevSecOps w Agile: jak włączyć bezpieczeństwo bez blokowania zespołów

Deklaracja „bezpieczeństwo w każdej ceremonii Agile” brzmi dobrze, ale rzadko wynika z niej praktyka. Realne wdrożenie wymaga prostych, powtarzalnych mechanizmów, które nie zabijają zwinności zespołów. DevSecOps w Agile to nie osobny etap „przed produkcją”, ale zestaw nawyków zaimplementowanych w codzienny rytm sprintów.

Security w ceremoniach Agile

Najprostszy sposób, żeby nie skończyć z bezpieczeństwem jako osobnym etapem „przed produkcją”, to wpleść je w istniejące ceremonie. W praktyce może wyglądać to tak:
► Backlog refinement – oznaczenie user stories z istotnymi implikacjami bezpieczeństwa (np. tag „security-impact”) oraz dodawanie dedykowanych security stories tam, gdzie to potrzebne.
► Sprint Planning – identyfikacja stories wymagających dodatkowych działań (modelowanie zagrożeń, testy bezpieczeństwa, feature flags) oraz świadoma decyzja, co trafia do sprintu.
► Daily – szybkie sygnalizowanie blokad związanych z bezpieczeństwem (np. CVE w kluczowej bibliotece), zwykle właśnie przez Security Championa.
► Review – demo nie tylko funkcji biznesowych, ale także tego, co w danym sprincie poprawiono w obszarze bezpieczeństwa.
► Retrospective / security retro – raz na kilka sprintów dedykowane spotkanie, podczas którego zespół analizuje powracające problemy bezpieczeństwa i modyfikuje proces (Definition of Done, testy, polityki brancha).

Kluczowym elementem jest Definition of Done, w którym bezpieczeństwo staje się równorzędną częścią jakości. Przykładowe kryteria DoD to: brak sekretów i kluczy w repozytorium, generowanie SBOM dla każdego builda, automatyczne SAST oraz skanowanie API (DAST) bez krytycznych alertów, zgodność z politykami Infrastructure as Code. Bez tak rozumianego DoD bezpieczeństwo pozostaje pustą deklaracją, a nie kryterium gotowości do wdrożenia.

Podsumowanie

DevSecOps nie jest podejściem technologicznym – to sposób organizacji pracy. Jego skuteczność zależy od tego, czy organizacja potrafi przypisać odpowiedzialność na poziomie strategicznym, taktycznym i operacyjnym, czy ma sensownie zbudowany program Security Champions. Security Champions i jasne procesy Agile decydują o tym, czy DevSecOps stanowi koszt, czy przewagę konkurencyjną.

Jeśli zarządzasz bezpieczeństwem, zacznij od trzech prostych kroków: nazwij właścicieli DevSecOps na poziomie strategicznym, taktycznym i operacyjnym oraz wyznacz Security Champions w kluczowych zespołach i daj im realnie 10–20% czasu na bezpieczeństwo.

W kolejnym artykule przybliżę temat metryk ROI i trendów 2024/2025.

Jakub Wasiljew
Senior Frontend Developer | Ambasador CyberOdporności
CyberShieldON

CyberShieldON – Gdy wiedza spotyka decyzję.
Tutaj cyberbezpieczeństwo to nie tylko technologia, ale też konsekwencje wyborów, ryzyko systemowe i odpowiedzialność.
Łączymy doświadczenie z projektów z refleksją nad tym, jak naprawdę działa organizacja i jak ją chronić. Dzielimy się praktyką, która wytrzymała presję, oraz pytaniami, które zmieniły kierunek działania.

To miejsce jest dla Ciebie, jeśli tworzysz systemy, zarządzasz bezpieczeństwem, projektujesz architekturę i nie zatrzymujesz się na poziomie technologicznym.

Nowe artykuły – regularnie na cybershieldon.pl