Zegar CRA już tyka, także dla urządzeń sprzedanych lata temu

Przez ostatnie tygodnie przeczytałem o Cyber Resilience Act więcej artykułów, niż chciałbym się przyznać, i spora część z nich wzajemnie sobie przeczy. W jednym czytam, że platforma do zgłoszeń jeszcze nie działa. W innym, że każde znane CVE w firmware trzeba zgłosić w ciągu doby. W trzecim, że tematem wystarczy się zająć od grudnia 2027. Większość powstała, zanim Komisja opublikowała pod koniec lipca oficjalne wytyczne, a niektóre są po prostu błędne.

Sięgnąłem więc do źródeł: do samego rozporządzenia, do wytycznych Komisji i do dokumentacji platformy zgłoszeniowej przygotowanej przez ENISA. Chciałem ustalić, co dziś faktycznie obowiązuje małą firmę, która produkuje urządzenia IoT. Poniżej zebrałem wnioski. Jestem inżynierem, więc nic tutaj nie jest poradą prawną, ale wszystko, co piszę, opiera się na oficjalnych tekstach, a własne opinie starałem się wyraźnie od nich oddzielać.

Co obowiązuje już teraz

CRA jest prawem od grudnia 2024, a większość jego przepisów stosuje się od 11 grudnia 2027. Tę późniejszą datę zapamiętała większość ludzi i to jej dotyczą główne obowiązki projektowe, dokumentacja techniczna i oznakowanie CE.

Z obowiązkiem zgłaszania z artykułu 14 jest inaczej. Stosuje się go od 11 września 2026 i obejmuje każdy produkt z elementami cyfrowymi udostępniony na rynku UE, także taki, który wprowadzono do obrotu długo przed powstaniem CRA. Jeśli w 2021 sprzedałeś flotę trackerów LTE, które nadal pracują u klientów, obowiązek zgłaszania dotyczy ich już dziś. Wytyczne Komisji idą jeszcze dalej: obowiązek ten trwa również po zakończeniu okresu wsparcia produktu. Wymagania dotyczące obsługi podatności wygasają razem z okresem wsparcia, natomiast obowiązek zgłaszania towarzyszy produktowi tak długo, jak długo ktoś go używa.

Dla mnie to najcenniejsza informacja z całej lektury, bo oznacza, że każda firma z urządzeniami w terenie musi działać już teraz, także ta, która uważała CRA za problem na 2027 rok.

Co właściwie podlega zgłoszeniu

Są dokładnie dwie sytuacje, które uruchamiają obowiązek. Pierwsza to aktywnie wykorzystywana podatność, czyli według definicji z rozporządzenia taka, co do której istnieją wiarygodne dowody, że złośliwy podmiot wykorzystał ją w systemie bez zgody jego właściciela. Druga to poważny incydent, czyli zdarzenie, które wpływa lub może wpłynąć na zdolność produktu do ochrony dostępności, autentyczności, integralności lub poufności wrażliwych albo ważnych danych lub funkcji, albo które doprowadziło lub może doprowadzić do uruchomienia złośliwego kodu w produkcie lub w sieci użytkownika. Skradziony klucz do podpisywania kodu czy przejęty serwer aktualizacji z pewnością się tu mieszczą.

Równie ważne jest to, czego zgłaszać nie trzeba. Wpis w bazie CVE dotyczący biblioteki, której używasz w firmware, sam w sobie nie oznacza aktywnie wykorzystywanej podatności w produkcie. Wytyczne mówią to wprost. Jeśli komponent zewnętrzny ma podatność, której nie da się wykorzystać w twoim produkcie (na przykład dlatego, że podatny kod nigdy się nie wykonuje) albo która nie została w nim wykorzystana, obowiązkowe zgłoszenie nie ma zastosowania. Nadal musisz się nią zająć, poinformować opiekuna komponentu i usunąć ją w okresie wsparcia, ale 24-godzinny zegar nie rusza.

Wytyczne rozstrzygają też, od kiedy liczy się czas. Uznaje się, że wiesz o problemie, gdy po szybkiej wstępnej ocenie masz rozsądny stopień pewności, że podatność jest wykorzystywana. Niejasny mail od nieznajomego nie uruchamia zegara. Z kolei odłożenie takiego maila na tydzień bez czytania to dokładnie to, przed czym wytyczne przestrzegają, bo kładą nacisk na szybką ocenę. Obowiązek nie działa też wstecz. Wykorzystania podatności, o którym wiedziałeś przed 11 września 2026, nie musisz teraz zgłaszać, natomiast wszystko, czego dowiesz się po tej dacie, już tak.

