Pierwszy termin wynikający z Cyber Resilience Act (CRA), który dotyka zespoły produktowe, to 11 września 2026 r., kiedy zaczynają obowiązywać wymogi dotyczące zgłaszania. Główne obowiązki wchodzą w życie 11 grudnia 2027 r. Zgłaszanie opiera się na procesach i ludziach, a te budowanie trwa długo, dlatego zajmij się nim przed wszystkim innym.
Co obowiązuje i od kiedy
CRA to rozporządzenie (UE) 2024/2847. Według strony Komisji Europejskiej poświęconej CRA rozporządzenie nakłada na producentów obowiązkowe wymagania cyberbezpieczeństwa obejmujące planowanie, projektowanie, wytwarzanie i utrzymanie produktów z elementami cyfrowymi. Wymaga też od producentów obsługi podatności przez cały cykl życia produktu.
| Data | Co się dzieje |
|---|---|
| 10 grudnia 2024 | CRA weszło w życie |
| 11 września 2026 | Zaczynają obowiązywać wymogi zgłaszania |
| 11 grudnia 2027 | Zaczynają obowiązywać główne obowiązki |
Produkty zgodne z wymaganiami będą oznaczane znakiem CE, a przestrzegania przepisów pilnują krajowe organy nadzoru rynku. Niektóre produkty o szczególnym znaczeniu dla cyberbezpieczeństwa mogą wymagać oceny przez niezależną jednostkę notyfikowaną przed wprowadzeniem na rynek UE. Ustal wcześnie, po której stronie tej granicy znajduje się Twój produkt, bo wpływa to na harmonogram.
Komisja opublikowała też 27 lipca 2026 r. praktyczne wytyczne dla producentów. Przeczytaj je, zanim zdecydujesz o kształcie któregokolwiek z procesów opisanych poniżej.
Dowody bezpiecznego wytwarzania
Regulatorzy i klienci zapytają, co zrobiono, więc twórz zapisy jako produkt uboczny codziennej pracy, zamiast odtwarzać je później. Pomaga w tym uznana struktura.
NIST Secure Software Development Framework, SP 800-218, to podstawowy zestaw ogólnych praktyk, które dokładasz do SDLC, jaki już stosujesz. Jego deklarowane cele to mniej podatności w wydanym oprogramowaniu, mniejszy wpływ tych, które pozostają, oraz usuwanie przyczyn źródłowych, by się nie powtarzały. Daje też wspólne słownictwo do rozmów z kupującymi i dostawcami. To dokument amerykański, a nie lista kontrolna CRA, więc traktuj go jako rusztowanie.
Dowody warte zachowania dla każdego wydania:
- model zagrożeń lub przegląd projektu, który obejmował daną zmianę
- wyniki code review i testów, w tym testów bezpieczeństwa
- listy zależności z wersjami oraz decyzje dotyczące znanych w nich problemów
- zatwierdzenie wydania z imieniem i nazwiskiem oraz datą
Materiały CISA Secure by Design dodają dwa praktyczne punkty. Odpowiedzialność powinna leżeć na poziomie zarządu, a ustawienia domyślne mają znaczenie: MFA, logowanie zdarzeń i SSO powinny być dostępne od razu, bez dodatkowych opłat. Jeśli Twój produkt sprzedaje je jako płatne dodatki, spodziewaj się pytań. CISA publikuje również wskazówki dotyczące map drogowych przejścia na języki bezpieczne pamięciowo (memory safe), co warto przeczytać, jeśli Twój kod jest w C lub C++.
Obsługa podatności i zgłaszanie
Od 11 września 2026 r. producenci muszą zgłaszać aktywnie wykorzystywane podatności, wraz z pozostałymi elementami wymienionymi na stronie Komisji poświęconej zgłaszaniu. Sprawdź tę stronę, by poznać dokładny zakres i właściwy kanał. Nie polegaj na streszczeniach, również na tym.
Czego potrzebujesz wewnątrz organizacji, niezależnie od ostatecznych szczegółów:
- Jednego punktu przyjmowania zgłoszeń. Monitorowany kontakt do spraw bezpieczeństwa na stronie produktu i w dokumentacji, z wyznaczonym właścicielem i zastępcą.
- Rutyny triage. Ktoś w ustalonym czasie decyduje, czy zgłoszenie jest zasadne, czy podatność jest wykorzystywana i których produktów oraz wersji dotyczy. Spójna ocena krytyczności przyspiesza ten proces, a nasz kalkulator CVSS przydaje się do uzgadniania ocen w zespole.
- Ścieżki decyzyjnej dla zgłoszeń. Zapisz, kto decyduje, że wykorzystywana podatność uruchamia obowiązek zgłoszenia i kto je składa. Przećwicz to raz na fikcyjnym przypadku, a jeśli tak miałoby to wyglądać w rzeczywistości, to poza godzinami pracy.
- Zapisu każdej decyzji. Także zgłoszeń uznanych za wykraczające poza zakres, wraz z uzasadnieniem.
Zgłaszanie nie zadziała, jeśli nie wiesz, co jest w środku Twojego produktu. Utrzymuj aktualny inwentarz komponentów dla każdej dostarczonej wersji, bo nie oszacujesz ekspozycji na nową podatność z pamięci.
Procesy aktualizacji
Komisja wskazuje brak terminowych aktualizacji bezpieczeństwa jako jeden z problemów, które ma rozwiązać CRA. Produkty muszą być projektowane, aktualizowane i utrzymywane tak, aby chroniły użytkowników. W praktyce oznacza to testowanie ścieżki aktualizacji równie poważnie jak funkcji.
Sprawdź w każdej linii produktowej:
- Możesz wydać poprawkę bezpieczeństwa oddzielnie od wydania z nowymi funkcjami.
- Klienci mogą dowiedzieć się, że aktualizacja istnieje, a jej instalacja nie wymaga kontaktu z supportem.
- Stare wersje mają podaną datę końca wsparcia, widoczną dla klientów przed zakupem.
- W przypadku hardware'u przetestowano aktualizację urządzenia, które było offline przez rok, oraz odzyskanie takiego, któremu aktualizacja przerwała się w połowie.
Typowa luka to nie technologia, lecz odpowiedzialność. Wiele zespołów potrafi przygotować łatkę w jeden dzień, a potem spędza trzy tygodnie na ustalaniu, kto może ją wydać.
Dokumentacja techniczna
Źródła wykorzystane w tym artykule nie wymieniają wymaganej zawartości dokumentacji technicznej, więc sięgnij po nią do tekstu aktu prawnego i wytycznych Komisji. Praktyczny wniosek jest taki, że dokumentację należy składać na bieżąco z opisanych wyżej dowodów, a nie pisać w ostatnim kwartale przed terminem.
Dla każdego produktu utwórz folder dokumentacji lub sekcję w repozytorium, z przypisanym właścicielem. Umieść tam projekt i ocenę ryzyka, inwentarz komponentów, wyniki testów, procedurę obsługi podatności i politykę aktualizacji. Wersjonuj ją razem z produktem. Gdy audytor lub organ poprosi o dokumentację, chcesz ją wyeksportować, a nie zlecać jej przygotowanie.
Jeśli podlegasz też dyrektywie NIS2, którą według Komisji CRA uzupełnia, wykorzystaj te same procedury dotyczące incydentów i podatności, zamiast prowadzić dwa zestawy.
Od czego zacząć
- Przeczytaj wytyczne Komisji z 27 lipca 2026 r. oraz stronę o zgłaszaniu i zapisz, które z Twoich produktów są objęte zakresem oraz czy któryś może wymagać jednostki notyfikowanej.
- Wyznacz właściciela przyjmowania zgłoszeń o podatnościach i zgłaszania podatności wykorzystywanych, opublikuj kontakt do spraw bezpieczeństwa i przeprowadź jedno ćwiczenie w tym kwartale.
- Przygotuj inwentarz komponentów dla każdego wspieranego wydania i uczyń jego generowanie częścią procesu build.
- Zmapuj obecny SDLC na praktyki SSDF, zapisz luki i zacznij przechowywać zapisy z przeglądów, testów i zatwierdzeń dla każdego wydania.
- Przetestuj ścieżkę aktualizacji od początku do końca i opublikuj daty końca wsparcia dla każdego produktu.
- Utwórz folder dokumentacji dla każdego produktu i wypełnij go tym, co już masz. Jeśli chcesz spojrzenia z zewnątrz na luki, nasza usługa doradcza oraz usługa bezpiecznego wytwarzania oprogramowania obejmują dokładnie ten obszar.
