CyberSec Update#32: Raportowanie podatności w CRA
Miesiąc do nowego obowiązku na podstawie CRA
NIS2 i nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa weszły już do powszechnej świadomości prawnej. Niestety nie można tego samego powiedzieć o innym, bardzo ważnym akcie prawnym z zakresu cyberbezpieczeństwa, tj. unijnym Akcie o cyberodporności (Cyber Resilience Act, CRA). Tymczasem już we wrześniu wchodzą w życie pierwsze obowiązki przewidziane w tych przepisach.
Obowiązek raportowania aktywnie wykorzystywanych podatności i poważnych incydentów
Wrzesień 2026 r. będzie pierwszym realnym sprawdzianem gotowości organizacji do wdrożenia wymagań CRA. Chociaż większość obowiązków wynikających z Cyber Resilience Act zacznie obowiązywać dopiero 11 grudnia 2027 r., jeden z nich pojawi się wcześniej.
Już od 11 września 2026 r. producenci produktów z elementami cyfrowymi będą zobowiązani do raportowania aktywnie wykorzystywanych podatności oraz poważnych incydentów mających wpływ na bezpieczeństwo tych produktów.
Nie jest to obowiązek, który można będzie zrealizować poprzez wysłanie prostego formularza „po fakcie”. W praktyce kluczowe będzie szybkie ustalenie, czego dotyczy problem, czy podatność jest aktywnie wykorzystywana, których wersji produktu dotyczy oraz kto odpowiada za decyzję o zgłoszeniu.
Dlaczego ten obowiązek jest tak istotny?
CRA jest regulacją produktową. Jej celem jest ograniczenie liczby podatności w produktach z elementami cyfrowymi oraz zapewnienie, aby cyberbezpieczeństwo było uwzględniane przez cały cykl życia produktu, a nie dopiero wtedy, gdy pojawi się problem.
Wrześniowy obowiązek raportowy jest więc czymś więcej niż formalnością. To pierwszy element CRA wymagający od producentów realnego działania operacyjnego. Jeżeli podatność jest aktywnie wykorzystywana, zegar zaczyna tykać. Producent nie może dopiero wtedy zastanawiać się, kto odpowiada za analizę zgłoszenia, gdzie znajduje się lista komponentów, jak ustalić dotknięte wersje produktu oraz kto kontaktuje się z właściwymi organami.
Jeżeli w pierwszych godzinach po zgłoszeniu organizacja dopiero próbuje ustalić, kto odpowiada za analizę, decyzję i komunikację, oznacza to, że proces raportowania CRA istnieje co najwyżej na papierze.
Co podlega zgłoszeniu?
CRA obejmuje dwa typy zdarzeń, które od 11 września 2026 r. będą wymagały raportowania.
Aktywnie wykorzystywana podatność
Nie chodzi o każdą lukę wykrytą w produkcie. Kluczowe będzie ustalenie, czy istnieją wiarygodne dowody potwierdzające, że podatność została wykorzystana przez podmiot działający bez uprawnienia.
Poważny incydent wpływający na bezpieczeństwo produktu
Może to być zdarzenie wpływające na poufność, integralność, autentyczność lub dostępność danych albo funkcji produktu. Dotyczy to również sytuacji mogących prowadzić do wprowadzenia złośliwego kodu do produktu lub systemów użytkownika.
Kiedy zaczyna biec termin?
W modelu raportowania CRA kluczowy jest moment, w którym producent uzyska wiedzę o zdarzeniu. Od tego momentu należy liczyć:
- 24 godziny na wysłanie wczesnego ostrzeżenia,
- 72 godziny na bardziej szczegółowe zgłoszenie,
- 14 dni na raport końcowy w przypadku aktywnie wykorzystywanej podatności,
- 1 miesiąc na raport końcowy w przypadku poważnego incydentu.
Oznacza to, że już w pierwszych godzinach należy ustalić podstawowe fakty: jaki produkt został dotknięty problemem, czy podatność jest aktywnie wykorzystywana, jaki może być wpływ na użytkowników oraz czy należy rozpocząć procedurę zgłoszeniową.
Czego nie zastąpi procedura incydentowa z NIS2?
W organizacjach objętych NIS2 naturalnym odruchem może być próba wykorzystania istniejących procedur incydentowych. Problem polega jednak na tym, że CRA wymaga dodatkowego pytania: czy problem dotyczy bezpieczeństwa produktu udostępnionego na rynku?
To zmienia perspektywę. Trzeba umieć połączyć zgłoszenie z konkretną wersją produktu, komponentem, biblioteką, modułem, firmware’em albo mechanizmem aktualizacji.
Dlatego producenci powinni uzupełnić swoje procesy NIS2 o element produktowy, w szczególności o obsługę podatności produktu, zarządzanie komponentami, procedurę Coordinated Vulnerability Disclosure (CVD) oraz ścieżkę raportowania zgodną z CRA.
Co producent powinien mieć gotowe przed 11 września?
Na miesiąc przed wejściem w życie nowych obowiązków minimalny poziom gotowości powinien obejmować:
- mapę produktów potencjalnie objętych CRA, wraz z określeniem właścicieli produktów w organizacji,
- procedurę wstępnej kwalifikacji podatności, pozwalającą ustalić, czy zgłoszenie dotyczy produktu i czy wymaga raportowania,
- kanał przyjmowania zgłoszeń podatności, np. dedykowany adres bezpieczeństwa lub formularz,
- ewidencję komponentów, bibliotek i modułów wykorzystywanych w produktach,
- wzory zgłoszeń oraz komunikatów wykorzystywanych w sytuacjach kryzysowych.
Co zrobić teraz?
Najbliższe tygodnie warto wykorzystać na praktyczny test gotowości. Dobrym ćwiczeniem może być symulacja sytuacji, w której producent otrzymuje informację o podatności w komponencie wykorzystywanym w kilku wersjach produktu, wraz z sugestią, że podatność jest już aktywnie wykorzystywana.
Organizacja powinna sprawdzić, czy w ciągu jednego dnia potrafi odpowiedzieć na następujące pytania:
- kto przyjmuje zgłoszenie,
- kto weryfikuje podatność od strony technicznej,
- kto ustala, których produktów i wersji dotyczy problem,
- kto ocenia, czy podatność jest aktywnie wykorzystywana,
- kto podejmuje decyzję o raportowaniu,
- kto odpowiada za komunikację z użytkownikami,
- jakie dowody są dokumentowane.
Jeżeli odpowiedzi nie są oczywiste, to właśnie te luki należy zamknąć w pierwszej kolejności.
Podsumowanie
11 września 2026 r. nie oznacza jeszcze pełnego wejścia w życie wszystkich obowiązków CRA. Oznacza jednak początek bardzo konkretnego reżimu raportowego. Producenci produktów z elementami cyfrowymi muszą być gotowi na szybkie zgłaszanie aktywnie wykorzystywanych podatności oraz poważnych incydentów wpływających na bezpieczeństwo produktu.
Nie można traktować tego obowiązku jako prostego rozszerzenia procedur incydentowych. CRA wymaga spojrzenia przez pryzmat produktu, jego komponentów, wersji, użytkowników i całego cyklu życia.
W pierwszych godzinach po zgłoszeniu nie powinno być miejsca na organizacyjną scenę z „Rejsu”, w której każdy zabiera głos, ale nie wiadomo, kto odpowiada za decyzję. Raportowanie zgodne z CRA wymaga wcześniejszego ustalenia ról, danych wejściowych oraz ścieżki eskalacji. To właśnie ta gotowość będzie odróżniać producentów przygotowanych od tych, którzy zaczną szukać „kierownika wycieczki”, gdy termin 24 godzin już zacznie biec.




