Załącznik I część II Rozporządzenia (UE) 2024/2847 określa osiem ponumerowanych obowiązków, które każdy producent produktu z elementami cyfrowymi musi realizować przez cały okres wsparcia: identyfikację opartą na SBOM, niezwłoczne usuwanie podatności, regularne testowanie, publiczne ujawnianie napraw, politykę koordynowanego ujawniania podatności, zewnętrzny kanał zgłaszania, bezpieczną dystrybucję aktualizacji oraz bezpłatne aktualizacje bezpieczeństwa. Niniejsza strona omawia po kolei każdy obowiązek i wskazuje, gdzie kończy się obsługa z załącznika I, a zaczyna zgłaszanie z artykułu 14.
Podsumowanie
- Załącznik I część II to specyfikacja inżynierska dla obsługi podatności w CRA, mająca zastosowanie do każdego producenta i każdego produktu z elementami cyfrowymi.
- Osiem ponumerowanych obowiązków: identyfikacja (z SBOM), niezwłoczne usuwanie podatności, regularne testowanie, publiczne ujawnianie naprawionych podatności, prowadzenie polityki CVD, ułatwianie zgłaszania podatności, bezpieczna dystrybucja aktualizacji, dostarczanie aktualizacji bezpieczeństwa bezpłatnie.
- Bezpłatność jest niepodważalna: aktualizacje bezpieczeństwa muszą być dostarczane bezpłatnie na podstawie załącznika I część II punkt 8, z jedynym wyjątkiem dla produktów wykonanych na zamówienie dla użytkowników biznesowych.
- Polityka CVD jest obowiązkowa, a nie opcjonalna: załącznik I część II punkt 5 czyni koordynowane ujawnianie podatności obowiązkiem związanym z oznakowaniem CE, a nie dobrą praktyką.
- Obsługa podatności biegnie przez cały okres wsparcia zdefiniowany w artykule 3(20) i artykule 13(8); minimum to pięć lat od wprowadzenia do obrotu.
- Obsługa podatności to nie zgłaszanie z artykułu 14: obsługa to bieżący proces inżynierski; zgłaszanie to rytm 24h/72h/14d uruchamiany wyłącznie przez aktywnie wykorzystywane podatności lub poważne incydenty (zob. zgłaszanie z artykułu 14 CRA).
Cztery kotwice ramujące obsługę podatności w CRA: zakres, czas trwania, zasada bezpłatności i pułap kary.
Osiem obowiązków z załącznika I część II
Załącznik I część II Rozporządzenia (UE) 2024/2847 wymienia osiem ponumerowanych obowiązków. Nie są one listą kontrolną: opisują ciągły cykl życia, który biegnie przez cały okres wsparcia. Poniższe pogrupowanie układa je według fazy operacyjnej, w której każdy z nich działa.
Punkty 1, 6. Identyfikacja komponentów i znanych podatności oparta na SBOM oraz publiczny kanał kontaktowy umożliwiający stronom zewnętrznym zgłaszanie tego, co przeoczyły skanery.
Punkty 2, 3. Niezwłoczne usuwanie podatności (skalowane wagą, a nie sztywnym SLA) oraz skuteczne, regularne testowanie kodu i jego zależności.
Punkty 7, 8. Bezpieczny kanał aktualizacji (podpisany, uwierzytelniony, automatyczny tam, gdzie ma to zastosowanie), z aktualizacjami bezpieczeństwa oddzielonymi od funkcjonalności i dostarczanymi bezpłatnie, z wyjątkiem produktów na zamówienie B2B.
Punkty 4, 5. Polityka koordynowanego ujawniania podatności wprowadzona i egzekwowana, wraz z publicznymi komunikatami po udostępnieniu poprawki, z wąskim wyjątkiem opóźnienia w "należycie uzasadnionych przypadkach".
Co każdy obowiązek oznacza w praktyce
| # | Obowiązek | Co rzeczywiście wymaga |
|---|---|---|
| 1 | Identyfikacja i dokumentacja podatności oraz komponentów | SBOM w formacie CycloneDX lub SPDX, obejmujący co najmniej zależności najwyższego poziomu. SBOM to indeks umożliwiający dopasowanie do CVE: nie da się usunąć tego, czego się nie skatalogowało. |
| 2 | Niezwłoczne usuwanie podatności, oddzielnie od funkcjonalności | Brak sztywnego SLA; oczekiwane tempo skaluje się z wagą. Gałęzie bezpieczeństwa muszą być oddzielne od gałęzi funkcjonalnych, aby użytkownicy nie mogli odraczać łatki przez odraczanie wydania. |
| 3 | Skuteczne i regularne testowanie | Analiza statyczna, testy dynamiczne, skanowanie zależności wobec źródeł danych o podatnościach oraz testy penetracyjne. "Regularne" musi odpowiadać ryzyku i tempu zmian kodu. |
| 4 | Publiczne ujawnianie naprawionych podatności | Po wydaniu poprawki opublikuj opis, dotknięty produkt, wpływ, wagę i naprawę. Opóźnienie wyłącznie "w należycie uzasadnionych przypadkach" do czasu, gdy użytkownicy będą mogli zastosować łatkę. CVE plus CSAF to de facto nośnik. |
| 5 | Polityka koordynowanego ujawniania podatności | Pisemna, egzekwowana polityka CVD z kanałem przyjmowania, SLA odpowiedzi i warunkami ujawniania. ISO/IEC 29147 i 30111 dostarczają formalne ramy. |
| 6 | Ułatwianie zewnętrznego zgłaszania podatności | Adres kontaktowy do zgłaszania problemów w produkcie i jego komponentach podmiotów trzecich. security.txt zgodnie z RFC 9116 spełnia wymóg kanału. |
| 7 | Bezpieczna dystrybucja aktualizacji | Podpisane, uwierzytelnione aktualizacje, automatyczne tam, gdzie ma to zastosowanie. Produkty bez kanału aktualizacji muszą go zbudować lub udokumentować, dlaczego automatyzacja nie ma zastosowania. Zob. aktualizacje bezpieczeństwa. |
| 8 | Bezpłatnie, z komunikatami doradczymi | Aktualizacje bezpieczeństwa muszą być rozpowszechniane bez zbędnej zwłoki i bezpłatnie (jedyny wyjątek: produkty na zamówienie dla użytkowników biznesowych, gdy strony uzgodniły inaczej). Każda aktualizacja musi nieść komunikat opisujący problem i działanie wymagane od użytkownika. Bramka płatnego utrzymania lub cicha łatka bez komunikatu narusza punkt 8. |
Obsługa podatności a okres wsparcia
Wymogi załącznika I część II obowiązują przez cały okres wsparcia zdefiniowany w artykule 3(20) i wymagany przez artykuł 13(8). Okres wsparcia wynosi co najmniej pięć lat od dnia wprowadzenia produktu na rynek UE lub oczekiwany okres używania produktu, jeśli jest krótszy i został ujawniony. Data zakończenia okresu wsparcia musi pojawić się w informacjach o produkcie zgodnie z załącznikiem II. Po zakończeniu okresu wsparcia obowiązki z załącznika I część II wygasają dla danej wersji produktu, jednak obowiązek przechowywania dokumentacji zgodnie z artykułem 31 (dziesięć lat od wprowadzenia do obrotu) trwa nadal. Zob. okres wsparcia w CRA.
Obsługa podatności to nie zgłaszanie z artykułu 14
CRA rozróżnia dwa obowiązki, które działają na różnych powierzchniach i wobec różnych odbiorców:
- Obsługa podatności z załącznika I część II to proces inżynierski: SBOM, usuwanie podatności, polityka CVD, publiczne ujawnianie, bezpieczne aktualizacje. Stosuje się do wszystkich podatności, przez cały czas, przez cały okres wsparcia. Realizowana jest przez organizację bezpieczeństwa produktu producenta.
- Zgłaszanie z artykułu 14 to powiadomienie regulacyjne uruchamiane przez aktywnie wykorzystywaną podatność (artykuł 3(42)) lub poważny incydent mający wpływ na bezpieczeństwo produktu. Realizowane jest przez ENISA Single Reporting Platform w rytmie 24h / 72h / 14d wobec ENISA i CSIRT wyznaczonego jako koordynator. Mechanika rejestracji w SRP, zob. rejestracja w ENISA SRP.
Zespół produktowy może być w pełni zgodny z załącznikiem I część II, nigdy nie składając zgłoszenia z artykułu 14, ponieważ większość podatności jest usuwana, zanim zaczną być aktywnie wykorzystywane. Artykuł 14 uruchamia się dopiero wtedy, gdy usuwanie nie nadąża za aktywnym wykorzystaniem. Zob. zgłaszanie z artykułu 14 CRA.
Kary za naruszenie
Niezgodność z istotnymi wymogami załącznika I, w tym z obsługą podatności z części II, podlega najwyższemu poziomowi kar administracyjnych z artykułu 64(2): do 15 000 000 EUR lub 2,5% całkowitego rocznego obrotu na poziomie światowym, w zależności od tego, która kwota jest wyższa. Obowiązek stosuje się od 11 grudnia 2027 r. dla produktów wprowadzanych do obrotu od tej daty.
Najczęściej zadawane pytania
Czy SBOM zgodnie z załącznikiem I część II punkt 1 musi obejmować zależności tranzytywne?
Dosłowne brzmienie wymaga "co najmniej zależności najwyższego poziomu", co stanowi regulacyjne minimum. Komponenty tranzytywne nie są nakazane przez punkt 1, ale są nakazane w praktyce przez punkt 2: nie da się "usuwać podatności bez zbędnej zwłoki" dla CVE w komponencie tranzytywnym, którego nigdy nie skatalogowano. Większość regulatorów i klientów oczekuje głębokiego SBOM zgodnego z BSI TR-03183 lub porównywalnymi wytycznymi. CycloneDX i SPDX kwalifikują się jako "powszechnie używane i czytelne maszynowo" formaty. Zob. wymogi SBOM w CRA.
Co oznacza "bez zbędnej zwłoki" w praktyce dla usuwania podatności na podstawie punktu 2?
CRA nie określa sztywnego SLA usuwania. "Bez zbędnej zwłoki" skaluje się z ryzykiem cyberbezpieczeństwa: krytyczna podatność z aktywnym wykorzystaniem w środowisku wymaga poprawki w dniach, podczas gdy problem o niskiej wadze może poczekać na kolejny regularny cykl. Wagę ustala się z CVSS, doprecyzowuje danymi prawdopodobieństwa wykorzystania z EPSS i potwierdza dowodami z katalogu CISA KEV, gdy podatność znajduje się na liście aktywnie wykorzystywanych CISA. Zob. ocena wagi dla operacyjnej drabiny stosowanej przez organy nadzoru rynku przy ocenie, czy producent usunął podatność "bez zbędnej zwłoki".
Czy aktualizacje bezpieczeństwa mogą być w jakichkolwiek okolicznościach płatne?
Istnieje tylko jeden wyjątek: załącznik I część II punkt 8 dopuszcza odpłatne ustalenie dla produktów wykonanych na zamówienie dostarczanych użytkownikowi biznesowemu, gdy producent i użytkownik biznesowy uzgodnili inaczej. Dla każdego innego produktu, w tym wszystkich produktów konsumenckich oraz standardowego B2B SaaS lub sprzętu, aktualizacje bezpieczeństwa muszą być bezpłatne przez cały okres wsparcia. Zamknięcie łatki bezpieczeństwa za płatnym poziomem utrzymania to bezpośrednie naruszenie punktu 8 i naraża producenta na kary najwyższego poziomu z artykułu 64(2).
Czy obowiązki z załącznika I część II trwają po zakończeniu okresu wsparcia?
Nie. Osiem obowiązków załącznika I część II stosuje się przez cały okres wsparcia zgodnie z artykułem 13(8) i wygasa dla danej wersji produktu wraz z zakończeniem tego okresu. Dwa obowiązki przeżywają okres wsparcia: obowiązek przechowywania dokumentacji technicznej zgodnie z artykułem 31 (dziesięć lat od wprowadzenia do obrotu) oraz wszelkie zgłaszanie z artykułu 14, które już biegło w chwili zakończenia okresu. Nowe podatności wykryte po zakończeniu wsparcia nie wymagają usuwania dla tej wersji, jednak producent musi opublikować jasną datę zakończenia wsparcia w informacjach o produkcie, aby użytkownicy mogli przejść na nową wersję. Zob. okres wsparcia i informowanie o zakończeniu wsparcia.
Kiedy zgłoszenie CVD staje się wyzwalaczem artykułu 14?
Wyzwalaczem jest "aktywnie wykorzystywana" zgodnie z artykułem 3(42), a nie "zgłoszona" ani "możliwa do wykorzystania". Działający proof-of-concept dołączony do zgłoszenia CVD sam w sobie nie jest wyzwalaczem artykułu 14; staje się nim, gdy istnieje uzasadnione przekonanie, że złośliwy aktor użył luki wobec rzeczywistego celu. Po przekroczeniu tego progu rozpoczyna się 24-godzinne wczesne ostrzeżenie do ENISA i CSIRT-koordynatora, następnie 72-godzinne powiadomienie i raport końcowy w ciągu 14 dni od udostępnienia środka naprawczego. Zob. zgłaszanie z artykułu 14 CRA.