Cyber Resilience Act od września 2026 roku: co twórcy oprogramowania powinni wiedzieć o 24- i 72-godzinnym zgłaszaniu podatności
Od 11 września 2026 roku zacznie obowiązywać jeden z najbardziej wymagających czasowo obowiązków wynikających z Cyber Resilience Act. Artykuł 14 rozporządzenia (UE) 2024/2847 zobowiązuje producentów objętych przepisami produktów z elementami cyfrowymi do zgłaszania określonych aktywnie wykorzystywanych podatności oraz poważnych incydentów bezpieczeństwa zgodnie ze ściśle określonym harmonogramem: wczesne ostrzeżenie należy przekazać w ciągu 24 godzin, a bardziej szczegółowe zgłoszenie w ciągu 72 godzin od momentu uzyskania wiedzy o zdarzeniu. Dla zespołów tworzących oprogramowanie nie jest to wyłącznie kwestia działu prawnego. Programiści, specjaliści ds. bezpieczeństwa, właściciele produktów i osoby odpowiedzialne za reagowanie na incydenty mogą jako pierwsi zauważyć dowody uruchamiające bieg terminu zgłoszeniowego. Praktyczne wyzwanie polega więc na prawidłowym rozpoznaniu zdarzeń podlegających zgłoszeniu, zabezpieczeniu wystarczających informacji do podjęcia uzasadnionej decyzji oraz sprawnym przejściu od analizy technicznej do zgłoszenia regulacyjnego bez opóźniania działań naprawczych.
Co zmienia się dla zespołów programistycznych 11 września 2026 roku
CRA weszło w życie 10 grudnia 2024 roku, jednak poszczególne obowiązki wynikające z rozporządzenia nie zaczynają obowiązywać jednocześnie. Większość jego przepisów będzie stosowana od 11 grudnia 2027 roku, natomiast artykuł 14 zacznie obowiązywać wcześniej — 11 września 2026 roku. To rozróżnienie ma duże znaczenie, ponieważ firmy nie mogą zakładać, że mają czas do końca 2027 roku na stworzenie procesu zgłaszania podatności. Wcześniejsze obowiązki raportowe mają również szeroki zakres przejściowy. Artykuł 69 stanowi, że artykuł 14 ma zastosowanie do wszystkich produktów z elementami cyfrowymi objętych CRA, w tym produktów wprowadzonych na rynek UE przed 11 grudnia 2027 roku. Oznacza to, że starsza aplikacja komputerowa, wcześniejsza wersja firmware’u lub komercyjna biblioteka może spowodować powstanie obowiązku zgłoszeniowego już we wrześniu 2026 roku, nawet jeśli produkt nie podlega jeszcze pełnemu zakresowi wymogów CRA przewidzianych na 2027 rok.
Dla programistów pierwszym zadaniem jest ustalenie, czy dane oprogramowanie stanowi część „produktu z elementami cyfrowymi”. CRA używa tego pojęcia w odniesieniu do produktów programowych lub sprzętowych, w tym komponentów oprogramowania i sprzętu dostarczanych oddzielnie, których zamierzone lub racjonalnie przewidywalne użycie obejmuje bezpośrednie albo pośrednie połączenie z urządzeniem lub siecią. Zakres może obejmować także zdalne przetwarzanie danych niezbędne do wykonywania jednej z funkcji produktu, jeżeli zostało ono zaprojektowane lub opracowane przez producenta albo na jego odpowiedzialność. Oznacza to, że analiza może wykraczać poza sam plik wykonywalny zainstalowany na urządzeniu użytkownika. Na przykład aplikacja mobilna zależna od kontrolowanego przez producenta API lub bazy danych może wymagać oceny razem z tą zdalną funkcjonalnością. Z kolei niezależne strony internetowe lub usługi chmurowe, które nie są potrzebne do działania produktu, nie są automatycznie objęte CRA.
Obowiązek prawny spoczywa na „producencie”, przy czym rozporządzenie definiuje to pojęcie szerzej, niż mogłoby wynikać z jego potocznego znaczenia. Producentem może być osoba fizyczna lub prawna, która opracowuje produkt z elementami cyfrowymi, zleca jego opracowanie i wprowadza go do obrotu pod własną nazwą lub znakiem towarowym, niezależnie od tego, czy produkt jest sprzedawany, monetyzowany w inny sposób czy udostępniany bezpłatnie. Programista zatrudniony w takiej organizacji nie musi osobiście przesyłać zgłoszenia, jednak informacje, które wykryje, mogą przesądzić o momencie, od którego uznaje się, że producent posiada wiedzę o zdarzeniu. Oprogramowanie bezpłatne i open source również wymaga dokładnej klasyfikacji. Niekomercyjny rozwój open source jest traktowany odmiennie, natomiast komercyjne produkty open source mogą wiązać się z obowiązkami producenta, a określone organizacje zapewniające trwałe wsparcie projektom open source mogą zostać uznane za podmioty zarządzające oprogramowaniem open source. Zespoły powinny więc ustalać odpowiedzialność prawną dla konkretnych produktów, zamiast zakładać, że sam rodzaj licencji, model biznesowy lub sposób tworzenia oprogramowania rozstrzyga tę kwestię.
Co dokładnie oznaczają terminy 24 i 72 godzin
Termin 24 godzin dotyczy wczesnego ostrzeżenia, a nie wymogu zakończenia pełnego dochodzenia lub opublikowania poprawki w ciągu jednego dnia. W przypadku aktywnie wykorzystywanej podatności termin zaczyna biec w momencie, gdy producent uzyska wiedzę, że produkt zawiera podatność, w odniesieniu do której istnieją wiarygodne dowody złośliwego wykorzystania bez zgody właściciela systemu. Wczesne ostrzeżenie należy przesłać bez zbędnej zwłoki, a w każdym przypadku nie później niż w ciągu 24 godzin. W stosownych przypadkach powinno ono wskazywać państwa członkowskie, w których producent wie, że produkt został udostępniony. W przypadku poważnego incydentu mającego wpływ na bezpieczeństwo produktu obowiązuje taki sam maksymalny termin 24 godzin. Wczesne ostrzeżenie powinno również wskazywać, czy istnieje podejrzenie, że incydent był skutkiem działań bezprawnych lub złośliwych, a także — jeśli ma to zastosowanie — wskazać odpowiednie państwa członkowskie.
Etap 72-godzinny obejmuje bardziej szczegółowe zgłoszenie, jednak nadal jest to wstępny opis regulacyjny, a nie zakończony raport z analizy kryminalistycznej. W przypadku aktywnie wykorzystywanej podatności producent powinien przekazać dostępne ogólne informacje dotyczące produktu, charakteru podatności i sposobu jej wykorzystania, podjętych działań naprawczych lub ograniczających ryzyko, środków dostępnych dla użytkowników oraz — w stosownych przypadkach — wskazać wrażliwość przekazywanych informacji. W przypadku poważnego incydentu zgłoszenie powinno opisywać jego charakter, zawierać wstępną ocenę oraz przedstawiać działania naprawcze lub ograniczające ryzyko, które zostały podjęte albo są dostępne dla użytkowników. Oba terminy liczone są od momentu uzyskania wiedzy o zdarzeniu podlegającym zgłoszeniu. Oczekiwanie na identyfikator CVE, pełną analizę przyczyny źródłowej, publiczny komunikat bezpieczeństwa lub gotową poprawkę może więc stworzyć niepotrzebne ryzyko naruszenia wymogów, jeśli organizacja posiada już wystarczające informacje, aby stwierdzić, że artykuł 14 ma zastosowanie.
Istnieje również późniejszy etap raportowania. W przypadku aktywnie wykorzystywanej podatności raport końcowy należy przekazać nie później niż 14 dni po udostępnieniu środka naprawczego lub ograniczającego ryzyko. Powinien on opisywać podatność, w tym jej poziom istotności i wpływ, przedstawiać dostępne informacje dotyczące podmiotu wykorzystującego podatność oraz wyjaśniać, jaka aktualizacja bezpieczeństwa lub inny środek naprawczy został udostępniony. W przypadku poważnego incydentu raport końcowy należy złożyć w ciągu miesiąca od 72-godzinnego zgłoszenia. Powinien on szczegółowo opisywać incydent, jego wagę i skutki, prawdopodobne zagrożenie lub przyczynę źródłową oraz środki ograniczające ryzyko, które zostały zastosowane lub nadal są wdrażane. Wyznaczony CSIRT może także zażądać raportu pośredniego dotyczącego aktualnego stanu sprawy. Programiści powinni więc traktować etapy 24- i 72-godzinny jako początek całej sekwencji raportowania, a nie jej zakończenie.
Jak ustalić, czy podatność lub incydent trzeba zgłosić
Jednym z najważniejszych rozróżnień w artykule 14 jest różnica między podatnością poważną z technicznego punktu widzenia a podatnością aktywnie wykorzystywaną. CRA definiuje aktywnie wykorzystywaną podatność poprzez odniesienie do wiarygodnych dowodów wskazujących, że złośliwy podmiot faktycznie wykorzystał ją w systemie bez odpowiedniego uprawnienia. Wysoka ocena istotności, opublikowany przez badacza proof of concept, teoretyczna ścieżka ataku lub alert ze skanera nie oznaczają automatycznie spełnienia tego kryterium. Takie sygnały mogą uzasadniać pilne dochodzenie i działania naprawcze, jednak obowiązek zgłoszenia podatności zgodnie z artykułem 14 koncentruje się na rzeczywistym wykorzystaniu. Rozsądny proces wewnętrzny powinien więc oddzielać trzy pytania: czy podatność występuje w produkcie objętym CRA, czy istnieją wiarygodne dowody jej złośliwego wykorzystania oraz kiedy producent uzyskał wiedzę o tych dowodach.
Ścieżka dotycząca incydentów wygląda inaczej. Artykuł 14 wymaga zgłaszania „poważnych incydentów mających wpływ na bezpieczeństwo produktu z elementami cyfrowymi”. Incydent uznaje się za poważny, jeżeli negatywnie wpływa lub może negatywnie wpłynąć na zdolność produktu do ochrony dostępności, autentyczności, integralności lub poufności wrażliwych albo istotnych danych lub funkcji, bądź jeżeli doprowadził lub może doprowadzić do wprowadzenia albo wykonania złośliwego kodu w produkcie lub w sieci i systemach informacyjnych użytkownika. Oznacza to, że zespoły powinny analizować wpływ zdarzenia na bezpieczeństwo produktu i jego użytkowników, a nie wyłącznie to, czy sama firma padła ofiarą wewnętrznego incydentu bezpieczeństwa. Na przykład naruszenie procesu kompilacji lub aktualizacji może mieć szczególne znaczenie, jeżeli może wpłynąć na kod dostarczany klientom.
Ponieważ bieg terminu zgłoszeniowego zależy od momentu uzyskania wiedzy o zdarzeniu, firmy potrzebują udokumentowanego sposobu podejmowania i rejestrowania decyzji dotyczącej spełnienia kryteriów. Programista, który otrzyma wiarygodne zgłoszenie od klienta, zespół bezpieczeństwa zauważający oznaki aktywnego wykorzystania lub badacz przedstawiający konkretne dowody mogą przekazać informacje wymagające szybkiej eskalacji. Organizacja powinna zapisywać, co było wiadomo, kiedy informacje stały się dostępne, jak oceniono dowody oraz kto podjął decyzję dotyczącą obowiązku zgłoszenia. Nie oznacza to, że każdy alert musi najpierw trafić do prawników, zanim dział techniczny zacznie działać. Oznacza natomiast, że działania techniczne i zgodnościowe powinny być prowadzone równolegle. Usuwanie problemu należy rozpocząć natychmiast, podczas gdy niewielki zespół decyzyjny ustala, czy zdarzenie stanowi aktywnie wykorzystywaną podatność, poważny incydent, oba te przypadki czy żaden z nich. Pisemny zapis jest szczególnie cenny wtedy, gdy początkowe informacje są niepełne, a klasyfikacja zmienia się wraz z postępem dochodzenia.
Jakie dowody programiści powinni zabezpieczyć w pierwszych godzinach
Pierwsze godziny dochodzenia często decydują o tym, czy firma będzie w stanie dotrzymać ustawowego harmonogramu bez pogorszenia jakości analizy technicznej. Programiści i osoby reagujące na incydenty powinny zabezpieczyć podstawowe informacje identyfikujące produkt, wersje objęte problemem, kanały dystrybucji, podejrzany podatny komponent, daty i godziny istotnych obserwacji oraz dowody potwierdzające aktywne wykorzystanie lub powagę incydentu. Logi, zgłoszenia klientów, dane o awariach, wskaźniki naruszenia bezpieczeństwa, korespondencja z badaczami i wyniki testów wewnętrznych mogą mieć znaczenie, ale zespoły nie powinny przeciążać procesu zgłoszeniowego niezweryfikowanymi informacjami. Celem etapu wczesnego ostrzeżenia jest ustalenie wiarygodnego zestawu podstawowych faktów. Lepiej jasno wskazać, co zostało potwierdzone, a co nadal jest badane, niż opóźniać zgłoszenie do czasu potwierdzenia każdego szczegółu technicznego.
Równie ważna jest ewidencja produktów. Podatność może znajdować się we wspólnej zależności wykorzystywanej w kilku produktach, wersjach lub edycjach, podczas gdy obowiązek raportowy dotyczy objętych problemem produktów z elementami cyfrowymi danego producenta. Zespół musi potrafić szybko ustalić, gdzie używany jest dany komponent, które wersje nadal pozostają w obrocie, czy oprogramowanie wciąż jest udostępniane w UE oraz które państwa członkowskie mają znaczenie dla zgłoszenia. Jest to jeden z powodów, dla których dokumentacja zależności oraz Software Bill of Materials mogą być wartościowe jeszcze przed rozpoczęciem obowiązywania szerszych wymogów CRA w 2027 roku. Skracają one czas pomiędzy stwierdzeniem „mamy problem w tej bibliotece” a ustaleniem „wiemy, które obsługiwane produkty mogą ją zawierać”. W przypadku starszych produktów zadanie może być trudniejsze, ponieważ systemy kompilacji, repozytoria, zależności lub wiedza dawnych członków zespołu mogą nie być już łatwo dostępne.
Zależności open source wymagają dodatkowej ścieżki komunikacji. Producent może stwierdzić, że problem nie znajduje się w kodzie napisanym przez jego własny zespół, lecz w komponencie utrzymywanym przez zewnętrzny projekt lub dostawcę. Podstawowe pytanie wynikające z artykułu 14 pozostaje jednak takie samo: czy własny produkt producenta objęty CRA zawiera aktywnie wykorzystywaną podatność lub został dotknięty poważnym incydentem. Jednocześnie zespół powinien posiadać odpowiedzialną procedurę kontaktowania się z opiekunem komponentu i koordynowania działań naprawczych, gdy jest to zasadne. Programiści nie powinni zakładać, że projekt źródłowy dokona zgłoszenia CRA w imieniu każdej firmy korzystającej z jego kodu. Każdy producent musi rozumieć własny produkt, posiadane dowody i swoją rolę prawną. Jest to szczególnie istotne w przypadku szeroko stosowanych bibliotek, ponieważ ta sama podatność może powodować różny poziom ryzyka i odmienne skutki w różnych produktach zależnych.
Jak stworzyć proces raportowania działający podczas rzeczywistego incydentu
Proces raportowania przewidziany w CRA został zaprojektowany tak, aby producent przesyłał jedno zgłoszenie za pośrednictwem CRA SRP zarządzanego przez ENISA. Zgłoszenie kierowane jest do CSIRT wyznaczonego jako koordynator dla właściwego państwa członkowskiego i co do zasady jest jednocześnie udostępniane ENISA. W przypadku producenta posiadającego główną siedzibę w UE właściwym państwem członkowskim jest zasadniczo państwo, w którym podejmowane są główne decyzje dotyczące cyberbezpieczeństwa jego produktów. Rozporządzenie określa również dodatkowe zasady dla producentów nieposiadających głównej siedziby w UE. Firmy działające w kilku krajach powinny więc ustalić właściwą ścieżkę zgłoszeniową jeszcze przed wystąpieniem incydentu. Termin 24 godzin pozostawia niewiele czasu na ustalanie podczas trwającego ataku, która spółka odpowiada za produkt lub do którego krajowego CSIRT należy przekazać zgłoszenie.
Wytyczne ENISA z sierpnia 2026 roku przedstawiają firmom programistycznym praktyczny obraz sposobu dostępu do CRA SRP w chwili jego uruchomienia. Wyznaczeni przedstawiciele uwierzytelniają się za pomocą osobistego konta EU Login z uwierzytelnianiem dwuskładnikowym; ENISA odradza korzystanie w tym celu ze wspólnej skrzynki funkcyjnej. Producent może posiadać jednego Primary Assigned Representative oraz maksymalnie 20 Secondary Assigned Representatives. ENISA wskazuje również, że weryfikacja powiązania wyznaczonego przedstawiciela z producentem jest przeprowadzana przez właściwy CSIRT i nie powinna uniemożliwiać przesłania wymaganego zgłoszenia. Ponieważ usługa ma rozpocząć działanie najpóźniej 11 września 2026 roku, a wytyczne mogą być nadal aktualizowane, organizacje powinny przed przygotowaniem lub wysłaniem pierwszego zgłoszenia sprawdzić najnowsze instrukcje ENISA, zamiast opierać się na starych zrzutach ekranu lub wcześniejszych wersjach procedur wewnętrznych.
Raportowanie nie zastępuje również komunikacji z użytkownikami, których dotyczy problem. Artykuł 14 wymaga, aby producenci po uzyskaniu wiedzy o aktywnie wykorzystywanej podatności lub poważnym incydencie poinformowali użytkowników dotkniętych problemem, a w stosownych przypadkach wszystkich użytkowników, o podatności lub incydencie oraz o dostępnych środkach naprawczych albo sposobach ograniczenia ryzyka. Komunikaty dla klientów muszą być koordynowane z zespołem technicznym, aby przekazywane instrukcje były dokładne, praktyczne i bezpieczne. Powinny być również uzgadniane z treścią zgłoszenia regulacyjnego, ponieważ przedwczesne ujawnienie szczegółów dotyczących sposobu wykorzystania podatności może zwiększyć ryzyko. CRA umożliwia oznaczenie informacji jako wrażliwych, a przepisy UE przewidują ograniczone sytuacje, w których przekazywanie informacji pomiędzy krajowymi CSIRT może zostać opóźnione ze względów cyberbezpieczeństwa. Z tego powodu dobrze przygotowany plan ujawniania informacji jest bardziej wartościowy niż zarówno domyślne zachowywanie wszystkiego w tajemnicy, jak i natychmiastowe publikowanie wszystkich szczegółów technicznych.
Praktyczna lista przygotowań dla zespołów programistycznych i bezpieczeństwa
Przed 11 września 2026 roku każda organizacja, która może zostać uznana za producenta w rozumieniu CRA, powinna potrafić odpowiedzieć na kilka podstawowych pytań operacyjnych bez rozpoczynania nowych analiz prawnych podczas incydentu. Powinna wiedzieć, które produkty programowe są objęte rozporządzeniem, który podmiot prawny jest producentem, kto może stwierdzić, że zgromadzone dowody wystarczają do uruchomienia obowiązku z artykułu 14, kto zapisuje moment uzyskania wiedzy o zdarzeniu, kto przygotowuje wczesne ostrzeżenie, kto je przesyła oraz kto może przejąć te zadania w razie niedostępności osoby odpowiedzialnej. Proces powinien obejmować także starsze produkty, a nie tylko aktualne wersje, ponieważ artykuł 14 obejmuje również produkty wprowadzone na rynek przed pełnym rozpoczęciem stosowania CRA w grudniu 2027 roku. Prosty rejestr produktów zawierający informacje o właścicielach, obsługiwanych wersjach, dostępności w UE i kontaktach eskalacyjnych może usunąć wiele godzin niepewności w sytuacji, gdy termin zgłoszeniowy już biegnie.
Zespoły powinny także przećwiczyć sekwencję 24- i 72-godzinną na realistycznym scenariuszu. Przydatne ćwiczenie może rozpocząć się od wiarygodnego zgłoszenia aktywnego wykorzystania podatności pod koniec dnia roboczego, po którym pojawiają się niepełne dowody, podatna zależność zewnętrzna i klienci w kilku państwach członkowskich. Ćwiczenie powinno sprawdzić, czy specjaliści techniczni potrafią zabezpieczyć dowody, zidentyfikować dotknięte wersje, ustalić działania możliwe do natychmiastowego podjęcia przez użytkowników oraz przygotować zwięzłe wczesne ostrzeżenie bez oczekiwania na pełne ustalenie przyczyny źródłowej. Następnie należy sprawdzić, czy 72-godzinne zgłoszenie można uzupełnić o dokładniejszy opis produktu, informacje o sposobie wykorzystania podatności, wstępną ocenę skutków oraz aktualny stan działań ograniczających ryzyko. Celem nie jest przygotowanie idealnego dokumentu z wyprzedzeniem. Chodzi o sprawdzenie, czy analiza techniczna, ocena prawna, akceptacja kierownictwa, komunikacja z klientami i samo zgłoszenie mogą przebiegać równolegle, a nie kolejno.
Na koniec zespoły programistyczne powinny wyraźnie oddzielić obowiązek raportowy rozpoczynający się we wrześniu 2026 roku od szerszego programu zgodności z CRA przewidzianego na grudzień 2027 roku. Rozporządzenie w późniejszym terminie wprowadzi szerszy zestaw wymogów dotyczących cyberbezpieczeństwa, obsługi podatności, dokumentacji oraz oceny zgodności, jednak artykuł 14 zaczyna obowiązywać wcześniej. Oznacza to, że przygotowanie procesu raportowania staje się bezpośrednim priorytetem operacyjnym nawet dla firm, które nadal realizują długoterminowy program dostosowania do CRA. Najbardziej użyteczne przygotowania są praktyczne: utrzymywanie przejrzystej ewidencji produktów, zdefiniowanie ścieżki klasyfikacji zdarzeń, dokładne rejestrowanie czasu uzyskania wiedzy, wyznaczenie podstawowych i zastępczych osób odpowiedzialnych za raportowanie, przygotowanie krótkich szablonów dla etapów 24- i 72-godzinnych oraz połączenie procesu raportowego z instalowaniem poprawek i komunikacją z użytkownikami. Gdy rzeczywisty incydent wystąpi, organizacja powinna już wiedzieć, co uruchamia obowiązek, od kiedy biegnie termin, kto odpowiada za działania oraz jakie dowody należy zabezpieczyć.
