Cyber Resilience Act (CRA) a TYPO3 co musi wiedzieć każdy właściciel strony
Nowe unijne rozporządzenie o cyberodporności zmienia zasady gry dla oprogramowania w UE — w tym dla open source. Wyjaśniamy, czego CRA wymaga, kogo dotyczy, jakie są terminy i co oznacza dla stron opartych na TYPO3
W skrócie
Co to jest:
Cyber Resilience Act (CRA) to rozporządzenie UE 2024/2847 wprowadzające obowiązkowe wymogi cyberbezpieczeństwa dla „produktów z elementami cyfrowymi” — czyli sprzętu i oprogramowania sprzedawanego na rynku UE. Weszło w życie 10 grudnia 2024 r.
Kluczowe terminy:
11 czerwca 2026 — zasady dla jednostek oceniających zgodność. 11 września 2026 — start obowiązkowego raportowania aktywnie wykorzystywanych podatności. 11 grudnia 2027 — pełne stosowanie wszystkich wymogów.
Kogo dotyczy:
Producentów, importerów i dystrybutorów oprogramowania komercyjnego — a po raz pierwszy w prawie UE również „opiekunów oprogramowania open source” (open-source stewards).
TYPO3 a CRA:
TYPO3 Association pełni rolę opiekuna (stewarda) TYPO3 i 11 czerwca 2026 dołączyło do Open Regulatory Compliance Working Group przy Eclipse Foundation, by przygotować ekosystem na CRA.
Kary:
Do 15 mln EUR lub 2,5% globalnego rocznego obrotu — w zależności od tego, która kwota jest wyższa.
Po RODO i NIS2 do europejskiego krajobrazu regulacyjnego dołącza kolejny akt o dużym znaczeniu: Cyber Resilience Act, czyli akt o cyberodporności. W odróżnieniu od RODO (które chroni dane osobowe) i NIS2 (które dotyczy podmiotów kluczowych i ważnych), CRA reguluje coś innego: bezpieczeństwo samych produktów cyfrowych — oprogramowania i sprzętu — przez cały cykl ich życia. To pierwszy taki horyzontalny akt w UE i już teraz wywołuje dużo pytań w świecie open source, w tym w społeczności TYPO3.
W tym artykule wyjaśniamy, czym jest CRA, jakie są jego terminy, kogo dotyczy, co oznacza pojęcie „opiekuna oprogramowania open source”, jak TYPO3 przygotowuje się na nowe wymogi — i co to wszystko znaczy w praktyce dla Ciebie, jeśli prowadzisz lub zlecasz stronę opartą na TYPO3. Zaznaczamy od razu: nie jesteśmy kancelarią prawną, a ten tekst ma charakter informacyjny. Wiążącą interpretację zawsze daje oryginalny tekst rozporządzenia i porada prawna dostosowana do Twojej sytuacji.
Czym jest Cyber Resilience Act
Cyber Resilience Act to rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/2847. Jego cel jest prosty do opisania, choć ambitny w skutkach: poprawić cyberbezpieczeństwo produktów cyfrowych dostępnych na rynku UE i sprawić, by producenci odpowiadali za bezpieczeństwo swoich produktów przez cały cykl życia — od projektu, przez rozwój, aż po utrzymanie i wycofanie.
CRA dotyczy „produktów z elementami cyfrowymi” (products with digital elements). To szeroka definicja obejmująca oprogramowanie, sprzęt oraz rozwiązania do zdalnego przetwarzania danych, które są częścią produktu. W praktyce CRA dotyka niemal każdego oprogramowania, które jest udostępniane komercyjnie na rynku UE — od systemów operacyjnych, przez aplikacje, po komponenty i biblioteki.
Bezpieczeństwo w fazie projektowania (security by design)Produkt ma być projektowany i rozwijany z uwzględnieniem cyberbezpieczeństwa, bez znanych podatności w momencie wprowadzenia na rynek
Zarządzanie podatnościami przez cały cykl życiaProducent musi wykrywać, łatać i komunikować podatności, oraz określić „okres wsparcia” (support period) produktu
Raportowanie i przejrzystośćObowiązek zgłaszania aktywnie wykorzystywanych podatności i poważnych incydentów oraz dostarczania użytkownikom dokumentacji i instrukcji
Ważny szczegół: CRA wprowadza wymóg udostępniania tzw. SBOM (Software Bill of Materials) — listy komponentów, z których zbudowane jest oprogramowanie, włącznie z zależnościami. Bez wiedzy o tym, co dokładnie zawiera produkt, nie da się zgłosić podatności w wymaganym czasie. To znacząca zmiana w sposobie myślenia o oprogramowaniu jako łańcuchu dostaw.
Terminy CRA kiedy co zaczyna obowiązywać
CRA wchodzi w życie etapami. To dobra wiadomość — jest czas na przygotowanie — ale też pułapka, bo niektóre obowiązki zaczynają działać wcześniej, niż wielu się spodziewa. Oto kluczowe daty:
10 grudnia 2024 - Wejście w życie
Rozporządzenie stało się obowiązującym prawem w całej UE. Rozpoczęły się okresy przejściowe: 21 miesięcy do obowiązków raportowania i 36 miesięcy do pełnego stosowania.
11 czerwca 2026 - Jednostki oceniające zgodność
Zaczynają obowiązywać przepisy o notyfikacji jednostek oceniających zgodność (Rozdział IV). Państwa członkowskie wyznaczają organy odpowiedzialne za certyfikację. To nie jest termin dla producentów — to budowanie infrastruktury oceny.
11 września 2026 - Start obowiązkowego raportowania
Najpilniejszy termin. Zaczyna obowiązywać obowiązek raportowania aktywnie wykorzystywanych podatności i poważnych incydentów (art. 14). Dotyczy wszystkich produktów objętych zakresem CRA, które są już na rynku UE — również tych wprowadzonych wcześniej. Zgłoszenie do ENISA w 24 godziny.
11 grudnia 2027 - Pełne stosowanie
Wszystkie pozostałe obowiązki CRA stają się w pełni wymagalne. Nowe produkty wprowadzane na rynek od tej daty muszą spełniać pełne wymogi: ocenę zgodności, oznakowanie CE, dokumentację techniczną i wymogi bezpieczeństwa z Załącznika I.
Najważniejszy wniosek z tego harmonogramu: chociaż pełne stosowanie przypada na grudzień 2027, obowiązek raportowania podatności startuje już 11 września 2026 i obejmuje również produkty już obecne na rynku. Dla producentów oprogramowania oznacza to konieczność zbudowania procesów monitorowania i zgłaszania podatności na długo przed pełnym wejściem w życie.
Open source pod lupą nowa rola „opiekuna”
CRA wprowadza coś, czego wcześniej w prawie europejskim nie było: pojęcie opiekuna oprogramowania open source (open-source software steward). To organizacja, która wspiera i utrzymuje projekt open source w czasie — poprzez zarządzanie (governance), infrastrukturę, zarządzanie wydaniami, koordynację bezpieczeństwa lub finansowanie.
To ważne rozróżnienie. CRA nie traktuje pojedynczego dewelopera, który publikuje swoją bibliotekę na GitHubie za darmo, tak samo jak komercyjnego producenta oprogramowania. Między tymi dwoma krańcami ustawodawca umieścił właśnie opiekuna — organizację, która w sposób zorganizowany i trwały dba o projekt open source wykorzystywany komercyjnie. Opiekunowie mają lżejszy zestaw obowiązków niż komercyjni producenci, ale nie są z CRA wyłączeni.
W ekosystemie TYPO3 tę rolę opiekuna pełni TYPO3 Association — stowarzyszenie, które od lat odpowiada za zarządzanie projektem, koordynację bezpieczeństwa (przez Security Team), wydania i finansowanie rozwoju. To właśnie dlatego CRA dotyczy TYPO3 nie jako abstrakcyjnego oprogramowania, ale jako konkretnego ekosystemu z odpowiedzialnym opiekunem.
Jak TYPO3 przygotowuje się na CRA
Społeczność TYPO3 nie czeka z założonymi rękami. W ostatnich miesiącach widać konkretne kroki w stronę gotowości na CRA.
Compliance Officer w strukturze Association
Na początku 2026 roku TYPO3 Association powołało nową rolę Compliance Officer, którą objęła Rachel Foucard. Funkcja została celowo umiejscowiona poza Zarządem, by zapewnić niezależność. Jej zakres to między innymi zgodność etyczna i prawna, europejskie regulacje cyfrowe, procesy zarządzania, przejrzystość oraz długoterminowa stabilność ekosystemu — a więc dokładnie te obszary, których dotyka CRA.
Członkostwo w Open Regulatory Compliance Working Group
11 czerwca 2026 TYPO3 Association ogłosiło dołączenie do Open Regulatory Compliance (ORC) Working Group — grupy roboczej hostowanej przez Eclipse Foundation. ORC zrzesza fundacje open source, producentów, dostawców, badaczy i przedstawicieli branży, którzy wspólnie pracują nad praktycznymi podejściami do zgodności regulacyjnej w ekosystemach open source.
Jak wyjaśnia Rachel Foucard w ogłoszeniu: żaden projekt open source nie powinien próbować nawigować tych tematów samotnie. ORC daje dostęp do rzetelnych informacji, praktycznej wiedzy eksperckiej i przestrzeni do współpracy — miejsca, gdzie organizacje open source mogą wymieniać się konkretnym doświadczeniem i wspólnie budować realistyczne interpretacje złożonych wymogów regulacyjnych. Dla TYPO3 dołączenie do ORC było, jak to ujęto, „naturalnym kolejnym krokiem”.
CRA, NIS2 i RODO jak to się ze sobą łączy?
Trzy europejskie regulacje często mylą się ze sobą, bo wszystkie dotykają cyberbezpieczeństwa. Różnią się jednak tym, CO i KOGO regulują.
RODO Chroni dane osobowe
RODO dotyczy przetwarzania danych osobowych. Wymaga środków technicznych i organizacyjnych chroniących dane (art. 32), w tym szyfrowania. Podmiotem odpowiedzialnym jest administrator danych. Dotyczy praktycznie każdej organizacji, która przetwarza dane osób fizycznych.
NIS2 Chroni podmioty kluczowe i ważne
NIS2 (w Polsce wdrażana nowelizacją ustawy o KSC) dotyczy organizacji — podmiotów kluczowych i ważnych w określonych sektorach, jak ochrona zdrowia, administracja publiczna, energetyka. Wymaga wdrożenia środków zarządzania ryzykiem cyberbezpieczeństwa na poziomie całej organizacji.
CRA Chroni produkty cyfrowe
CRA dotyczy produktów — oprogramowania i sprzętu wprowadzanego na rynek. Podmiotem odpowiedzialnym jest producent (lub importer, dystrybutor, opiekun open source). To różnica względem NIS2: NIS2 patrzy na organizację, CRA patrzy na produkt. Co ważne, CRA jawnie uzupełnia NIS2 — nie zastępuje jej, lecz działa na innej warstwie łańcucha dostaw.
Dla typowej organizacji — powiedzmy szpitala z portalem pacjenta na TYPO3 — te trzy regulacje nakładają się warstwowo. RODO chroni dane pacjentów w formularzach. NIS2 wymaga od szpitala (jako podmiotu) zarządzania ryzykiem cyber. CRA dotyczy producentów oprogramowania, którego szpital używa — w tym CMS, rozszerzeń i komponentów. Zrozumienie, która regulacja dotyczy której warstwy, jest pierwszym krokiem do świadomego compliance.
Co to oznacza dla Twojej strony TYPO3 W praktyce
Najczęstsze pytanie brzmi: „czy jako właściciel strony na TYPO3 muszę sam spełniać wymogi CRA?”. Odpowiedź wymaga rozróżnienia ról.
Jeśli jesteś właścicielem strony (użytkownikiem TYPO3)
Sama strona internetowa zbudowana na TYPO3 zwykle nie czyni Cię „producentem produktu z elementami cyfrowymi” w rozumieniu CRA — jesteś użytkownikiem oprogramowania, nie jego producentem wprowadzającym je na rynek. Obowiązki CRA spoczywają głównie na producentach oprogramowania (w tym opiekunie TYPO3) i twórcach komercyjnych rozszerzeń. To jednak nie znaczy, że CRA Cię nie dotyczy pośrednio.
CRA realnie wpłynie na Ciebie przez łańcuch dostaw. Oprogramowanie, którego używasz, będzie musiało spełniać wymogi — a to przekłada się na wymagania wobec Twoich dostawców: agencji, hostingu, twórców rozszerzeń. Warto już dziś pytać partnerów technologicznych, jak przygotowują się na CRA.
Jeśli tworzysz lub sprzedajesz rozszerzenia TYPO3
Tu sytuacja jest poważniejsza. Jeśli tworzysz komercyjne rozszerzenia TYPO3 i wprowadzasz je na rynek UE, możesz być traktowany jako producent w rozumieniu CRA — ze wszystkimi obowiązkami: security by design, zarządzanie podatnościami, SBOM, raportowanie, dokumentacja. To dotyczy również nas jako twórców własnych rozwiązań, dlatego śledzimy ten temat na bieżąco.
Co warto zrobić już teraz
✓ Zinwentaryzuj oprogramowanie swojej strony — wersja TYPO3, lista rozszerzeń, komponenty, zależności (zalążek SBOM)
✓ Upewnij się, że używasz wspieranej wersji TYPO3 — oprogramowanie bez wsparcia bezpieczeństwa jest sprzeczne z duchem CRA i NIS2
✓ Zapytaj dostawców (agencja, hosting, twórcy rozszerzeń), jak przygotowują się na CRA i czy zapewniają okres wsparcia
✓ Wdróż proces zarządzania podatnościami — monitorowanie advisories, regularne aktualizacje, dokumentacja łatek
✓ Jeśli podlegasz też NIS2 — zsynchronizuj procesy; raportowanie podatności i zarządzanie ryzykiem częściowo się pokrywają
Kary i konsekwencje
CRA, podobnie jak RODO i NIS2, ma zęby. Maksymalna kara za niezgodność z najpoważniejszymi obowiązkami to do 15 mln EUR lub 2,5% globalnego rocznego obrotu — w zależności od tego, która kwota jest wyższa. To poziom porównywalny z RODO i wystarczająco wysoki, by potraktować temat poważnie.
Warto jednak zachować proporcje. CRA nie jest stworzony po to, by karać małe firmy prowadzące strony internetowe. Jego celem są producenci oprogramowania, którzy zaniedbują bezpieczeństwo swoich produktów. Dla większości właścicieli stron TYPO3 najważniejsze będzie świadome zarządzanie łańcuchem dostaw i współpraca z odpowiedzialnymi dostawcami — a nie samodzielne przechodzenie oceny zgodności.
Najczęściej zadawane pytania
Sama strona internetowa zwykle nie czyni Cię producentem produktu z elementami cyfrowymi w rozumieniu CRA — jesteś użytkownikiem oprogramowania. Główne obowiązki spoczywają na producentach oprogramowania (w tym opiekunie TYPO3) i twórcach komercyjnych rozszerzeń. CRA wpłynie na Ciebie pośrednio — przez wymagania wobec Twoich dostawców. Wiążącą ocenę w Twoim konkretnym przypadku daje prawnik.
NIS2 reguluje organizacje — podmioty kluczowe i ważne (szpitale, gminy, energetyka) — i wymaga od nich zarządzania ryzykiem cyber na poziomie całej organizacji. CRA reguluje produkty — oprogramowanie i sprzęt — i nakłada obowiązki na ich producentów. NIS2 patrzy na organizację, CRA na produkt. Obie regulacje się uzupełniają.
Nie całkowicie. CRA wprowadził rozróżnienie: pojedynczy deweloper publikujący darmowy kod ma inne (lżejsze) traktowanie niż komercyjny producent. Między nimi jest „opiekun oprogramowania open source” (np. TYPO3 Association) z własnym, lżejszym niż producent, ale niezerowym zestawem obowiązków. Oprogramowanie open source wykorzystywane komercyjnie nie jest więc po prostu wyłączone.
SBOM (Software Bill of Materials) to lista wszystkich komponentów i zależności, z których zbudowane jest oprogramowanie. CRA wymaga go od producentów — bez wiedzy o tym, co zawiera produkt, nie da się zgłosić podatności w wymaganym czasie. Jeśli jesteś właścicielem strony, nie musisz formalnie tworzyć SBOM, ale inwentaryzacja Twojego oprogramowania (wersja TYPO3, rozszerzenia) to dobra praktyka i punkt wyjścia.
Kluczowe daty: 11 września 2026 — start obowiązkowego raportowania podatności (dotyczy producentów, też dla produktów już na rynku). 11 grudnia 2027 — pełne stosowanie dla nowych produktów. Jeśli jesteś właścicielem strony, nie masz własnego „twardego terminu”, ale warto wykorzystać ten czas na uporządkowanie łańcucha dostaw i procesów aktualizacji.
Bardzo bezpośrednio. CRA kładzie nacisk na zarządzanie podatnościami przez cały cykl życia. TYPO3 ma własny Security Team publikujący advisories i regularne wydania bezpieczeństwa — to dokładnie ten typ procesu, którego CRA oczekuje. Dla Ciebie jako użytkownika oznacza to, że regularne instalowanie aktualizacji TYPO3 i utrzymywanie wspieranej wersji to nie tylko dobra praktyka, ale element zgodności z duchem nowych regulacji.
July 2026 in TYPO3 — monthly round-up
TYPO3: Hacked or Vulnerable? Immediate help and a checklist
Securing TYPO3: 10 measures to prevent security vulnerabilities
Czerwiec 2026 w TYPO3 — 14 podatności, fala rozszerzeń AI i logowanie bez hasła
Jak możemy pomóc
CRA to kolejna warstwa regulacyjna, która — obok NIS2 i RODO — podnosi poprzeczkę dla bezpieczeństwa stron internetowych. Jako agencja wyspecjalizowana w TYPO3, z naciskiem na bezpieczeństwo i compliance, możemy pomóc:
✓ Inwentaryzacja oprogramowania strony — wersja TYPO3, rozszerzenia, zależności (zalążek SBOM) i ocena gotowości
✓ Aktualizacja do wspieranej wersji TYPO3 i wdrożenie procesu regularnych aktualizacji bezpieczeństwa
✓ Wdrożenie zarządzania podatnościami — monitorowanie advisories, dokumentacja łatek pod audyt NIS2 i CRA
✓ Doradztwo przy wyborze rozszerzeń — dojrzałe, utrzymywane projekty z jasnym okresem wsparcia
✓ Stała umowa utrzymaniowa z gwarantowaną reakcją na advisories TYPO3 Security Team
Telefon: 12 333 44 01. Email: [email protected]. Zaznaczamy, że świadczymy usługi techniczne, a nie doradztwo prawne — w kwestiach interpretacji CRA w Twojej konkretnej sytuacji warto skonsultować się z prawnikiem specjalizującym się w prawie nowych technologii.
