Każdy producent objęty CRA potrzebuje działającego procesu obsługi podatności dla każdego produktu: wiedzieć, co znajduje się w produkcie, znajdować i usuwać podatności, regularnie testować, publikować komunikaty, przyjmować zgłoszenia zewnętrzne oraz dostarczać aktualizacje bezpieczeństwa bezpiecznie i bezpłatnie. Ta strona wyjaśnia ten model operacyjny i moment, w którym przechodzi on w pilne zgłaszanie regulacyjne.
Podsumowanie
- Obsługa podatności to operacyjny model inżynierski, którego każdy producent objęty CRA potrzebuje dla 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 są domyślnie bezpłatne, z wąskim wyjątkiem dla produktów wykonanych na zamówienie dla użytkowników biznesowych.
- Polityka CVD jest obowiązkowa, a nie opcjonalna: koordynowane ujawnianie podatności jest częścią gotowości do oznakowania CE, a nie dobrowolną dobrą praktyką.
- Obsługa podatności biegnie przez cały okres wsparcia; minimum to pięć lat od wprowadzenia do obrotu, chyba że oczekiwany okres używania produktu jest krótszy i został ujawniony.
- Obsługa podatności to nie pilne zgłaszanie regulacyjne: obsługa to codzienny proces inżynierski; zgłaszanie zaczyna się tylko przy aktywnym wykorzystaniu lub poważnych incydentach.
Cztery punkty odniesienia obsługi podatności w CRA: zakres, czas trwania, koszt aktualizacji i granica z pilnym zgłaszaniem.
Osiem obowiązków obsługi podatności
CRA nie traktuje obsługi podatności jako jednorazowej listy kontrolnej. Oczekuje ciągłego cyklu przez cały okres wsparcia, od inwentaryzacji komponentów po usuwanie podatności, ujawnianie i bezpieczne dostarczanie aktualizacji. Tabela grupuje osiem obowiązków według fazy operacyjnej, w której zwykle działają.
| Faza | Punkty | Co obejmuje | Fokus operacyjny |
|---|---|---|---|
| Wykrywanie i katalogowaniePrzyjmowanie i inwentarz | Punkty 1 i 6 | Identyfikację komponentów i znanych podatności opartą na SBOM oraz publiczny kanał zgłaszania. | Utrzymywać aktualne dane komponentów i ułatwić zgłaszającym kontakt z zespołem bezpieczeństwa produktu. |
| Inżynieria i naprawaUsuwanie podatności i testy | Punkty 2 i 3 | Niezwłoczne usuwanie podatności oraz skuteczne, regularne testowanie kodu i zależności. | Używać wagi do ustalania pilności, a potem zachowywać dowody, że poprawki i testy wykonano na czas. |
| DystrybucjaBezpieczny kanał aktualizacji | Punkty 7 i 8 | Podpisane, uwierzytelnione aktualizacje bezpieczeństwa, oddzielne od funkcji i bezpłatne poza produktami B2B na zamówienie. | Dostarczać poprawki bezpieczeństwa bez zmuszania użytkowników do aktualizacji funkcji albo płatnych poziomów utrzymania. |
| Koordynacja i ujawnianieCVD i komunikaty | Punkty 4 i 5 | Egzekwowaną politykę koordynowanego ujawniania podatności oraz publiczne komunikaty po udostępnieniu poprawki. | Prowadzić przyjmowanie zgłoszeń, powiadomienia użytkowników i uzasadnione opóźnienia ujawnienia z jednego playbooka. |
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
Obsługa podatności trwa przez cały okres wsparcia. Domyślne minimum to pięć lat od dnia wprowadzenia produktu na rynek UE, chyba że oczekiwany okres używania produktu jest krótszy i został ujawniony. Data zakończenia okresu wsparcia musi znaleźć się w informacjach o produkcie. Po zakończeniu tego okresu aktywne obowiązki obsługi wygasają dla danej wersji produktu, ale dokumentację techniczną i deklarację zgodności trzeba nadal przechowywać przez 10 lat od wprowadzenia do obrotu albo przez okres wsparcia, w zależności od tego, który okres jest dłuższy. Zob. okres wsparcia w CRA.
Obsługa podatności to nie pilne zgłaszanie
CRA rozróżnia dwa obowiązki, które działają na różnych powierzchniach i wobec różnych odbiorców:
- Obsługa podatności to proces inżynierski: SBOM, usuwanie podatności, polityka CVD, publiczne ujawnianie i bezpieczne aktualizacje. Stosuje się do wszystkich podatności przez cały okres wsparcia i należy do organizacji bezpieczeństwa produktu producenta.
- Pilne zgłaszanie regulacyjne zaczyna się tylko wtedy, gdy istnieje aktywnie wykorzystywana podatność albo poważny incydent mający wpływ na bezpieczeństwo produktu. Jest składane przez ENISA Single Reporting Platform w rytmie 24h / 72h, a następnie w formie raportu końcowego (w ciągu 14 dni od udostępnienia środka naprawczego lub łagodzącego w przypadku aktywnie wykorzystywanej podatności albo w ciągu miesiąca od powiadomienia 72h w przypadku poważnego incydentu), do ENISA i CSIRT wyznaczonego jako koordynator. Mechanika rejestracji w SRP, zob. rejestracja w ENISA SRP.
Zespół produktowy może prowadzić zgodny proces obsługi podatności i nigdy nie złożyć pilnego zgłoszenia, ponieważ większość podatności jest usuwana, zanim zaczną być aktywnie wykorzystywane. Zgłaszanie zaczyna się dopiero wtedy, gdy usuwanie nie nadąża za aktywnym wykorzystaniem albo poważnym incydentem. Zob. zgłaszanie podatności w CRA.
Ekspozycja na kary
Błędy w obsłudze podatności mogą powodować poważne kary administracyjne, ale szczegółowe poziomy należą do osobnego przewodnika egzekucyjnego. Zobacz kary i egzekwowanie CRA, aby sprawdzić poziomy kar, wyzwalacze egzekwowania i miejsce błędów obsługi podatności w szerszym modelu kar.
Najczęściej zadawane pytania
Czy SBOM musi obejmować zależności tranzytywne?
Regulacyjne minimum to zależności najwyższego poziomu, ale praktyczny SBOM zwykle powinien iść głębiej. 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: produkty wykonane na zamówienie dostarczane użytkownikowi biznesowemu mogą korzystać z odpłatnego ustalenia, 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 naraża producenta na najwyższy poziom ryzyka egzekucyjnego.
Czy obowiązki obsługi podatności trwają po zakończeniu okresu wsparcia?
Nie. Osiem obowiązków obsługi podatności wygasa dla danej wersji produktu wraz z zakończeniem okresu wsparcia. Nowe podatności wykryte po zakończeniu wsparcia nie muszą być usuwane dla tej wersji, pod warunkiem że producent opublikował jasną datę zakończenia wsparcia, aby użytkownicy mogli przejść na nową wersję. Dwa obowiązki trwają niezależnie od tego. Dokumentację techniczną oraz deklarację zgodności UE trzeba nadal przechowywać przez 10 lat od wprowadzenia do obrotu albo przez okres wsparcia, w zależności od tego, który okres jest dłuższy. Zgłaszanie jest odrębne od obsługi: jeśli producent uzyska wiedzę o aktywnie wykorzystywanej podatności albo o poważnym incydencie w produkcie, obowiązek zgłoszenia z artykułu 14 może nadal mieć zastosowanie, ponieważ nie jest powiązany z okresem wsparcia. Zob. okres wsparcia i informowanie o zakończeniu wsparcia.
Kiedy zgłoszenie CVD wymaga pilnego zgłoszenia?
Wyzwalaczem jest aktywne wykorzystanie, a nie prywatne zgłoszenie ani sam dowód możliwości wykorzystania. Działający proof-of-concept dołączony do zgłoszenia CVD sam w sobie nie wymaga zgłoszenia; wymaga go wtedy, 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 podatności w CRA.