Zgłaszanie podatności i incydentów w CRA

Od 11 września 2026 r. producenci CRA muszą zgłaszać aktywnie wykorzystywane podatności i poważne incydenty przez platformę ENISA Single Reporting Platform. Ten przewodnik wyjaśnia, co uruchamia zgłoszenie, jak działają terminy 24h, 72h, 14 dni i 1 miesiąca oraz gdzie w tym procesie mieszczą się CVD, VEX i informowanie użytkowników.

Co trzeba zgłaszać

Zgłaszanie CRA ma dwa obowiązkowe strumienie zdarzeń i osobny obowiązek informowania użytkowników. Obowiązek spoczywa na producencie produktu z elementami cyfrowymi na rynku UE:

1. Zgłaszaj każdą aktywnie wykorzystywaną podatność w produkcie do koordynującego CSIRT i ENISA według cyklu 24h / 72h / 14d.
2. Zgłaszaj każdy poważny incydent wpływający na bezpieczeństwo produktu według cyklu 24h / 72h / 1 miesiąc.
3. Informuj dotkniętych użytkowników o podatności lub incydencie oraz środkach korygujących bez zbędnej zwłoki.

Ta strona obejmuje także dwie powiązane kontrole: obowiązkową politykę CVD oraz dowody zastosowania, takie jak VEX. Żaden z tych obowiązków nie ma progu wielkości. Mikroprzedsiębiorstwa i małe przedsiębiorstwa mają tylko wąskie złagodzenie kar za ostrzeżenie 24h; nie są zwolnione ze zgłaszania.

Platforma ENISA Single Reporting Platform (SRP)

SRP jest jedynym kanałem obowiązkowych zgłoszeń CRA dotyczących podatności i incydentów. Producent zgłasza raz przez elektroniczny punkt koordynującego CSIRT; zgłoszenie jest jednocześnie dostępne dla ENISA, chyba że zastosowano wyjątkowy mechanizm opóźnionego rozpowszechniania. Koordynujący CSIRT przekazuje następnie informacje właściwym CSIRT w innych państwach członkowskich.

Opóźnienie rozpowszechniania pozwala koordynującemu CSIRT wstrzymać przekazanie powiadomienia dalej w wyjątkowych okolicznościach, z uzasadnionych względów cyberbezpieczeństwa i tylko na czas ściśle niezbędny. Producent może o to wystąpić i może oznaczyć wrażliwość informacji, ale decyzja należy do CSIRT. Istnieje też drugie, odrębne opóźnienie dla podatności, o której koordynujący CSIRT dowiedział się w ramach procedury skoordynowanego ujawniania. CSIRT może wtedy wstrzymać powiadomienie z uzasadnionych względów cyberbezpieczeństwa, na okres nie dłuższy niż ściśle niezbędny i do czasu, aż strony tego ujawnienia wyrażą zgodę na jej upublicznienie. Warto o tym wiedzieć, jeśli prowadzisz proces CVD, ale i tutaj decyzja należy do CSIRT, więc nie licz na to, że embargo się utrzyma.

Szczególnie wyjątkowe okoliczności (PEC) to węższy i odrębny mechanizm. Dotyczą wyłącznie powiadomienia 72-godzinnego o aktywnie wykorzystywanej podatności i tylko wtedy, gdy wykorzystanie ogranicza się do państwa członkowskiego koordynatora, gdy szersze ujawnienie godziłoby w istotne interesy tego państwa albo gdy samo rozpowszechnienie stworzyłoby bezpośrednie wysokie ryzyko dla cyberbezpieczeństwa. Zgłaszający zaznacza je przełącznikiem w platformie i może dodać uzasadnienie, a rozstrzyga koordynujący CSIRT. Dopóki PEC obowiązuje, ENISA i tak otrzymuje ograniczony zakres: informację, że powiadomienie złożono, ogólne informacje o produkcie, ogólny charakter wykorzystania oraz to, że powołano się na względy bezpieczeństwa. Pełne powiadomienie trafia do ENISA po zakończeniu opóźnienia. Procedurę opisują wytyczne ENISA dotyczące PEC.

