Security by design w CRA — jak przełożyć wymagania na pracę zespołu

„Security by design” nie jest osobnym dokumentem do podpisania. Dla produktu z elementami cyfrowymi powinno być widoczne w decyzjach projektowych, ograniczeniu powierzchni ataku, ustawieniach domyślnych, obsłudze aktualizacji, testach i sposobie reagowania na podatności przez cały cykl życia.

Najlepszy model pracy jest prosty: ryzyko → wymaganie → decyzja projektowa → zadanie → test → wynik → dowód → przegląd.

Co trzeba przełożyć na pracę produktu

Załącznik I CRA zawiera zasadnicze wymagania cyberbezpieczeństwa. W praktyce zespoły muszą rozpatrywać m.in.:

projektowanie produktu z odpowiednim poziomem cyberbezpieczeństwa zależnym od ryzyka;
ochronę przed nieautoryzowanym dostępem;
ochronę poufności, integralności i dostępności danych oraz funkcji;
minimalizację powierzchni ataku;
ograniczanie skutków incydentu;
rejestrowanie i monitorowanie istotnej aktywności związanej z bezpieczeństwem;
bezpieczne usuwanie danych i ustawień;
bezpieczne dostarczanie aktualizacji;
regularne testy i przeglądy bezpieczeństwa;
coordinated vulnerability disclosure.

Lista kontrolna jest punktem startu. Nie jest dowodem wykonania.

Przykład: wymaganie „ogranicz nieautoryzowany dostęp”

Słaby zapis:

„System posiada uwierzytelnianie.”

Zapis operacyjny:

Ryzyko: przejęcie konta administracyjnego może zmienić konfigurację produktu.
Decyzja: role uprzywilejowane wymagają określonego mechanizmu uwierzytelniania i kontroli sesji.
Właściciel: konkretny zespół lub osoba.
Implementacja: link do zmiany technicznej.
Test: scenariusz potwierdzający wymagane zachowanie.
Wynik: PASS/FAIL z datą i wersją produktu.
Dowód: raport/log/screenshot/artefakt testowy.
Przegląd: ponowna ocena po zmianie mechanizmu logowania lub profilu ryzyka.

Dzięki temu po pół roku wiadomo nie tylko, co firma deklarowała, ale również co sprawdzono.

Security by default

Domyślna konfiguracja ma znaczenie, bo użytkownik często nie zmienia ustawień po wdrożeniu. CRA odnosi się m.in. do bezpiecznej konfiguracji, aktualizacji i mechanizmów ochronnych.

Dla każdej ważnej funkcji warto odpowiedzieć:

jakie ustawienie otrzymuje nowy użytkownik;
dlaczego jest bezpieczne dla typowego przypadku;
co użytkownik może osłabić lub wyłączyć;
czy ryzykowna zmiana jest zrozumiała;
czy produkt potrafi wrócić do bezpiecznego stanu;
jaki test potwierdza zachowanie po instalacji i aktualizacji.

Włącz security do release, nie do dokumentacji po release

Przegląd przed wydaniem powinien sprawdzać co najmniej:

czy zmienił się threat model / profil ryzyka;
czy pojawiły się nowe zależności;
czy testy bezpieczeństwa pokrywają zmianę;
czy znane podatności mają decyzje;
czy dokumentacja użytkownika i instrukcje bezpieczeństwa są aktualne;
czy okres wsparcia i zależności pozostają realistyczne;
czy dowody są przypięte do właściwej wersji.

Jeżeli te pytania pojawiają się dopiero podczas audytu, organizacja ma proces dokumentacyjny, a nie security by design.

ENISA: powtarzalne działania zamiast haseł

ENISA opublikowała 30 lipca 2026 r. „Secure by Design and Default Playbook” dla MŚP. Materiał skupia się na przekładaniu zasad na powtarzalne działania w istniejących procesach engineering, product i release. To dobry kierunek także dla wdrożenia CRA: wykorzystać to, co zespół już robi, ale dodać odpowiedzialność i ślad wykonania.

Jak Pulsar wspiera model dowodowy

Potwierdzone obszary Pulsara — ryzyka, kontrole, zadania, dokumenty, dowody, audyty, raporty i historia analiz — pozwalają powiązać decyzję projektową z jej wynikiem i przeglądem.

AI w Pulsarze powinno pozostawać pomocnikiem przygotowującym drafty. Nie powinno autonomicznie zatwierdzać oceny ryzyka, wyjątku bezpieczeństwa ani zgodności produktu.

Zobacz Pulsar GRC na przepływie wymaganie → dowód

Powiązane materiały

Źródła

Stan źródeł: 12 września 2026 r.