Praktyczne przewodniki dla software house'ów, firm SaaS, zespołów produktowych, producentów hardware i liderów engineeringu, którzy muszą tworzyć bezpieczne produkty cyfrowe oraz spełniać wymagania cyberbezpieczeństwa, w tym Cyber Resilience Act. Omawiamy secure SDLC, product security, threat modeling, zarządzanie podatnościami, SBOM, bezpieczne aktualizacje, DevSecOps, testy bezpieczeństwa, responsible disclosure i podejście secure-by-design.
Threat modeling: praktyczny przewodnik dla zespołów produktowych
Threat modeling, czyli modelowanie zagrożeń, pomaga zespołom produktowym znaleźć problemy bezpieczeństwa na etapie projektowania, zanim trafią do kodu i produkcji. Sprawdź, jak przeprowadzić praktyczną sesję, jakie pytania zadać, jak używać STRIDE, jak dokumentować wyniki i jak zamienić zagrożenia w konkretne zadania dla zespołu.
Opracowanie: Zespół redakcyjny CCyber
Threat modeling, czyli modelowanie zagrożeń, to praktyczna metoda analizowania produktu, funkcji lub architektury pod kątem tego, co może pójść źle z perspektywy bezpieczeństwa i prywatności. Zespół produktowy powinien zacząć od czterech pytań: nad czym pracujemy, co może pójść źle, co z tym zrobimy i czy wykonaliśmy wystarczająco dobrą pracę. Wynikiem dobrej sesji nie jest sam diagram, ale lista ryzyk, decyzji, wymagań bezpieczeństwa, testów i zadań do wdrożenia.
Lipiec 2026
Threat modeling to analiza produktu, funkcji, procesu lub architektury z perspektywy potencjalnych zagrożeń. Celem jest znalezienie problemów bezpieczeństwa i prywatności zanim zostaną utrwalone w kodzie, konfiguracji, integracji lub procesie biznesowym.
W praktyce modelowanie zagrożeń pomaga odpowiedzieć na cztery pytania:
Dobrze przeprowadzone modelowanie zagrożeń nie jest akademickim ćwiczeniem. To warsztat, którego celem jest poprawa projektu, zmniejszenie ryzyka i stworzenie zadań, które zespół może realnie wykonać.
Zespoły produktowe podejmują decyzje, które mają bezpośredni wpływ na bezpieczeństwo: jak działa logowanie, kto ma dostęp do danych, jak działa API, gdzie są granice klienta w SaaS, jakie integracje mają dostęp do systemu i jak produkt reaguje na błędy.
Jeśli bezpieczeństwo pojawia się dopiero podczas testu penetracyjnego przed wydaniem, wiele decyzji architektonicznych jest już trudnych do zmiany. Modelowanie zagrożeń przesuwa rozmowę wcześniej, tam gdzie poprawki są tańsze i mniej bolesne.
Modelowanie zagrożeń pomaga:
Najlepszy moment to etap koncepcji, architektury lub planowania pierwszej wersji produktu. Wtedy zespół może jeszcze zmienić podejście do danych, uwierzytelniania, integracji i uprawnień bez dużych kosztów.
Nie każda drobna zmiana wymaga pełnej sesji. Modelowanie zagrożeń warto wykonać przy funkcjach, które mają większy wpływ na bezpieczeństwo.
Przykłady funkcji wysokiego ryzyka:
Modelowanie zagrożeń warto wykonać przy migracji do chmury, zmianie dostawcy tożsamości, wdrożeniu nowego API, przejściu na mikroserwisy, zmianie modelu danych albo wdrożeniu nowych integracji.
Jeżeli firma miała incydent albo wykryła poważną podatność, modelowanie zagrożeń pomaga ustalić, czy problem był jednorazowy, czy wynikał ze słabego założenia projektowego.
Modelowanie zagrożeń może wspierać przygotowanie do CRA, NIS2, ISO/IEC 27001, SOC 2, wymagań klientów albo oceny zgodności produktu.
Najczęstszy błąd to zbyt szeroki zakres. Sesja typu „modelujemy cały system” może szybko zamienić się w chaotyczną rozmowę bez efektu. Lepiej zacząć od konkretnej funkcji, usługi, modułu lub przepływu danych.
Dobry zakres:
Dowód do przygotowania: krótki opis zakresu sesji i cel modelowania.
Modelowanie zagrożeń nie powinno być samotnym ćwiczeniem security. Najlepsze wyniki powstają wtedy, gdy w sesji uczestniczą osoby, które rozumieją produkt, architekturę, dane, użytkowników i ryzyko biznesowe.
Typowy skład sesji:
Nie chodzi o dużą grupę. Chodzi o właściwe osoby. Sesja 5-7 osób często działa lepiej niż spotkanie całego działu.
Dowód do przygotowania: lista uczestników, role i właściciel wyników sesji.
Model nie musi być idealny. Ma pomóc zespołowi wspólnie zobaczyć, jak działa system. Najczęściej wystarczy diagram przepływu danych, diagram architektury albo schemat procesu.
Model powinien pokazywać:
Dowód do przygotowania: diagram systemu albo diagram przepływu danych z oznaczonymi granicami zaufania.
Nie każde dane mają ten sam poziom ryzyka. Zespół powinien wiedzieć, które dane są publiczne, wewnętrzne, poufne, osobowe, finansowe, medyczne, techniczne albo objęte tajemnicą przedsiębiorstwa.
Warto odpowiedzieć na pytania:
Dowód do przygotowania: lista danych, klasyfikacja i miejsca przetwarzania.
Granica zaufania to miejsce, w którym dane lub żądanie przechodzi między obszarami o różnym poziomie kontroli. Właśnie tam często pojawiają się najważniejsze ryzyka.
Przykłady granic zaufania:
Dowód do przygotowania: diagram z oznaczonymi granicami zaufania i opisem kontroli na tych granicach.
Najpierw zespół musi wspólnie zrozumieć zakres. Product owner opisuje funkcję, architekt pokazuje model, developerzy uzupełniają szczegóły, a security pomaga znaleźć miejsca ryzyka.
Ustal:
Na tym etapie zespół identyfikuje zagrożenia. Można użyć STRIDE, listy kontrolnej OWASP, poprzednich incydentów, wymagań klientów, MITRE ATT&CK albo zwykłej burzy mózgów.
Przykładowe pytania:
STRIDE pomaga uporządkować dyskusję. Nie jest jedyną metodą, ale jest praktyczna i dobrze działa z zespołami produktowymi.
STRIDE obejmuje:
Przy każdym elemencie modelu można zapytać, które kategorie STRIDE mają sens. Nie trzeba robić tego mechanicznie dla każdego pola. Celem jest znalezienie realnych zagrożeń, nie wypełnienie tabeli.
Nie każde zagrożenie jest tak samo ważne. Po zidentyfikowaniu zagrożeń trzeba ustalić, które wymagają działania teraz, które można zaplanować później, a które można świadomie zaakceptować.
Przy ocenie ryzyka weź pod uwagę:
W praktyce wystarczy prosta skala: krytyczne, wysokie, średnie, niskie. Najważniejsze jest, żeby zespół rozumiał, dlaczego dane ryzyko ma taki priorytet.
Dla każdego istotnego zagrożenia trzeba określić reakcję. Najczęściej są cztery możliwości: ograniczyć ryzyko, usunąć funkcję lub element ryzyka, przenieść odpowiedzialność albo świadomie zaakceptować ryzyko.
Dobre działania ograniczające ryzyko powinny być konkretne:
Jeżeli reakcja nie prowadzi do zadania, wymagania lub testu, prawdopodobnie jest zbyt ogólna.
Największa wartość modelowania zagrożeń pojawia się wtedy, gdy wyniki trafiają do pracy zespołu. Ryzyka powinny zostać zamienione w zadania w backlogu, wymagania bezpieczeństwa, testy, decyzje lub akceptacje ryzyka.
Dla każdego istotnego zagrożenia określ:
Na koniec sesji zespół powinien sprawdzić, czy model ma sens i czy wyniki są użyteczne.
Pytania kontrolne:
W SaaS bardzo ważne jest oddzielenie danych klientów. Jedno z najważniejszych pytań brzmi: czy klient A może przypadkiem albo celowo zobaczyć dane klienta B?
Sprawdź:
Panel administratora jest częstym miejscem ryzyka, bo daje szerokie uprawnienia. Modelowanie powinno sprawdzić, kto ma dostęp, jak jest chroniony i co można zrobić z poziomu panelu.
Sprawdź:
API w SaaS jest często główną powierzchnią ataku. Błędy autoryzacji, brak limitów zapytań, zbyt szerokie tokeny i niebezpieczne integracje mogą prowadzić do poważnych incydentów.
Jeżeli produkt używa AI lub agentów automatyzujących działania, modelowanie zagrożeń powinno uwzględnić nowe ryzyka: prompt injection, ujawnienie danych z kontekstu, nadmierne uprawnienia agenta i nadmierne poleganie na wyniku AI.
Jeżeli modelowanie zagrożeń odbywa się po zbudowaniu funkcji, zespół może odkryć problemy, których naprawa wymaga dużych zmian architektonicznych. Lepiej robić je wcześnie.
Próba modelowania całej platformy podczas jednej sesji zwykle kończy się powierzchowną analizą. Lepiej modelować mniejsze fragmenty, ale dokładniej.
Security i developerzy nie zawsze znają pełny kontekst biznesowy. Product owner pomaga zrozumieć, jak funkcja ma działać, co jest krytyczne dla klienta i które ryzyka są najważniejsze.
Narzędzia mogą pomóc, ale nie zastąpią myślenia. Modelowanie zagrożeń to przede wszystkim rozmowa, zrozumienie systemu i podejmowanie decyzji.
Jeśli po sesji nie powstają zadania, wymagania ani testy, modelowanie nie wpływa na produkt. Wyniki muszą trafić do procesu wytwarzania.
Produkt się zmienia. Model zagrożeń powinien być aktualizowany przy istotnych zmianach architektury, nowych integracjach, nowych danych i nowych funkcjach wysokiego ryzyka.
Diagram ma pomóc w rozmowie, a nie być dziełem sztuki. Lepiej mieć prosty diagram, który zespół rozumie, niż idealny model, którego nikt nie używa.
Firma SaaS planuje nową funkcję eksportu danych klientów przez API. Funkcja ma umożliwiać klientom pobieranie dużych raportów i integrację z zewnętrznymi systemami analitycznymi.
Zespół produktowy organizuje 90-minutową sesję modelowania zagrożeń. Na diagramie pokazuje użytkownika, API, usługę autoryzacji, bazę danych, kolejkę zadań, magazyn plików i zewnętrzny system klienta.
Podczas sesji zespół identyfikuje kilka ryzyk: klient może pobrać raport innego klienta, token API może mieć zbyt szerokie uprawnienia, eksport może ujawnić dane w logach, funkcja może zostać nadużyta do przeciążenia systemu, a link do raportu może być dostępny zbyt długo.
Wyniki sesji trafiają do backlogu: kontrola dostępu na poziomie obiektu, krótszy czas życia linków, limity zapytań, usunięcie danych wrażliwych z logów, testy autoryzacji i monitoring nietypowych eksportów.
Dzięki temu zespół wykrywa problemy przed napisaniem większości kodu. Test penetracyjny później potwierdza, że najważniejsze ryzyka zostały ograniczone już na etapie projektu.
ccyber.io pomaga zespołom produktowym, software house’om i firmom SaaS przeprowadzać modelowanie zagrożeń w sposób praktyczny, lekki i powiązany z realną pracą zespołu.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest warsztat pilotażowy dla jednej funkcji wysokiego ryzyka. Dzięki temu zespół szybko widzi wartość metody i może wdrożyć prosty, powtarzalny proces bez nadmiernej biurokracji.
Nie. Najlepsze modelowanie zagrożeń angażuje product ownerów, developerów, architektów, DevOps, testerów i osoby odpowiedzialne za bezpieczeństwo. Security może moderować, ale produkt i technologia muszą być reprezentowane przez zespół.
Nie. Na start wystarczy diagram, tablica, dokument i prosty szablon. Narzędzia mogą pomóc później, gdy firma chce zwiększyć powtarzalność i skalę procesu.
Dla jednej funkcji wysokiego ryzyka często wystarczy 60-90 minut. Dla większego systemu lepiej zrobić kilka mniejszych sesji niż jedno długie spotkanie.
Nie. STRIDE jest popularną i praktyczną strukturą, ale nie jest jedyną metodą. Można używać także innych podejść, checklist, scenariuszy ataków, MITRE ATT&CK, OWASP ASVS albo własnej metody dopasowanej do firmy.
Najlepiej przed developmentem funkcji wysokiego ryzyka, przy zmianach architektury, nowych integracjach, nowych przepływach danych, funkcjach AI, panelach administracyjnych i API.
Wynikiem powinny być konkretne zagrożenia, ocena ryzyka, decyzje, wymagania bezpieczeństwa, zadania w backlogu, testy, właściciele i terminy.
Tak. CRA wymaga podejścia do bezpieczeństwa produktu przez cały cykl życia. Modelowanie zagrożeń pomaga przygotować ocenę ryzyka produktu, wymagania bezpieczeństwa, dokumentację i dowody projektowe.
Nie. Modelowanie zagrożeń nie zastępuje testów. Pomaga znaleźć problemy wcześniej i lepiej zaplanować testy. Najlepsze podejście łączy modelowanie, przegląd kodu, testy automatyczne i testy manualne.
Threat modeling to jedno z najbardziej praktycznych narzędzi dla zespołów produktowych, które chcą budować bezpieczniejsze oprogramowanie bez czekania na test penetracyjny na końcu projektu.
Najważniejsze jest proste podejście: ustal zakres, zrozum system, oznacz dane i granice zaufania, zidentyfikuj zagrożenia, wybierz reakcje, zamień wyniki w zadania i wracaj do modelu przy istotnych zmianach.
Dobre modelowanie zagrożeń nie tworzy dokumentacji dla samej dokumentacji. Tworzy lepsze decyzje produktowe, lepsze wymagania bezpieczeństwa, lepsze testy i mniejsze ryzyko dla klientów oraz firmy.
Checklista bezpiecznego wytwarzania oprogramowania dla firm SaaS i software house’ów
Secure SDLC pomaga firmom SaaS i software house’om wbudować bezpieczeństwo w cały cykl tworzenia oprogramowania: od wymagań i architektury, przez kodowanie, testy i CI/CD, po wydanie, monitoring, aktualizacje i obsługę podatności. Sprawdź praktyczną checklistę, która pomaga ograniczyć ryzyko, przygotować dowody i spełnić wymagania klientów oraz regulacji.
Opracowanie: Zespół redakcyjny CCyber
Secure SDLC to bezpieczny cykl wytwarzania oprogramowania, czyli sposób pracy, w którym bezpieczeństwo jest obecne od wymagań i projektu architektury aż po wdrożenie, monitoring, aktualizacje i obsługę podatności. Firmy SaaS i software house’y powinny zacząć od checklisty obejmującej właściciela bezpieczeństwa produktu, wymagania bezpieczeństwa, modelowanie zagrożeń, standardy kodowania, przeglądy kodu, testy SAST, DAST i SCA, SBOM, bezpieczeństwo CI/CD, zarządzanie sekretami, podatnościami i dowodami.
Lipiec 2026
Secure SDLC to bezpieczny cykl wytwarzania oprogramowania. Oznacza włączenie bezpieczeństwa do każdego etapu tworzenia produktu: od pomysłu, wymagań i architektury, przez development, testy, wdrożenie, utrzymanie, aktualizacje i obsługę podatności.
W praktyce Secure SDLC odpowiada na pytania:
Secure SDLC nie musi oznaczać wolniejszego developmentu. Dobrze wdrożony proces usuwa część chaosu, ogranicza poprawki na końcu projektu i pomaga wykrywać problemy wcześniej, kiedy ich naprawa jest tańsza.
Firmy SaaS i software house’y tworzą oprogramowanie, które często przetwarza dane klientów, integruje się z systemami zewnętrznymi, korzysta z chmury, API, komponentów open source i automatycznych wdrożeń. To oznacza dużą powierzchnię ataku.
Klienci coraz częściej oczekują nie tylko deklaracji „dbamy o bezpieczeństwo”, ale konkretnych dowodów:
Secure SDLC jest też coraz ważniejszy regulacyjnie. Cyber Resilience Act wprowadza wymagania cyberbezpieczeństwa dla produktów z elementami cyfrowymi, a klienci objęci NIS2, DORA lub ISO/IEC 27001 mogą przenosić wymagania bezpieczeństwa na swoich dostawców technologii.
Bezpieczeństwo produktu nie może być „niczyje”. W firmie powinien istnieć właściciel procesu bezpieczeństwa aplikacji lub produktu. Nie musi to być osobny dział w małej firmie, ale odpowiedzialność musi być jasna.
Właściciel powinien koordynować:
Dowód do przygotowania: decyzja o właścicielu bezpieczeństwa produktu, zakres odpowiedzialności i lista osób wspierających.
Nie da się zabezpieczyć produktu, którego zespół nie ma dobrze opisanego. Firmy SaaS i software house’y powinny mieć listę produktów, repozytoriów, aplikacji, API, usług, bibliotek, komponentów i środowisk.
Rejestr powinien obejmować:
Dowód do przygotowania: rejestr produktów i repozytoriów z właścicielami oraz klasyfikacją krytyczności.
Bezpieczeństwo nie powinno być dodatkiem do funkcji. Powinno być częścią wymagań. Product owner, architekt, developer i security powinni wiedzieć, jakie wymagania bezpieczeństwa musi spełnić produkt.
Przykładowe wymagania:
Dowód do przygotowania: lista wymagań bezpieczeństwa produktu powiązana z backlogiem, ryzykiem i testami.
Modelowanie zagrożeń pomaga zespołowi odpowiedzieć na pytanie: co może pójść źle i jak temu zapobiec? Nie trzeba modelować wszystkiego od razu. Zacznij od funkcji wysokiego ryzyka.
Modelowanie zagrożeń warto wykonać dla:
Wynikiem modelowania powinny być konkretne wymagania, zadania w backlogu i testy.
Dowód do przygotowania: diagram przepływu danych, lista zagrożeń, decyzje o kontrolach i zadania naprawcze.
Standard bezpiecznego kodowania powinien być prosty, praktyczny i dopasowany do technologii używanych przez zespół. Nie może być dokumentem, którego nikt nie czyta.
Standard powinien obejmować:
Dowód do przygotowania: standard kodowania, checklisty dla pull requestów i potwierdzenie szkolenia zespołu.
Hasła, klucze API, tokeny, certyfikaty i inne sekrety nie powinny trafiać do repozytorium kodu, ticketów, dokumentacji, komunikatorów ani plików konfiguracyjnych bez ochrony.
Minimalne zasady:
Dowód do przygotowania: polityka sekretów, konfiguracja sejfu, wyniki skanowania i rejestr rotacji sekretów.
Nowoczesne aplikacje korzystają z wielu bibliotek i pakietów. To przyspiesza pracę, ale wprowadza ryzyko łańcucha dostaw oprogramowania.
Firma powinna wiedzieć:
Dowód do przygotowania: rejestr zależności, wyniki skanowania SCA i procedura aktualizacji podatnych komponentów.
SBOM, czyli spis komponentów oprogramowania, pomaga pokazać, z czego składa się produkt. Jest ważny dla bezpieczeństwa łańcucha dostaw, CRA, rozmów z klientami i szybkiej reakcji na nowe podatności.
Dobry SBOM powinien być:
Dowód do przygotowania: SBOM dla głównego produktu i proces jego aktualizacji.
Repozytorium kodu jest jednym z najważniejszych zasobów firmy technologicznej. Przejęcie repozytorium może prowadzić do wycieku kodu, sekretów, manipulacji kodem albo ataku na klientów.
Minimum zabezpieczeń:
Dowód do przygotowania: konfiguracja repozytoriów, status MFA, zasady ochrony gałęzi i raport z przeglądu uprawnień.
Pipeline CI/CD może stać się ścieżką ataku na produkt. Jeśli atakujący przejmie proces budowania lub wdrożenia, może wprowadzić złośliwy kod do legalnej wersji produktu.
Kontroluj:
Dowód do przygotowania: dokumentacja pipeline, lista uprawnień, konfiguracja sekretów, logi wdrożeń i zasady zatwierdzania produkcji.
Testy bezpieczeństwa powinny być częścią procesu wytwarzania, a nie tylko działaniem przed wydaniem. Dla firm SaaS i software house’ów minimum to połączenie kilku typów testów.
W praktyce:
Nie każde ostrzeżenie z narzędzia jest krytyczne. Potrzebny jest proces triage, czyli oceny, które wyniki są rzeczywiście ważne i wymagają naprawy.
Dowód do przygotowania: wyniki testów SAST, DAST, SCA, skanowania sekretów, decyzje triage i status napraw.
W produktach SaaS API jest często najważniejszą powierzchnią ataku. Błędy w autoryzacji, kontroli obiektów, limitach zapytań i separacji danych klientów mogą prowadzić do poważnych incydentów.
Testy API powinny obejmować:
Dowód do przygotowania: plan testów API, wyniki testów, podatności i potwierdzenie napraw.
Błędy konfiguracji są jedną z najczęstszych przyczyn incydentów w usługach chmurowych i SaaS. Środowiska developerskie, testowe i produkcyjne powinny być oddzielone i zarządzane według jasnych zasad.
Sprawdź:
Dowód do przygotowania: standard środowisk, wyniki przeglądu konfiguracji i raport z kontroli dostępu do produkcji.
Produkt powinien generować logi, które pomagają wykryć incydent, przeanalizować zdarzenie i udowodnić, co się stało. Brak logów oznacza brak widoczności.
Logować warto:
Logi muszą być chronione przed modyfikacją, dostępne do analizy i przechowywane zgodnie z zasadami firmy oraz wymaganiami klientów.
Dowód do przygotowania: lista logowanych zdarzeń, retencja logów, alerty i raport z monitoringu.
Podatności nie kończą się w dniu wydania produktu. Firma musi mieć proces przyjmowania zgłoszeń, oceny, naprawy, komunikacji i dokumentowania podatności.
Proces powinien obejmować:
Dowód do przygotowania: procedura zarządzania podatnościami, rejestr podatności, status napraw i raporty po retestach.
Dobra checklista Secure SDLC kończy się dowodami. Klienci, audytorzy i regulatorzy coraz częściej pytają nie tylko o to, czy firma „robi bezpieczeństwo”, ale czy potrafi to wykazać.
Najważniejsze dowody:
Dowód do przygotowania: pakiet dowodów Secure SDLC gotowy do klienta, audytu lub oceny zgodności.
Jeśli bezpieczeństwo pojawia się dopiero na końcu, zespół ma mało czasu na naprawy, a koszty rosną. Bezpieczeństwo powinno być częścią wymagań, projektu i codziennej pracy.
Mały software house nie musi od razu tworzyć rozbudowanego programu jak duża korporacja. Lepiej zacząć od minimum, które działa, i stopniowo zwiększać dojrzałość.
Jeśli nikt nie odpowiada za Secure SDLC, zadania bezpieczeństwa będą odkładane. Właściciel nie musi wykonywać wszystkiego sam, ale musi koordynować proces.
Współczesny proces wdrożeniowy jest krytycznym elementem bezpieczeństwa. Przejęcie pipeline może być równie groźne jak podatność w aplikacji.
Aplikacja może być dobrze napisana, ale nadal podatna przez bibliotekę, pakiet lub komponent zewnętrzny. Dlatego SCA i SBOM są tak ważne.
Produkt nie kończy życia w dniu wdrożenia. Podatności będą pojawiać się później, dlatego firma musi mieć proces wykrywania, oceny, naprawy i komunikacji.
Zespół może robić wiele dobrych rzeczy, ale jeśli nie ma dowodów, trudno pokazać dojrzałość klientowi, audytorowi lub regulatorowi.
Firma SaaS rozwija platformę dla klientów B2B. Ma kilka zespołów developerskich, szybkie wdrożenia, wiele integracji API, środowisko chmurowe i rosnące wymagania klientów dotyczące bezpieczeństwa.
Do tej pory bezpieczeństwo polegało głównie na testach penetracyjnych raz w roku. Po każdym teście zespół dostawał długą listę podatności, które trzeba było naprawić pod presją czasu.
Po wdrożeniu podstaw Secure SDLC firma zmienia podejście. Wprowadza wymagania bezpieczeństwa do backlogu, robi modelowanie zagrożeń dla funkcji wysokiego ryzyka, dodaje skanowanie sekretów i zależności do CI/CD, przygotowuje SBOM i tworzy proces obsługi podatności.
Po 90 dniach firma nie jest „idealnie bezpieczna”, ale ma dużo lepszą kontrolę. Wie, które produkty są krytyczne, jakie podatności są otwarte, jakie zależności są używane i jakie dowody może pokazać klientowi.
ccyber.io pomaga firmom SaaS i software house’om wdrożyć Secure SDLC w sposób praktyczny, lekki i dopasowany do realnego sposobu pracy zespołów developerskich.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest krótki Secure SDLC assessment. Pozwala ustalić, które elementy procesu już działają, gdzie są największe luki i co warto wdrożyć w pierwszych 30, 60 i 90 dniach.
Nie. Małe i średnie firmy również mogą wdrożyć Secure SDLC, ale powinny zacząć od prostych praktyk: wymagań bezpieczeństwa, przeglądów kodu, skanowania zależności, kontroli sekretów i procesu obsługi podatności.
Nie. Test penetracyjny jest ważny, ale nie zastępuje bezpiecznego procesu wytwarzania. Secure SDLC pomaga wykrywać i usuwać problemy wcześniej, zanim trafią do produkcji.
Najlepiej zacząć od rejestru produktów, właściciela bezpieczeństwa, wymagań bezpieczeństwa, kontroli repozytoriów, skanowania sekretów i zależności oraz pilotażu na jednym produkcie.
Secure SDLC opisuje cały bezpieczny cykl wytwarzania oprogramowania. DevSecOps jest sposobem praktycznego włączania bezpieczeństwa do pracy DevOps, automatyzacji, CI/CD, testów i wdrożeń.
SBOM jest coraz bardziej przydatny, szczególnie dla firm sprzedających oprogramowanie klientom B2B, przygotowujących się do CRA, obsługujących sektor regulowany lub zarządzających wieloma komponentami open source.
Tak. Secure SDLC pomaga przygotować procesy i dowody potrzebne do bezpieczeństwa produktu: ocenę ryzyka, wymagania bezpieczeństwa, testy, zarządzanie podatnościami, SBOM, dokumentację i aktualizacje.
Modelowanie zagrożeń warto wykonywać przy nowych funkcjach wysokiego ryzyka, dużych zmianach architektury, nowych integracjach, nowych typach danych i zmianach wpływających na dostęp lub uprawnienia.
Na start zwykle wystarczą narzędzia do skanowania sekretów, zależności, kodu, konfiguracji i aplikacji oraz proces przeglądu kodu i podatności. Narzędzia powinny wspierać proces, a nie zastępować myślenie o ryzyku.
Secure SDLC dla firm SaaS i software house’ów nie powinien być ciężkim, biurokratycznym procesem. Powinien być praktyczną checklistą działań, które pomagają tworzyć bezpieczniejsze produkty i szybciej odpowiadać na wymagania klientów, audytorów oraz regulacji.
Najważniejsze elementy to wymagania bezpieczeństwa, modelowanie zagrożeń, bezpieczne kodowanie, kontrola sekretów, zarządzanie zależnościami, SBOM, zabezpieczenie repozytoriów i CI/CD, testy bezpieczeństwa, zarządzanie podatnościami i dowody.
Firmy, które wdrożą Secure SDLC wcześnie, zmniejszają ryzyko techniczne, ograniczają koszt późnych poprawek i budują przewagę sprzedażową jako bardziej wiarygodny dostawca oprogramowania.
Cyber Resilience Act dla software house’ów: co trzeba przygotować w 2026 i 2027 roku?
Cyber Resilience Act zmienia cyberbezpieczeństwo produktów cyfrowych z dobrej praktyki w obowiązek regulacyjny. Firmy tworzące oprogramowanie powinny przygotować ocenę ryzyka produktu, bezpieczny cykl wytwarzania, zarządzanie podatnościami, dokumentację techniczną, SBOM, proces aktualizacji, zgłaszanie incydentów i plan zgodności na 2026 oraz 2027 rok.
Opracowanie: Zespół redakcyjny CCyber
Software house powinien zacząć przygotowania do Cyber Resilience Act od sprawdzenia, czy tworzone oprogramowanie jest produktem z elementami cyfrowymi wprowadzanym na rynek UE oraz jaką rolę pełni firma: producenta, podwykonawcy, dostawcy komponentu czy dostawcy usługi. W 2026 roku trzeba przygotować przede wszystkim proces obsługi podatności i zgłoszeń, ocenę ryzyka produktu, bezpieczny cykl wytwarzania oprogramowania, dokumentację techniczną, SBOM, zasady aktualizacji oraz plan zgodności przed pełnym stosowaniem CRA w 2027 roku.
Lipiec 2026
Cyber Resilience Act, czyli CRA, to unijne rozporządzenie wprowadzające wymagania cyberbezpieczeństwa dla produktów z elementami cyfrowymi. Jego celem jest zwiększenie bezpieczeństwa produktów dostępnych na rynku UE oraz zapewnienie, że podatności będą obsługiwane przez cały okres wsparcia produktu.
W praktyce CRA oznacza, że cyberbezpieczeństwo produktu cyfrowego nie może być dodatkiem na końcu projektu. Musi być uwzględnione w planowaniu, projektowaniu, tworzeniu, testowaniu, wydaniu, aktualizacjach, obsłudze podatności i komunikacji z użytkownikami.
Dla software house’ów CRA jest ważne, ponieważ wiele firm technologicznych nie sprzedaje już tylko „usługi programistycznej”. Tworzy aplikacje, komponenty, platformy, produkty SaaS, integracje, biblioteki, moduły, firmware, aplikacje mobilne, systemy IoT albo oprogramowanie wprowadzane na rynek pod własną marką lub marką klienta.
Najważniejsze pytanie nie brzmi „czy tworzymy software?”, ale „czy wprowadzamy produkt z elementami cyfrowymi na rynek UE pod własną nazwą lub znakiem towarowym?”.
Software house może występować w różnych rolach:
Jeżeli firma tylko tworzy oprogramowanie na zamówienie klienta, a klient wprowadza produkt na rynek pod własną marką, obowiązki producenta mogą spoczywać głównie na kliencie. To nie oznacza jednak, że software house może ignorować CRA. Klient prawdopodobnie przeniesie część wymagań na dostawcę przez umowę, proces wytwarzania, dokumentację, testy, obsługę podatności i dowody bezpieczeństwa.
CRA obejmuje produkty z elementami cyfrowymi, czyli oprogramowanie lub sprzęt oraz powiązane z nimi rozwiązania zdalnego przetwarzania danych, jeśli produkt jest udostępniany na rynku UE i jego przewidywane użycie obejmuje połączenie z urządzeniem albo siecią.
Przykłady, które mogą wymagać analizy pod CRA:
Sam fakt, że firma tworzy oprogramowanie, nie zawsze oznacza automatyczne objęcie CRA. Każdy przypadek trzeba ocenić na podstawie modelu biznesowego, sposobu udostępniania produktu, roli firmy, rodzaju produktu i umów z klientami.
Od tej daty stosowane są przepisy dotyczące jednostek oceniających zgodność. Dla software house’u ma to znaczenie głównie wtedy, gdy produkt będzie wymagał udziału jednostki notyfikowanej albo będzie należał do kategorii ważnych lub krytycznych produktów.
Od tej daty zaczynają obowiązywać przepisy dotyczące zgłaszania aktywnie wykorzystywanych podatności i poważnych incydentów mających wpływ na bezpieczeństwo produktu z elementami cyfrowymi.
W praktyce oznacza to, że producent powinien mieć przygotowany proces:
Od tej daty zacznie obowiązywać większość wymagań CRA. Produkty objęte CRA będą musiały spełniać wymagania cyberbezpieczeństwa, przejść odpowiednią ocenę zgodności, mieć dokumentację techniczną, deklarację zgodności UE, oznakowanie CE oraz określony okres wsparcia.
Software house powinien zacząć od mapy produktów i ról. Bez tego trudno określić, które obowiązki dotyczą firmy bezpośrednio, a które będą wynikały z umów z klientami.
Sprawdź:
Dowód do przygotowania: rejestr produktów, właściciel produktu, rola firmy, rynek, typ produktu, model udostępniania i wstępna kwalifikacja pod CRA.
CRA wymaga podejścia opartego na ryzyku. Producent powinien ocenić ryzyka cyberbezpieczeństwa produktu i wykorzystać wynik tej oceny przy projektowaniu, rozwoju, dostarczeniu i utrzymaniu produktu.
Ocena ryzyka powinna obejmować:
Dowód do przygotowania: raport oceny ryzyka produktu i lista wymagań bezpieczeństwa wynikających z tej oceny.
Software house powinien uporządkować proces tworzenia oprogramowania tak, aby bezpieczeństwo było częścią codziennej pracy zespołu, a nie jednorazowym testem przed wydaniem.
Bezpieczny cykl wytwarzania powinien obejmować:
Dowód do przygotowania: opis procesu bezpiecznego wytwarzania oprogramowania, procedury, checklisty i wyniki testów.
CRA wzmacnia obowiązki producentów w zakresie obsługi podatności. Firma musi mieć proces, który pozwala wykrywać, analizować, priorytetyzować, naprawiać i komunikować podatności.
Proces powinien określać:
Dowód do przygotowania: procedura zarządzania podatnościami, rejestr podatności, status napraw i decyzje o zgłoszeniach.
Firma powinna umożliwić klientom, badaczom bezpieczeństwa i użytkownikom zgłaszanie podatności w kontrolowany sposób. W praktyce oznacza to przygotowanie jasnego kanału kontaktu, zasad obsługi zgłoszeń i odpowiedzialności po stronie zespołu.
Warto przygotować:
Dowód do przygotowania: polityka zgłaszania podatności, kanał kontaktu, rejestr zgłoszeń i metryki obsługi.
SBOM, czyli spis komponentów oprogramowania, pomaga ustalić, z jakich bibliotek, pakietów i komponentów składa się produkt. Jest ważny dla zarządzania podatnościami, bezpieczeństwa łańcucha dostaw i szybkiej reakcji na nowe podatności w komponentach.
Software house powinien wiedzieć:
Dowód do przygotowania: SBOM dla produktu, proces aktualizacji SBOM i powiązanie z zarządzaniem podatnościami.
Dokumentacja techniczna jest jednym z najważniejszych elementów przygotowania do CRA. Powinna pokazywać, że produkt spełnia wymagania cyberbezpieczeństwa, a firma potrafi to udowodnić.
Dokumentacja może obejmować:
Dowód do przygotowania: komplet dokumentacji technicznej produktu zgodny z wymaganiami CRA i gotowy do okazania organom nadzoru rynku.
Od 11 września 2026 roku producenci będą musieli zgłaszać aktywnie wykorzystywane podatności i poważne incydenty wpływające na bezpieczeństwo produktów z elementami cyfrowymi.
Firma powinna mieć proces pozwalający odpowiedzieć na pytania:
Dowód do przygotowania: procedura zgłoszeń CRA, role, wzory notatek, ścieżka eskalacji i rejestr zgłoszeń.
W 2027 roku firma powinna przejść od planowania do pełnej gotowości. Produkt powinien mieć wdrożone wymagania bezpieczeństwa, proces aktualizacji, dokumentację techniczną i dowody testów.
Najważniejsze elementy gotowości:
Przed wprowadzeniem produktu na rynek producent powinien wykonać odpowiednią ocenę zgodności. Dla wielu produktów może być możliwa samoocena, ale dla niektórych kategorii ważnych lub krytycznych produktów może być wymagany bardziej rygorystyczny tryb, w tym udział jednostki notyfikowanej.
Software house powinien sprawdzić:
Dla produktów objętych CRA producent powinien przygotować deklarację zgodności UE i umieścić oznakowanie CE, jeśli produkt spełnia wymagania. To wymaga wcześniejszego zebrania dokumentacji, testów, oceny ryzyka i dowodów spełnienia wymagań.
CRA nie kończy się w dniu wydania produktu. Producent musi obsługiwać podatności i aktualizacje w okresie wsparcia. To wymaga ludzi, procesu, narzędzi i budżetu.
W 2027 roku firma powinna mieć gotowe:
Pełne stosowanie większości obowiązków zacznie się w 2027 roku, ale obowiązki raportowania pojawiają się wcześniej. Dodatkowo przygotowanie procesów, dokumentacji i testów może zająć wiele miesięcy.
CRA ma skutki prawne, ale problem jest także techniczny i organizacyjny. Prawnicy mogą pomóc w interpretacji, ale zespoły produktowe, techniczne i bezpieczeństwa muszą wdrożyć procesy.
Jeżeli software house tworzy produkt dla klienta, trzeba jasno ustalić, kto odpowiada za ocenę ryzyka, dokumentację techniczną, testy, SBOM, obsługę podatności i zgodność produktu.
Nowoczesne produkty cyfrowe korzystają z wielu bibliotek i komponentów zewnętrznych. Bez SBOM trudno szybko ocenić, czy nowa podatność dotyczy produktu.
Jeżeli test bezpieczeństwa pojawia się dopiero przed wydaniem, naprawa błędów jest droższa i trudniejsza. Bezpieczeństwo powinno być częścią całego cyklu tworzenia produktu.
Produkt trzeba utrzymywać po wydaniu. Potrzebne są aktualizacje, obsługa zgłoszeń, monitorowanie podatności, komunikacja z użytkownikami i dokumentowanie działań.
Nawet jeśli zespół wykonuje dobre praktyki, musi umieć je pokazać. Brak dokumentacji, rejestrów i wyników testów osłabia gotowość do oceny zgodności, rozmów z klientami i kontroli.
Software house rozwija platformę SaaS dla klientów z sektora B2B. Produkt ma aplikację webową, API, integracje z systemami klientów, aplikację mobilną i komponent instalowany u klienta. Firma do tej pory koncentrowała się na funkcjach i czasie wdrożenia, a bezpieczeństwo sprawdzała głównie przez okresowe testy penetracyjne.
Po wstępnej analizie CRA okazuje się, że firma musi uporządkować znacznie więcej niż sam test bezpieczeństwa. Potrzebuje rejestru produktów, oceny ryzyka, modelowania zagrożeń, SBOM, procesu obsługi podatności, procedury zgłoszeń, dokumentacji technicznej i zasad aktualizacji.
Największą zmianą nie jest zakup nowego narzędzia. Największą zmianą jest przejście od podejścia „testujemy przed wydaniem” do podejścia „bezpieczeństwo jest częścią całego cyklu życia produktu”.
W ciągu 90 dni firma może przygotować fundament: mapę produktów, ocenę ryzyka, proces zgłaszania podatności, SBOM dla głównego produktu, podstawową dokumentację techniczną i plan działań na 2027 rok.
ccyber.io pomaga software house’om i firmom produktowym przygotować się do Cyber Resilience Act w sposób praktyczny, techniczny i biznesowy. Nie ograniczamy się do interpretacji regulacji. Pomagamy przełożyć CRA na procesy, dokumentację, testy i dowody.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest krótki warsztat CRA readiness. Pozwala ustalić, które produkty mogą być objęte CRA, jakie role pełni firma, jakie dowody już istnieją i które działania trzeba wykonać przed terminami w 2026 oraz 2027 roku.
Może dotyczyć. Jeśli software house wprowadza na rynek UE produkt z elementami cyfrowymi pod własną marką, może pełnić rolę producenta. Jeśli tworzy produkt dla klienta, wymagania mogą zostać przeniesione umownie przez klienta.
To zależy od modelu produktu i sposobu świadczenia usługi. CRA może obejmować powiązane rozwiązania zdalnego przetwarzania danych, jeśli są niezbędne dla funkcji produktu z elementami cyfrowymi. Każdy przypadek SaaS warto ocenić indywidualnie.
CRA ma szczególne podejście do wolnego i otwartego oprogramowania. Niekomercyjne udostępnianie open source co do zasady jest traktowane inaczej niż produkt wprowadzany na rynek w ramach działalności komercyjnej. Jeżeli firma monetyzuje produkt open source lub wprowadza go na rynek, trzeba przeprowadzić analizę zakresu.
Najważniejsze jest przygotowanie procesu zgłaszania aktywnie wykorzystywanych podatności i poważnych incydentów wpływających na bezpieczeństwo produktu. Firma powinna ustalić role, terminy, kanały zgłoszeń i sposób dokumentowania decyzji.
Trzeba przygotować pełną gotowość do głównych wymagań CRA: ocenę ryzyka produktu, bezpieczny cykl wytwarzania, obsługę podatności, dokumentację techniczną, ocenę zgodności, deklarację zgodności, oznakowanie CE, okres wsparcia i informacje dla użytkowników.
CRA wzmacnia znaczenie znajomości komponentów i zarządzania podatnościami. W praktyce SBOM jest jednym z najważniejszych narzędzi do wykazania kontroli nad komponentami, zależnościami i ryzykiem łańcucha dostaw oprogramowania.
Nie. Test penetracyjny jest ważny, ale nie wystarcza. CRA wymaga podejścia obejmującego cały cykl życia produktu: ocenę ryzyka, projektowanie, development, testy, dokumentację, aktualizacje, obsługę podatności i wsparcie po wydaniu.
Najlepiej zacząć od mapy produktów i ról, analizy zakresu CRA, oceny luk oraz planu działań na 2026 i 2027 rok. Następnie trzeba uporządkować bezpieczny cykl wytwarzania, podatności, SBOM i dokumentację.
Cyber Resilience Act zmienia sposób, w jaki firmy technologiczne powinny myśleć o bezpieczeństwie produktu. Bezpieczeństwo nie jest już tylko dobrą praktyką, przewagą sprzedażową albo wymaganiem większego klienta. Staje się elementem zgodności, dokumentacji, oceny ryzyka i odpowiedzialności producenta.
Software house’y powinny wykorzystać 2026 rok na przygotowanie fundamentów: mapy produktów, procesu obsługi podatności, oceny ryzyka, bezpiecznego cyklu wytwarzania, SBOM, dokumentacji technicznej i procedur zgłoszeniowych.
W 2027 roku organizacja powinna przejść do pełnej gotowości: oceny zgodności, dowodów spełnienia wymagań, informacji dla użytkowników, okresu wsparcia, deklaracji zgodności i procesu utrzymania bezpieczeństwa produktu po wydaniu.
Piszemy o regulacjach takich jak NIS2, DORA, CRA i ISO 27001, o bezpieczeństwie MŚP i infrastruktury krytycznej, a także o cyberhigienie, cyberzagrożeniach i budowaniu świadomości bezpieczeństwa w organizacji.
Każdy artykuł to praktyczna wiedza - bez żargonu i z konkretnymi wskazówkami do wdrożenia, które pomagają firmom skutecznie chronić dane, ludzi i ciągłość działania.