- Email: biuro@kicb.pl
- Rondo Organizacji Narodów Zjednoczonych 1, 00-124 Warszawa
Rozporządzenie Cyber Resilience Act (CRA), czyli rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/2847, wchodzi w życie. Dokument ten wprowadza jednolite w całej UE wymagania dotyczące cyberbezpieczeństwa produktów z elementami cyfrowymi. To kluczowa zmiana w projektowaniu, wdrażaniu i utrzymaniu produktów z elementami cyfrowymi.
Zgodnie z definicją, „produkt z elementami cyfrowymi” oznacza oprogramowanie komputerowe lub sprzęt komputerowy oraz powiązane z nimi rozwiązania w zakresie zdalnego przetwarzania danych, w tym komponenty oprogramowania lub sprzętu, które są oddzielnie wprowadzane do obrotu. Rozporządzenie nie obejmuje jednak niektórych sektorów i kategorii produktów, takich jak wyroby medyczne, pojazdy, lotnictwo, systemy wojskowe oraz oprogramowanie świadczone wyłącznie jako usługa (SaaS) czy oprogramowanie open source rozwijane niekomercyjnie.
Jak podkreśla CERT Polska w swoim najnowszym poradniku zatytułowanym „Dobre praktyki zarządzania bezpieczeństwem oprogramowania. Poradnik dla producentów w kontekście Cyber Resilience Act”, zarządzanie bezpieczeństwem IT staje się fundamentem legalnego funkcjonowania biznesu na rynku europejskim, a nie jedynie opcjonalnym dodatkiem.
Wdrożenie tych przepisów zostało rozłożone w czasie, a najbliższe kluczowe terminy przypadają już na bieżący rok.
Od 11 czerwca 2026 roku zaczną obowiązywać przepisy dotyczące podmiotów oceniających zgodność, natomiast przełomowym momentem dla działów R&D i Security będzie 11 września 2026 roku. Wtedy wchodzi w życie artykuł 14 CRA, nakładający na producentów rygorystyczny obowiązek bezzwłocznego zgłaszania aktywnie wykorzystywanych podatności oraz poważnych incydentów mających wpływ na bezpieczeństwo produktu. Zgłoszenia te będą składane centralnie za pośrednictwem platformy Single Reporting Platform zarządzanej przez ENISA, dlatego dobrą praktyką jest wypracowanie wewnętrznej procedury pozwalającej na szybkie rozpoznanie takich zdarzeń na podstawie własnych obserwacji, zgłoszeń użytkowników czy informacji od niezależnych badaczy.
Od 11 grudnia 2027 roku zaczną obowiązywać wszystkie pozostałe zapisy, w tym wymogi dotyczące certyfikacji i deklaracji zgodności CE.
Aby sprostać tym wymaganiom, tradycyjne podejście polegające na testowaniu kodu tuż przed premierą musi zostać zastąpione przez zarządzanie bezpieczeństwem obejmujące cały cykl życia produktu – od projektowania, przez wytwarzanie i utrzymanie, aż po jego wycofanie z rynku. Fundamentem staje się zasada Security by Design, czyli uwzględnianie zagrożeń, planowanie mechanizmów uwierzytelniania, szyfrowania danych czy podziału uprawnień, zanim powstanie pierwsza linia kodu.
CRA wprowadza również obowiązek przeprowadzania regularnej oceny ryzyka w kontekście cyberbezpieczeństwa, która musi być aktualizowana przy każdej istotnej zmianie funkcjonalnej, architektonicznej lub środowiskowej, bezpośrednio wpływając na decyzje projektowe i sposób reagowania na luki. Ważnym elementem staje się także jednoznaczna identyfikacja produktu i jego wersji, co pozwala precyzyjnie określić, które wydania są objęte wsparciem. W tym procesie kluczową rolę odgrywa utrzymywanie aktualnego wykazu komponentów oprogramowania, czyli Software Bill of Materials (SBOM). Posiadanie SBOM pozwala szybko ocenić wpływ nowo ujawnionej podatności na produkt i przyspieszyć analizę ryzyka. CERT Polska rekomenduje automatyczne generowanie SBOM przy każdym procesie budowania aplikacji oraz odsyła do szczegółowych wytycznych w przewodniku OWASP CycloneDX: Authoritative Guide to SBOM.
Po wdrożeniu produktu zarządzanie bezpieczeństwem przechodzi w fazę ciągłego utrzymania, co wymaga systematycznego śledzenia informacji o podatnościach w komponentach własnych i zewnętrznych poprzez monitorowanie publicznych baz oraz subskrypcję komunikatów bezpieczeństwa, na przykład w usłudze moje.cert.pl. Za te procesy powinna odpowiadać jasno określona rola lub zespół, formalnie wskazany nawet w niewielkich organizacjach.
Wdrożenie uporządkowanego procesu obsługi podatności to kolejny bezwzględny wymóg. Producent powinien publicznie udostępnić jasny kanał zgłaszania luk, na przykład dedykowany adres e-mail lub formularz, a także opublikować plik security.txt zgodnie ze specyfikacją RFC 9116, co ułatwia badaczom szybki kontakt. Każde zgłoszenie musi zostać zweryfikowane pod kątem realnego wpływu na produkt i ewentualnego aktywnego wykorzystywania przez cyberprzestępców. W przypadku istotnych podatności CERT Polska zachęca do współpracy z ich zespołem w celu uzgodnienia harmonogramu naprawczego i momentu upublicznienia informacji.
Po opracowaniu, poprawki bezpieczeństwa powinny być testowane i wdrażane w jak najkrótszym czasie, przy czym producent nie powinien udostępniać wersji z nowymi funkcjami, jeśli posiada wiedzę o istniejącej i nierozwiązanej podatności w tej wersji. Rekomendowanym sposobem komunikacji jest przypisanie unikalnego identyfikatora CVE. Zespół CERT Polska od 2023 roku posiada status CNA (CVE Numbering Authority) i wspiera producentów w rezerwacji numerów oraz publikacji wpisów, natomiast firmy regularnie obsługujące podatności mogą rozważyć samodzielne uzyskanie takiego statusu. Cały ten proces, w tym terminy reakcji i podjęte działania, musi być skrupulatnie dokumentowany, co pozwala na wykazanie należytej staranności przed organami nadzoru rynku.
Ochrona użytkownika końcowego w ramach CRA opiera się również na skutecznym dostarczaniu aktualizacji zabezpieczeń, które domyślnie powinny instalować się automatycznie. Użytkownicy muszą być o nich jasno informowani, zachowując możliwość czasowego odroczenia lub rezygnacji z automatu. Co niezwykle ważne, jeśli jest to technicznie wykonalne, aktualizacje bezpieczeństwa powinny być dostarczane oddzielnie od zmian funkcjonalnych, aby użytkownicy nie byli zmuszani do instalowania nowych funkcji tylko po to, by zabezpieczyć system. Rozporządzenie wprowadza także minimalny okres wsparcia produktu, który co do zasady wynosi co najmniej pięć lat, chyba że przewidywany czas użytkowania produktu jest krótszy.
Wszystkie te operacje wymagają prowadzenia dokumentacji technicznej obejmującej architekturę, mechanizmy ochronne, SBOM oraz rejestr usuwanych podatności i incydentów. CERT Polska zaznacza, że dokumentacja ta powinna powstawać naturalnie w toku procesu wytwórczego, a nie jako jednorazowy dokument tworzony przed audytem. Pomocne jest tu wykorzystanie narzędzi klasy ALM, takich jak GitLab czy Jira z Confluence, które pozwalają połączyć zarządzanie zmianami z dokumentacją w jednym ekosystemie, tworząc pełną, audytowalną historię produktu.
Choć Cyber Resilience Act nakłada nowe obowiązki regulacyjne, warto traktować go jako element długofalowej strategii biznesowej. Prawidłowo wdrożone procesy obsługi podatności, automatyzacja SBOM i przejrzysta komunikacja nie tylko minimalizują skutki incydentów, ale przede wszystkim podnoszą jakość oprogramowania i budują zaufanie użytkowników na rynku.
Najnowsze komentarze