Cyber Resilience Act
Checklista gotowości producenta
Ta checklista pomaga przypisać odpowiedzialność i zbierać dowody podczas przygotowywania produktów z elementami cyfrowymi do CRA.
Przewodnik po Cyber Resilience Act
Praktyczna mapa drogowa dla zespołów budujących produkty z elementami cyfrowymi: co zrobić, kto odpowiada i jakie dowody zachować. Co mówi prawo, wyjaśnia strona czym jest Cyber Resilience Act.
Ostatnia aktualizacja: 15 października 2026
What the Cyber Resilience Act asks manufacturers to do
Zakres rozporządzenia (UE) 2024/2847, daty jego stosowania, terminy zgłoszeń oraz miejsce obowiązków dotyczących SBOM i obsługi podatności.
Petteri Pulkkinen i Erika Marttinen na Kubernetes Community Days Helsinki 2026, od 8:03 do 15:20 nagrania SBOMbastic: Getting Ready for Upcoming EU Cybersecurity Regulation in Software Supply Chains.
Kroki przebiegają mniej więcej po kolei, ale dla produktów już obecnych na rynku najpierw liczą się kroki od 5 do 8, ponieważ obowiązek zgłaszania już ich dotyczy.
Należy wymienić każdy produkt z elementami cyfrowymi udostępniany w UE, łącznie z oprogramowaniem sprzedawanym osobno i backendami chmurowymi potrzebnymi produktom do działania. Dla każdego trzeba potwierdzić, że nie jest wyłączony (wyroby medyczne, pojazdy, lotnictwo, wyposażenie morskie, obronność) oraz czy są Państwo jego producentem, importerem czy dystrybutorem.
Proszę sprawdzić produkt w CRA Checker →Większość produktów należy do kategorii domyślnej. Należy porównać swoje produkty z listami produktów ważnych (załącznik III) i krytycznych (załącznik IV); ich opisy techniczne podaje rozporządzenie wykonawcze (UE) 2025/2392. Kategoria decyduje, czy dozwolona jest samoocena, czy potrzebna jest jednostka notyfikowana lub certyfikacja.
Dla każdego produktu należy napisać ocenę ryzyka cyberbezpieczeństwa. Decyduje ona o tym, jak stosuje się zasadnicze wymagania z załącznika I, i jest częścią dokumentacji technicznej. Należy ją aktualizować, gdy zmienia się produkt lub zagrożenia.
Należy zdecydować, jak długo obsługiwane będą podatności każdego produktu: co najmniej pięć lat, chyba że przewidywane użytkowanie produktu jest krótsze. Trzeba poinformować użytkowników, kiedy wsparcie się kończy, i utrzymywać każdą aktualizację bezpieczeństwa dostępną przez co najmniej 10 lat.
CRA wymaga zestawienia komponentów oprogramowania w powszechnie stosowanym formacie czytelnym maszynowo, obejmującego co najmniej zależności najwyższego poziomu. Generowanie go w buildzie, który tworzy wydanie, a nie jednorazowo ręcznie, zapewnia jego zgodność z tym, co dostarczono.
Gdzie wpisuje się CRACI: CRACI rejestruje SBOM podczas działania każdego buildu, łącznie z zależnościami przechodnimi i pakietami przywróconymi z cache, i eksportuje go w formacie CycloneDX lub SPDX.
Przez cały okres wsparcia należy obserwować pod kątem nowych podatności wydane wersje, a nie tylko gałąź główną. Trzeba naprawiać je bez zwłoki i dostarczać aktualizacje bezpieczeństwa bezpłatnie oraz, gdy to wykonalne, oddzielnie od aktualizacji funkcji.
Gdzie wpisuje się CRACI: Po wydaniu CRACI ponownie sprawdza monitorowane SBOM-y względem nowych podatności, a zespoły bezpieczeństwa wykonują triaż znalezisk i przekazują je zespołom odpowiedzialnym za poprawkę. Bramki polityk mogą blokować build na podstawie znalezisk.
Badacze i klienci powinni otrzymać kontakt do zgłaszania podatności oraz politykę skoordynowanego ujawniania podatności. Gdy aktualizacja jest dostępna, należy opublikować informacje o podatnościach, które naprawia.
Od 11 września 2026 aktywnie wykorzystywana podatność lub poważny incydent wymaga wczesnego ostrzeżenia w ciągu 24 godzin, zgłoszenia w ciągu 72 godzin i raportu końcowego, przez Single Reporting Platform. Należy wskazać, kto potwierdza aktywne wykorzystanie, kto składa zgłoszenie i kto informuje użytkowników. Najtrudniej jest ustalić w ciągu kilku godzin, które produkty i wydania zawierają podatny komponent.
Gdzie wpisuje się CRACI: Historia buildów CRACI pokazuje, które buildy zawierały podatną zależność, widok inwentarza pokazuje, które wersje są wdrożone w których produktach, a CRACI składa zgłoszenia CRA w Państwa imieniu.
Należy dostarczać produkty bez znanych podatności możliwych do wykorzystania i z domyślnie bezpieczną konfiguracją, chronić dane i dostęp, ograniczać powierzchnię ataku i umożliwiać aktualizacje bezpieczeństwa, w stosownych przypadkach domyślnie automatyczne. Bezpieczeństwo trzeba regularnie testować i przeglądać.
Gdzie wpisuje się CRACI: CRACI egzekwuje politykę ruchu wychodzącego dla tego, co buildy mogą pobierać, a bramki polityk mogą blokować build na podstawie znalezisk.
Należy zebrać dokumentację techniczną opisaną w załączniku VII, przeprowadzić ocenę zgodności dla swojej kategorii, sporządzić deklarację zgodności UE i umieścić oznakowanie CE. Dokumentację i deklarację trzeba przechowywać przez co najmniej 10 lat lub przez okres wsparcia, zależnie od tego, który jest dłuższy.
Gdzie wpisuje się CRACI: CRACI eksportuje SBOM-y w formacie CycloneDX lub SPDX, łącznie z podatnościami znalezionymi w ich komponentach, a jego API zwraca SBOM-y, ślady sieciowe i dane o pochodzeniu do dokumentacji technicznej. Ocena i deklaracja pozostają Państwa procesem.
Organy nadzoru rynku mogą zażądać Państwa dokumentacji technicznej. Oto, co pozostawia po sobie każde wymaganie i gdzie CRACI rejestruje to z Państwa buildów.
| Wymaganie | Gdzie | Dowody do zachowania | Z CRACI |
|---|---|---|---|
| Ocena ryzyka cyberbezpieczeństwa | Art. 13, załącznik I | Udokumentowana ocena dla każdego produktu | Państwa proces |
| Brak znanych podatności możliwych do wykorzystania w chwili wydania | Załącznik I, część I | Stan podatności buildu wydania | SBOM buildu wydania sprawdzany względem biuletynów; bramki polityk |
| Zestawienie komponentów oprogramowania | Załącznik I, część II | SBOM czytelny maszynowo dla każdego wydania | Rejestrowany z każdego buildu, CycloneDX lub SPDX |
| Obsługa podatności przez okres wsparcia | Art. 13, załącznik I, część II | Znaleziska, decyzje triażu, poprawki, biuletyny | Ciągła ponowna ocena, triaż, VEX |
| Należyta staranność wobec komponentów stron trzecich | Art. 13 | Zapisy komponentów, także oprogramowania kupowanego | SBOM-y dostawców monitorowane razem z własnymi; zadeklarowane licencje |
| Zgłaszanie wykorzystywanych podatności i poważnych incydentów | Art. 14 | Wczesne ostrzeżenia, zgłoszenia, raporty końcowe | Składa zgłoszenia w Państwa imieniu |
| Okres wsparcia | Art. 13 | Opublikowana data końca wsparcia | Państwa proces |
| Dokumentacja techniczna i deklaracja | Art. 13, załącznik VII | Przechowywane przez 10 lat lub przez okres wsparcia | Eksport SBOM i dane z API do dokumentacji |
Cyber Resilience Act
Ta checklista pomaga przypisać odpowiedzialność i zbierać dowody podczas przygotowywania produktów z elementami cyfrowymi do CRA.
Praktyczne pytania zespołów, które zaczynają pracę nad CRA
Należy spełnić zasadnicze wymagania z załącznika I na podstawie oceny ryzyka cyberbezpieczeństwa, prowadzić SBOM, obsługiwać podatności przez okres wsparcia wynoszący co najmniej pięć lat, zgłaszać aktywnie wykorzystywane podatności i poważne incydenty, prowadzić dokumentację techniczną, przejść ocenę zgodności i umieścić oznakowanie CE.
Od zakresu i zgłaszania. Należy ustalić, które produkty obejmuje CRA, a następnie upewnić się, że da się spełnić 24-godzinny termin wczesnego ostrzeżenia dla aktywnie wykorzystywanej podatności, ponieważ obowiązek zgłaszania ma zastosowanie od 11 września 2026, także dla produktów już obecnych na rynku. Reszta obowiązuje od 11 grudnia 2027.
Wymienia ją załącznik VII. Obejmuje ocenę ryzyka cyberbezpieczeństwa produktu, SBOM i informacje o tym, jak producent obsługuje podatności. Przechowuje się ją przez co najmniej 10 lat lub przez okres wsparcia, zależnie od tego, który jest dłuższy, i przekazuje organom nadzoru rynku na żądanie.
Nie. SBOM jest częścią dokumentacji technicznej i trafia do organu nadzoru rynku na żądanie. Rozporządzenie nie wymaga jego publikowania.
Tak. 27 lipca 2026 Komisja Europejska opublikowała niewiążące wytyczne C(2026) 5252 z 67 praktycznymi przykładami. Obejmują zdalne przetwarzanie danych, wolne i otwarte oprogramowanie, istotną zmianę, okresy wsparcia, zgłaszanie i ocenę ryzyka. Rozporządzenie wykonawcze (UE) 2025/2392 opisuje kategorie produktów ważnych i krytycznych.
Obowiązki są takie same, ale mikro- i małe przedsiębiorstwa nie są karane za niedotrzymanie 24-godzinnego terminu wczesnego ostrzeżenia, a wytyczne Komisji napisano z myślą o mikroprzedsiębiorstwach i MŚP.
Nie. Spełnienie wymagań CRA to proces producenta, obejmujący ocenę ryzyka, ocenę zgodności i deklarację. CRACI automatyzuje znaczną część pracy nad widocznością łańcucha dostaw i dowodami potrzebnymi w tym procesie: SBOM-y z każdego buildu, śledzenie podatności po wydaniu i zgłoszenia CRA.
Proszę zobaczyć, jak CRACI rejestruje SBOM z każdego buildu, monitoruje to, co Państwo dostarczyli, i składa zgłoszenia CRA w Państwa imieniu