Jak biegnie zegar

Od chwili, w której wiesz o problemie, kolejność jest z góry ustalona. W ciągu 24 godzin składasz wczesne ostrzeżenie, które zawiera niewiele więcej niż opis tego, co się stało, i listę krajów UE, w których produkt jest sprzedawany. W ciągu 72 godzin wysyłasz pełniejsze zgłoszenie ze wstępną oceną i ewentualnymi środkami zaradczymi, które mogą zastosować użytkownicy. Raport końcowy składasz w przypadku wykorzystywanej podatności 14 dni po udostępnieniu poprawki lub środka zaradczego, a w przypadku poważnego incydentu miesiąc po zgłoszeniu 72-godzinnym.

Równolegle trzeba poinformować użytkowników, których sprawa dotyczy. Wytyczne podchodzą do tego rozsądnie i uzależniają zakres informacji od ryzyka. Nie musi to być publiczny komunikat ze szczegółami technicznymi, a przy produktach używanych we wrażliwych środowiskach wytyczne wprost pozwalają ograniczyć informację do zainteresowanych klientów do czasu wydania poprawki. Kiedy aktualizacja bezpieczeństwa jest już dostępna, zasady obsługi podatności wymagają opublikowania informacji o usuniętej podatności.

W przepisach o karach jest jeden szczegół, który moim zdaniem zainteresuje wielu czytelników. Mikroprzedsiębiorstw i małych przedsiębiorstw nie można ukarać za przekroczenie 24-godzinnego terminu na wczesne ostrzeżenie. Pozostałe terminy i same obowiązki obowiązują jednak w pełni, a wszystkim innym za naruszenie artykułu 14 grożą kary do piętnastu milionów euro lub dwóch i pół procent światowego obrotu, w zależności od tego, która kwota jest wyższa.

Gdzie zgłaszać i co to oznacza w praktyce

Zgłoszenia przechodzą przez Single Reporting Platform prowadzoną przez ENISA, która działa od 11 września. Zgłoszenie składasz raz, do krajowego CSIRT-u państwa członkowskiego, w którym firma ma główną siedzibę, a platforma przekazuje je ENISA i pozostałym zainteresowanym państwom.

W dokumentacji ENISA zaskoczyły mnie dwie praktyczne kwestie. Pierwsza: dostęp wymaga osobistego konta EU Login z uwierzytelnianiem wieloskładnikowym, które należy do osoby wyznaczonej przez firmę, a rejestracja obejmuje etap weryfikacji. Firma może mieć jednego głównego przedstawiciela i maksymalnie dwudziestu dodatkowych. Bardzo radzę załatwić to teraz, w spokojne popołudnie, a nie o drugiej w nocy, gdy 24-godzinny zegar już tyka.

Druga: platforma na starcie nie ma API. Każde zgłoszenie ktoś musi ręcznie wpisać w formularz na stronie. Narzędzie, które obiecuje automatyczne wysyłanie zgłoszeń CRA, obiecuje więc coś, czego platforma obecnie nie obsługuje. Oprogramowanie może natomiast przejąć wszystko, co dzieje się wokół formularza, a właśnie tam schodzi najwięcej czasu.

Backend też jest częścią produktu

W IoT ma to ogromne znaczenie. CRA zalicza do produktu również zdalne przetwarzanie danych, a wytyczne wyjaśniają, że chodzi o zaprojektowane przez producenta oprogramowanie po stronie serwera, bez którego produkt nie mógłby realizować którejś ze swoich funkcji. Wytyczne omawiają to na przykładzie inteligentnego termostatu z aplikacją i backendem w chmurze działającym na infrastrukturze zewnętrznego dostawcy. Wniosek: w rozumieniu CRA backend jest częścią produktu, także jeśli chodzi o zgłoszenia.

