Stan na 13 września 2026 r. Akt o cyberodporności UE (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ą obowiązują od 11 września 2026 r., główne obowiązki 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ę oceną 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 podczas typowego przeglądu pull request: aktualność inwentarza zależności i SBOM, ścieżki zgłaszania luk oraz usunięcie kontroli bezpieczeństwa jako martwego kodu. Jeśli twój zespół prawny lub produktowy nie potwierdził, że CRA dotyczy twojego produktu, przerwij tutaj i zapytaj ich.
Co obowiązuje i kiedy (kalendarz programisty)
Od 11 września 2026 r. obowiązują obowiązki sprawozdawcze związane z systemem zgłaszania luk i incydentów określonych w Akcie, 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 bezpieczeństwa od samego początku, procesy obsługi luk oraz transparentność związana z SBOM dla produktów z elementami cyfrowymi) będą miały szersze zastosowanie. Dokładna klasyfikacja twojego produktu (domyślna, ważna, krytyczna) to kwestia prawna i produktowa, a nie coś, co decyduje przegląd kodu.
Traktuj te daty jako punkty odniesienia dla planowania. Jeśli poprawki w Dzienniku Urzędowym lub dalsze wytyczne je zmienią, zweryfikuj tę stronę (zob. rejestr aktualności dat).
Co może pojawić się 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 twój proces obsługi luk. Ścieżka obsługi luk: zmiana usuwa lub twardo koduje zamknięcie kontaktu bezpieczeństwa, kanału doradczego lub wewnętrznego webhooka do triage'u luk, którego twój proces zgodny z CRA zakłada, że istnieje. Erozja bezpieczeństwa od samego początku: pull request „porządkujący” usuwa uwierzytelnianie na porcie administracyjnym, wyłącza sprawdzanie aktualizacji lub wyłącza weryfikację integralności pakietów aktualizacji, ponieważ były one uciążliwe.
To są kształty inżynierskie. Nie stanowią one pełnego pliku zgodności CRA, historii znakowania CE ani oceny przez jednostkę notyfikowaną.
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ół ds. 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 twój proces zależy od tego inwentarza do obsługi luk i transparentności, usunięcie zadania nie jest neutralnym działaniem higienicznym. Przegląd uwzględniający zgodność sygnalizuje utratę kroku inwentaryzacji w pull request, aby zespół produktowy i ds. bezpieczeństwa mógł formalnie zaakceptować ryzyko lub przywrócić zadanie. heygrc cytując tutaj kontrolę frameworka to sygnał, a nie orzeczenie, ż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 myśl Aktu. Nie twierdzi, że heygrc sprawia, że produkt jest zgodny z CRA. Nie zastępuje PSIRT, przeglądu prawnego ani planu reagowania na nadzór rynku.
Jeśli do tej pory potrzebowałeś jedynie SOC 2 lub ISO 27001 dla klientów, CRA może nadal nie mieć zastosowania. Nie wymuszaj jego dopasowania.
Rola heygrc i granice uczciwości
heygrc został zaprojektowany, aby uwidaczniać istotne dla kontroli zmiany w pull requestach w oparciu o aktywowane frameworki. 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 twoja aktywowana baza wiedzy je zawiera.
Zachowaj SAST, skanery zależności i recenzenta kodu. Prawo produktowe CRA w większości znajduje się poza diffem. Diff wykrywa jedynie tę część, która cicho usuwa to, co te programy zakładają, że nadal działa.