Stan na 11 sierpnia 2026 r. Unijne rozporządzenie w sprawie cyberodporności (Rozporządzenie (UE) 2024/2847) określa wymagania dotyczące cyberbezpieczeństwa dla produktów z elementami cyfrowymi wprowadzanych na rynek Unii. Wytyczne praktyczne Komisji zostały opublikowane 27 lipca 2026 r. Obowiązki związane ze sprawozdawczością mają zastosowanie od 11 września 2026 r., główne wymagania dotyczące produktów od 11 grudnia 2027 r. Ten przewodnik jest przeznaczony dla inżynierów oprogramowania pracujących nad produktami, które mogą podlegać CRA, a nie dla prawników zajmujących się ocena zgodności.
Uczciwość zakresu: CRA nie zastępuje SOC 2, ISO 27001 ani RODO. Nie jest to "kolejna kontrolka bota zgodności". Wiele obowiązków CRA dotyczy producentów, dokumentacji oraz procesów posprzedażowych. Tylko część z nich może zostać wykryta w typowym pull request: aktualność inwentarza zależności i SBOM, ścieżki zgłaszania luk oraz usunięte kontrole bezpieczeństwa jako martwy kod. Jeśli Twój zespół prawny lub produktowy nie potwierdził, że CRA dotyczy Twojego produktu, przerwij tutaj i zapytaj ich.
Co wchodzi w życie i kiedy (kalendarz programisty)
Od 11 września 2026 r. zaczynają obowiązywać obowiązki sprawozdawcze związane z systemem zgłaszania luk i incydentów określonych w CRA, zgodnie z harmonogramem ustalonym w rozporządzeniu i wytycznych Komisji dla producentów. Od 11 grudnia 2027 r. główne wymagania dotyczące cyberbezpieczeństwa produktów (w tym oczekiwania dotyczące secure-by-design, procesów obsługi luk oraz przejrzystości SBOM dla produktów z elementami cyfrowymi) będą miały szersze zastosowanie. Dokładna klasyfikacja Twojego produktu (domyślna, ważna, krytyczna) jest kwestią prawną i produktową, a nie czymś, co decyduje przegląd kodu.
Traktuj te daty jako punkty odniesienia w planowaniu. Jeśli poprawki w Dzienniku Urzędowym lub dalsze wytyczne je zmienią, zweryfikuj tę stronę (zob. rejestr aktualności dat).
Co może się pojawić w pull request
Aktualność zależności i SBOM: zmiana blokuje przestarzały komponent, usuwa generowanie software bill of materials z CI lub przestaje publikować inwentarz komponentów, od którego zależy proces obsługi luk. Ścieżka obsługi luk: zmiana usuwa lub twardo koduje zamknięcie kontaktu bezpieczeństwa, kanału doradczego lub webhooka do triage'u luk, którego proces zgodny z CRA zakłada istnienie. Erozja secure-by-design: pull request „porządkujący” usuwa uwierzytelnianie na porcie administracyjnym, wyłącza sprawdzanie aktualizacji lub wyłącza weryfikację integralności pakietów aktualizacyjnych, ponieważ były uciążliwe.
To są kształty inżynierskie. Nie stanowią one pełnego pliku zgodności CRA, historii znakowania CE ani oceny jednostki notyfikowanej.
Przykład praktyczny: CI przestaje generować inwentarz komponentów
Zespół platformowy skraca CI o dwie minuty, usuwając zadanie, które uruchamiało syft (lub równoważne narzędzie) i przesyłało artefakt SBOM przy każdym tagu wydania. Dockerfile i aplikacja nadal się kompilują. Testy pozostają zielone. Komentarze w przeglądzie dotyczą kosztów potoku. Tygodnie później zespół bezpieczeństwa nie może odpowiedzieć na pytanie „jakie wersje zostały wydane w 1.8.3” bez rekonstrukcji z warstw.
Jeśli Twój produkt podlega CRA, a proces zależy od tego inwentarza do obsługi luk i przejrzystości, usunięcie zadania nie jest neutralnym działaniem higienicznym. Przegląd świadomy zgodności sygnalizuje utratę kroku inwentaryzacji w pull request, aby zespół produktowy i bezpieczeństwa mógł formalnie zaakceptować ryzyko lub przywrócić zadanie. heygrc cytując tutaj kontrolę frameworka jest sygnałem, a nie orzeczeniem, że produkt jest niezgodny.
Wyraźne cele poza zakresem
Ten przewodnik nie obejmuje modułów oceny zgodności, znakowania CE, rejestracji producentów, sporządzania deklaracji zgodności UE ani określenia, czy Twój produkt jest „ważny” lub „krytyczny” w rozumieniu CRA. Nie twierdzi, że heygrc sprawia, że produkt jest zgodny z CRA. Nie zastępuje PSIRT, przeglądu prawnego ani planu reagowania na nadzór rynkowy.
Jeśli do tej pory potrzebowałeś jedynie SOC 2 lub ISO 27001 dla klientów, CRA może nadal nie dotyczyć. Nie wymuszaj jego zastosowania.
Rola heygrc i granica uczciwości
heygrc został zaprojektowany, aby ujawniać istotne dla kontroli zmiany w pull requestach w odniesieniu do włączonych frameworków. W przypadku higieny inżynierskiej związanej z CRA, przydatne pokrycie dotyczy tej samej klasy ustaleń, co bezpieczny rozwój i obsługa luk w ramach innych frameworków (np. wymagania oprogramowania NIS 2 Art. 21, kontrole bezpiecznego rozwoju ISO 27001): usunięte sprawdzania integralności aktualizacji, osłabione uwierzytelnianie, usunięte zadania inwentaryzacyjne. Mapuj ostrożnie; nie wymyślaj numerów artykułów CRA w ustaleniach, chyba że włączona baza wiedzy je zawiera.
Zachowaj SAST, skanery zależności i recenzenta kodu. Prawo dotyczące produktów CRA znajduje się głównie poza diffem. Diff wykrywa jedynie tę część, która cicho usuwa to, co te programy zakładają, że nadal działa.