Załącznik I Część II lit. 5 unijnego Cyber Resilience Act (rozporządzenie (UE) 2024/2847) zobowiązuje każdego producenta do wprowadzenia i egzekwowania polityki koordynowanego ujawniania podatności (CVD), natomiast art. 13 ust. 17 wymaga jednego, dostępnego dla człowieka punktu kontaktowego do przyjmowania zgłoszeń o podatnościach. Nie przewidziano żadnego wyłączenia dla MŚP. Niniejsza strona omawia, co polityka musi zawierać, jak publikować kanał kontaktowy oraz jak CVD współdziała ze zgłaszaniem na podstawie art. 14 i z szerszymi ramami Załącznika I Część II.
Podsumowanie
- Polityka CVD jest obowiązkowa na podstawie Załącznika I Część II lit. 5: pisemna, opublikowana, egzekwowana, bez progu wielkości podmiotu.
- Art. 13 ust. 17 wymaga jednego punktu kontaktowego umożliwiającego użytkownikom zgłaszanie podatności; kanał nie może ograniczać się do narzędzi automatycznych.
security.txt(RFC 9116) jest de facto standardem publikowania danych kontaktowych, jednak CRA nie narzuca konkretnego formatu.- CVD to nie art. 14: CVD reguluje relację z osobami zgłaszającymi podatności; art. 14 to regulacyjny zegar do ENISA i koordynującego CSIRT w przypadku aktywnie wykorzystywanych podatności.
- Publiczne ujawnienie naprawionych podatności jest wymagane na podstawie Załącznika I Część II lit. 4, z wąskim wyjątkiem dla opóźnienia -- gdy ryzyko bezpieczeństwa związane z publikacją przewyższa korzyść, dopóki użytkownicy nie mieli możliwości zastosowania łatki.
- Obowiązują kary najwyższego rzędu: do €15 000 000 lub 2,5% całkowitego rocznego obrotu na poziomie światowym na podstawie art. 64 ust. 2, w zależności od tego, która kwota jest wyższa.
Cztery filary zgodnej z CRA postawy w zakresie CVD: obowiązek posiadania polityki, obowiązek kontaktowy, standard publikacji oraz pułap kary.
Czego CRA rzeczywiście wymaga w zakresie CVD
Załącznik I Część II lit. 5 jest krótki. Dosłowne brzmienie rozporządzenia (UE) 2024/2847:
(5) wprowadzić i egzekwować politykę w zakresie koordynowanego ujawniania podatności;
To pojedyncze zdanie zawiera cztery elementy operacyjne, z których każdy może zawieść w praktyce w odmienny sposób:
Oznacza istnienie pisemnej, publicznie dostępnej polityki. Nieudokumentowany wewnętrzny zwyczaj triażu wiadomości na adres security@ nie spełnia tego wymogu.
Wymaga stosowania polityki w praktyce, nie tylko jej opublikowania. Terminy potwierdzenia odbioru, zobowiązania do triażu i warunki ujawnienia zawarte w dokumencie muszą być przestrzegane w rzeczywistości. Polityka obiecująca potwierdzenie w ciągu 72 godzin, które rutynowo zajmuje trzy tygodnie, nie jest egzekwowana.
Jest kierunkiem, któremu polityka musi służyć. Załącznik I Część II lit. 6 stanowi to wprost: producenci muszą "ułatwiać wymianę informacji o potencjalnych podatnościach", "w tym przez podanie adresu kontaktowego".
Brak w tekście RCC. Motyw 76 opisuje CVD jako ustrukturyzowany proces zgłaszania i wymienia programy bug-bounty jako zachętę do zgłoszeń. Praktyka branżowa (ISO/IEC 29147, wytyczne dobrych praktyk ENISA) traktuje safe-harbour dla badań w dobrej wierze jako normę polityki CVD; sam RCC tego nie kodyfikuje.
Szersze ramy Załącznika I Część II (osiem ponumerowanych obowiązków, których jednym jest CVD) omówiono w artykule obsługa podatności według CRA.
Jeden punkt kontaktowy (art. 13 ust. 17)
Art. 13 ust. 17 uzupełnia Załącznik I Część II lit. 5 i nadaje mu kształt operacyjny. Dosłowne brzmienie:
- Na potrzeby niniejszego rozporządzenia producenci wyznaczają jeden punkt kontaktowy, umożliwiający użytkownikom bezpośrednią i szybką komunikację z nimi, w tym w celu ułatwienia zgłaszania podatności produktu z elementami cyfrowymi.
Producenci zapewniają, że jeden punkt kontaktowy jest łatwo identyfikowalny przez użytkowników. Zamieszczają go również w informacjach i instrukcjach dla użytkownika określonych w Załączniku II.
Jeden punkt kontaktowy umożliwia użytkownikom wybór preferowanego środka komunikacji i nie ogranicza takich środków do narzędzi automatycznych.
Trzy zasady, które należy wziąć pod uwagę:
- Łatwa identyfikowalność. Dane kontaktowe muszą być widoczne w informacjach o produkcie, w instrukcjach z Załącznika II oraz na publicznie dostępnej stronie internetowej. Kontakt dostępny wyłącznie po przeczytaniu polityki prywatności nie spełnia tego wymogu.
- Wiele kanałów. "Wybór preferowanego środka komunikacji" oznacza co najmniej dwa. Działająca skrzynka pocztowa
security@wraz z formularzem internetowym, z dostępnym kluczem PGP dla wrażliwych zgłoszeń, stanowi realistyczne minimum. - Brak przyjmowania wyłącznie przez automaty. "Nie ogranicza takich środków do narzędzi automatycznych" wyklucza sytuację, w której jedynym dostępnym adresem jest
security-noreply@lub chatbot zamykający zgłoszenia bez weryfikacji przez człowieka.
CRA nie wymaga oddzielenia wsparcia dla konsumentów od przyjmowania zgłoszeń o podatnościach, jednak większość producentów korzysta z dedykowanej skrzynki bezpieczeństwa kierowanej do zespołu ds. bezpieczeństwa produktu, aby CVD był wyodrębniony od ogólnego wsparcia.
Publikowanie polityki CVD: security.txt i inne metody
CRA nie wymienia security.txt, RFC 9116 ani żadnego konkretnego formatu publikacji. Wymaga kanału kontaktowego, który jest "łatwo identyfikowalny", oraz polityki CVD, która jest "wprowadzona i egzekwowana". W tych ramach branża przyjęła security.txt jako de facto standard.
Pola RFC 9116 warte opublikowania:
| Pole | Przeznaczenie |
|---|---|
Contact: |
Jeden lub więcej kanałów zgłaszania. Wymagany co najmniej jeden. |
Expires: |
Data, po której plik staje się nieaktualny. Wymagane przez RFC 9116. |
Encryption: |
Klucz publiczny (PGP, S/MIME) do poufnych zgłoszeń. |
Acknowledgments: |
Strona wyrażająca podziękowanie badaczom za poprzednie ujawnienia. |
Policy: |
Łącze do pełnego dokumentu polityki CVD. |
Preferred-Languages: |
Języki, w których działa zespół triażu. |
Canonical: |
URL, pod którym plik powinien się znajdować. |
Gdzie hostować plik. Standardowe miejsce to https://example.com/.well-known/security.txt, serwowany przez HTTPS. RFC 9116 akceptuje również https://example.com/security.txt jako alternatywę, jednak preferowane jest well-known.
Poza security.txt. Standard "łatwej identyfikowalności" oznacza, że dane kontaktowe powinny pojawić się również na stronie wsparcia lub kontaktu dla produktu, w instrukcjach z Załącznika II, w dokumentacji dla deweloperów produktów API, a także na publicznej stronie polityki CVD, do której badacze mogą się odwoływać.
Producenci prowadzący programy nagród za błędy (bug bounty) zazwyczaj dodają HackerOne, Bugcrowd lub Intigriti jako dodatkowe kanały przyjmowania zgłoszeń. Kanały te spełniają obowiązek "ułatwiania zgłaszania" (Załącznik I Część II lit. 6) i obowiązek "bez ograniczenia do narzędzi automatycznych" (art. 13 ust. 17) wyłącznie wtedy, gdy są otwarte na zewnętrznych badaczy z odpowiedzią człowieka. Prywatny, prowadzony na zaproszenie program bounty sam w sobie nie spełnia wymogu publicznego kanału kontaktowego i musi współistnieć z kanałem publicznym.
Przyjmowanie i triaż zgłoszeń o podatnościach
Polityka CVD jest egzekwowana przez udokumentowany proces przyjmowania zgłoszeń i ich triażu. Elementy opisane poniżej nie są wprost wymagane przez CRA, jednak tak wygląda egzekwowalna polityka w praktyce.
| Etap | Co robi egzekwowalna polityka | Częsty błąd |
|---|---|---|
| Potwierdzenie odbioru | Potwierdzenie przyjęcia w ramach opublikowanego SLA. Branżowe minimum to 72 godziny; wiele polityk zobowiązuje się do 24 lub 48 godzin dla zgłoszeń o wysokiej ważności. To, co się publikuje, musi być przestrzegane. | "Odpowiemy niezwłocznie" -- sformułowanie nieegzekwowalne samo w sobie. |
| Triaż | Walidacja (powtarzalność na obsługiwanej wersji), ocena ważności (CVSS v3.1 lub v4.0 z korektami środowiskowymi, zob. ocena ważności), ocena możliwości wykorzystania (znany exploit, publiczny PoC lub dowód aktywnego wykorzystania -- to jest próg art. 14) oraz określenie zakresu dotkniętych wersji na podstawie SBOM. | Zamknięcie zgłoszenia jako "nie da się odtworzyć" bez podania testowanego zakresu wersji. |
| Relacja z badaczem | Opublikowanie trzech elementów: klauzuli bezpiecznego portu dla działalności w dobrej wierze w zdefiniowanym zakresie; pozycji poza zakresem (dane produkcyjne, inżynieria społeczna, ataki na dostępność wobec działającej infrastruktury); oczekiwań dotyczących ujawnienia (okno embarga, warunki naprawy, uznanie autorstwa). Typowe embargo: do czasu wydania łatki, twarde ograniczenie 90 dni. | Zastrzeżenie prawa do podjęcia działań prawnych wobec badań w zakresie -- co niszczy kanał. |
| Zamknięcie pętli | Każde zgłoszenie otrzymuje odpowiedź końcową: naprawione (z komunikatem bezpieczeństwa i CVE), duplikat, nie zostanie naprawione (z uzasadnieniem) lub poza zakresem. | Potwierdzenie odbioru i brak dalszego kontaktu -- najczęstsza przyczyna, dla której polityki CVD nie wyglądają na egzekwowane z zewnątrz. |
Koordynacja z ENISA i zewnętrznymi badaczami
Przyjmowanie zgłoszeń CVD i zgłaszanie do ENISA na podstawie art. 14 to odrębne obowiązki wobec różnych odbiorców. Polityka CVD reguluje relację z osobą zgłaszającą. Art. 14 reguluje regulacyjne powiadomienie producenta do ENISA i koordynującego CSIRT. Oba toczą się równolegle i uruchamiane są innymi zdarzeniami.
Kiedy zgłoszenie CVD staje się zdarzeniem wyzwalającym art. 14. Art. 14 ust. 1 zobowiązuje producentów do zgłaszania "każdej aktywnie wykorzystywanej podatności" za pośrednictwem SRP. Art. 14 ust. 2 określa harmonogram: wczesne ostrzeżenie w ciągu 24 godzin, powiadomienie w ciągu 72 godzin oraz raport końcowy w ciągu 14 dni od udostępnienia środka naprawczego. Zdarzeniem wyzwalającym jest "aktywne wykorzystanie", a nie samo "zgłoszenie". Zgłoszenie CVD z działającym dowodem koncepcji samo w sobie nie stanowi zdarzenia wyzwalającego art. 14; staje się nim w momencie, gdy istnieje uzasadnione przekonanie, że złośliwy podmiot użył luki wobec rzeczywistego celu. W przypadku poważnych incydentów na podstawie art. 14 ust. 3 i 14 ust. 4 harmonogram wynosi 24 godziny, 72 godziny, a następnie raport końcowy w ciągu jednego miesiąca od powiadomienia w ciągu 72 godzin. Oba strumienie mają wspólne wczesne etapy i rozchodzą się na etapie raportu końcowego. Nie należy łączyć ich w jedno ujęcie "24h/72h/14d". Zob. zgłaszanie podatności CRA na podstawie art. 14.
ENISA i CSIRT wyznaczone jako koordynatorzy. Art. 14 ust. 7 wymaga przesłania zgłoszenia za pośrednictwem SRP, korzystając z elektronicznego punktu końcowego CSIRT wyznaczonego jako koordynator w państwie członkowskim siedziby głównej producenta. Motyw 76 stanowi szersze uzasadnienie: producenci mogą otrzymywać zgłoszenia bezpośrednio lub pośrednio za pośrednictwem CSIRT wyznaczonego jako koordynator na podstawie art. 12 ust. 1 dyrektywy (UE) 2022/2555 (NIS2). Informacje o mechanice rejestracji w SRP znajdziesz w artykule rejestracja w ENISA SRP.
Koordynacja z badaczami. Gdy badacz proponuje embargo na czas dostarczania łatki, należy udokumentować uzgodnione okno i je przestrzegać. Gdy badacz odmawia lub publikuje przedwcześnie, polityka CVD powinna określać sposób postępowania -- zazwyczaj poprzez przyspieszenie komunikatu i łatki.
Terminy publicznego ujawnienia
Publiczne ujawnienie naprawionej podatności nie jest opcjonalne w ramach CRA. Załącznik I Część II lit. 4 zobowiązuje producentów -- "po udostępnieniu aktualizacji bezpieczeństwa" -- do "dzielenia się i publicznego ujawniania informacji o naprawionych podatnościach, w tym opisu podatności, informacji umożliwiających użytkownikom identyfikację produktu z elementami cyfrowymi, którego te podatności dotyczą, ich skutków, ważności oraz jasnych i dostępnych informacji pomagających użytkownikom usunąć podatności". Ten sam punkt dopuszcza opóźnienie "w należycie uzasadnionych przypadkach, gdy producenci uznają, że ryzyko bezpieczeństwa związane z publikacją przewyższa korzyści bezpieczeństwa", jednak wyłącznie "do czasu, gdy użytkownicy mieli możliwość zastosowania odpowiedniej łatki".
Okna embarga. De facto branżowy standard to 90 dni od zgłoszenia do publicznego ujawnienia, licząc od daty pierwszego powiadomienia producenta. Project Zero, CERT/CC i większość krajowych CSIRT stosuje lub zbliża się do tego punktu odniesienia. W przypadku aktywnie wykorzystywanych podatności okno zazwyczaj skraca się do dni, ponieważ art. 14 ust. 2 lit. c wymaga raportu końcowego w ciągu 14 dni od udostępnienia środka naprawczego.
Format publicznego ujawnienia. Komunikat bezpieczeństwa zgodny z CRA powinien zawierać co najmniej identyfikator CVE, czytelny opis, dotkniętą wersję produktu, ważność (podstawowy wynik CVSS), wpływ, zalecenia naprawcze oraz uznanie autorstwa, jeśli badacz wyraził zgodę na wymienienie go z imienia. CSAF (Common Security Advisory Framework) to maszynowo czytelny format, którego oczekuje większość krajowych CSIRT i baza danych podatności ENISA.
"Należycie uzasadnione" opóźnienie z lit. 4 jest wąskie. Pozwala wstrzymać publiczne szczegóły do czasu, gdy użytkownicy będą mogli zastosować łatkę; nie pozwala na ciche naprawy, które nigdy nie zostają opisane. Producent, który wydaje łatkę i nigdy nie opisuje tego, co naprawił, narusza lit. 4 bez względu na intencje.
Częste błędy
| Błąd | Dlaczego nie spełnia wymagań CRA |
|---|---|
| Działania prawne wobec badaczy działających w dobrej wierze | Narusza "egzekwowanie polityki koordynowanego ujawniania podatności" (Załącznik I Część II lit. 5) i niszczy kanał przyjmowania zgłoszeń wymagany przez lit. 6. |
| Brak publicznego kanału kontaktowego, tylko wewnętrzny portal po zalogowaniu | Narusza wymóg "łatwej identyfikowalności" z art. 13 ust. 17 oraz "podanie adresu kontaktowego" z Załącznika I Część II lit. 6. |
Autoresponder security-noreply@ bez ludzkiego triażu |
Art. 13 ust. 17 zakazuje ograniczania komunikacji do narzędzi automatycznych. |
| Potwierdzenie odbioru i brak dalszego kontaktu | Polityka jest "wprowadzona", ale nie "egzekwowana". Załącznik I Część II lit. 5 wymaga obu. |
| Zamykanie zgłoszeń jako "nie zostanie naprawione" bez uzasadnienia | Z zewnątrz nieodróżnialne od ignorowania zgłoszenia; badacze eskalują przez publikację. |
| Bundlowanie poprawek bezpieczeństwa w wydaniach funkcjonalnych, które użytkownicy odraczają | Narusza Załącznik I Część II lit. 2: aktualizacje bezpieczeństwa muszą być oddzielalne od aktualizacji funkcjonalności "tam, gdzie jest to technicznie wykonalne". |
| Ciche łatanie bez komunikatu bezpieczeństwa | Narusza obowiązek publicznego ujawnienia z Załącznika I Część II lit. 4. |
| Traktowanie przyjmowania zgłoszeń CVD jako zgłoszenia do ENISA na podstawie art. 14 | Różni odbiorcy, różne obowiązki. CVD nie zwalnia z art. 14, a art. 14 nie zwalnia z CVD. |
Często zadawane pytania
Czy mali producenci muszą posiadać politykę CVD zgodnie z CRA?
Tak. Obowiązek polityki CVD nie ma progu wielkości. Dotyczy każdego producenta wprowadzającego na rynek UE produkt z elementami cyfrowymi, niezależnie od liczby pracowników lub obrotu. Mikroprzedsiębiorstwa i małe przedsiębiorstwa korzystają z wąskiej ulgi w karach finansowych dotyczącej 24-godzinnych terminów art. 14 na mocy Artykułu 64(10)(a), który obejmuje zarówno Artykuł 14(2)(a) dla aktywnie wykorzystywanych podatności, jak i Artykuł 14(4)(a) dla poważnych incydentów. Ulga dotyczy wyłącznie tych kar, nie obowiązku materialnego, i nie obejmuje średnich przedsiębiorstw. (Załącznik I Część II punkt 5; Artykuł 64(10)(a); Artykuł 3(19).)
Czy `security.txt` jest obowiązkowy zgodnie z CRA?
Nie. CRA nie wymienia security.txt ani RFC 9116. Nakłada obowiązek posiadania "łatwo identyfikowalnego" jednego punktu kontaktowego i adresu kontaktowego do zgłaszania podatności. security.txt jest de facto standardem stosowanym do wypełnienia tych obowiązków, ponieważ jest tym, czego automatyczne skanery i większość badaczy szuka w pierwszej kolejności, jednak dane kontaktowe opublikowane w widocznym miejscu na publicznej stronie bezpieczeństwa i w instrukcjach z Załącznika II również spełniają wymagania. Twardym wymogiem jest opublikowany, działający, dostępny dla człowieka kanał; format jest kwestią wyboru. (Artykuł 13(17); Załącznik I Część II punkt 6; RFC 9116.)
Czy kanał przyjmowania zgłoszeń CVD może być tym samym kanałem co zgłoszenie do ENISA na podstawie art. 14?
Nie. To różni odbiorcy i różne obowiązki. Przyjmowanie zgłoszeń CVD to kanał, przez który zewnętrzni badacze i użytkownicy zgłaszają podatności producentowi. Zgłoszenie na podstawie art. 14 to regulacyjne powiadomienie producenta kierowane do ENISA i koordynującego CSIRT za pośrednictwem Jednolitej Platformy Zgłaszania. Badacz nie składa zgłoszenia do SRP; robi to producent. Mylenie tych dwóch kanałów prowadzi albo do niepotwierdzenia odbioru zgłoszenia badaczowi (naruszenie CVD), albo do niezawiadomienia ENISA w przypadku potwierdzenia eksploitacji (groźba kary najwyższego rzędu). (Artykuł 14(1) i 14(7); Artykuł 16; Artykuł 64(2).)
Co się dzieje, gdy zewnętrzny badacz zgłosi aktywnie wykorzystywaną podatność?
Równolegle uruchamiają się dwa zegary. Proces CVD reguluje relację z badaczem: potwierdzenie odbioru, triaż, uzgodnienie embarga, wydanie łatki, komunikat bezpieczeństwa, uznanie autorstwa. Proces art. 14 reguluje relację z regulatorem: wczesne ostrzeżenie do ENISA i koordynującego CSIRT w ciągu 24 godzin, powiadomienie w ciągu 72 godzin, raport końcowy w ciągu 14 dni od udostępnienia środka naprawczego. Zegar 24-godzinny startuje, gdy producent uzyska świadomość aktywnej eksploitacji; oczekiwanie na pewność forensyczną spowoduje przekroczenie terminu. Oba procesy toczą się równolegle i kończą na różnych płaszczyznach. (Artykuł 14(1) i 14(2); Załącznik I Część II punkt 5.)
Czy polityka CVD musi oferować badaczom klauzulę bezpiecznego portu?
Nie, RCC nie wymaga wyraźnej klauzuli safe-harbour. Motyw 76 opisuje CVD jako ustrukturyzowany proces zgłaszania i wymienia programy bug-bounty jako sposób motywowania do zgłoszeń; nie kodyfikuje safe harbour ani ograniczenia ryzyka prawnego dla badaczy. Norma pochodzi z praktyki branżowej, nie z rozporządzenia: ISO/IEC 29147, wytyczne dobrych praktyk ENISA i większość rekomendacji krajowych CSIRT-ów zbiegają się na pisemnej klauzuli safe-harbour obejmującej badania w dobrej wierze w opublikowanym zakresie. Polityka zastrzegająca prawo do działań prawnych przeciwko badaniom w zakresie doprowadza do upadku kanału i w praktyce nie spełnia połowy "egzekwować" Załącznika I Części II punktu 5. (Motyw 76; ISO/IEC 29147; wytyczne ENISA dot. CVD.)