akt o cyberodporności

Akt o cyberodporności (Cyber Resilience Act, CRA) to rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/2847 z 23 października 2024 roku w sprawie horyzontalnych wymagań cyberbezpieczeństwa dla produktów z elementami cyfrowymi ^[1]. Wymaga, by sprzęt i oprogramowanie były projektowane bezpiecznie i przez zadeklarowany okres otrzymywały poprawki. Nakłada też na producentów obowiązek zgłaszania aktywnie wykorzystywanych podatności. Według Komisji Europejskiej akt wszedł w życie 10 grudnia 2024 roku ^[2], a jego główne obowiązki stosuje się od 11 grudnia 2027 roku ^[2].

Kogo dotyczy

Rozporządzenie reguluje produkty z elementami cyfrowymi, czyli oprogramowanie lub sprzęt wraz z rozwiązaniami zdalnego przetwarzania danych, także komponenty wprowadzane do obrotu osobno ^[1]. Komisja podaje przykłady od elektronicznych nianiek i inteligentnych zegarków po aplikacje i programy komputerowe ^[2]. Część produktów o podwyższonym ryzyku wymaga oceny przez stronę trzecią, zanim trafi na rynek Unii ^[2], a zgodne produkty oznacza się znakiem CE ^[2].

Główne obowiązki spoczywają na producencie. Jest nim osoba fizyczna lub prawna, która wytwarza produkt z elementami cyfrowymi albo zleca jego wytworzenie i wprowadza go do obrotu pod własną nazwą lub znakiem towarowym ^[1]. Osobną kategorię tworzą opiekunowie oprogramowania otwartego. To osoby prawne inne niż producent, których celem jest systematyczne i trwałe wspieranie rozwoju określonych produktów ^[1]. Komisja zaznacza, że akt ma szczególne podejście do wolnego i otwartego oprogramowania ze względu na jego rolę w gospodarce cyfrowej ^[2].

Obowiązki producenta

Producent musi zapewnić, że produkt zaprojektowano, wytworzono i wyprodukowano zgodnie z zasadniczymi wymaganiami cyberbezpieczeństwa z części I załącznika I ^[1]. Ocenia ryzyko cyberbezpieczeństwa i uwzględnia jej wyniki na etapach planowania, projektowania, rozwoju, produkcji, dostawy i utrzymania ^[1]. Gdy wykryje podatność w komponencie innej firmy, zgłasza ją temu, kto komponent wytwarza lub utrzymuje, i usuwa ją zgodnie z wymaganiami dotyczącymi obsługi podatności ^[1]. To jeden z mechanizmów ograniczających ataki na łańcuch dostaw (supply chain attack).

Okres wsparcia, w którym producent obsługuje podatności, trwa co najmniej pięć lat ^[1]. Krótszy okres jest dopuszczalny tylko wtedy, gdy produkt ma być używany krócej; odpowiada on wtedy przewidywanemu czasowi użytkowania ^[1]. W praktyce oznacza to wieloletnie zarządzanie podatnościami i wydawanie aktualizacji oprogramowania.

Zgłaszanie podatności i incydentów

Aktywnie wykorzystywana podatność to taka, co do której istnieją wiarygodne dowody, że złośliwy podmiot wykorzystał ją w systemie bez zgody jego właściciela ^[1]. Od 11 września 2026 roku producenci muszą zgłaszać takie podatności oraz poważne incydenty wpływające na bezpieczeństwo produktów ^[3]. Terminy pokazuje schemat poniżej.

RYS. 1Zgłoszenie aktywnie wykorzystywanej podatności

Dla podatności raport końcowy składa się najpóźniej 14 dni po udostępnieniu środka naprawczego, a dla poważnych incydentów w ciągu miesiąca ^[3]. Zgłoszenia trafiają przez jednolitą platformę zgłoszeniową CRA do zespołu CSIRT w państwie, w którym producent ma siedzibę ^[3]. Poza szczególnie wyjątkowymi okolicznościami informacja jest jednocześnie udostępniana ENISA ^[3]. CSIRT bez zwłoki przekazuje ją zespołom w innych państwach, w których produkt jest dostępny ^[3]. Ten obowiązek zgłaszania przypomina mechanizm z dyrektywy NIS2, ale dotyczy producenta produktu, a nie operatora usługi.

Terminy i kary

Rozporządzenie wchodzi w życie etapami, co zestawia tabela.

Najwyższy próg kar administracyjnych za naruszenie zasadniczych wymagań i obowiązków producenta wynosi do 15 000 000 EUR albo do 2,5% całkowitego rocznego światowego obrotu przedsiębiorstwa ^[1]. Niższe progi to 10 000 000 EUR lub 2% obrotu oraz 5 000 000 EUR lub 1% obrotu ^[1]. Kar administracyjnych nie stosuje się do naruszeń popełnionych przez opiekunów oprogramowania otwartego ^[1].

W WordPressie

WordPress jest oprogramowaniem otwartym, rozwijanym przez społeczność, a wtyczki i motywy tworzy wielu niezależnych autorów. Społeczność zabrała głos już na etapie projektu. W sierpniu 2023 roku WordPress.org opublikował stanowisko wobec projektu rozporządzenia ^[4]. Wskazano w nim, że zakaz wprowadzania „niedokończonego oprogramowania” może hamować rozwój projektów otwartych, a niejasna definicja „działalności handlowej” może niezamierzenie objąć projekty społecznościowe non-profit ^[4]. WordPress wraz z Drupalem, Joomla i TYPO3 zaproponował spotkanie w Brukseli ^[4]. Stanowisko dotyczyło projektu, nie ostatecznego tekstu.

Dla opiekuna strony na WordPressie akt ma znaczenie pośrednie. Obowiązki spoczywają na producentach, a więc na tych, którzy wprowadzają produkt do obrotu pod własną nazwą ^[1]. W przypadku płatnych wtyczek i motywów mogą to być ich autorzy. Dla opiekuna witryny ważne są skutki:

• producent musi informować o podatnościach i wydawać poprawki przez okres wsparcia ^[1], co ułatwia planowanie zarządzania poprawkami (patch management);
• podatność we wtyczce wykorzystywana w atakach powinna trafić do CSIRT w ciągu 24 godzin od chwili, gdy producent się o niej dowie ^[3];
• obecny obieg zgłoszeń w samym WordPressie wygląda tak: błędy wtyczek trafiają do autora i zespołu wtyczek, błędy motywów do autora i zespołu przeglądu motywów ^[5].

Dobre praktyki

Z perspektywy autora oprogramowania, także wtyczki do WordPressa:

• ustalić i opublikować okres wsparcia, pamiętając o minimum pięciu latach ^[1];
• prowadzić spis komponentów, na przykład w formie SBOM (wykazu komponentów oprogramowania), by wiedzieć, której biblioteki dotyczy zgłoszona luka;
• przyjąć politykę skoordynowanego ujawniania podatności (coordinated vulnerability disclosure) i kanał kontaktu dla badaczy;
• przygotować procedurę pozwalającą zmieścić się w 24 i 72 godzinach od wykrycia aktywnego wykorzystania ^[3];
• zgłaszać podatności w cudzych komponentach ich twórcom, jak wymaga art. 13 ^[1].