Każda osoba, która znajdzie podatność w Twoim produkcie, potrzebuje jasnego, dostępnego dla człowieka sposobu zgłoszenia, a Twój zespół potrzebuje pisemnej polityki opisującej, jak takie zgłoszenie zostanie potwierdzone, poddane triażowi, naprawione i ujawnione. Zgodnie z unijnym Cyber Resilience Act (Rozporządzenie (UE) 2024/2847) oznacza to wprowadzenie i egzekwowanie polityki skoordynowanego ujawniania podatności (CVD) oraz wskazanie pojedynczego punktu kontaktowego do przyjmowania zgłoszeń. Nie przewidziano wyłączenia dla MŚP. Ta strona omawia, co polityka musi zawierać, jak opublikować kanał kontaktowy oraz jak CVD łączy się ze zgłaszaniem podatności i z szerszymi ramami obsługi podatności.
Podsumowanie
- Polityka CVD jest obowiązkowa. Pisemna, opublikowana, egzekwowana, bez progu wielkości podmiotu. Szczegółowo opisano to w sekcji Czego CRA rzeczywiście wymaga poniżej.
- Pojedynczy punkt kontaktowy jest wymagany. Użytkownicy muszą móc skontaktować się z człowiekiem; kanału nie wolno ograniczać do narzędzi zautomatyzowanych.
security.txt(RFC 9116) to de facto przyjęta konwencja publikowania danych kontaktowych, choć CRA nie narzuca konkretnego formatu.- CVD to nie to samo co zgłaszanie do ENISA. CVD reguluje relację ze zgłaszającym; regulacyjny zegar do ENISA i koordynującego CSIRT biegnie równolegle. Zobacz Koordynacja z ENISA poniżej.
- Publiczne ujawnienie naprawionych podatności jest wymagane, z wąskim wyjątkiem opóźnienia w sytuacjach, w których ryzyko dla bezpieczeństwa związane z publikacją przewyższa korzyść, dopóki użytkownicy nie mieli możliwości zastosowania poprawki.
- Szczegóły kar należą do przewodnika egzekwowania. Zobacz kary i egzekucję po drabinę kar i środki rynkowe.
Cztery filary zgodnej z CRA postawy CVD: polityka, kontakt, publikacja i odesłanie do egzekwowania.
Czego CRA rzeczywiście wymaga w zakresie CVD
Sam wymóg jest krótki: producenci muszą "wprowadzić i egzekwować politykę skoordynowanego ujawniania podatności". To jedno zdanie zawiera cztery elementy operacyjne, z których każdy może zawieść w odmienny sposób:
| Wymóg | Co to oznacza w praktyce | Typowy błąd |
|---|---|---|
| WprowadzićUdokumentowana polityka | Istnieje pisemna, dostępna polityka. Wyjaśnia zgłaszającym, co mieści się w zakresie, jak zgłaszać, jakiej odpowiedzi można oczekiwać i kiedy następuje ujawnienie. | Nieudokumentowany wewnętrzny zwyczaj triażu wiadomości na adres security@ nie spełnia tego wymogu. |
| EgzekwowaćDziałający proces | Polityka jest stosowana, a nie tylko opublikowana. Terminy potwierdzenia odbioru, zobowiązania w zakresie triażu i warunki ujawnienia opisane w dokumencie są przestrzegane w praktyce. | Polityka obiecująca potwierdzenie w ciągu 72 godzin, które rutynowo zajmuje trzy tygodnie, nie jest egzekwowana. |
| Ułatwiać zgłaszanieDostępny kanał | Polityka ułatwia zewnętrznym zgłaszającym dzielenie się informacjami o podatnościach: adres kontaktowy, opublikowany proces oraz dostępny dla człowieka kanał, który nie jest ukryty za logowaniem lub chatbotem. | Portal dostępny wyłącznie po zalogowaniu, kanał obsługiwany tylko przez bota lub ukryta ścieżka kontaktu nie realizują kierunku tego obowiązku. |
| Nie karać zgłaszającychNorma dobrej wiary | Nie jest to dosłowny przepis CRA. CRA opisuje CVD jako ustrukturyzowane zgłaszanie i odnotowuje, że programy bug-bounty mogą motywować do zgłoszeń. ISO/IEC 29147 oraz wytyczne ENISA dobrych praktyk traktują bezpieczny port dla badań prowadzonych w dobrej wierze jako typowy element polityki CVD. | Zastrzeganie sobie działań prawnych wobec badań w zakresie i w dobrej wierze niszczy kanał zgłoszeń, nawet jeśli adres kontaktowy istnieje. |
Szersze ramy (osiem ponumerowanych obowiązków, z których CVD jest jednym) opisano w artykule obsługa podatności.
Pojedynczy punkt kontaktowy
Polityka CVD działa tylko wtedy, gdy zgłaszający potrafią znaleźć realny kontakt i mają ludzką ścieżkę do producenta. Obowiązek pojedynczego punktu kontaktowego z CRA przekłada się na trzy konkretne wymagania :
- Łatwa rozpoznawalność. Kontakt musi być widoczny w informacjach o produkcie i w instrukcjach towarzyszących produktowi. Zamieszczenie go na publicznie dostępnej stronie internetowej jest zalecane i przyjętą normą branżową, ale CRA nie wymienia witryny jako osobnego wymaganego kanału. Kontakt dostępny dopiero po przeczytaniu polityki prywatności nie spełnia tego testu.
- Wiele kanałów. "Wybór preferowanych środków komunikacji" oznacza co najmniej dwa. Działająca skrzynka
security@plus formularz internetowy, z kluczem PGP dostępnym dla wrażliwych zgłoszeń, to realistyczne minimum. - Bez wyłącznie zautomatyzowanej obsługi. "Nie ogranicza tych środków do narzędzi zautomatyzowanych" wyklucza sytuację, w której jedynym dostępnym adresem jest
security-noreply@lub chatbot, który zamyka zgłoszenia bez weryfikacji człowieka.
CRA nie wymaga oddzielenia obsługi konsumentów od przyjmowania zgłoszeń o podatnościach, ale większość producentów prowadzi dedykowaną skrzynkę bezpieczeństwa kierowaną do zespołu bezpieczeństwa produktu, aby CVD pozostało odseparowane od ogólnego wsparcia.
Publikowanie polityki CVD: security.txt i nie tylko
CRA nie wymienia security.txt, RFC 9116 ani żadnego konkretnego formatu publikacji. Wymaga kanału kontaktowego "łatwo rozpoznawalnego" oraz polityki CVD "wprowadzonej i egzekwowanej". W tych ramach branża przyjęła security.txt jako konwencję de facto.
Pola RFC 9116 warte opublikowania:
| Pole | Cel |
|---|---|
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 wymieniająca badaczy za poprzednie ujawnienia. |
Policy: |
Łącze do pełnego dokumentu polityki CVD. |
Preferred-Languages: |
Języki, w których pracuje zespół triażu. |
Canonical: |
URL, pod którym plik powinien się znajdować. |
Gdzie umieścić plik. Konwencjonalna lokalizacja to https://example.com/.well-known/security.txt, serwowany przez HTTPS. RFC 9116 dopuszcza również https://example.com/security.txt jako fallback, ale well-known jest preferowane.
Poza security.txt. Standard "łatwej rozpoznawalności" oznacza, że dane kontaktowe powinny pojawić się także na stronie wsparcia lub kontaktu produktu, w instrukcjach towarzyszących produktowi, w dokumentacji deweloperskiej produktów API oraz na publicznej stronie polityki CVD, do której badacze mogą się odwoływać.
Producenci prowadzący programy nagród za błędy zwykle dodają HackerOne, Bugcrowd lub Intigriti jako dodatkowe kanały przyjmowania. Spełniają one obowiązek "ułatwiania zgłaszania" oraz wymóg "bez ograniczenia do narzędzi zautomatyzowanych" tylko wtedy, gdy są otwarte na zewnętrznych zgłaszających z ludzką odpowiedzią. Prywatny program nagród działający na zaproszenie 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 i triażu. Mechanika opisana poniżej nie jest wprost wymagana przez CRA, ale tak wygląda egzekwowalna polityka w praktyce.
| Etap | Co robi egzekwowalna polityka | Typowy błąd |
|---|---|---|
| Potwierdzenie odbioru | Potwierdź odbiór 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 dotkliwości. To, co publikujesz, jest tym, co robisz. | "Odpowiemy niezwłocznie" jest sformułowaniem nieegzekwowalnym samym w sobie. |
| Triaż | Walidacja (powtarzalność na obsługiwanej wersji), ocena dotkliwości (CVSS v3.1 lub v4.0 z korektami środowiskowymi, zobacz ocena dotkliwości), ocena możliwości wykorzystania (znany exploit, publiczny PoC lub dowód użycia w środowisku, co uruchamia eskalację regulacyjną) oraz zakres dotkniętych wersji na podstawie SBOM. | Zamknięcie jako "nie można odtworzyć" bez podania przetestowanego zakresu wersji. |
| Relacja ze zgłaszającym | Opublikuj trzy rzeczy: klauzulę bezpiecznego portu dla badań w dobrej wierze w zakresie; pozycje poza zakresem (dane produkcyjne, inżynieria społeczna, denial-of-service wobec działającej infrastruktury); oraz oczekiwania dotyczące ujawnienia (okno embarga, warunki naprawy, uznanie autorstwa). Typowe embargo: do czasu wydania łatki, twarde ograniczenie 90 dni. | Zastrzeganie sobie prawa do 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. | Pojedyncze potwierdzenie i następnie milczenie, najczęstszy powód, dla którego polityki CVD nie wyglądają z zewnątrz na egzekwowane. |
Koordynacja z ENISA i zewnętrznymi badaczami
Przyjmowanie zgłoszeń CVD i zgłaszanie do ENISA to różne obowiązki wobec różnych odbiorców. Polityka CVD reguluje relację ze zgłaszającym. Regulacyjne powiadomienie reguluje Twój obowiązek wobec ENISA i koordynującego CSIRT. Toczą się równolegle i uruchamiane są innymi zdarzeniami.
Kiedy zgłoszenie CVD staje się regulacyjnym wyzwalaczem. Producenci muszą zgłaszać "jakąkolwiek aktywnie wykorzystywaną podatność" przez SRP w cyklu 24 godzin, 72 godzin oraz 14 dni. Wyzwalaczem jest "aktywne wykorzystanie", a nie "zgłoszenie". Zgłoszenie CVD z działającym dowodem koncepcji samo w sobie nie jest jeszcze regulacyjnym wyzwalaczem; staje się nim, gdy istnieją wiarygodne dowody, że złośliwy podmiot wykorzystał podatność w systemie bez upoważnienia.
Poważne incydenty biegną w innym rytmie: 24 godziny, 72 godziny, a następnie raport końcowy w ciągu miesiąca od powiadomienia 72-godzinnego. 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". Zobacz zgłaszanie podatności.
ENISA i CSIRT-y wyznaczone jako koordynatorzy. Zgłoszenie biegnie przez SRP, z wykorzystaniem elektronicznego punktu końcowego CSIRT wyznaczonego jako koordynator w państwie członkowskim głównej siedziby producenta. Producenci mogą otrzymywać zgłoszenia bezpośrednio lub pośrednio przez CSIRT wyznaczony jako koordynator w trybie dyrektywy NIS2. Mechanikę rejestracji w SRP opisano w artykule rejestracja w SRP ENISA.
Koordynacja z badaczami. Gdy badacz proponuje embargo na czas wydania łatki, udokumentuj uzgodnione okno i je przestrzegaj. Gdy badacz odmawia lub publikuje przedwcześnie, polityka CVD powinna określać reakcję, zazwyczaj przez przyspieszenie komunikatu i łatki.
Terminy publicznego ujawnienia
Publiczne ujawnienie naprawionej podatności nie jest opcjonalne w ramach CRA. Po udostępnieniu aktualizacji zabezpieczeń producenci muszą udostępnić i publicznie ujawnić opis podatności, informacje pozwalające użytkownikom zidentyfikować dotknięty produkt, skutki, dotkliwość oraz jasne wskazówki naprawcze. Opóźnienie jest dopuszczalne "w należycie uzasadnionych przypadkach", w których ryzyko dla bezpieczeństwa związane z publikacją przewyższa korzyść, ale tylko "do czasu, gdy użytkownicy będą mogli wprowadzić odpowiednią poprawkę".
Okna embarga. De facto standard branżowy to 90 dni od zgłoszenia do publicznego ujawnienia, licząc od dnia, w którym producent został po raz pierwszy powiadomiony. Project Zero, CERT/CC i większość krajowych CSIRT operuje przy tym punkcie odniesienia lub blisko niego. W przypadku aktywnie wykorzystywanych podatności okno zwykle skraca się do dni, ponieważ raport końcowy do regulatora jest należny 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, jasny opis, dotknięty produkt i zakres wersji, dotkliwość (podstawowy wynik CVSS), wpływ, wskazania naprawcze oraz uznanie autorstwa, gdy zgłaszający zgodził się być wymieniony. CSAF (Common Security Advisory Framework) to maszynowo czytelny format oczekiwany przez większość krajowych CSIRT oraz bazę danych podatności ENISA.
Opóźnienie "należycie uzasadnione" jest wąskie. Pozwala wstrzymać publiczne szczegóły do czasu, gdy użytkownicy mogą zastosować poprawkę; nie pozwala na ciche naprawy, które nigdy nie zostają opisane. Producent, który wydaje łatkę i nigdy nie opisuje, co naprawił, narusza obowiązek publicznego ujawnienia, niezależnie od intencji.
Częste błędy
| Błąd | Dlaczego nie spełnia wymagań CRA |
|---|---|
| Działania prawne wobec badaczy w dobrej wierze | Łamie obowiązek "egzekwowania polityki skoordynowanego ujawniania podatności" i niszczy kanał przyjmowania zgłoszeń, którego wymaga ten sam obowiązek. |
| Brak publicznego kanału kontaktowego, tylko wewnętrzny portal po zalogowaniu | Nie spełnia obowiązku "łatwej rozpoznawalności" pojedynczego punktu kontaktowego ani obowiązku "podania adresu kontaktowego". |
Autoresponder security-noreply@ bez ludzkiego triażu |
Pojedynczy punkt kontaktowy nie może ograniczać komunikacji do narzędzi zautomatyzowanych. |
| Potwierdzenie odbioru i brak dalszego kontaktu | Polityka jest "wprowadzona", ale nie "egzekwowana"; oba elementy są wymagane. |
| Zamykanie zgłoszeń jako "nie zostanie naprawione" bez uzasadnienia | Z zewnątrz nieodróżnialne od ignorowania zgłoszenia; badacze eskalują przez publikację. |
| Łączenie poprawek bezpieczeństwa z wydaniami funkcjonalnymi, które użytkownicy odraczają | 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. |
| Traktowanie przyjmowania zgłoszeń CVD jako zgłoszenia do ENISA | Różni odbiorcy, różne obowiązki. CVD nie zwalnia ze zgłoszenia regulacyjnego, a zgłoszenie regulacyjne nie zwalnia z CVD. |
Najczęściej zadawane pytania
Czy mali producenci potrzebują polityki CVD zgodnie z CRA?
Tak. Obowiązek polityki CVD nie ma progu wielkości. Dotyczy każdego producenta wprowadzającego do obrotu w 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 dotyczącej 24-godzinnych terminów wczesnego ostrzeżenia, ale ulga obejmuje wyłącznie [te kary](/cra-compliance/penalties-and-enforcement), nie sam obowiązek materialny, i nie rozciąga się na średnie przedsiębiorstwa. Dwuosobowy producent firmware'u potrzebuje opublikowanej polityki CVD, kanału kontaktowego oraz procesu triażu w taki sam sposób jak duży dostawca.
Czy `security.txt` jest obowiązkowy zgodnie z CRA?
Nie. CRA nie wymienia security.txt ani RFC 9116. Nakłada obowiązek "łatwo rozpoznawalnego" pojedynczego punktu kontaktowego oraz adresu kontaktowego do zgłaszania podatności. security.txt jest konwencją de facto stosowaną do wypełnienia tych obowiązków, ponieważ jest tym, czego automatyczne skanery i większość badaczy szuka w pierwszej kolejności, ale dane kontaktowe opublikowane w widocznym miejscu na publicznej stronie bezpieczeństwa i w instrukcjach towarzyszących produktowi również są zgodne. Twardym wymogiem jest opublikowany, działający, dostępny dla człowieka kanał; format jest kwestią wyboru.
Czy kanał przyjmowania zgłoszeń CVD może być tym samym kanałem, co zgłoszenie do ENISA?
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 do ENISA to regulacyjne powiadomienie producenta kierowane do ENISA i koordynującego CSIRT, składane przez pojedynczą platformę sprawozdawczą. 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 wykorzystania (poważne ryzyko sankcji).
Co się dzieje, gdy zewnętrzny badacz zgłasza aktywnie wykorzystywaną podatność?
Równolegle uruchamiają się dwa zegary. Proces CVD reguluje relację z badaczem: potwierdzenie odbioru, triaż, uzgodnienie embarga, wydanie łatki, opublikowanie komunikatu, uznanie autorstwa zgłaszającego. Proces regulacyjny reguluje relację z ENISA i koordynującym CSIRT: wczesne ostrzeżenie w 24 godziny, powiadomienie w 72 godziny i raport końcowy w ciągu 14 dni od udostępnienia środka naprawczego. Zegar 24-godzinny startuje, gdy producent uzyska świadomość aktywnego wykorzystania, co może być momentem, w którym dowody badacza czynią ten wniosek wiarygodnym. Czekanie na pewność forensyczną sprawi, że termin zostanie przekroczony. Oba procesy biegną równolegle i kończą się na różnych płaszczyznach.
Czy polityka CVD musi oferować badaczom prawną klauzulę bezpiecznego portu?
Nie, CRA nie wymaga wprost klauzuli bezpiecznego portu. Opisuje CVD jako ustrukturyzowany proces zgłaszania i odnotowuje programy bug-bounty jako sposób motywowania zgłoszeń; nie kodyfikuje bezpiecznego portu ani ograniczenia ryzyka prawnego dla badaczy. Norma pochodzi z praktyki branżowej, nie z rozporządzenia: ISO/IEC 29147, wytyczne dobrych praktyk ENISA oraz większość rekomendacji krajowych CSIRT zbiegają się na pisemnej klauzuli bezpiecznego portu obejmującej badania w dobrej wierze w opublikowanym zakresie. Polityka zastrzegająca prawo do działań prawnych wobec badań w zakresie niszczy kanał w praktyce i nie spełnia połowy "egzekwować" obowiązku CVD.