Stan na 6 listopada 2026 r.: SRP jest dostępna od 11 września 2026 r. pod adresem portal.cra-srp.enisa.europa.eu. Na stronie startowej wybiera się rolę Assigned Representative, czyli konto w SRP, które zgłasza w imieniu producenta lub opiekuna otwartego oprogramowania. To nie to samo co upoważniony przedstawiciel w rozumieniu CRA. Logowanie działa przez osobiste konto EU Login z włączonym uwierzytelnianiem wieloskładnikowym. ENISA podniosła platformę do wersji 1.3 4 listopada 2026 r. i podaje, że jej dokumentacja jest wciąż aktualizowana. FAQ nosi datę 15 października 2026 r., a przewodniki po rejestracji Assigned Representative, interfejsie i składaniu powiadomień noszą datę 12 września 2026 r. 9 września 2026 r. ENISA po raz pierwszy opublikowała AR User Manual, a 4 listopada 2026 r. wydała go ponownie jako wersję 1.3. To przewodnik klik po kliku po rejestracji, trzech etapach zgłoszenia i aktualizacji powiadomienia. Glosariusz SRP w wersji 1.6 opisuje platformę pole po polu, tylko po angielsku. Lista CSIRT wyznaczonych jako koordynatorzy nosi datę 10 września 2026 r. W pierwszym wydaniu nie ma API, zgłoszenia składa się przez interfejs platformy, a zgłaszanie dobrowolne nie jest jeszcze dostępne. ENISA oznacza wszystkie te materiały jako aktualny stan wiedzy, który może się zmienić. Załóż konto EU Login, zanim będzie potrzebne, skorzystaj z przewodnika po rejestracji w ENISA SRP, a w razie potrzeby napisz na cra-srp-helpdesk@enisa.europa.eu.

Terminy zgłaszania w szczegółach

Harmonogram zgłaszania

Co zawiera każde zgłoszenie

Wczesne ostrzeżenie (24 godziny). Wczesne ostrzeżenie jest ostrzeżeniem, a nie pełną analizą. W przypadku podatności należy je wysłać bez zbędnej zwłoki i w ciągu 24 godzin od uzyskania wiedzy, a tam gdzie ma to zastosowanie, wskazać państwa członkowskie, w których według wiedzy producenta produkt został udostępniony. W przypadku poważnych incydentów trzeba też podać co najmniej, czy incydent jest podejrzewany o spowodowanie działaniami niezgodnymi z prawem lub złośliwymi. Wewnętrzne szablony mogą dodawać pola wersji produktu, wagi, zakresu skutków i właściciela, ale to pola operacyjne, a nie wszystkie są minimum prawnym.

Szczegółowe powiadomienie (72 godziny). Na tym etapie działają dwa odrębne obowiązki. Powiadomienie 72-godzinne o podatności dotyczy aktywnie wykorzystywanych podatności i podaje ogólne informacje o produkcie, exploicie, podatności, podjętych środkach, środkach dla użytkowników oraz, tam gdzie ma to zastosowanie, o wrażliwości. Powiadomienie 72-godzinne o incydencie dotyczy poważnych incydentów i podaje ogólne informacje o incydencie, wstępną ocenę, podjęte środki, środki dla użytkowników oraz, tam gdzie ma to zastosowanie, wrażliwość.

Raport końcowy. W przypadku podatności 14-dniowy zegar startuje, gdy dostępny jest środek korygujący lub ograniczający ryzyko, a nie przy wykryciu ani przy powiadomieniu 72-godzinnym. Raport końcowy musi zawierać co najmniej opis podatności, jej wagę i skutki, informacje o złośliwych podmiotach, jeśli są dostępne, oraz szczegóły aktualizacji zabezpieczeń lub innych środków korygujących. W przypadku poważnych incydentów jednomiesięczny zegar liczy się od powiadomienia 72-godzinnego o incydencie, a raport końcowy musi zawierać co najmniej szczegółowy opis incydentu, jego wagę i skutki, prawdopodobny rodzaj zagrożenia lub przyczynę źródłową oraz zastosowane lub trwające środki ograniczające ryzyko.

