Cyber Resilience Act: nowy obowiązek testowania podatności przez cały cykl życia produktu

Cyber Resilience Act, w skrócie CRA, to rozporządzenie unijne 2024/2847, które w kilku miejscach zmienia definicję dobrze przetestowanego produktu. Do tej pory wystarczyło przetestować oprogramowanie przed premierą, odhaczyć raport bezpieczeństwa i wydać wersję. CRA wymaga testowania podatności przez cały okres wsparcia produktu, nie tylko raz, przed wydaniem. Dla firm, które sprzedają oprogramowanie jako produkt, nie tylko usługę wdrożenia na cudzym kodzie, to zmiana fundamentalna, a terminy są już bardzo bliskie. Ten artykuł rozkłada CRA na to, co naprawdę trzeba wiedzieć: kogo dotyczy, jakie ma terminy, i co konkretnie zmienia się w codziennej pracy zespołu QA, nie tylko w dziale prawnym.

Kogo dotyczy CRA i dlaczego termin jest bliżej, niż się wydaje

Rozporządzenie wprowadza jednolite, unijne wymogi cyberbezpieczeństwa dla produktów cyfrowych, czyli w praktyce dla każdego producenta, który wprowadza na rynek UE oprogramowanie albo urządzenie z elementami cyfrowymi. Nie trzeba być gigantem technologicznym, żeby podlegać CRA. Wystarczy sprzedawać produkt, nie tylko świadczyć usługę wdrożenia na cudzym kodzie. Definicja produktu z elementami cyfrowymi jest celowo szeroka: obejmuje wbudowane oprogramowanie w urządzeniach, aplikacje sprzedawane jako produkt, biblioteki dystrybuowane komercyjnie i komponenty integrowane w cudzych systemach. Uwaga za to na częsty błąd w drugą stronę: czysty SaaS zwykle zostaje poza CRA, bo typowe usługi chmurowe podlegają raczej pod NIS2, co podkreśla przewodnik Security Bez Tabu dla producentów. Granica jest jednak cienka, urządzenie sprzedawane razem z usługą chmurową, na przykład kamera z platformą online, jest już traktowane w całości jako produkt z elementami cyfrowymi. Jeśli Wasz produkt łączy sprzęt, aplikację i chmurę, o zakresie decyduje całość, nie jego najwygodniejszy fragment.

To rozróżnienie, produkt kontra usługa, jest kluczowe i często mylące. Firma, która buduje dedykowane oprogramowanie dla jednego klienta na zlecenie, zwykle nie podlega CRA w tym samym zakresie, co firma, która to samo oprogramowanie sprzedaje wielu klientom jako gotowy produkt. Granica bywa płynna: software house, który zaczyna sprzedawać własny produkt SaaS obok projektów na zlecenie, w pewnym momencie przekracza tę granicę, często niezauważalnie dla siebie samego, dopóki nie sprawdzi tego świadomie.

CERT Polska opisuje istotę zmiany wprost: producent musi systematycznie monitorować i testować produkt pod kątem podatności nie tylko podczas rozwoju, ale przez cały okres jego użytkowania. To jest różnica względem dotychczasowej praktyki, w której test bezpieczeństwa był jednorazowym wydarzeniem przed wdrożeniem, a nie ciągłym procesem. Dotychczasowy model, w którym audyt bezpieczeństwa jest projektem z datą początku i końca, przestaje wystarczać, niezależnie od tego, jak dokładny był w momencie realizacji. Według CERT Polska kalendarz stosowania rozporządzenia ma zresztą więcej etapów, niż się powszechnie pamięta: już od 11 czerwca 2026 stosuje się rozdział IV, czyli artykuły 35 do 51 o jednostkach oceniających zgodność.

