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ólne 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 11 września 2026 r.: SRP jest dostępna 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 odświeżyła FAQ i przewodnik po rejestracji Assigned Representative 10 września 2026 r., a przewodniki po interfejsie i po składaniu powiadomień 9 września 2026 r. Tego samego dnia opublikowała też liczący 55 stron AR User Manual, czyli przewodnik klik po kliku po rejestracji, trzech etapach zgłoszenia i aktualizacji powiadomienia. Glosariusz SRP w wersji 1.3 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 pojawi się dopiero w późniejszej fazie. ENISA oznacza wszystkie te materiały jako aktualny stan wiedzy, który może się zmienić. 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 jest ostrzeżeniem, a nie pełną analizą. Powiadomienie 72h daje ogólne informacje o produkcie, exploicie lub incydencie, podjętych środkach, działaniach użytkowników i wrażliwości, gdy ma to znaczenie. Raport końcowy zawiera co najmniej dane wymagane dla danego strumienia: opis podatności, wagę, wpływ i środki korygujące albo opis incydentu, prawdopodobną przyczynę i trwające działania.

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.3 wymienia 39 pól: 18 wspólnych dla obu strumieni, 12 dotyczących wyłącznie aktywnie wykorzystywanej podatności i 9 dotyczących wyłącznie poważnego incydentu. 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.3, ostatnia aktualizacja 10 września 2026 r.

Co uruchamia obowiązek zgłoszenia

1. Aktywnie wykorzystywane podatności

Aktywnie wykorzystywana podatność oznacza, że istnieją wiarygodne dowody, iż złośliwy podmiot wykorzystał podatność w systemie bez upoważnienia i producent uzyskał o tym wiedzę. Publiczna PoC lub demonstracja badacza sama nie wystarcza.

2. Poważne incydenty

Poważny incydent podlega zgłoszeniu, gdy wpływa lub może wpływać na ochronę przez produkt dostępności, autentyczności, integralności lub poufności wrażliwych lub ważnych danych lub funkcji, albo gdy prowadzi lub może prowadzić 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.

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) mają wąską ulgę od kar administracyjnych wyłącznie za pominięcie pierwszego ostrzeżenia 24h. Ulga nie usuwa obowiązku zgłoszenia i nie obejmuje powiadomienia 72h ani raportów końcowych. Średnie przedsiębiorstwa nie mają takiej ulgi. Pełną strukturę kar opisuje przewodnik kary i egzekwowanie CRA.

Typowe błędy

• Czekanie na pewność forensyczną. 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; zgłaszanie CRA zaczyna się, gdy wstępna ocena daje producentowi rozsądny stopień pewności co do aktywnego wykorzystania.
• Jedna osoba eskalacyjna. Zegar 24h nie zatrzymuje się na weekend.
• Brak opublikowanej polityki CVD. Dokument wewnętrzny nie wystarcza.
• Brak decyzji o zastosowaniu. Bez VEX lub odpowiednika trudno obronić, dlaczego CVE nie wpływa na produkt.
• Traktowanie SRP jako przyszłego problemu. Szablony, dyżury i relacje z CSIRT muszą być gotowe przed pierwszym zdarzeniem podlegającym zgłoszeniu, a nie budowane w jego trakcie.

1. Glosariusz podaje to pole jako obowiązkowe przy wczesnym ostrzeżeniu 24h i w tym samym wierszu zaznacza, że pojawi się ono w kolejnym wydaniu platformy. Do czasu tego wydania możesz go nie znaleźć na ekranie. Prowadź własny znacznik czasu uzyskania wiedzy i przygotuj się na podanie go w obu wariantach. ↩︎

2. Glosariusz zaznacza, że w obecnym wydaniu pole to nosi etykietę „Date and time when the incident was detected (UTC time)”. Wykrycie to nie to samo co uzyskanie wiedzy, więc odnotowuj oba momenty. ↩︎