1. Producent uzyskuje wiedzę. Zegar 24h startuje, gdy szybka wstępna ocena daje producentowi rozsądny stopień pewności, że podatność w jego produkcie jest aktywnie wykorzystywana.
2. +24h. Wyślij wczesne ostrzeżenie przez ENISA SRP.
3. +72h. Dodaj szczegóły techniczne, dotknięte wersje, status wykorzystania i status naprawy.
4. Środek dostępny. Dla podatności zegar raportu końcowego zaczyna się tutaj, nie przy wykryciu.
5. +14d. Wyślij końcowe dane dla strumienia podatności lub incydentu.

Poważne incydenty przechodzą przez te same kroki wstępne (ostrzeżenie 24h i powiadomienie 72h); raport końcowy jest składany w ciągu 1 miesiąca po powiadomieniu 72h.

Pola danych w szablonie zgłoszeń SRP

Glosariusz SRP ENISA opisuje pole po polu, czego platforma wymaga na każdym etapie. Wersja 1.6 wymienia 43 pola: 19 wspólnych dla obu strumieni, 13 dotyczących wyłącznie aktywnie wykorzystywanej podatności, 9 dotyczących wyłącznie poważnego incydentu i 2 pola notatek zamykających. Dokument jest dostępny tylko po angielsku, a ENISA opisuje go jako aktualny stan wiedzy, który może się zmienić. Kody: X obowiązkowe, O opcjonalne, C skopiowane z poprzedniego etapu domyślnie lub zaktualizowane, I obowiązkowe, jeśli informacja jest dostępna, - nie dotyczy na tym etapie.

Kryteria wagi (i34): poważny incydent to incydent, który (1) negatywnie wpływa lub może negatywnie wpływać na zdolność produktu do ochrony dostępności, autentyczności, integralności lub poufności wrażliwych albo istotnych danych bądź funkcji, albo (2) doprowadził lub może doprowadzić do wprowadzenia lub uruchomienia złośliwego kodu w produkcie bądź w sieci i systemach informatycznych użytkownika.

Źródło: Glosariusz SRP ENISA, wersja 1.6, ostatnia aktualizacja 21 października 2026 r.

Co uruchamia obowiązek zgłoszenia

1. Aktywnie wykorzystywane podatności

Aktywnie wykorzystywana podatność to podatność w produkcie, co do której istnieją wiarygodne dowody, że złośliwy podmiot wykorzystał ją w systemie bez upoważnienia. Producent musi też uzyskać wiedzę o tym wykorzystaniu, zanim zacznie biec zegar zgłoszenia.

To nie to samo co publiczne ujawnienie, opublikowany proof-of-concept czy badacz pokazujący możliwość wykorzystania w laboratorium. Takie sygnały należą do obsługi podatności i triażu CVD, chyba że dają wiarygodne dowody złośliwego wykorzystania wobec rzeczywistego systemu.

2. Poważne incydenty

Poważny incydent to incydent mający wpływ na bezpieczeństwo produktu, który spełnia jedno z dwóch kryteriów:

• negatywnie wpływa lub może negatywnie wpływać na zdolność produktu do ochrony dostępności, autentyczności, integralności lub poufności wrażliwych albo istotnych danych bądź funkcji, albo
• doprowadził lub może doprowadzić do wprowadzenia lub uruchomienia złośliwego kodu w produkcie lub w sieci i systemach informatycznych użytkownika.

Scenariusze zgłaszane i niezgłaszane

Wiedza i dowody

Definicja CRA używa wiarygodnych dowodów do określenia aktywnie wykorzystywanej podatności. Wiedza jest odrębnym testem: po szybkiej wstępnej ocenie producent musi mieć rozsądny stopień pewności, że podatność w jego produkcie jest aktywnie wykorzystywana. Zakończone dochodzenie forensyczne nie jest wymagane.

Przyjmowanie CVD i bramka zgłoszenia

Polityka CVD jest kanałem, który zmienia zewnętrzne raporty w ustrukturyzowany triage. Jeśli triage wskazuje aktywne wykorzystanie, oceń je niezwłocznie. Termin zgłoszenia startuje, gdy wstępna ocena daje producentowi rozsądny stopień pewności. Publiczna strona CVD i security.txt w /.well-known/security.txt to praktyczny sposób, aby kontakt był łatwy do znalezienia.