Warto zatrzymać się przy pierwszym terminie dłużej, bo to on realnie testuje gotowość firmy, nie deklarację. Zgłoszenie w 24 godziny od wykrycia aktywnie wykorzystywanej podatności zakłada, że firma w ogóle ma mechanizm wykrywania takiej sytuacji w czasie zbliżonym do rzeczywistego. Zespoły, które dziś dowiadują się o podatnościach z opóźnionych raportów miesięcznych albo z wiadomości od klienta, nie mają szans dotrzymać tego terminu, niezależnie od tego, jak szybko zareagują po fakcie. Budowa tego mechanizmu, monitoring, alerting, jasno przypisana odpowiedzialność za triage, to praca na miesiące, nie tygodnie, co czyni wrzesień 2026 znacznie bliższym terminem, niż sugeruje kalendarz.

Artykuł 14 CRA nie kończy się zresztą na jednym zgłoszeniu. To proces trzystopniowy: wczesne ostrzeżenie w 24 godziny od wykrycia, pełne zgłoszenie w 72 godziny z opisem podatności i wskazówkami dla użytkowników, a na końcu raport końcowy w 14 dni od wdrożenia poprawki albo środków zaradczych. Każdy z tych trzech kroków trafia do ENISA i właściwego zespołu CSIRT, więc firma musi mieć nie jeden proces zgłoszeniowy, tylko trzy punkty kontrolne rozłożone w czasie, z których każdy wymaga innego poziomu szczegółowości informacji o incydencie. Jak podaje portal cyberresilienceact.eu, raport końcowy dla poważnego incydentu ma osobny termin 1 miesiąca od pełnego zgłoszenia. Według zestawienia opublikowanego przez ENISA 4 września 2026 koordynatora CSIRT do przyjmowania takich zgłoszeń wyznaczyło już wszystkich 27 państw członkowskich. Ten sam portal cyberresilienceact.eu podaje nawet limity techniczne formularza, 4000 znaków na opis zgłoszenia i 2000 znaków na opis podjętych środków, więc zwięzłe pisanie o incydentach też staje się kompetencją zespołu.

Testowanie jako proces ciągły, nie jednorazowy odbiór

Esencja CRA mieści się w jednym zdaniu z załącznika I do rozporządzenia: bezpieczeństwo musi być wbudowane w projekt, zarządzanie podatnościami musi działać stale, a konfiguracja domyślna musi być bezpieczna. Dla zespołu QA oznacza to koniec modelu, w którym test bezpieczeństwa jest jednym z etapów przed wydaniem, obok testów funkcjonalnych i wydajnościowych. Test podatności staje się elementem cyklu utrzymania, tak samo rutynowym jak monitoring produkcji. Security Bez Tabu podaje jeszcze jeden wymóg, o którym rzadko się pamięta: wydane poprawki bezpieczeństwa mają pozostać dostępne do pobrania przez 10 lat, więc archiwum aktualizacji staje się częścią produktu, a nie folderem na dysku administratora.

Praktyczna konsekwencja jest ostra: producent nie może wypuścić nowej funkcji, jeśli wie o nierozwiązanej podatności w obecnej wersji. To wymaga procesu, który na bieżąco łączy zarządzanie podatnościami z planowaniem wydań, nie oddzielnego audytu raz na kwartał. Firmy, które dziś traktują testy bezpieczeństwa jako punktowy zakup przed dużym wdrożeniem, będą musiały przejść na model subskrypcyjny: stały monitoring, powtarzalne testy penetracyjne, udokumentowany proces reagowania. To zmiana nie tylko technologiczna, ale i budżetowa: koszt bezpieczeństwa przestaje być pozycją jednorazową w budżecie projektu, a staje się stałym kosztem operacyjnym, podobnym do hostingu czy licencji. Test bezpieczeństwa przestaje być jak przegląd samochodu przed daleką trasą, a zaczyna przypominać mycie zębów: nikt nie wystawia za nie dyplomu, ale każda dłuższa przerwa szybko robi się widoczna dla otoczenia.

