Rozporządzenie (UE) 2024/2847, czyli CRA, wymaga od producentów obsługi podatności przez okres wsparcia oraz rozpowszechniania dostępnych aktualizacji bezpieczeństwa bez zwłoki i bezpłatnie. Ta strona opisuje mechanikę dostarczania aktualizacji dla architektur wbudowanych, samodzielnych, SaaS i hybrydowych. Informacje o czasie trwania wsparcia znajdziesz w podstawach okresu wsparcia; informacje o ujawnianiu daty zakończenia wsparcia przed zakupem znajdziesz w ujawnianiu końca wsparcia.
Podsumowanie
- Aktualizacje bezpieczeństwa to nie aktualizacje funkcjonalne. Zmiana usuwająca podatność podlega obowiązkom aktualizacji bezpieczeństwa; nowa funkcja nie.
- Poprawki bezpieczeństwa nie mogą być zamknięte za płatnym pakietem. Dostępne aktualizacje bezpieczeństwa powinny być rozpowszechniane bez zwłoki i bezpłatnie, z komunikatami doradczymi informującymi użytkowników, czego dotyczy aktualizacja i jakie działania należy podjąć, z wyjątkiem odmiennych ustaleń dla produktów tworzonych na miarę dla użytkowników biznesowych.
- Automatycznie tam, gdzie ma to zastosowanie. Automatyczne aktualizacje bezpieczeństwa są domyślnym modelem tam, gdzie ma to sens, z bezpiecznymi mechanizmami dystrybucji i jasną kontrolą użytkownika.
- Cele łatania powinny wynikać z poziomu ważności. Praktyczne cele to dni dla krytycznych podatności aktywnie wykorzystywanych, 30 dni dla wysokich, 90 dni dla średnich i następny cykl dla niskich.
- Architektura zmienia model dostarczania. Firmware wbudowany, samodzielne oprogramowanie, SaaS i produkty hybrydowe mają różne mechanizmy aktualizacji, które trzeba opisać w dokumentacji technicznej.
- Zgłaszanie łączy się z cyklem aktualizacji. Gdy wykryta zostaje aktywnie wykorzystywana podatność, 24-godzinne wczesne ostrzeżenie do koordynującego CSIRT i ENISA biegnie równolegle z procesem poprawki; mechanizm aktualizacji musi zasilać proces zgłoszeniowy.
Cztery punkty zgodności aktualizacji bezpieczeństwa CRA: zasada kosztu, preferencja dystrybucji, dostępność aktualizacji i model kar.
Progi kar opisuje przewodnik po sankcjach i egzekwowaniu.
Co kwalifikuje się jako aktualizacja bezpieczeństwa
Obowiązek aktualizacji zaczyna się od oceny ryzyka cyberbezpieczeństwa produktu i właściwych cech bezpieczeństwa. Bezpieczna konfiguracja domyślna, poufność, integralność i dostępność decydują, czy zmiana jest istotna dla bezpieczeństwa. Producent musi następnie skutecznie obsługiwać podatności w okresie wsparcia.
Aktualizacja bezpieczeństwa to zmiana usuwająca podatność, czyli słabość produktu możliwą do wykorzystania do naruszenia poufności, integralności lub dostępności. Różnica względem aktualizacji funkcjonalnej ma znaczenie: dostępne aktualizacje bezpieczeństwa muszą być bezpłatne i rozpowszechniane bez zwłoki; aktualizacje funkcjonalne nie mają tych obowiązków.
| Typ aktualizacji | Obowiązek aktualizacji bezpieczeństwa | Czy można pobrać opłatę? |
|---|---|---|
| Poprawka znanego CVE | Tak (aktualizacja bezpieczeństwa) | Nie |
| Utwardzenie zmniejszające powierzchnię ataku | Tak (aktualizacja bezpieczeństwa) | Nie |
| Nowa funkcja bez znaczenia dla bezpieczeństwa | Nie | Tak |
| Wersja główna z nowymi możliwościami | Nie (chyba że zawiera poprawki bezpieczeństwa) | Tak |
| Aktualizacja zależności usuwająca znaną podatność | Tak (aktualizacja bezpieczeństwa) | Nie |
| Zmiana konfiguracji zamykająca lukę bezpieczeństwa | Tak (aktualizacja bezpieczeństwa) | Nie |
Bez zwłoki nie oznacza w rozporządzeniu konkretnej liczby dni. Producent powinien jednak ustalić cele operacyjne według ważności, aby decyzje o poprawkach były spójne, udokumentowane i możliwe do wyjaśnienia. Diagram pokazuje praktyczne okno łatania od momentu, w którym producent dowiaduje się o podatności:
| Ważność | Praktyczny cel operacyjny |
|---|---|
| Krytyczna (aktywnie wykorzystywana) | Dni, nie tygodnie |
| Wysoka (łatwa do zdalnego wykorzystania) | W 30 dni |
| Średnia | W 90 dni |
| Niska | W następnym regularnym cyklu |
To nie są terminy narzucone przez CRA. Są to cele wewnętrzne, które pomagają wykazać, że zwłoka była kontrolowana, oparta na ryzyku i udokumentowana.
Jak dostarczać aktualizacje bezpieczeństwa zgodne z CRA
Aktualizacje automatyczne
Tam, gdzie jest to technicznie możliwe i właściwe, automatyczne aktualizacje bezpieczeństwa są preferowanym modelem. Zgodny model automatyczny powinien domyślnie włączać aktualizacje bezpieczeństwa, oferować jasny mechanizm rezygnacji, informować o dostępnych aktualizacjach, umożliwiać czasowe odroczenie tam, gdzie to właściwe, i bezpiecznie dystrybuować aktualizacje.
Solidny mechanizm automatycznych aktualizacji powinien zapewniać:
- Bezpieczny kanał pobierania (TLS, podpisane pakiety)
- Weryfikacja integralności przed instalacją
- Możliwość wycofania w razie niepowodzenia aktualizacji
- Obsługa problemów z łącznością
- Widoczny status aktualizacji dla użytkownika
Użytkownik musi móc wyłączyć aktualizacje automatyczne, z jasnym ostrzeżeniem o skutkach bezpieczeństwa. Przy aktualizacjach krytycznych producent powinien udokumentować każdą decyzję o braku możliwości odroczenia w ocenie ryzyka i dokumentacji technicznej.
Aktualizacje ręczne
Produkty, które nie mogą odbierać aktualizacji automatycznych, wymagają ręcznego procesu dostarczania:
- Pakiety do pobrania z jasnym wersjonowaniem
- Podpisy kryptograficzne i opublikowane klucze publiczne do weryfikacji
- Dokumentacja instalacji
- Powiadomienie wszystkimi dostępnymi kanałami
Wbudowane i SaaS: odmienne modele aktualizacji
Mechanizm dostarczania zależy od architektury produktu:
| Typ produktu | Model aktualizacji | Kluczowa kwestia CRA |
|---|---|---|
| Firmware wbudowany | Producent udostępnia podpisany firmware; klient go stosuje | Potrzebne OTA albo udokumentowany proces ręczny; długa eksploatacja może wymagać wsparcia powyżej pięciu lat |
| Samodzielne oprogramowanie | Producent publikuje pakiet; klient instaluje | Preferowany agent automatycznej aktualizacji; pinning wersji zwiększa obciążenie wsparcia |
| SaaS / chmura | Producent kontroluje środowisko; aktualizacje są przezroczyste | Najpierw sprawdź, czy usługa jest w zakresie jako produkt z elementami cyfrowymi albo rozwiązanie zdalnego przetwarzania danych |
| Hybryda | Aktualizacje agenta kontroluje producent; backend aktualizuje się przezroczyście | Każdy składnik ma własny okres wsparcia; agent jest produktem z elementami cyfrowymi, który wyznacza zegar |
Szerzej o obsłudze podatności poza samą dostawą aktualizacji (polityka CVD, publiczne ujawnienie, zgłoszenia do osób trzecich) piszemy w przewodniku po obsłudze podatności.
Obowiązki zgłaszania podczas dostarczania aktualizacji
Zgłaszanie CRA nakłada obowiązki terminowe dla aktywnie wykorzystywanych podatności i poważnych incydentów wpływających na bezpieczeństwo produktu. Proces aktualizacji powinien zbierać fakty potrzebne do tych zgłoszeń, bo raport końcowy musi zawierać szczegóły aktualizacji bezpieczeństwa lub innych środków naprawczych.
Operacyjnie wygląda to tak:
| Wyzwalacz | Obowiązek w procesie aktualizacji |
|---|---|
| Aktywnie wykorzystywana podatność | Zapisz czas uzyskania wiedzy, produkty, fakty wykorzystania, stan mitygacji i szczegóły aktualizacji dla sekwencji 24 h, 72 h i raportu końcowego. |
| Poważny incydent | Zapisz wpływ, podejrzaną bezprawną lub złośliwą przyczynę, wstępną ocenę, mitygacje i działania dla użytkowników. |
| Powiadomienie użytkowników | Przygotuj jasne instrukcje ograniczania ryzyka i działań naprawczych dla użytkowników dotkniętych skutkami, a gdy właściwe także dla wszystkich użytkowników. |
Nie traktuj zgłaszania jako osobnego kroku po fakcie. Informacje z supportu, PSIRT, telemetrii, obsługi klienta lub wdrożeń muszą szybko trafić do osoby odpowiedzialnej za zgłoszenia, gdy próg zgłoszeniowy może być spełniony.
Pełną mechanikę terminów, w tym zawartość każdego zgłoszenia i różnice między dwoma strumieniami, opisuje przewodnik po zgłaszaniu podatności.
Dostępność aktualizacji po publikacji
Jednorazowe udostępnienie poprawki nie wystarcza. Każda aktualizacja bezpieczeństwa udostępniona użytkownikom w okresie wsparcia musi pozostać dostępna co najmniej 10 lat od wydania albo do końca okresu wsparcia, jeżeli ten jest dłuższy. To zmienia proces release: stare pakiety, komunikaty, podpisy, hashe i instrukcje instalacji wymagają trwałego hostingu i śledzenia wersji.
Informacje dla użytkowników muszą też wskazywać rodzaj wsparcia technicznego w zakresie bezpieczeństwa oraz datę końca okresu wsparcia, w którym użytkownicy mogą oczekiwać obsługi podatności i aktualizacji. Model ujawnienia przed zakupem opisuje ujawnienie końca wsparcia.
Częste błędy
Ignorowanie zależności przechodnich. Większość podatności w produktach połączonych pochodzi z bibliotek i komponentów stron trzecich. Obowiązek obsługi podatności obejmuje cały produkt, w tym komponenty. SBOM jest warunkiem wstępnym. Zobacz przewodnik po SBOM.
Pobieranie opłat za aktualizacje bezpieczeństwa. Umieszczanie poprawek bezpieczeństwa w płatnym pakiecie wsparcia koliduje z podstawowym modelem aktualizacji CRA, chyba że działa wyjątek dla produktów biznesowych tworzonych na miarę. Podstawowe poprawki bezpieczeństwa muszą być bezpłatne.
Często zadawane pytania
Czy aktualizacje bezpieczeństwa muszą zawsze być bezpłatne?
Tak, dostępne aktualizacje bezpieczeństwa muszą być bezpłatne, chyba że działa wąski wyjątek dla produktów biznesowych tworzonych na miarę. Producent nie może ukryć poprawki podatności w płatnej subskrypcji, pakiecie premium ani płatnej wersji głównej i traktować tego jako zwykłej zgodności z CRA. Aktualizacje funkcjonalne i usługi profesjonalne można rozliczać osobno. Granicą jest to, czy zmiana usuwa zidentyfikowany problem bezpieczeństwa w produkcie.
Jak szybko producent musi wydać aktualizację bezpieczeństwa zgodnie z CRA?
CRA nie ustala stałego terminu łatania. Producent potrzebuje więc udokumentowanych celów według ważności. Krytyczne aktywnie wykorzystywane podatności powinny być obsługiwane w dniach, wysokie około 30 dni, średnie około 90 dni, a niskie w następnym regularnym cyklu, chyba że ocena ryzyka uzasadnia inny cel. Śledź rzeczywisty czas do poprawki dla każdej podatności, aby zwłoka była widoczna, oparta na ryzyku i możliwa do wyjaśnienia.
Czy CRA wymaga automatycznych aktualizacji?
Nie zawsze. Automatyczne aktualizacje bezpieczeństwa są wymagane tam, gdzie mają zastosowanie, a produkt powinien także informować o dostępnych aktualizacjach i pozwalać na czasowe odroczenie. Dla wiarygodnie połączonych produktów konsumenckich to zwykle oczekiwany model. Dla systemów izolowanych, wybranych urządzeń medycznych lub sprzętu krytycznego udokumentowany proces ręczny może być uzasadniony. Dokumentacja techniczna powinna wyjaśniać wybrane podejście, a instrukcje użytkownika powinny wyjaśniać, jak wyłączyć instalację automatyczną.
Czy produkt SaaS ma okres wsparcia CRA?
To zależy, czy usługa jest w zakresie jako produkt z elementami cyfrowymi albo rozwiązanie zdalnego przetwarzania danych. Czysty samodzielny SaaS, bez sprzętu, oprogramowania do pobrania ani zdalnego przetwarzania pod odpowiedzialnością producenta, zwykle nie mieści się w tym modelu aktualizacji. Jeśli oferta obejmuje agenta lokalnego, klienta do pobrania, bramę sprzętową albo objęte przetwarzanie zdalne, zmapuj okres wsparcia i mechanizm aktualizacji dla składnika w zakresie. Informacje dla użytkownika nadal muszą wskazywać typ wsparcia i datę końca.
Co dzieje się z aktualizacjami bezpieczeństwa po zakończeniu okresu wsparcia CRA?
Zwykły obowiązek obsługi podatności jest związany z okresem wsparcia, ale już wydane aktualizacje muszą pozostać dostępne. Każda aktualizacja bezpieczeństwa udostępniona w okresie wsparcia musi pozostać dostępna co najmniej 10 lat od wydania albo do końca okresu wsparcia, jeżeli ten jest dłuższy. Producent powinien jasno komunikować koniec wsparcia z wyprzedzeniem i utrzymywać instrukcje użytkownika przez wymagany okres. Nie zakładaj, że po końcu wsparcia można ignorować zgłoszenia bez analizy prawnej konkretnego przypadku.