Dla typowego urządzenia IoT oznacza to, że regulacja obejmuje funkcje Lambda, reguły MQTT, usługę provisioningu i API, z którego korzysta aplikacja mobilna. Usługę zarządzaną, którą tylko konfigurujesz, na przykład hostowany broker MQTT, traktuje się raczej jak komponent, który trzeba ocenić i starannie wybrać. W praktyce włamanie do usługi provisioningu to incydent CRA dotyczący twojego urządzenia.

Dwa popularne twierdzenia, które są błędne

Pierwsze głosi, że okres wsparcia wynosi pięć lat. Rozporządzenie ustala pięć lat jako minimum, chyba że produkt rzeczywiście ma być używany krócej, a wytyczne Komisji wprost stwierdzają, że pięć lat nie jest wartością domyślną. Jeśli produkt ma działać dłużej, potrzebuje dłuższego okresu wsparcia. Kto produkuje liczniki energii, sterowniki przemysłowe albo czujniki budynkowe, które wiszą na ścianie po dziesięć czy piętnaście lat, powinien przeczytać to zdanie dwa razy. Datę zakończenia wsparcia trzeba też podać w momencie zakupu, co najmniej z dokładnością do miesiąca i roku.

Drugie głosi, że potrzebny jest kompletny, idealny SBOM obejmujący wszystko, aż do ostatniej zależności przechodniej. Przepisy wymagają zestawienia komponentów oprogramowania (SBOM) w powszechnie stosowanym formacie nadającym się do odczytu maszynowego, które obejmuje co najmniej zależności najwyższego poziomu. Schodzenie głębiej to dobra praktyka, która bardzo ułatwia pracę z podatnościami, ale prawne minimum jest niższe, niż sugeruje wiele artykułów. W projektach na ESP-IDF Espressif udostępnia już narzędzia, które generują SBOM w formacie SPDX i sprawdzają go pod kątem znanych podatności, więc dużą część tej pracy masz za darmo.

Czego naprawdę potrzebuje mały zespół

Kiedy złożyłem to wszystko w całość, wyszło mi, że w typowej firmie sprzętowej z kilkoma tysiącami urządzeń w terenie cała praca sprowadza się głównie do tego, żeby umieć szybko odpowiedzieć na kilka pytań. Które wersje firmware działają gdzie i co jest w każdej z nich? Które z podatności opublikowanych w tym tygodniu dotyczą komponentu używanego w twoim produkcie i czy podatny kod jest osiągalny w twoim buildzie? Kto w firmie decyduje, że coś jest aktywnie wykorzystywane, i kto ma konto EU Login, żeby złożyć wczesne ostrzeżenie? Jak poinformujesz klientów, których to dotyczy, i jak potem udowodnisz, że poprawka faktycznie trafiła na urządzenia we flocie?

Do żadnej z tych rzeczy nie potrzeba dużej platformy compliance. Wystarczy SBOM dla każdego wydania firmware, lista wersji urządzeń z backendu floty, codzienne porównywanie nowych podatności z tymi SBOM-ami, krótka spisana procedura podejmowania decyzji w ciągu 24 godzin i szablon dla każdego z trzech zgłoszeń z polami, o które pyta ENISA. Większość zespołów ma już połowę tych danych w systemie budowania i w backendzie IoT. Tyle że nikt ich dotąd ze sobą nie połączył.

Właśnie to łączenie najbardziej mnie jako inżyniera ciekawi i właśnie do tego buduję teraz narzędzia. Pierwsze z nich są już bezpłatnie dostępne na tej stronie: zegar zgłoszeń, który wylicza terminy i wypisuje pola, o które ENISA pyta na każdym etapie, sprawdzenie zakresu oraz generator security.txt. Jeśli robisz urządzenia IoT i właśnie mierzysz się z którymś z tych tematów, zwłaszcza w małym zespole, który nagle musi pilnować 24-godzinnego zegara, chętnie porozmawiam.

Co jeszcze może się zmienić

Część tych informacji będzie się jeszcze zmieniać. Normy zharmonizowane, które ułatwią wykazanie zgodności z obowiązkami od 2027, są wciąż w przygotowaniu, ENISA regularnie aktualizuje wytyczne dotyczące platformy, a Komisja określiła swoje lipcowe wytyczne jako pierwszy zestaw. Rdzeń obowiązku zgłaszania jest jednak zapisany w samym rozporządzeniu i ta część jest przesądzona. Jeśli twoje urządzenia są na rynku UE, zegar tyka od września.