Okres wsparcia CRA: pięcioletnie minimum

Unijny Cyber Resilience Act sprawia, że planowanie okresu wsparcia jest decyzją przy wprowadzaniu produktu na rynek, a nie późniejszym dodatkiem. Producent musi ustalić, jak długo użytkownicy mogą oczekiwać obsługi podatności, opublikować datę końca wsparcia przy zakupie i utrzymywać dostępność aktualizacji bezpieczeństwa przez wymagany okres. Ten przewodnik obejmuje mechanikę czasu trwania: kiedy zaczyna się zegar, jak działa wyjątek krótszego oczekiwanego użycia, jak nakładają się portfele wielu wersji i co muszą obejmować umowy z dostawcami upstream. O kadencji dostarczania zobacz Aktualizacje bezpieczeństwa CRA; o dacie końca okresu wsparcia widocznej dla użytkownika zobacz Ujawnienie końca wsparcia.

Czego CRA wymaga dla okresu wsparcia

Okres wsparcia to okno, w którym producent musi utrzymywać aktywny proces obsługi podatności produktu. Obejmuje produkt i jego komponenty, zaczyna się od wprowadzenia na rynek UE i musi być wystarczająco długi, aby odpowiadać temu, jak użytkownicy mogą racjonalnie oczekiwać używania produktu. Producent powinien ustalić go na podstawie dowodów praktycznych: rodzaju produktu, zamierzonego przeznaczenia, porównywalnych produktów, właściwych przepisów Unii określających czas życia produktów, dostępności środowiska operacyjnego, okresów wsparcia kluczowych komponentów osób trzecich oraz wytycznych ADCO lub Komisji. Praktyczny wniosek jest prosty: wsparcie trzeba ustalić przed premierą i utrzymywać przez całe zadeklarowane okno.

Obowiązek ma trzy elementy:

Kiedy zaczyna się pięcioletni zegar

Zegar wsparcia zaczyna się, gdy produkt trafia na rynek UE, a nie gdy kupuje go klient końcowy. W unijnym prawie produktowym jest to pierwsze udostępnienie produktu na rynku Unii do dystrybucji lub używania. Dla planowania wsparcia liczy się data wprowadzenia na rynek.

Zegar startuje: data, w której produkt po raz pierwszy jest udostępniany dystrybutorowi, sprzedawcy, importerowi lub użytkownikowi do dystrybucji lub używania na rynku UE.

Zegar nie startuje przy: zakupie przez klienta, aktywacji przez klienta, wysyłce konkretnego egzemplarza ani instalacji produktu przez klienta.

Przykład praktyczny:

1. Styczeń 2028. Produkt v1.0 zostaje wprowadzony na rynek UE. Pięcioletni okres wsparcia zaczyna biec. Producent jest zobowiązany do aktualizacji bezpieczeństwa co najmniej do stycznia 2033 r.
2. Czerwiec 2029. Klient kupuje v1.0 od sprzedawcy. Pozostaje mu około 3,5 roku wsparcia, a nie pięć lat od zakupu.
3. Styczeń 2033. Okres wsparcia się kończy. Podstawowe zobowiązanie do obsługi podatności dla v1.0 wygasa. Dalsze powiadomienia użytkowników lub działania regulacyjne zależą od faktów.

Dobra praktyka: śledź daty wprowadzenia na rynek według wersji produktu, nie według pojedynczego egzemplarza. Jeden rekord daty wprowadzenia na rynek dla SKU jest zwykle praktyczną bazą dowodową do obliczania dat końca wsparcia.

Wyjątek krótszego oczekiwanego użycia

Pięcioletnie minimum można skrócić tylko wtedy, gdy produkt rzeczywiście ma być używany krócej niż pięć lat. Ten wyjątek jest węższy, niż się wydaje, i wynika z przepisu o okresie wsparcia:

• "Oczekiwany okres używania produktu" ocenia się z perspektywy racjonalnych oczekiwań użytkowników na podstawie charakteru produktu, typowego używania podobnych produktów i komunikacji producenta.
• Krótszy okres musi być udokumentowany w dokumentacji technicznej i ujawniony użytkownikom przy zakupie, w tym co najmniej przez miesiąc i rok daty końca wsparcia.
• Producent nie może powołać się na ten wyjątek po odkryciu podatności. Ocena musi powstać przed wprowadzeniem na rynek i zostać zapisana w dokumentacji technicznej.
• Dla większości produktów programowych, urządzeń IoT i połączonego sprzętu pięć lat jest praktycznym minimum. Wyjątek dotyczy produktów o obiektywnie krótkiej przydatności, takich jak sprzęt jednorazowy lub o ograniczonym cyklu, a nie produktów, dla których producent po prostu wolałby krótszy obowiązek.

Wsparcie wielu wersji

Większość producentów ma jednocześnie na rynku kilka wersji produktu. Produkty sprzętowe i niezależnie utrzymywane wersje oprogramowania mogą tworzyć nakładające się okna wsparcia. Produkty programowe mają też ograniczoną ścieżkę tylko-najnowszej-wersji dla kolejnych istotnie zmodyfikowanych wersji, ale tylko wtedy, gdy użytkownicy wcześniejszych wersji mogą przejść na najnowszą wersję bezpłatnie i bez dodatkowych kosztów środowiska sprzętowego lub programowego.

Rozłożone okresy wsparcia tworzą nakładające się obowiązki:

Od stycznia 2029 do stycznia 2033, przez cztery lata, producent może być zobowiązany do aktualizacji bezpieczeństwa dla wszystkich trzech wersji jednocześnie, chyba że zastosowanie ma kwalifikująca się ścieżka programowa tylko-najnowszej-wersji. Każda wersja ma własną ekspozycję na CVE, własne drzewo zależności i potencjalnie własną bazę klientów. Backportowanie poprawek między głównymi wersjami jest technicznie złożone i kosztowne.

Strategie ograniczania obciążenia wieloma wersjami:

1. Wspólna baza kodu. Tam, gdzie to możliwe, utrzymuj jeden rdzeń łatany pod kątem bezpieczeństwa, na którym opierają się wszystkie wersje. Poprawki bezpieczeństwa zastosowane raz propagują się do wszystkich wersji.
2. Silne zachęty migracyjne. Krótsze odstępy między klientami na starych wersjach zmniejszają aktywną macierz wsparcia. Ceny aktualizacji, bezpłatne narzędzia migracyjne i kredyty wsparcia przyspieszają konsolidację wersji.
3. Jawny harmonogram EOL wersji. Opublikuj datę końca wsparcia dla każdej wersji przy wprowadzeniu na rynek. Klienci, którzy wiedzą, że v1.0 kończy się w styczniu 2033 r., mają czas zaplanować migrację bez presji awaryjnej.
4. Ścieżka najnowszej wersji dla kwalifikującego się oprogramowania. Jeśli korzystasz ze ścieżki najnowszej wersji, udokumentuj, jak użytkownicy poprzednich wersji otrzymują najnowszą wersję bezpłatnie i bez kosztów dostosowania środowiska.

Obowiązki dostawców i umowy upstream

Producent ponosi obowiązek okresu wsparcia nawet wtedy, gdy podatność pochodzi z komponentu upstream. Jeśli produktu nie da się załatać, ponieważ dostawca komponentu zakończył wsparcie, producent nadal potrzebuje ścieżki naprawy. Luka w umowie upstream nie jest obroną w ramach reguły okresu wsparcia.

Co to oznacza w praktyce:

• Jeżeli produkt zawiera system operacyjny, middleware lub firmware chipsetu od strony trzeciej, producent musi zabezpieczyć umowę dostaw obejmującą pełny okres wsparcia. Dostawca upstream, który zapewnia poprawki bezpieczeństwa przez trzy lata, zmusza producenta do samodzielnego utrzymywania poprawek po trzecim roku albo do zaprzestania wprowadzania produktu na rynek UE po EOL upstream.
• Śledzenie zależności oparte na SBOM (zobacz przewodnik po klastrze SBOM) jest mechanizmem operacyjnym: producent nie może monitorować podatności upstream, jeśli nie wie, co znajduje się w produkcie.
• Umowy dostaw powinny określać: czas zobowiązania upstream do łatania, obowiązki powiadamiania o nowo odkrytych podatnościach, dostęp do kodu źródłowego lub narzędzi łatania, jeśli dostawca upstream wycofa komponent, oraz warunki odszkodowania za podatności pochodzące z komponentów upstream.