Drugi element, o którym łatwo zapomnieć, to zakaz wydawania nowych funkcji przy znanej, nierozwiązanej podatności. W praktyce oznacza to, że backlog produktowy i backlog bezpieczeństwa przestają być osobnymi listami priorytetów, prowadzonymi przez różne zespoły w różnym rytmie. Product owner, który dziś planuje sprint bez informacji o statusie znanych podatności, planuje na ślepo, nawet jeśli sam kod, który chce wydać, jest bez zarzutu. Jest też wymiar czysto operacyjny: poprawka bezpieczeństwa musi przejść regresję, zanim wyjdzie na produkcję, a zegar zgłoszeń tyka od momentu wykrycia. W projekcie dla Argos skróciliśmy pełną regresję przed wydaniem z 5 dni do 10 godzin i to jest dokładnie ten rząd wielkości, który decyduje o tym, czy 24 godziny na wczesne ostrzeżenie i szybka poprawka są u Was realne, czy tylko zapisane w procedurze.

Nasza perspektywa: co z tego realnie wynika

Co się realnie zmienia w praktyce testowania

Źródło: Multicert, CERT Polska, Security Bez Tabu, materiały o Cyber Resilience Act, 2026.

Dla firm, które kupują testy u zewnętrznego dostawcy, pojawia się dodatkowy argument za niezależnością testera od producenta kodu. Jeżeli audytor musi ocenić, czy proces zarządzania podatnościami działa rzetelnie, a nie tylko na papierze, wewnętrzny zespół, który sam pisał kod i sam go testuje, ma słabszą pozycję dowodową niż zespół zewnętrzny, bez konfliktu interesu. To nie jest różnica kosmetyczna. W modelach oceny zgodności, które znamy z innych regulacji, niezależność testera bywa formalnym wymogiem, nie tylko dobrą praktyką, a CRA zmierza w tym samym kierunku dla kategorii produktów o podwyższonym ryzyku. Audytowaliśmy procesy QA w organizacjach z sektora regulowanego, między innymi w PKO BP, i właśnie tam widać najlepiej, że audytor pyta najpierw o ślad dokumentacyjny i rozdzielenie ról, a dopiero potem o wyniki samych testów.

Warto też zauważyć, że wymóg bezpiecznej konfiguracji domyślnej zmienia sposób projektowania testów akceptacyjnych. Test, który dziś sprawdza, czy funkcja działa zgodnie ze specyfikacją, będzie musiał dodatkowo sprawdzać, czy domyślna konfiguracja tej funkcji jest bezpieczna bez żadnej dodatkowej interwencji użytkownika. To wymaga rozszerzenia klasycznych kryteriów akceptacji o kryteria bezpieczeństwa, które dotąd żyły osobno, w oddzielnym dokumencie, czytanym przez inny zespół. Zespołom, które te kompetencje dopiero budują, dobrze robi start od szkolenia z testów bezpieczeństwa dla początkujących albo warsztatu z testów penetracyjnych aplikacji webowej, a terminy najbliższych grup otwartych znajdziecie w kalendarzu szkoleń. Szkoliliśmy z tego zakresu między innymi 14 osób z AgroApp na dwudniowych warsztatach z testów bezpieczeństwa i z naszego doświadczenia wynika, że próg wejścia jest niższy, niż większość zespołów zakłada.

CRA a NIS2: różne regulacje, ten sam błąd firm

Firmy, które już przeszły przez wdrożenie NIS2, czasem zakładają, że CRA jest tylko rozszerzeniem tego samego obowiązku. To błąd, bo obie regulacje patrzą na zupełnie inny przedmiot. NIS2 reguluje bezpieczeństwo organizacji i usług w sektorach kluczowych dla gospodarki: energetyce, transporcie, bankowości, ochronie zdrowia, i dotyczy głównie średnich i dużych firm z tych branż. CRA nie pyta, w jakim sektorze działacie, tylko czy sprzedajecie w UE produkt z elementami cyfrowymi. Producent oprogramowania księgowego dla małych firm nie mieści się w żadnym sektorze objętym NIS2, a mimo to podlega CRA na takich samych zasadach jak dostawca oprogramowania przemysłowego.

