Art. 13 ust. 8 unijnego Cyber Resilience Act (rozporządzenie (UE) 2024/2847) zobowiązuje producentów do dostarczania aktualizacji bezpieczeństwa bezpłatnie i bez zbędnej zwłoki przez cały okres wsparcia. Niniejsza strona omawia mechanikę dostarczania aktualizacji dla architektur wbudowanych, samodzielnych, SaaS i hybrydowych. Informacje o mechanice czasu trwania okresu wsparcia znajdziesz w artykule Podstawy okresu wsparcia CRA; informacje o ujawnianiu daty zakończenia wsparcia przed zakupem znajdziesz w artykule Ujawnianie daty zakończenia wsparcia CRA.
Podsumowanie
- Aktualizacje bezpieczeństwa to nie aktualizacje funkcjonalne. Zmiana usuwająca podatność podlega regułom kosztowym i harmonogramowym z art. 13 ust. 8; zmiana dodająca nowe możliwości -- już nie.
- Bezpłatnie na podstawie art. 13 ust. 8. Producenci nie mogą bundlować poprawek bezpieczeństwa w płatnych subskrypcjach, pakietach premium ani płatnych uaktualnieniach do nowej wersji głównej.
- Automatycznie tam, gdzie to możliwe, zgodnie z Załącznikiem I Część II. Lit. 7 wymaga bezpiecznych mechanizmów dystrybucji z automatycznym dostarczaniem tam, gdzie ma to zastosowanie; lit. 8 wymaga niezwłocznego udostępniania aktualizacji.
- "Bez zbędnej zwłoki" zależy od poziomu ważności. Branżowe standardy zakładają: kilka dni dla aktywnie wykorzystywanych krytycznych podatności, 30 dni dla podatności wysokiego ryzyka, 90 dni dla średniego ryzyka oraz najbliższy regularny cykl aktualizacji dla podatności niskiego ryzyka.
- Architektura produktu determinuje model dostarczania. Wbudowane oprogramowanie układowe, samodzielne oprogramowanie, SaaS i produkty hybrydowe mają odrębną mechanikę aktualizacji, którą plik techniczny musi dokumentować.
- Art. 14 dotyczący zgłaszania podatności wchodzi w interakcję z cyklem życia aktualizacji. Gdy zostanie wykryta aktywnie wykorzystywana podatność, 24-godzinny termin wczesnego ostrzeżenia do ENISA biegnie równolegle z procesem łatania; mechanizm aktualizacji musi być zintegrowany z procesem zgłaszania, a nie stanowić odrębny krok następujący po nim.
Cztery filary zgodności z CRA w zakresie aktualizacji bezpieczeństwa: reguła kosztowa, preferowana dystrybucja, oczekiwany harmonogram oraz pułap kary.
Pobieranie opłat za aktualizacje bezpieczeństwa to jeden z najbardziej bezpośrednich sposobów na stwierdzenie niezgodności. Jeżeli poprawka usuwająca podatność jest dostępna wyłącznie dla klientów płatnego pakietu wsparcia, za płatną subskrypcją lub w ramach uaktualnienia do nowej wersji głównej oferowanego odpłatnie, takie rozwiązanie nie spełnia wymagań art. 13 ust. 8. Podstawowe łatki bezpieczeństwa muszą być dostępne dla wszystkich użytkowników produktu wprowadzonego na rynek, bez żadnych dodatkowych kosztów, przez cały okres wsparcia. Wydania nowych funkcji, usługi profesjonalne oraz opcjonalne możliwości nadal mogą być oferowane odpłatnie. Granicą jest to, czy dana zmiana usuwa podatność.
Co kwalifikuje się jako aktualizacja bezpieczeństwa
Art. 13 ust. 2 CRA zobowiązuje producentów do projektowania i wytwarzania produktów, które są "bezpieczne domyślnie" i zapewniają "poufność, integralność i dostępność danych". Art. 13 ust. 8 wymaga następnie, aby podatności wykryte po wprowadzeniu na rynek były obsługiwane przez cały okres wsparcia.
Aktualizacja bezpieczeństwa w rozumieniu CRA to zmiana usuwająca podatność, czyli słabość produktu, która mogłaby zostać wykorzystana do naruszenia poufności, integralności lub dostępności. Rozróżnienie od aktualizacji funkcjonalnej ma znaczenie z dwóch powodów: aktualizacje bezpieczeństwa muszą być bezpłatne i dostarczone bez zbędnej zwłoki, natomiast aktualizacje funkcjonalne nie podlegają żadnemu z tych obowiązków.
| Rodzaj aktualizacji | Obowiązek z art. 13 ust. 8 | Może być płatna? |
|---|---|---|
| Łatka naprawiająca znane CVE | Tak (aktualizacja bezpieczeństwa) | Nie |
| Zmiana wzmacniająca zabezpieczenia i zmniejszająca powierzchnię ataku | Tak (aktualizacja bezpieczeństwa) | Nie |
| Nowa funkcja bez znaczenia dla bezpieczeństwa | Nie | Tak |
| Nowa wersja główna z nowymi możliwościami | Nie (chyba że zawiera poprawki bezpieczeństwa) | Tak |
| Aktualizacja zależności eliminująca znane CVE | Tak (aktualizacja bezpieczeństwa) | Nie |
| Zmiana konfiguracji zamykająca lukę bezpieczeństwa | Tak (aktualizacja bezpieczeństwa) | Nie |
"Bez zbędnej zwłoki" nie jest zdefiniowane numerycznie w rozporządzeniu, jednak ogólne oczekiwania organów nadzoru rynku i wytycznych ENISA są zgodne z praktyką branżową opartą na poziomie ważności. Poniższy diagram przedstawia okno łatania dla każdego poziomu ważności, mierzone od momentu ujawnienia podatności (T0):
| Poziom ważności | Branżowe oczekiwanie |
|---|---|
| Krytyczny (aktywnie wykorzystywany) | Dni, nie tygodnie |
| Wysoki (łatwy do zdalnego wykorzystania) | W ciągu 30 dni |
| Średni | W ciągu 90 dni |
| Niski | Włączony do następnego regularnego cyklu aktualizacji |
Nie są to terminy wymagane przez CRA, lecz standard, według którego "bez zbędnej zwłoki" będzie oceniane w postępowaniach egzekucyjnych.
Jak dostarczać aktualizacje bezpieczeństwa zgodne z CRA
Aktualizacje automatyczne
Tam, gdzie jest to technicznie wykonalne i właściwe, art. 13 ust. 8 i Załącznik I Część II preferują automatyczne aktualizacje bezpieczeństwa. Produkt powinien być zdolny do odbierania i stosowania aktualizacji bez konieczności podejmowania ręcznych działań przez użytkownika.
Wymagania dla zgodnego mechanizmu automatycznych aktualizacji:
- Bezpieczny kanał pobierania (TLS, podpisane pakiety)
- Weryfikacja integralności przed instalacją
- Możliwość wycofania aktualizacji w razie niepowodzenia
- Obsługa problemów z łącznością
- Widoczność stanu aktualizacji dla użytkownika
Użytkownik musi zachować możliwość rezygnacji z automatycznych aktualizacji, z wyraźnym ostrzeżeniem o konsekwencjach bezpieczeństwa takiej decyzji. W przypadku krytycznych aktualizacji bezpieczeństwa producent może zaprojektować system tak, aby stosował aktualizację bez możliwości odroczenia. Art. 13 ust. 8 dopuszcza takie rozwiązanie, gdy ryzyko je uzasadnia.
Aktualizacje ręczne
Produkty, które nie mogą otrzymywać automatycznych aktualizacji (przemysłowe systemy izolowane od sieci, urządzenia wbudowane bez łączności, niektóre urządzenia medyczne lub o krytycznym znaczeniu dla bezpieczeństwa), wymagają ręcznego procesu dostarczania aktualizacji:
- Pobieralne pakiety aktualizacji z przejrzystym wersjonowaniem
- Podpisy kryptograficzne i opublikowane klucze publiczne do weryfikacji
- Dokumentacja instalacyjna
- Powiadomienia wszystkimi dostępnymi kanałami (e-mail, portal internetowy, interfejs produktu, powiadomienie fizyczne w razie konieczności)
Wbudowane i SaaS: odmienne modele aktualizacji
Mechanizm dostarczania aktualizacji różni się istotnie w zależności od architektury produktu:
| Typ produktu | Model aktualizacji | Kluczowa kwestia CRA |
|---|---|---|
| Wbudowane oprogramowanie układowe (IoT, przemysłowe) | Producent przesyła podpisane oprogramowanie układowe; klient stosuje | Musi posiadać możliwość OTA lub udokumentowany proces ręczny; długi czas użytkowania urządzeń może zbliżać oczekiwany okres użytkowania do pięciu lat |
| Samodzielne oprogramowanie (desktopowe, serwerowe) | Producent publikuje pakiet; klient instaluje | Preferowany automatyczny agent aktualizacji; blokowanie wersji przez klientów korporacyjnych tworzy obciążenie obsługą wielu wersji |
| SaaS / chmura | Producent kontroluje środowisko; aktualizacje są przezroczyste dla użytkownika | Zegar nadal startuje w momencie wprowadzenia na rynek; okres wsparcia ma znaczenie głównie dla komponentów lokalnych lub hybrydowych; wersjonowanie API tworzy własne zobowiązania wsparcia |
| Hybrydowy (agent lokalny + backend chmurowy) | Aktualizacje agenta są kontrolowane przez producenta; aktualizacje backendu są przezroczyste | Każdy komponent ma własny zegar okresu wsparcia; agent jest produktem z elementami cyfrowymi i to jego zegar obowiązuje |
Informacje o szerszej obsłudze podatności w ramach Załącznika I Część II wykraczającej poza dostarczanie aktualizacji (polityka CVD, publiczne ujawnianie, zgłaszanie przez strony trzecie) znajdziesz w przewodniku po obsłudze podatności.
Obowiązki zgłaszania podatności w trakcie i po zakończeniu okresu wsparcia
Art. 14 nakłada na producentów terminowe obowiązki zgłaszania aktywnie wykorzystywanych podatności i poważnych incydentów. Obowiązki te stosuje się w trakcie okresu wsparcia.
Kluczowa interakcja:
| Faza | Obowiązek zgłaszania z art. 14 |
|---|---|
| W trakcie okresu wsparcia | Art. 14 stosuje się w pełni: wczesne ostrzeżenie w ciągu 24 godzin, powiadomienie w ciągu 72 godzin, raport końcowy w ciągu 14 dni dla aktywnie wykorzystywanych podatności; 24h / 72h / 1 miesiąc dla poważnych incydentów. Za pośrednictwem jednolitej platformy zgłaszania ENISA. |
| Po zakończeniu okresu wsparcia | Brak obowiązku zgłaszania z art. 14 dla podatności wykrytych po zakończeniu wsparcia. Jeżeli producent dowie się o krytycznej, aktywnie wykorzystywanej podatności w nieobsługiwanym produkcie dotykającej znacznej zainstalowanej bazy, nie ma obowiązku zgłaszania. Odpowiedzialne ujawnienie i powiadomienie użytkowników są zdecydowanie zalecane ze względów reputacyjnych i współpracy z organami nadzoru rynku. |
Data zakończenia okresu wsparcia jest zatem również horyzontem z art. 14. Po wygaśnięciu okresu wsparcia producent nie ma obowiązku badania, łatania ani zgłaszania podatności wykrytych w tej wersji produktu. Organy nadzoru rynku mogą nadal prowadzić dochodzenia na podstawie art. 58, jeżeli produkt stwarza znaczące ryzyko cyberbezpieczeństwa, jednak bieżący obowiązek zarządzania podatnościami wynikający z art. 13 ust. 8 wygasł.
Pełną mechanikę terminów z art. 14, w tym co każde zgłoszenie musi zawierać oraz jak różnią się dwa strumienie zgłaszania (aktywnie wykorzystywane podatności i poważne incydenty), znajdziesz w przewodniku po zgłaszaniu podatności.
Częste błędy
Pomijanie zależności przechodnich. Większość podatności w podłączonych produktach pochodzi z bibliotek i komponentów stron trzecich, a nie z kodu pierwszej strony. Obowiązek z art. 13 ust. 8 obejmuje cały produkt, nie tylko kod napisany przez producenta. SBOM jest warunkiem wstępnym. Zapoznaj się z przewodnikiem po klastrze SBOM, aby poznać ramy śledzenia zależności, które umożliwiają operacyjne monitorowanie podatności przechodnich.
Pobieranie opłat za aktualizacje bezpieczeństwa. Bundlowanie poprawek bezpieczeństwa w płatnym pakiecie wsparcia narusza art. 13 ust. 8. Podstawowe łatki bezpieczeństwa muszą być bezpłatne.
Często zadawane pytania
Czy aktualizacje bezpieczeństwa muszą zawsze być bezpłatne?
Tak. Art. 13 ust. 8 wymaga, aby aktualizacje bezpieczeństwa były dostarczane bezpłatnie. Producent nie może bundlować poprawki bezpieczeństwa w płatnej subskrypcji, płatnym pakiecie wsparcia ani w uaktualnieniu do nowej wersji głównej i twierdzić, że spełnia wymagania art. 13 ust. 8. Aktualizacje funkcjonalne, nowe możliwości i płatne usługi profesjonalne są odrębną kwestią i mogą być odpłatne. Obowiązek dotyczy wyłącznie aktualizacji usuwających podatności: zmian naprawiających słabość bezpieczeństwa produktu wprowadzonego na rynek.
Jak szybko producent musi wydać aktualizację bezpieczeństwa zgodnie z CRA?
Art. 13 ust. 8 CRA wymaga aktualizacji bezpieczeństwa "bez zbędnej zwłoki", ale nie definiuje numerycznie terminu. Organy nadzoru rynku i wytyczne ENISA są zgodne z praktyką branżową opartą na poziomie ważności: krytyczne, aktywnie wykorzystywane podatności powinny być łatane w ciągu kilku dni, podatności wysokiego ryzyka -- w ciągu około 30 dni, średniego ryzyka -- w ciągu 90 dni, a niskiego ryzyka -- bundlowane do następnego regularnego cyklu aktualizacji. Nie są to terminy wymagane przez CRA, lecz standard, według którego "bez zbędnej zwłoki" będzie oceniane w postępowaniach egzekucyjnych. Producenci powinni śledzić rzeczywisty czas łatania każdego CVE, aby odchylenia od tej wartości bazowej były widoczne i możliwe do obrony.
Czy CRA wymaga automatycznych aktualizacji?
Nie we wszystkich przypadkach. Załącznik I Część II lit. 7 wymaga od producentów zapewnienia bezpiecznych mechanizmów dystrybucji z automatycznym dostarczaniem "tam, gdzie ma to zastosowanie". W przypadku produktów z niezawodną łącznością i bez operacyjnych powodów do odroczenia automatyczne aktualizacje są oczekiwanym standardem. W przypadku przemysłowych systemów izolowanych od sieci, niektórych urządzeń medycznych lub sprzętu o krytycznym znaczeniu dla bezpieczeństwa, gdzie automatyczna instalacja łatki mogłaby zakłócić działanie, dopuszczalny jest udokumentowany ręczny proces aktualizacji. Plik techniczny z Załącznika VII musi uzasadniać wybrane podejście. Użytkownicy muszą zachować możliwość rezygnacji z automatycznych aktualizacji z wyraźnymi ostrzeżeniami o konsekwencjach bezpieczeństwa, z wyjątkiem przypadków, gdy ryzyko uzasadnia niedodatkowalne krytyczne poprawki.
Czy produkt SaaS ma okres wsparcia CRA?
To zależy od tego, czy produkt SaaS mieści się w zakresie CRA jako produkt z elementami cyfrowymi. Czyste usługi SaaS, które nie są bundlowane ze składnikiem sprzętowym ani pobieranym programem agenta, są co do zasady poza zakresem na podstawie art. 2 ust. 1. W przypadku gdy produkt SaaS zawiera agenta lokalnego, pobieranego klienta lub sprzętową bramę wprowadzoną na rynek UE, ten składnik jest w zakresie i jego zegar okresu wsparcia z art. 13 ust. 8 startuje w momencie wprowadzenia na rynek. Backend hostowany w chmurze, gdy jest pod kontrolą producenta i stale aktualizowany, zazwyczaj spełnia obowiązek łatania "bez zbędnej zwłoki" przez przezroczyste wdrożenie, jednak producent musi nadal dokumentować zobowiązanie wsparcia w informacjach z Załącznika II dla składnika objętego zakresem.
Co dzieje się z aktualizacjami bezpieczeństwa po zakończeniu okresu wsparcia CRA?
Obowiązki z art. 13 ust. 8 kończą się wraz z okresem wsparcia. Po upływie ujawnionej daty zakończenia producent nie ma obowiązku CRA do badania, łatania ani dystrybucji aktualizacji bezpieczeństwa dla tej wersji produktu, a obowiązki zgłaszania z art. 14 również wygasają, ponieważ stosują się wyłącznie w trakcie okresu wsparcia. Organy nadzoru rynku mogą nadal prowadzić dochodzenia na podstawie art. 58, jeżeli produkt stwarza znaczące ryzyko cyberbezpieczeństwa po zakończeniu cyklu życia, jednak codzienny obowiązek zarządzania podatnościami wygasł. Producenci powinni z wyprzedzeniem wyraźnie informować użytkowników o zakończeniu wsparcia; ujawnienie daty zakończenia z Załącznika II lit. k jest skierowanym do użytkownika instrumentem służącym temu celowi. Kontynuowanie dostarczania łatek goodwill po zakończeniu wsparcia jest dozwolone, lecz nie jest wymagane.