Importerzy i dystrybutorzy, którzy wprowadzają produkt na rynek pod własną nazwą lub znakiem towarowym albo istotnie modyfikują produkt już wprowadzony do obrotu, są traktowani jak producenci i przejmują obowiązki producenta, w tym ryzyko umów upstream. Zobacz przewodnik po obowiązkach importera, aby przejść przez decyzję o eskalacji roli.

Planowanie końca życia i odpowiedzialne przejścia produktowe

Gdy okres wsparcia się kończy, podstawowe zobowiązanie do obsługi podatności dla danej wersji produktu wygasa, ale część odpowiedzialności pozostaje.

Co pozostaje po zakończeniu wsparcia:

• Data końca okresu wsparcia ujawniona przy zakupie pozostaje zobowiązaniem widocznym dla użytkownika.
• Dokumentacja techniczna i deklaracja zgodności UE muszą być przechowywane przez co najmniej 10 lat od wprowadzenia na rynek albo przez okres wsparcia, w zależności od tego, który okres jest dłuższy.
• Informacje i instrukcje dla użytkowników muszą pozostać dostępne dla użytkowników i organów nadzoru rynku przez ten sam okres (10 lat albo okres wsparcia, w zależności od tego, który jest dłuższy), niezależnie od kanału dostarczenia; jeżeli są udostępniane online, muszą być przez ten okres dostępne także online.
• Tam, gdzie jest to technicznie wykonalne, producent powinien wyświetlać użytkownikom powiadomienie, że produkt osiągnął koniec okresu wsparcia.
• Podatności w produktach bez wsparcia nadal wymagają ostrożnej obsługi. CRA nie daje ogólnego zdania safe harbour dla każdego pytania o zgłaszanie incydentów przy EOL, a organy nadzoru rynku mogą nadal działać, gdy produkt stwarza istotne ryzyko cyberbezpieczeństwa. Ekspozycję na kary omawia przewodnik po sankcjach i egzekwowaniu.

Obowiązki komunikacyjne przy końcu wsparcia:

CRA nie określa ustawowego okresu uprzedzenia o końcu wsparcia. Ujawnienie daty końca okresu wsparcia przy zakupie oznacza, że użytkownicy, którzy kupili produkt po wdrożeniu ujawnienia, byli już poinformowani. Dla produktów, w których pierwotne ujawnienie było nieobecne lub niejasne, wcześniejsze powiadomienie jest operacyjną kontrolą ryzyka, a nie terminem numerowanym w CRA.

Po EOL: producent powinien utrzymywać kontakt bezpieczeństwa do odpowiedzialnego ujawniania podatności, utrzymywać dostępność dokumentacji produktu i współpracować z każdym dochodzeniem organu nadzoru rynku.

Częste błędy

• Brak śledzenia dat wprowadzenia na rynek. Bez rekordu daty wprowadzenia dla każdej wersji producent nie może obliczyć, kiedy obowiązki wsparcia zaczynają się lub kończą, nie może wygenerować widocznej dla użytkownika daty końca wsparcia i nie może wykazać zgodności organom nadzoru rynku.

• Brak planowania pod upstream EOL. Jeżeli dostawca chipsetu, systemu operacyjnego lub middleware kończy wsparcie przed wygaśnięciem okresu wsparcia producenta, producent musi mieć plan. Reaktywne odkrycie upstream EOL bez umowy dostaw jest częstym i kosztownym trybem awarii.

• Łączenie łatek bezpieczeństwa z wydaniami funkcji. Bundlowanie poprawek bezpieczeństwa z dużymi aktualizacjami wersji zmusza klientów do akceptowania nowych funkcji i nowej powierzchni ryzyka, aby dostać poprawkę bezpieczeństwa. Poprawki bezpieczeństwa powinny być dostarczane jako poprawki bezpieczeństwa, bez wymuszania płatnych poziomów lub dużych aktualizacji funkcjonalnych.