Samą politykę CVD, w tym wymagane elementy, konwencje okien ujawnienia, język bezpiecznej przystani i szablony komunikacji z badaczami, opisuje przewodnik po skoordynowanym ujawnianiu podatności w CRA. To, jak CVD wpisuje się w szerszy cykl obsługi podatności, opisuje obsługa podatności w CRA. Połączony przegląd obsługi i zgłaszania z Artykułu 14 daje obsługa i zgłaszanie podatności.

VEX i zastosowanie podatności

VEX (Vulnerability Exploitability eXchange) to ustrukturyzowane, maszynowo czytelne oświadczenie o tym, czy podatność w komponencie SBOM rzeczywiście wpływa na konkretny produkt. Zamienia surowe dopasowania CVE na możliwy do obrony status przypisany do wersji produktu:

Dla zgłaszania liczy się zastosowanie razem z aktywnym wykorzystaniem. Podatność oznaczona jako affected i poparta wiarygodnymi dowodami aktywnego wykorzystania to zdarzenie, które uruchamia zegar wczesnego ostrzeżenia 24h. Podatność oznaczona jako not_affected z rzetelnym uzasadnieniem wspiera decyzję o niezgłaszaniu. CRA nie wymienia VEX z nazwy, ale VEX jest praktycznym sposobem zachowania takiego uzasadnienia. Formaty VEX, przykłady, typy uzasadnień, narzędzia i integrację z SBOM opisuje przewodnik VEX.

Ulga dla małych producentów

Mikroprzedsiębiorstwa i małe przedsiębiorstwa (definiowane jako mniej niż 50 pracowników oraz roczny obrót lub suma bilansowa do 10 mln EUR; mikroprzedsiębiorstwa: mniej niż 10 pracowników, do 2 mln EUR) nie podlegają karom administracyjnym wyłącznie za niedotrzymanie pierwszego terminu wczesnego ostrzeżenia w ciągu 24 godzin. Ulga obejmuje tylko kary za termin pierwszego etapu.

Nadal obowiązuje, bez ulgi dla MŚP:

• szczegółowe powiadomienie w ciągu 72 godzin,
• raport końcowy po 14 dniach dla podatności i po miesiącu dla poważnych incydentów,
• polityka CVD,
• wszystkie pozostałe obowiązki CRA dotyczące bezpieczeństwa produktu, w tym podstawowy wymóg braku znanych możliwych do wykorzystania podatności.

Średnie przedsiębiorstwa nie mają takiej ulgi. To wąskie wyłączenie z kar, a nie okrojony reżim zgłaszania. Szerszą strukturę kar, w tym wycofania produktów i uprawnienia nadzoru rynku, opisuje kary i egzekwowanie CRA.

Typowe błędy

• Czekanie na pewność forensyczną przed uruchomieniem zegara. Wystarczą szybka wstępna ocena i rozsądny stopień pewności. Zakończone dochodzenie forensyczne nie jest wymagane.
• Mieszanie CVD i pilnego zgłaszania. Raport badacza to intake CVD, a pilne zgłaszanie zaczyna się, gdy wstępna ocena daje producentowi rozsądny stopień pewności co do aktywnego wykorzystania. Polityka CVD musi zawierać wyraźną bramkę na ten moment.
• Eskalacja z jednym punktem awarii. Jedna osoba uprawniona do zgłaszania, nieosiągalna w piątek wieczorem. Zegar 24h się nie zatrzymuje.
• Pierwszy kontakt z koordynującym CSIRT w trakcie incydentu. Relację i routing trzeba ustalić teraz, gdy żaden zegar nie biegnie.
• Brak opublikowanej polityki CVD. Wymagana jest polityka publiczna, dokument wewnętrzny nie wystarcza.
• Brak decyzji o zastosowaniu podatności. Bez VEX lub równoważnego zapisu trudno obronić, dlaczego znana CVE w SBOM nie jest możliwa do wykorzystania w produkcie.
• Traktowanie SRP jako problemu na przyszłość. Szablony, rotę eskalacji i relacje z CSIRT trzeba mieć gotowe przed pierwszym zdarzeniem podlegającym zgłoszeniu, a nie budować w jego trakcie.

1. Glosariusz opisuje to pole jako moment, w którym producent lub inna właściwa strona po raz pierwszy wykryła podatność („first detected”). Wykrycie to nie to samo co uzyskanie wiedzy, więc odnotowuj oba momenty. ↩︎