Cyberbezpieczeństwo oprogramowania przez lata bywało traktowane przede wszystkim jako zadanie techniczne. Zespół programistyczny miał zadbać o bezpieczeństwo kodu, administratorzy o konfigurację infrastruktury, a po wdrożeniu należało reagować na zgłoszone problemy i publikować poprawki. W wielu organizacjach taki model nadal funkcjonuje.
Unijne rozporządzenie Cyber Resilience Act, w skrócie CRA, wzmacnia inne podejście: bezpieczeństwo produktu cyfrowego powinno być uwzględniane od początku jego projektowania i utrzymywane przez okres jego wsparcia. Nie chodzi wyłącznie o zabezpieczenie systemu w dniu premiery, lecz także o zarządzanie podatnościami, aktualizacje, dokumentację, odpowiedzialność producenta i możliwość reagowania na incydenty.
Dla firm tworzących oprogramowanie, rozwijających własne produkty cyfrowe lub wprowadzających je na rynek europejski oznacza to konieczność przyjrzenia się nie tylko kodowi, ale również procesom biznesowym i organizacyjnym.
Co ważne, CRA nie jest już wyłącznie regulacją, do której można zacząć przygotowywać się w odległej przyszłości. Rozporządzenie weszło w życie 10 grudnia 2024 roku. Obowiązki dotyczące raportowania określonych podatności i poważnych incydentów zaczęły być stosowane 11 września 2026 roku, natomiast zasadnicza część wymagań zacznie obowiązywać 11 grudnia 2027 roku. To dwa różne etapy, których nie należy ze sobą mylić.
Czym jest Cyber Resilience Act?
Cyber Resilience Act to unijne rozporządzenie dotyczące cyberbezpieczeństwa produktów zawierających elementy cyfrowe. Jego celem jest podniesienie poziomu bezpieczeństwa takich produktów dostępnych na rynku Unii Europejskiej i ograniczenie sytuacji, w których użytkownicy otrzymują rozwiązania podatne na ataki, niewłaściwie zabezpieczone lub pozbawione odpowiedniego wsparcia.
Regulacja obejmuje szeroką kategorię produktów sprzętowych i programowych, których zamierzone zastosowanie lub racjonalnie przewidywalne wykorzystanie wiąże się z bezpośrednim albo pośrednim połączeniem logicznym lub fizycznym z urządzeniem bądź siecią. W zakres mogą wchodzić zarówno gotowe produkty, jak i komponenty cyfrowe wprowadzane na rynek oddzielnie.
W praktyce oznacza to, że CRA nie dotyczy wyłącznie urządzeń kojarzonych z Internetem rzeczy. W odpowiednich okolicznościach regulacja może obejmować również oprogramowanie, systemy operacyjne, aplikacje czy inne komponenty cyfrowe oferowane na rynku.
Istotna jest jednak granica między samym tworzeniem oprogramowania a wprowadzaniem produktu na rynek. Nie każda usługa programistyczna, każda strona internetowa ani każdy system zbudowany na zamówienie automatycznie podlegają identycznym obowiązkom. Znaczenie mają między innymi charakter rozwiązania, sposób jego udostępniania, rola poszczególnych firm oraz ewentualne wyłączenia przewidziane w przepisach.
Dlatego pierwszym krokiem nie powinno być bezrefleksyjne wdrażanie wszystkich możliwych procedur. Najpierw trzeba ustalić, czy konkretny produkt mieści się w zakresie CRA i jaka rola przypada danej organizacji.
Dlaczego CRA zmienia podejście do tworzenia oprogramowania?
Najważniejsza zmiana polega na tym, że cyberbezpieczeństwo przestaje być wyłącznie zestawem działań wykonywanych przy okazji wdrożenia lub po wykryciu problemu. Staje się elementem całego cyklu życia produktu.
W takim modelu bezpieczeństwo powinno być brane pod uwagę podczas analizy wymagań, projektowania architektury, implementacji, testowania, przygotowania do wydania, utrzymania i planowania zakończenia wsparcia. Nie wystarczy stwierdzić, że aplikacja działa poprawnie. Trzeba również rozumieć, jakie ryzyka wiążą się z jej funkcjami, zależnościami, sposobem aktualizacji i integracjami.
Przykładowo, zespół może poprawnie zabezpieczyć własny kod, a jednocześnie korzystać z biblioteki, w której wykryto podatność. Produkt może mieć mechanizm logowania, ale niewłaściwie zarządzać uprawnieniami. Aktualizacje mogą być dostępne, lecz nie mieć jasno określonej procedury dystrybucji. Firma może też nie wiedzieć, które wersje produktu pozostają w użyciu u klientów.
Każdy z tych przypadków pokazuje, że bezpieczeństwo nie zależy wyłącznie od umiejętności programistów. Wymaga również kontroli nad zależnościami, procesu reagowania na zgłoszenia, dokumentacji i odpowiedzialności za produkt po jego udostępnieniu.
CRA wzmacnia więc kierunek, w którym dojrzały proces wytwarzania oprogramowania powinien zmierzać niezależnie od samej regulacji: bezpieczeństwo trzeba projektować, weryfikować i utrzymywać, a nie tylko deklarować.
Kogo dotyczą przepisy i dlaczego trzeba ustalić rolę firmy?
CRA kieruje zasadnicze obowiązki przede wszystkim do producentów produktów z elementami cyfrowymi. W rozumieniu rozporządzenia producentem jest podmiot, który opracowuje produkt lub zleca jego opracowanie, a następnie udostępnia go na rynku pod własną nazwą lub znakiem towarowym.
To rozróżnienie ma znaczenie dla software house'ów i firm technologicznych.
Jeżeli firma tworzy system na zlecenie klienta, nie oznacza to automatycznie, że w każdym przypadku będzie producentem w rozumieniu CRA. Znaczenie ma konkretny model współpracy, sposób udostępniania produktu i to, kto występuje jako podmiot odpowiedzialny za niego na rynku. Nie można też z góry założyć, że odpowiedzialność zawsze spoczywa wyłącznie na zamawiającym. W określonych modelach biznesowych sytuacja może wyglądać inaczej.
Warto przeanalizować kilka typowych scenariuszy:
-
Firma rozwijająca własny produkt SaaS lub aplikację pod własną marką. Należy sprawdzić, czy produkt mieści się w zakresie CRA oraz czy sposób jego udostępniania i architektura powodują objęcie go regulacją.
-
Software house tworzący system dla klienta. Trzeba ustalić, kto będzie udostępniał rozwiązanie na rynku, pod jaką marką i w jakiej roli występują strony. Sam fakt napisania kodu nie rozstrzyga wszystkich kwestii prawnych.
-
Producent integrujący komponenty innych dostawców. Konieczne może być przeanalizowanie nie tylko własnego rozwiązania, ale również zależności, sposobu ich aktualizacji oraz informacji bezpieczeństwa przekazywanych przez dostawców.
-
Firma sprzedająca produkt pod własną marką, opracowany przez inny podmiot. Taki model może mieć inne konsekwencje niż zwykłe świadczenie usługi programistycznej i wymaga osobnej oceny.
-
Dostawca komponentu programowego. Jeżeli komponent jest odrębnie udostępniany na rynku, może wymagać własnej analizy zakresu regulacji.
To nie jest kompletna lista przypadków ani formalna kwalifikacja prawna. Ma pokazać, dlaczego warto zacząć od mapowania produktów i ról, a nie od ogólnego stwierdzenia, że „CRA dotyczy wszystkich programistów”.
Rozporządzenie przewiduje również wyłączenia i szczególne zasady, między innymi dla niektórych kategorii produktów regulowanych odrębnymi przepisami oraz określonych przypadków oprogramowania open source. Szczegółów tych wyłączeń nie należy jednak interpretować na podstawie samej nazwy produktu czy modelu licencji. Potrzebna jest analiza konkretnej sytuacji.
Terminy CRA: co obowiązuje już teraz, a co nadejdzie w 2027 roku?
W planowaniu zgodności z regulacją kluczowe są daty. Warto rozdzielić wejście rozporządzenia w życie, rozpoczęcie stosowania obowiązków raportowania i rozpoczęcie stosowania zasadniczej części wymagań.
10 grudnia 2024 roku - wejście CRA w życie. Rozporządzenie zostało przyjęte i weszło w życie, ale nie oznaczało to jednoczesnego rozpoczęcia stosowania wszystkich obowiązków.
11 września 2026 roku - rozpoczęcie stosowania obowiązków raportowania z art. 14. Producenci objętych regulacją produktów muszą zgłaszać aktywnie wykorzystywane podatności oraz poważne incydenty mające wpływ na bezpieczeństwo produktu, gdy dowiedzą się o takim zdarzeniu. Obowiązki te mają własne terminy i procedurę raportowania.
11 grudnia 2027 roku - rozpoczęcie stosowania zasadniczej części CRA. Od tej daty zaczną być stosowane główne wymagania rozporządzenia dotyczące produktów z elementami cyfrowymi, w tym wymogi związane z bezpieczeństwem produktu, obsługą podatności i procedurami oceny zgodności, zgodnie z właściwymi przepisami.
Istotny szczegół: obowiązki raportowania, które zaczęły być stosowane we wrześniu 2026 roku, dotyczą również produktów objętych CRA, które zostały udostępnione na rynku przed 11 grudnia 2027 roku. Nie należy więc zakładać, że wszystkie obowiązki związane z regulacją zaczynają się dopiero w grudniu 2027 roku.
Istnieją również przepisy przejściowe, a sytuacja produktów już dostępnych na rynku może zależeć od konkretnych okoliczności, między innymi od tego, czy po rozpoczęciu stosowania zasadniczej części rozporządzenia produkt zostanie poddany istotnej modyfikacji. Z tego powodu daty warto traktować jako punkt wyjścia do analizy, a nie jako samodzielną odpowiedź na pytanie o obowiązki konkretnej firmy.
Podstawowym źródłem informacji jest oficjalne podsumowanie Komisji Europejskiej oraz jej strona poświęcona raportowaniu w ramach CRA.
Raportowanie podatności i incydentów: obowiązek, który już się rozpoczął
Jednym z najbardziej praktycznych aspektów CRA jest obowiązek raportowania określonych zdarzeń związanych z bezpieczeństwem produktów.
Nie chodzi o zgłaszanie każdej drobnej usterki, każdego błędu aplikacji ani każdej potencjalnej podatności, którą ktoś zgłosił w niezweryfikowanym komentarzu. Przepisy wskazują konkretne kategorie zdarzeń, w tym aktywnie wykorzystywane podatności oraz poważne incydenty wpływające na bezpieczeństwo produktu.
Aktywnie wykorzystywana podatność to w uproszczeniu podatność, w przypadku której istnieją wiarygodne dowody, że została wykorzystana przez atakującego bez uprawnienia. Poważny incydent dotyczy zdarzenia mającego istotny wpływ na bezpieczeństwo produktu. Ocena, czy dane zdarzenie spełnia kryteria ustawowe, wymaga uwzględnienia okoliczności i odpowiednich definicji, a nie tylko intuicyjnej oceny zespołu.
Dla producentów objętych obowiązkiem raportowania podstawowe terminy obejmują:
-
24 godziny na wstępne ostrzeżenie od momentu uzyskania wiedzy o zdarzeniu objętym obowiązkiem;
-
72 godziny na główne zgłoszenie;
-
w przypadku aktywnie wykorzystywanej podatności raport końcowy nie później niż 14 dni po udostępnieniu środka naprawczego lub łagodzącego;
-
w przypadku poważnego incydentu raport końcowy w ciągu miesiąca od zgłoszenia 72-godzinnego.
Terminy i wymagania należy interpretować zgodnie z odpowiednimi przepisami oraz aktualnymi wytycznymi. Nie należy traktować powyższego skrótu jako kompletnej instrukcji prawnej dla każdego przypadku.
Zgłoszenia są przekazywane za pośrednictwem unijnej platformy CRA Single Reporting Platform, prowadzonej przez ENISA. Zgodnie z zasadami systemu producent dokonuje zgłoszenia przez tę platformę, a właściwy CSIRT i ENISA uczestniczą w dalszym procesie.
Co to oznacza operacyjnie? Firma nie powinna dopiero po wykryciu problemu zastanawiać się, kto ma ocenić jego wagę, kto podejmie decyzję o zgłoszeniu i skąd wziąć informacje niezbędne do przygotowania raportu.
Warto mieć wcześniej ustalony proces obejmujący co najmniej:
-
odbiór zgłoszeń od klientów, badaczy bezpieczeństwa i innych źródeł;
-
weryfikację, czy zgłoszenie dotyczy rzeczywistej podatności lub incydentu;
-
ocenę wpływu na produkt i ustalenie, czy zdarzenie może podlegać obowiązkowi raportowania;
-
określenie osób odpowiedzialnych za decyzje techniczne, organizacyjne i formalne;
-
przygotowanie wymaganych informacji oraz obsługę terminów;
-
opracowanie poprawki lub innych środków ograniczających ryzyko;
-
poinformowanie odpowiednich odbiorców zgodnie z właściwymi obowiązkami;
-
udokumentowanie działań i wyciągnięcie wniosków po zakończeniu incydentu.
Nie każda firma musi budować w tym celu rozbudowany dział bezpieczeństwa. Skala procesu powinna odpowiadać charakterowi produktu, ryzyku i strukturze organizacji. Musi jednak być na tyle konkretna, aby w sytuacji kryzysowej dało się działać szybko, a nie dopiero ustalać podstawowe zasady odpowiedzialności.
Security by design i security by default
Dwa pojęcia szczególnie dobrze opisują kierunek, w którym zmierza CRA: security by design oraz security by default.
Security by design oznacza uwzględnianie bezpieczeństwa już na etapie projektowania produktu. Security by default zakłada natomiast, że domyślna konfiguracja powinna wspierać bezpieczne korzystanie z rozwiązania, zamiast wymagać od użytkownika samodzielnego naprawiania niebezpiecznych ustawień.
W praktyce nie sprowadza się to do jednej funkcji ani do listy kontrolek w panelu administracyjnym. To zestaw decyzji architektonicznych i implementacyjnych, które wpływają na bezpieczeństwo całego produktu.
W zależności od charakteru rozwiązania warto przeanalizować między innymi:
-
sposób uwierzytelniania i zarządzania sesją;
-
model uprawnień i kontrolę dostępu do danych;
-
bezpieczne przechowywanie sekretów i danych uwierzytelniających;
-
ochronę danych podczas przesyłania i przechowywania;
-
mechanizmy aktualizacji i ich bezpieczeństwo;
-
sposób obsługi błędów oraz rejestrowania zdarzeń;
-
ograniczanie powierzchni ataku i wyłączanie zbędnych funkcji;
-
konfigurację domyślną, w tym brak niebezpiecznych ustawień startowych;
-
obsługę podatności w komponentach własnych i zewnętrznych.
Nie wszystkie środki będą potrzebne w każdym produkcie w identycznej formie. Innych rozwiązań wymaga aplikacja mobilna, innych system wbudowany, a jeszcze innych rozbudowana platforma biznesowa. Dlatego analiza ryzyka powinna poprzedzać dobór konkretnych mechanizmów.
Ważne jest także to, że bezpieczeństwo nie kończy się na samym kodzie. Błędna konfiguracja środowiska, nadmierne uprawnienia, niekontrolowany dostęp do repozytorium czy nieprzemyślany proces publikowania aktualizacji mogą podważyć jakość nawet dobrze zaprojektowanego rozwiązania.
Analiza ryzyka i dokumentacja techniczna
CRA przewiduje podejście oparte na ocenie ryzyka cyberbezpieczeństwa produktu. Taka analiza powinna wpływać na decyzje dotyczące projektowania, rozwoju, produkcji, dostarczania i utrzymania rozwiązania.
Warto zacząć od kilku podstawowych pytań:
-
Jakie dane przetwarza produkt i jakie skutki miałoby ich ujawnienie, modyfikacja lub utrata dostępności?
-
Z jakimi urządzeniami, sieciami i usługami zewnętrznymi komunikuje się system?
-
Jakie uprawnienia posiada aplikacja i kto może z nich korzystać?
-
Jakie są najważniejsze zależności technologiczne?
-
Co się stanie, jeśli jedna z zależności okaże się podatna?
-
W jaki sposób producent może dostarczyć poprawkę i sprawdzić, czy została wdrożona?
-
Jakie ryzyka pozostają po zastosowaniu zabezpieczeń?
Odpowiedzi nie powinny pozostawać wyłącznie w głowach programistów. W zależności od produktu i obowiązków producenta istotna będzie dokumentacja techniczna pokazująca między innymi, jakie rozwiązanie wprowadzono na rynek, jakie ryzyka rozpoznano i w jaki sposób spełniane są odpowiednie wymagania.
Dobra dokumentacja nie jest jedynie materiałem przygotowywanym na potrzeby audytu. Pomaga również rozwijać system, przekazywać odpowiedzialność pomiędzy zespołami, odtwarzać decyzje architektoniczne i reagować na problemy po wdrożeniu.
Nie oznacza to, że każda firma powinna od razu przygotowywać ogromny dokument opisujący wszystkie możliwe scenariusze. Zakres dokumentacji powinien wynikać z rodzaju produktu i obowiązujących wymagań. Kluczowe jest, aby dokumenty były aktualne, spójne z rzeczywistym rozwiązaniem i możliwe do wykorzystania w pracy.
Zależności i komponenty zewnętrzne: bezpieczeństwo całego łańcucha dostaw
Współczesne oprogramowanie rzadko powstaje całkowicie od zera. Wykorzystuje biblioteki, frameworki, gotowe komponenty, silniki baz danych, systemy operacyjne i usługi zewnętrzne. To przyspiesza rozwój, ale oznacza również, że bezpieczeństwo produktu zależy częściowo od elementów, nad którymi producent nie ma pełnej kontroli.
Jeśli w popularnej bibliotece zostanie wykryta podatność, problem może dotyczyć wielu niezależnych produktów. Sam fakt, że dana biblioteka pochodzi z uznanego projektu, nie gwarantuje, że pozostanie bezpieczna przez cały okres jej używania.
Dlatego warto znać skład technologiczny produktu i mieć możliwość ustalenia, które komponenty zostały wykorzystane, w jakich wersjach i w jakich częściach systemu. Pomocne są między innymi kontrola zależności, skanowanie podatności, rejestrowanie zmian oraz procedury aktualizacji.
W bardziej dojrzałych procesach wykorzystuje się również zestawienia komponentów oprogramowania, znane jako SBOM (Software Bill of Materials). Takie zestawienie może ułatwić identyfikację bibliotek i innych elementów, których dotyczy nowo wykryta podatność. Nie należy jednak zakładać, że sam SBOM automatycznie zapewnia zgodność z CRA. Jest narzędziem wspierającym zarządzanie komponentami, a nie zastępstwem dla całego procesu bezpieczeństwa i dokumentacji wymaganej dla konkretnego produktu.
Istotna jest również relacja z dostawcami. Firma powinna wiedzieć, w jaki sposób otrzymuje informacje o podatnościach, kto odpowiada za aktualizacje wykorzystywanych komponentów i jak szybko może zareagować na krytyczny problem.
To szczególnie ważne w długowiecznych systemach biznesowych, w których wymiana pojedynczej biblioteki może wpływać na integracje, kompatybilność lub stabilność całego rozwiązania.
Aktualizacje i okres wsparcia produktu
Jednym z najważniejszych zagadnień jest utrzymywanie produktu po jego udostępnieniu na rynku. W przypadku produktów objętych CRA producent musi określić okres wsparcia i zapewniać odpowiednią obsługę podatności przez ten okres, zgodnie z wymaganiami rozporządzenia.
To oznacza, że bezpieczeństwo trzeba planować nie tylko na moment uruchomienia produktu, ale również na kolejne miesiące i lata jego użytkowania.
W praktyce warto ustalić:
-
kto monitoruje informacje o nowych podatnościach;
-
w jaki sposób ocenia się ich wpływ na produkt;
-
kto podejmuje decyzję o przygotowaniu poprawki;
-
jak testowane i publikowane są aktualizacje;
-
jak informowani są użytkownicy lub klienci;
-
jak długo produkt będzie wspierany;
-
jak komunikowany jest koniec okresu wsparcia.
Ważna jest również przewidywalność. Użytkownik powinien otrzymywać czytelne informacje dotyczące bezpieczeństwa i wsparcia produktu. Samo stwierdzenie, że producent „w razie potrzeby przygotuje aktualizację”, nie zastępuje procesu, który pozwala rzeczywiście obsłużyć wykrytą podatność.
Nie każda aktualizacja musi mieć taki sam tryb. Zespół powinien jednak umieć rozróżnić zwykłe zmiany funkcjonalne od poprawek bezpieczeństwa i ocenić, kiedy ryzyko wymaga przyspieszonego działania.
Z perspektywy biznesowej warto także pamiętać, że utrzymywanie oprogramowania kosztuje. Jeżeli model sprzedaży nie uwzględnia okresu wsparcia, monitorowania zależności, reagowania na podatności i dostarczania poprawek, firma może obiecać klientowi więcej, niż jest w stanie odpowiedzialnie zapewnić.
CRA jest więc nie tylko tematem dla zespołu technicznego. Może mieć wpływ na ofertę, umowy, wycenę produktu, planowanie rozwoju i sposób komunikowania warunków wsparcia.
Testy bezpieczeństwa i proces wydawania nowych wersji
Bezpieczeństwa produktu nie da się wiarygodnie potwierdzić jednym testem wykonanym tuż przed premierą. Potrzebny jest proces, który pomaga wykrywać problemy w miarę rozwoju oprogramowania.
W zależności od rodzaju produktu i poziomu ryzyka może obejmować przeglądy kodu, analizę statyczną, testy zależności, skanowanie konfiguracji, testy dynamiczne i testy penetracyjne. Narzędzia automatyczne są przydatne, ale ich wyniki wymagają interpretacji. Nie każdy alert oznacza rzeczywiste zagrożenie, a brak alertów nie dowodzi, że system jest bezpieczny.
Warto również powiązać działania bezpieczeństwa z procesem CI/CD, czyli automatyzacją budowania, testowania i wdrażania oprogramowania. Dzięki temu wybrane kontrole mogą być wykonywane regularnie, a nie tylko wtedy, gdy ktoś pamięta o ich uruchomieniu.
Nie chodzi o to, aby każdą zmianę blokować dziesiątkami nieskoordynowanych kontroli. Chodzi o dobór testów do ryzyka i o jasne zasady postępowania, kiedy kontrola wykryje problem. Zespół powinien wiedzieć, które błędy uniemożliwiają wydanie wersji, które wymagają dodatkowej analizy i kto może zaakceptować pozostałe ryzyko.
Proces wydawania wersji powinien także umożliwiać identyfikację konkretnej wersji produktu, odtworzenie istotnych zmian oraz powiązanie poprawki z problemem, który ma rozwiązać. To ułatwia analizę incydentów i pomaga wykazać, jakie działania zostały podjęte.
W przypadku CRA szczegółowy zestaw wymaganych działań zależy od produktu i odpowiedniej procedury oceny zgodności. Warto zatem traktować testy i automatyzację jako elementy wspierające realizację wymagań, a nie jako samodzielny certyfikat zgodności.
Czy CRA dotyczy również małych firm i software house'ów?
Wielkość organizacji nie powinna być jedynym kryterium oceny, czy temat warto przeanalizować. Kluczowe jest to, jaki produkt firma tworzy lub udostępnia, jaką rolę pełni i jakie obowiązki wynikają z przepisów.
Małe przedsiębiorstwa mogą mieć mniej zasobów niż duzi producenci, ale również rozwijają produkty cyfrowe, integrują komponenty i utrzymują systemy używane przez klientów. Właśnie dlatego warto zacząć od działań proporcjonalnych do skali działalności, zamiast zakładać, że przygotowanie do CRA musi oznaczać kosztowny program compliance od pierwszego dnia.
Dla mniejszej firmy rozsądnym początkiem może być sporządzenie listy produktów, ustalenie ról prawnych, rozpoznanie najważniejszych zależności, opisanie procesu obsługi podatności i wskazanie osób odpowiedzialnych za bezpieczeństwo. Dopiero potem można określić, które dodatkowe kontrole, dokumenty lub konsultacje są rzeczywiście potrzebne.
Nie należy przy tym zakładać, że każdy mniejszy podmiot jest zwolniony z obowiązków. CRA zawiera szczególne zasady i proporcjonalne rozwiązania w określonych przypadkach, ale nie można sprowadzić ich do ogólnej reguły, że mała firma nie musi się przygotowywać.
Warto również rozdzielić obowiązki producenta od oczekiwań jego klientów. Nawet jeżeli dany software house nie jest producentem konkretnego produktu w rozumieniu CRA, klient może oczekiwać informacji o użytych komponentach, sposobie obsługi podatności, aktualizacjach czy dokumentacji technicznej. Jasne uzgodnienia ograniczają ryzyko, że po wdrożeniu każda ze stron będzie zakładała, że za bezpieczeństwo odpowiada ktoś inny.
Jak przygotować firmę do CRA? Praktyczna lista działań
Najlepszy punkt wyjścia to plan oparty na rzeczywistych produktach, procesach i odpowiedzialności. Poniższe kroki nie stanowią kompletnej listy prawnych wymagań dla każdego przypadku, ale pomagają uporządkować przygotowania.
1. Sporządź wykaz produktów cyfrowych. Zidentyfikuj rozwiązania oferowane na rynku, ich przeznaczenie, sposób dystrybucji i najważniejsze komponenty. Nie ograniczaj się do produktów, które firma aktywnie rozwija. Uwzględnij również wersje utrzymywane i udostępniane klientom.
2. Ustal rolę firmy przy każdym produkcie. Sprawdź, kto opracowuje rozwiązanie, kto zleca jego opracowanie, pod czyją marką jest ono udostępniane i kto odpowiada za produkt na rynku. Przy nietypowym modelu współpracy nie opieraj decyzji wyłącznie na potocznej nazwie usługi.
3. Zweryfikuj zakres regulacji i możliwe wyłączenia. Dla każdego produktu oceń, czy mieści się w zakresie CRA, jakie przepisy mogą mieć zastosowanie i czy występują okoliczności wymagające szczególnej interpretacji. W razie wątpliwości skorzystaj z aktualnych wytycznych Komisji Europejskiej i odpowiedniej konsultacji prawnej.
4. Wykonaj ocenę ryzyka. Zidentyfikuj najważniejsze zagrożenia, dane, integracje, zależności i skutki potencjalnego incydentu. Na tej podstawie określ, jakie zabezpieczenia i kontrole są adekwatne do produktu.
5. Opisz proces obsługi podatności. Ustal, gdzie przyjmowane są zgłoszenia, jak są weryfikowane, kto ocenia ich wagę, jak powstają poprawki i jak dokumentuje się decyzje. Proces powinien działać również wtedy, gdy problem pojawia się poza standardowymi godzinami pracy.
6. Przygotuj procedurę raportowania. Ponieważ obowiązki raportowania z art. 14 są już stosowane, podmiot objęty tymi obowiązkami powinien znać kryteria zgłoszenia, wymagane terminy i sposób korzystania z platformy CRA Single Reporting Platform. Wewnętrzna procedura musi umożliwiać zebranie informacji bez niepotrzebnej zwłoki.
7. Przejrzyj zależności technologiczne. Sprawdź biblioteki, frameworki i inne komponenty, z których korzysta produkt. Zastanów się, czy firma potrafi szybko ustalić, które wersje jej oprogramowania są narażone na nowo wykrytą podatność.
8. Zweryfikuj aktualizacje i okres wsparcia. Ustal, jak przygotowywane, testowane i publikowane są poprawki bezpieczeństwa oraz jak komunikowane są zasady wsparcia. Oceń, czy obecny model utrzymania jest zgodny z deklaracjami wobec klientów i wymaganiami dotyczącymi danego produktu.
9. Sprawdź dokumentację. Zgromadź informacje techniczne i procesowe, które są potrzebne do zarządzania bezpieczeństwem oraz wykazania spełnienia właściwych wymagań. Dokumentacja powinna odzwierciedlać rzeczywisty produkt, a nie wyłącznie plan jego działania.
10. Ustal odpowiedzialność w zespole i w umowach. Wskaż, kto odpowiada za bezpieczeństwo produktu, kto podejmuje decyzje podczas incydentu i jak współpracują producent, software house, dostawcy komponentów oraz klient. Upewnij się, że zakres wsparcia i aktualizacji jest jasno określony.
11. Zweryfikuj gotowość w praktyce. Przećwicz scenariusz wykrycia poważnej podatności. Sprawdź, czy zespół potrafi ustalić zakres problemu, zidentyfikować podatne wersje, podjąć decyzje i przygotować poprawkę. Sama obecność procedury w dokumencie nie gwarantuje, że zadziała w rzeczywistym zdarzeniu.
12. Monitoruj aktualne wytyczne. Szczegóły wdrażania CRA są rozwijane w materiałach Komisji Europejskiej, a regulacja zawiera mechanizmy oraz wymagania, które należy interpretować w kontekście konkretnego produktu. Warto regularnie sprawdzać oficjalne publikacje i aktualizować plan przygotowań.
Najczęstsze błędy w przygotowaniach
Pierwszym błędem jest odkładanie tematu do końca 2027 roku. To pomija fakt, że obowiązki raportowania określonych zdarzeń już się rozpoczęły, a przygotowanie procesów bezpieczeństwa może wymagać zmian organizacyjnych, technicznych i umownych.
Drugim błędem jest założenie, że CRA dotyczy wyłącznie producentów sprzętu. Rozporządzenie obejmuje również odpowiednie kategorie oprogramowania i komponentów cyfrowych, choć zakres trzeba ocenić w odniesieniu do konkretnego produktu.
Trzecim błędem jest uznanie, że wystarczy kupić narzędzie do skanowania podatności. Narzędzie może pomóc wykrywać problemy, ale nie zastąpi oceny ryzyka, odpowiedzialności za decyzje, procesu aktualizacji, obsługi zgłoszeń ani wymaganej dokumentacji.
Czwartym błędem jest traktowanie zgodności jako jednorazowego projektu. Produkt zmienia się w czasie, pojawiają się nowe podatności, aktualizowane są komponenty, a sposób korzystania z rozwiązania może się rozwijać. Proces bezpieczeństwa musi uwzględniać tę dynamikę.
Piątym błędem jest niejasny podział odpowiedzialności między producentem, wykonawcą i klientem. W umowach oraz w praktyce zespołu powinno być jasne, kto monitoruje podatności, przygotowuje poprawki, komunikuje problemy i podejmuje decyzje.
Szóstym błędem jest tworzenie dokumentacji, która nie odpowiada rzeczywistemu stanowi produktu. Dokument opisujący architekturę sprzed kilku lat, nieaktualny wykaz komponentów lub procedura, której nikt nie zna, nie zapewnią dobrej podstawy do reagowania na incydenty.
CRA jako impuls do uporządkowania procesu tworzenia oprogramowania
Nowe wymagania regulacyjne mogą być postrzegane jako dodatkowy obowiązek, ale przygotowanie do CRA daje również okazję do sprawdzenia, jak firma zarządza bezpieczeństwem własnych produktów.
Czy wiadomo, z jakich komponentów składa się system? Czy zespół potrafi szybko ustalić, które wersje wymagają poprawki? Czy aktualizacje bezpieczeństwa mają jasno określoną ścieżkę? Czy klient wie, jak długo produkt będzie wspierany? Czy w razie incydentu wiadomo, kto podejmuje decyzje i jakie działania należy wykonać?
Jeżeli odpowiedzi na te pytania są niejasne, problem nie zaczyna się od regulacji. CRA jedynie zwiększa znaczenie obszarów, które już wcześniej wpływały na bezpieczeństwo, utrzymywalność i wiarygodność produktu.
Dojrzałe wytwarzanie oprogramowania nie polega na obietnicy, że błędy nigdy się nie pojawią. Polega na ograniczaniu ryzyka, szybkim wykrywaniu problemów, odpowiedzialnym reagowaniu i utrzymywaniu produktu w stanie, który odpowiada jego przeznaczeniu oraz zobowiązaniom producenta.
Co warto zrobić teraz?
Na początek nie trzeba wdrażać wszystkich możliwych procedur naraz. Warto sporządzić listę produktów, ustalić role organizacji, zweryfikować zakres CRA i sprawdzić, czy działają podstawowe procesy obsługi podatności oraz incydentów. Szczególnie pilne jest to w przypadku podmiotów, które już podlegają obowiązkom raportowania.
Kolejny etap to analiza ryzyka, zależności, aktualizacji, okresów wsparcia i dokumentacji. Dopiero na tej podstawie można zaplanować konkretne zmiany technologiczne i organizacyjne, a także ocenić, czy potrzebna jest dodatkowa konsultacja prawna lub specjalistyczna ocena zgodności.
Cyber Resilience Act nie powinien być sprowadzany do jednego terminu w kalendarzu. To regulacja, która wzmacnia podejście do cyberbezpieczeństwa w całym cyklu życia produktu cyfrowego. Im wcześniej firma zrozumie, jakiego produktu i jakiej roli dotyczy jej sytuacja, tym łatwiej będzie przygotować proporcjonalny, praktyczny plan działania.
Ważne: artykuł ma charakter informacyjny i nie stanowi porady prawnej ani formalnej oceny zgodności. Zakres obowiązków należy ustalić na podstawie pełnego tekstu rozporządzenia, aktualnych wytycznych i sytuacji konkretnego produktu.
Źródła i dalsza lektura
-
Komisja Europejska: Cyber Resilience Act - podsumowanie przepisów
-
Komisja Europejska: Cyber Resilience Act - obowiązki producentów
-
Komisja Europejska: Cyber Resilience Act - obowiązki raportowania