Konsekwencja jest praktyczna: firma może w pełni wywiązać się z NIS2, a i tak zostać całkowicie nieprzygotowana na CRA, bo to dwa niezależne obowiązki zgodności, sprawdzane przez różne instytucje i na podstawie różnych kryteriów. Warto traktować je jako dwa osobne projekty compliance, nie jeden rozszerzony o kolejny paragraf. Do kompletu regulacyjnego dochodzą jeszcze dwa akty, które opisaliśmy osobno: DORA z wymogiem corocznych testów niezależnych dla sektora finansowego oraz AI Act z obowiązkami testowania systemów wysokiego ryzyka. A jeśli zarząd dopiero oswaja temat bezpieczeństwa, dobrym punktem startu jest minimalny zestaw działań w testach bezpieczeństwa dla zarządów na Strefie QA.

Ile kosztuje brak zgodności

CRA ma trójstopniową skalę kar, podobnie jak inne nowe regulacje cyfrowe UE. Jak wynika z artykułu 64 rozporządzenia 2024/2847, najwyższy próg, do 15 milionów euro albo 2,5% globalnego rocznego obrotu, dotyczy producentów, którzy nie spełniają podstawowych wymogów cyberbezpieczeństwa z załącznika I albo łamią obowiązki zgłoszeniowe z artykułów 13 i 14. Importerzy i dystrybutorzy odpowiadają w niższym progu, do 10 milionów euro albo 2% obrotu, a podanie fałszywych albo niepełnych informacji organom nadzoru kosztuje do 5 milionów euro albo 1% obrotu. Poza samymi karami finansowymi organy nadzoru mogą też zakazać sprzedaży produktu na rynku UE albo nakazać jego wycofanie, co dla firmy sprzedającej produkt jako główne źródło przychodu bywa dotkliwsze niż sama kara pieniężna.

Co to oznacza praktycznie dla waszej firmy

Zanim zaczniecie budować proces zgodności z CRA, warto odpowiedzieć sobie na trzy pytania. Pierwsze: czy ktokolwiek w firmie formalnie sprawdził, czy to, co sprzedajecie, jest produktem z elementami cyfrowymi w rozumieniu CRA, czy usługą wdrożenia poza jego zakresem. Drugie: czy macie dziś mechanizm, który wykryje aktywnie wykorzystywaną podatność i przeprowadzi zgłoszenie przez wszystkie trzy etapy, od 24 godzin do 14 dni, czy dowiadujecie się o incydentach z opóźnieniem. Trzecie: czy backlog bezpieczeństwa i backlog produktowy są dziś jedną listą priorytetów, czy dwiema osobnymi, prowadzonymi bez wzajemnej widoczności.

Firmy, które zaczną odpowiadać na te pytania teraz, mają do września 2026 czas na zbudowanie procesu zgłoszeniowego bez presji, i do grudnia 2027 na pełne dostosowanie produktów. To wciąż dużo czasu, ale tylko dla tych, którzy zaczną liczyć go już dziś, nie w roku, w którym termin przestaje być teorią.

Powiązane na blogu Quality Island

• Testy penetracyjne i testy bezpieczeństwa: jak sprawdzić odporność systemu
• Długofalowa współpraca QA w organizacji IT

Pełna lista źródeł

• CERT Polska, CRA, nowe obowiązki dla producentów oprogramowania i korzyści dla użytkowników, 2026. Stąd wzięliśmy zasadę ciągłego monitorowania podatności, kalendarz etapów stosowania i wyjątek dla wersji testowych
• Multicert, Cyber Resilience Act 2026, trzy terminy, które producent oprogramowania musi znać, 2026. Stąd zestawienie trzech kluczowych terminów CRA
• Security Bez Tabu, Cyber Resilience Act, kompleksowy przewodnik dla producentów. Stąd zakres CRA wobec usług chmurowych i wymóg dostępności poprawek przez 10 lat
• cyberresilienceact.eu, CRA Reporting, 24h, 72h i 14-day Deadlines, Artykuł 14, 2026. Stąd progi czasowe zgłoszeń, limity platformy zgłoszeniowej i informacja o koordynatorach CSIRT ogłoszonych przez ENISA
• Rozporządzenie UE 2024/2847 (Cyber Resilience Act), 2024, Artykuł 14 o zgłoszeniach i Artykuł 64 o karach