Jak łączą się PCI Secure SLC i unijny CRA? PCI Secure SLC (standard bezpiecznego cyklu wytwórczego oprogramowania) oraz Cyber Resilience Act (unijne rozporządzenie o produktach z elementami cyfrowymi) dzielą wspólny rdzeń: projektowanie z bezpieczeństwem od początku (secure-by-design) i formalną obsługę podatności. Zwalidowany proces SLC pokrywa znaczną część praktyk, których wymaga CRA – choć nie zastępuje formalnej oceny zgodności CRA.
Definicja kanoniczna: Cyber Resilience Act (CRA) to rozporządzenie UE 2024/2847 nakładające na producentów produktów z elementami cyfrowymi obowiązki bezpieczeństwa przez cały cykl życia: projektowanie secure-by-design, obsługę podatności, SBOM, raportowanie i ocenę zgodności zakończoną oznaczeniem CE.
Dla dostawcy oprogramowania, który już posiada lub rozważa walidację Secure SLC, CRA to nie osobny świat, lecz częściowo pokrywający się zestaw wymogów. Ten artykuł pokazuje, gdzie te regulacje się spotykają i jak wykorzystać jedną do przygotowania na drugą.
PCI SLC a CRA – w skrócie:
- CRA weszło w życie 10 gru 2024; obowiązki raportowania podatności (art. 14) zaczynają obowiązywać 11 wrz 2026, a pełne stosowanie – w tym secure-by-design, SBOM, ocena zgodności i oznaczenie CE – od 11 gru 2027.
- PCI Secure SLC v1.1 waliduje proces wytwórczy dostawcy w czterech obszarach: governance, bezpieczna inżynieria, zarządzanie oprogramowaniem i danymi oraz komunikacja bezpieczeństwa.
- Wspólny rdzeń obu regulacji to secure-by-design i formalna obsługa podatności – obszary, które SLC ocenia wprost, a CRA wymaga jako obowiązku prawnego.
- CRA idzie dalej niż SLC w kilku obszarach: wymaga SBOM w formacie maszynowym, raportowania aktywnie wykorzystywanych podatności do ENISA w 24 godziny oraz oznaczenia CE po ocenie zgodności.
- Kary CRA sięgają 15 mln EUR lub 2,5% światowego rocznego obrotu, w zależności od tego, co wyższe – stawka jest realna, a przygotowanie zajmuje zwykle 18-24 miesiące.
- Patronusec jako akredytowany QSA pomaga dostawcom oprogramowania wykorzystać zwalidowany proces SLC jako fundament przygotowania do CRA.
Spis treści
Czym jest CRA i kogo obejmuje?
Cyber Resilience Act to unijne rozporządzenie nakładające obowiązki cyberbezpieczeństwa na producentów produktów z elementami cyfrowymi wprowadzanych na rynek UE. Obejmuje oprogramowanie komercyjne, SaaS, urządzenia IoT i sprzęt podłączony – a producenci spoza UE są objęci, jeśli ich produkty trafiają na rynek unijny.
CRA (rozporządzenie UE 2024/2847) wprowadza obowiązki po obu stronach cyklu życia produktu. Przed wprowadzeniem na rynek: bezpieczna domyślna konfiguracja, szyfrowana komunikacja, kontrola dostępu na interfejsach, weryfikacja integralności oprogramowania, odporność na ataki DoS. Po wprowadzeniu: utrzymanie SBOM, formalny proces obsługi podatności z publiczną polityką ujawniania, wydawanie poprawek bez zbędnej zwłoki i raportowanie aktywnie wykorzystywanych podatności.
Kalendarium wejścia w życie według tekstu rozporządzenia i przewodników:
- 10 gru 2024 – wejście w życie rozporządzenia.
- 11 wrz 2026 – obowiązek raportowania (art. 14): aktywnie wykorzystywane podatności i poważne incydenty raportowane do ENISA z wczesnym ostrzeżeniem w 24 godziny.
- 11 gru 2027 – pełne stosowanie: secure-by-design, SBOM, ocena zgodności, dokumentacja techniczna i oznaczenie CE dla produktów wprowadzanych na rynek.
CRA klasyfikuje produkty w czterech kategoriach ryzyka (domyślna, ważna klasy I, ważna klasy II, krytyczna), a klasa determinuje ścieżkę oceny zgodności – w tym ewentualne zaangażowanie jednostki notyfikowanej. Kary sięgają 15 mln EUR lub 2,5% światowego rocznego obrotu.
CRA jest regulacją produktową i ciągłą zarazem: nie ocenia organizacji raz, lecz nakłada trwałe obowiązki – secure-by-design, obsługę podatności, monitoring po wprowadzeniu na rynek i transparentność SBOM – na cały cykl życia każdego produktu.
Gdzie PCI Secure SLC i CRA się pokrywają?
PCI Secure SLC i CRA pokrywają się w dwóch fundamentalnych obszarach: projektowaniu z bezpieczeństwem od początku (secure-by-design) i formalnej obsłudze podatności. Oba wymagają, by bezpieczeństwo było wbudowane w proces wytwórczy, a nie dodane po fakcie – i oba traktują zarządzanie podatnościami jako obowiązek ciągły.
Mapa wspólnych elementów:
| Obszar | PCI Secure SLC | CRA |
|---|---|---|
| Secure-by-design | Bezpieczna inżynieria: modelowanie zagrożeń, bezpieczne kodowanie, redukcja podatności | Wymóg projektowania z bezpieczną domyślną konfiguracją i odpornością przed wprowadzeniem na rynek |
| Obsługa podatności | Komunikacja bezpieczeństwa: kanał zgłaszania, triaging, wydawanie i dystrybucja poprawek | Formalny proces obsługi podatności z publiczną polityką ujawniania i terminowymi poprawkami |
| Governance i odpowiedzialność | Governance bezpieczeństwa oprogramowania: program, polityka, role | Odpowiedzialność producenta za bezpieczeństwo produktu przez cykl życia |
| Zarządzanie zmianą | Zarządzanie oprogramowaniem i danymi: kontrolowane zmiany i wydania | Wydawanie aktualizacji bezpieczeństwa przez okres wsparcia |
| Zarządzanie ryzykiem | Zarządzanie ryzykiem jako rutyna, dostosowywanie kontroli do zagrożeń | Ocena ryzyka cyberbezpieczeństwa jako podstawa spełnienia wymogów zasadniczych |
Wniosek praktyczny: dostawca ze zwalidowanym procesem Secure SLC ma już zbudowaną znaczną część fundamentów, których CRA wymaga jako obowiązku prawnego. Modelowanie zagrożeń, bezpieczne kodowanie, kanał zgłaszania podatności, kontrolowane wydania i zarządzanie ryzykiem to elementy oceniane w SLC i wymagane w CRA.
Secure SLC i CRA nie są konkurencyjnymi regulacjami, lecz dwoma spojrzeniami na to samo: SLC waliduje, że proces wytwórczy jest bezpieczny, a CRA wymaga tego samego jako warunku wprowadzenia produktu na rynek UE.
Czego CRA wymaga ponad to, co pokrywa SLC?
CRA idzie dalej niż Secure SLC w kilku obszarach, które dostawca musi domknąć osobno: SBOM w formacie maszynowym, terminowe raportowanie do ENISA, ocena zgodności zakończona oznaczeniem CE oraz dokumentacja techniczna przechowywana przez 10 lat. Zwalidowany proces SLC to fundament, ale nie komplet.
Obszary specyficzne dla CRA, których SLC nie pokrywa wprost:
- SBOM (Software Bill of Materials). CRA wymaga utrzymywania maszynowo czytelnego zestawienia komponentów produktu. To wykracza poza wymogi SLC – i w praktyce jest potrzebne wcześniej niż formalny termin, bo bez SBOM nie da się rzetelnie raportować podatności od wrz 2026.
- Raportowanie do ENISA w twardych terminach. Aktywnie wykorzystywane podatności i poważne incydenty raportowane z wczesnym ostrzeżeniem w 24 godziny i pełnym zgłoszeniem w 72 godziny. SLC wymaga procesu obsługi podatności, ale nie narzuca tych konkretnych terminów regulacyjnych ani kanału ENISA.
- Ocena zgodności i oznaczenie CE. CRA wymaga formalnej oceny zgodności (dla części klas z udziałem jednostki notyfikowanej), deklaracji zgodności UE i oznaczenia CE. To mechanizm regulacyjny, którego SLC nie zawiera.
- Dokumentacja techniczna przez 10 lat. CRA nakłada obowiązek prowadzenia dokumentacji technicznej (Annex VII) przechowywanej przez 10 lat od wprowadzenia produktu na rynek.
- Klasyfikacja produktu. CRA wymaga zaklasyfikowania każdego produktu do jednej z czterech kategorii ryzyka, co determinuje ścieżkę oceny – to logika produktowa nieobecna w SLC.
W praktyce oznacza to: SLC daje dojrzały proces wytwórczy i obsługę podatności, ale dostawca musi dołożyć warstwę SBOM, mechanizm raportowania regulacyjnego i formalną ścieżkę oceny zgodności CE. Dobra wiadomość: te elementy nadbudowuje się łatwiej na działającym procesie SLC niż od zera.
Jak certyfikacja PCI SLC wspiera przygotowanie do CRA?
Zwalidowany proces Secure SLC skraca drogę do zgodności z CRA, bo dostarcza gotowy, udokumentowany fundament secure-by-design i obsługi podatności – dwóch najbardziej pracochłonnych obszarów CRA. Zamiast budować te praktyki od zera pod presją terminów regulacyjnych, dostawca rozbudowuje istniejący, oceniony proces.
Konkretne dźwignie, które daje SLC:
- Gotowy secure-by-design. Modelowanie zagrożeń i bezpieczne kodowanie ocenione w SLC to bezpośredni dowód praktyk, których CRA wymaga przed wprowadzeniem produktu na rynek.
- Działający proces podatności. Kanał zgłaszania, triaging i dystrybucja poprawek z SLC to szkielet, na którym buduje się raportowanie CRA – wystarczy dołożyć terminy ENISA i integrację z jej platformą.
- Governance i odpowiedzialność. Formalny program i przypisane role z SLC odpowiadają na wymóg odpowiedzialności producenta w CRA.
- Zarządzanie zmianą i wydaniami. Kontrolowane wydania z SLC wspierają obowiązek wydawania aktualizacji bezpieczeństwa przez okres wsparcia.
- Kultura dowodów. Dostawca przyzwyczajony do dokumentowania praktyk na potrzeby oceny SLC łatwiej zbuduje dokumentację techniczną wymaganą przez CRA.
Warto jednak zachować precyzję: certyfikacja PCI SLC nie jest oceną zgodności CRA i jej nie zastępuje. CRA ma własny mechanizm (deklaracja zgodności, oznaczenie CE, dla części klas jednostka notyfikowana). SLC jest fundamentem operacyjnym i dowodowym, który znacząco skraca przygotowanie – ale formalną zgodność z CRA trzeba osiągnąć osobno, jej własną ścieżką.
Patronusec Insight: Z naszego doświadczenia projektowego wynika, że dostawcy oprogramowania najczęściej podchodzą do SLC i CRA jak do dwóch niezależnych projektów, dublując pracę. Tymczasem secure-by-design i obsługa podatności to ten sam fundament – raz zbudowany, obsługuje oba reżimy. Rekomendujemy planować je razem: jeśli i tak budujesz proces pod SLC, zaprojektuj go od początku tak, by dokumentacja i kanał podatności spełniały również wymogi CRA (SBOM, terminy ENISA). To różnica między jednym projektem a dwoma.
Jak zaplanować wspólną ścieżkę SLC i CRA?
Wspólną ścieżkę planuje się od mapy pokrycia: najpierw ustala się, które wymogi CRA pokrywa istniejący lub planowany proces SLC, a potem domyka lukę specyficzną dla CRA (SBOM, raportowanie, ocena zgodności). Kolejność zależy od tego, co dostawca ma już wdrożone.
Rekomendowana sekwencja:
- Mapa pokrycia SLC-CRA – zestawienie czterech obszarów SLC z wymogami zasadniczymi CRA; identyfikacja, co jest wspólne, a co specyficzne dla CRA.
- Budowa lub walidacja procesu SLC – jeśli proces jeszcze nie istnieje, buduje się go z myślą o obu reżimach naraz (dokumentacja i kanał podatności od razu pod CRA).
- Domknięcie warstwy CRA – SBOM w formacie maszynowym, mechanizm raportowania do ENISA z terminami 24/72 godziny, klasyfikacja produktów i ścieżka oceny zgodności.
- Dokumentacja techniczna i CE – kompletowanie dokumentacji (Annex VII), deklaracja zgodności UE, oznaczenie CE zgodnie z klasą produktu.
- Utrzymanie – coroczna atestacja SLC i ciągłe obowiązki CRA (monitoring po wprowadzeniu na rynek, raportowanie) jako jeden zintegrowany proces.
Praktyczny wyznacznik terminów: obowiązek raportowania CRA rusza 11 wrz 2026, więc kanał podatności i SBOM potrzebne są wcześniej. Pełne stosowanie od 11 gru 2027 oznacza, że ocenę zgodności i CE trzeba mieć przygotowane z wyprzedzeniem – jednostki notyfikowane mają kolejki, a przygotowanie zajmuje zwykle 18-24 miesiące.
Patronusec pomaga dostawcom zbudować tę wspólną ścieżkę w ramach usług PCI SLC oraz doradztwa zgodności – tak, by jeden proces obsługiwał oba reżimy zamiast dublować pracę.
FAQ – PCI SLC a CRA
Czy certyfikacja PCI SLC zapewnia zgodność z CRA?
Nie. PCI SLC waliduje proces wytwórczy i pokrywa znaczną część fundamentów CRA (secure-by-design, obsługa podatności), ale nie jest oceną zgodności CRA i jej nie zastępuje. CRA ma własny mechanizm: deklarację zgodności UE, oznaczenie CE i – dla części klas produktów – udział jednostki notyfikowanej. SLC skraca przygotowanie, ale zgodność CRA osiąga się osobno.
Od kiedy obowiązują wymogi CRA?
CRA weszło w życie 10 gru 2024. Obowiązki raportowania podatności (art. 14) zaczynają obowiązywać 11 wrz 2026, z wczesnym ostrzeżeniem do ENISA w 24 godziny. Pełne stosowanie – secure-by-design, SBOM, ocena zgodności, dokumentacja techniczna i oznaczenie CE – obowiązuje od 11 gru 2027 dla produktów wprowadzanych na rynek UE.
Które wymogi CRA pokrywa proces SLC?
Przede wszystkim secure-by-design (modelowanie zagrożeń, bezpieczne kodowanie) i obsługę podatności (kanał zgłaszania, triaging, poprawki), a także governance, zarządzanie zmianą i zarządzanie ryzykiem. To najbardziej pracochłonne obszary CRA – zwalidowany proces SLC dostarcza dla nich gotowy, udokumentowany fundament.
Czego CRA wymaga ponad SLC?
SBOM w formacie maszynowym, raportowania aktywnie wykorzystywanych podatności do ENISA w twardych terminach (24/72 godziny), formalnej oceny zgodności zakończonej oznaczeniem CE, dokumentacji technicznej przechowywanej 10 lat oraz klasyfikacji produktu do jednej z czterech kategorii ryzyka. To warstwa regulacyjno-produktowa, której SLC nie zawiera.
Czy CRA dotyczy dostawców spoza UE?
Tak. Producenci spoza UE są objęci CRA, jeśli ich produkty z elementami cyfrowymi trafiają na rynek unijny. Rozporządzenie jest regulacją produktową – liczy się to, czy produkt jest udostępniany na rynku UE, a nie gdzie ma siedzibę producent. Dostawcy globalni planują zgodność niezależnie od lokalizacji.
Jak Patronusec pomaga połączyć SLC i CRA?
Zaczynamy od mapy pokrycia SLC-CRA: pokazujemy, które wymogi CRA pokrywa istniejący lub planowany proces SLC, a co trzeba domknąć osobno (SBOM, raportowanie, CE). Następnie pomagamy zaprojektować jeden proces obsługujący oba reżimy. Po bezpłatnej rozmowie scope-assessment przedstawiamy stałą wycenę.
Warto przeczytać
Ścieżka lektury dla tematu zgodności oprogramowania:
- Proces developerski zgodny ze standardem PCI Secure SLC – fundament: jak zbudować zwalidowany proces wytwórczy.
- PCI SLC jako przewaga konkurencyjna dla software house – biznesowa wartość SLC, w tym w kontekście CRA.
- PCI SSF v2.0 a v1.2.1 – co zmienia się dla dostawcy oprogramowania płatniczego – drugi standard ramy SSF.
- NIS2 – kontekst regulacyjny – szerszy krajobraz unijnych regulacji cyberbezpieczeństwa.
PCI SLC a CRA – bezpłatna konsultacja
Patronusec jako akredytowany QSA pomaga dostawcom oprogramowania wykorzystać zwalidowany proces PCI SLC jako fundament przygotowania do CRA. W bezpłatnej 30-minutowej konsultacji zbudujemy wstępną mapę pokrycia SLC-CRA dla Twojej organizacji.
Umów konsultację | PCI SLC | NIS2 | DORA
