Od uzyskania wiedzy do final report
CRA reporting — odpowiedź w skrócie
Obowiązkowemu reportingowi podlegają dwa rodzaje zdarzeń: aktywnie wykorzystywana podatność oraz poważny incydent wpływający na bezpieczeństwo produktu z elementami cyfrowymi. Producent składa jedno zgłoszenie przez oficjalny ENISA SRP i wskazuje właściwy CSIRT koordynujący.
Sam numer CVE, wynik skanera, zgłoszenie klienta albo informacja o podatnym komponencie nie przesądzają jeszcze, że powstał obowiązek raportowy. Potrzebne jest udokumentowane human triage i ocena przesłanek art. 14 dla konkretnego produktu oraz zdarzenia.
Co trzeba zgłaszać w CRA?
- actively exploited vulnerability — podatność, dla której istnieją wiarygodne dowody wykorzystania przez złośliwego aktora
- severe incident having an impact on the security of the product — incydent spełniający kryteria z art. 14 ust. 5
Skąd może rozpocząć się incident workflow?
Operacyjny intake może rozpocząć się od zgłoszenia klienta lub badacza, zespołu security, dostawcy, GitLab finding albo monitoringu wewnętrznego. To przykładowe kanały wykrywania i eskalacji w organizacji, a nie oficjalna ani zamknięta lista źródeł określona przez ENISA.
W CRA Workspace kontrolowanym punktem wejścia jest moduł Security Intake. Rejestruje informację źródłową i pozwala przypisać ją do dokładnego produktu oraz opcjonalnie customer deployment i release'u, ale sam nie potwierdza podatności, incydentu ani obowiązku zgłoszenia.
Każdy sygnał wymaga human triage. Dopiero osobny Article 14 Review ocenia, czy producent uzyskał wiedzę o aktywnie wykorzystywanej podatności albo poważnym incydencie spełniającym przesłanki zgłoszenia.
Customer report, security finding lub alert monitoringu nie uruchamia automatycznie terminów 24h i 72h. Jeżeli review potwierdzi obowiązek, zgłoszenie jest wysyłane przez oficjalny CRA Single Reporting Platform; CRA Workspace nie zastępuje SRP.
Sygnał wymaga triage. Nie jest automatycznie zdarzeniem podlegającym zgłoszeniu ani początkiem terminu raportowego.
Jakie są terminy CRA: 24h, 72h i final report?
Terminy 24h i 72h liczy się od uzyskania przez producenta wiedzy o zdarzeniu podlegającym zgłoszeniu. Final report ma inną regułę dla aktywnie wykorzystywanej podatności i dla poważnego incydentu.
Liczniki widoczne w SRP są pomocnicze. Według aktualnego FAQ ENISA licznik dla etapu 72h pokazuje 48 godzin od wysłania Early Warning, co może dać inną wartość niż prawny termin 72 godzin od awareness. Organizacja powinna utrzymywać własny zegar prawny i alarmować przy rozbieżności.
| Etap | Termin | Zakres |
|---|---|---|
| Early warning | bez zbędnej zwłoki, maks. 24h | pierwsze ostrzeżenie o podatności albo incydencie |
| Vulnerability / incident notification | bez zbędnej zwłoki, maks. 72h | informacje o produkcie, zdarzeniu i działaniach |
| Final report — podatność | maks. 14 dni od dostępności środka naprawczego lub łagodzącego | opis podatności, wpływ i udostępniona poprawka |
| Final report — incydent | w ciągu miesiąca od zgłoszenia 72h | opis incydentu, przyczyna i działania łagodzące |
Gdzie wysłać zgłoszenie CRA?
Obowiązkowe zgłoszenie producent składa elektronicznie przez operacyjnie dostępną CRA Single Reporting Platform ENISA. Early Warning staje się dostępny dla ENISA i wskazanego CSIRT Designated as Coordinator. Pozostałe zainteresowane CSIRT-y otrzymują go dopiero po manual dissemination przez CDaC. CRACompliance.pl nie jest oficjalną platformą reportingową.
Dla 72h Notification i Final Report pełne dane są automatycznie dostępne ENISA, jeśli nie zastosowano Particularly Exceptional Circumstances. Przy PEC CDaC kontroluje dalsze udostępnienie zgodnie z właściwymi regułami.
Obecna wersja SRP nie udostępnia API. Po ręcznej wysyłce warto zachować timestamp, SRP Notification ID, osobę wysyłającą oraz screenshot lub PDF potwierdzenia jako evidence, powiązane z konkretnym produktem, wdrożeniem i release'em.
Jak wygląda cykl życia notification?
Operacyjna sekwencja to draft, Early Warning, 72-hour Notification i Final Report. Każdy kolejny etap wymaga wcześniejszego submission. Po wysłaniu Final Report notification staje się nieedytowalna.
Aktualizacja zgłoszenia przed Final Report automatycznie powiadamia CDaC, ENISA oraz zainteresowane CSIRT-y, które otrzymały już notification przez dissemination. Wewnętrzny rekord powinien zachować historyczne wersje i zamrozić final report zamiast nadpisywać go późniejszym remediation.
Jak działają konta i role w SRP?
Dla producenta istnieje jeden Primary Assigned Representative i maksymalnie 20 Secondary Assigned Representatives. Według FAQ ENISA z 17 września 2026 r. wszyscy Primary i Secondary AR powiązani z tym samym producentem widzą i aktualizują wszystkie wysłane zgłoszenia. Kolejny etap, na przykład 72h Notification lub Final Report, może wysłać inny AR. Draft pozostaje prywatny wyłącznie dla osoby, która go utworzyła.
Secondary AR może przejąć rolę Primary po akceptacji właściwego CSIRT Designated as Coordinator. Primary może zaprosić Secondary dopiero po uzyskaniu statusu Verified dla powiązania AR–manufacturer.
Przy błędnej nazwie producenta należy utworzyć poprawny wpis ponownie. Jeśli błędny wpis jest już Verified albo niezweryfikowane powiązanie ma zostać odrzucone, trzeba zwrócić się do CDaC. Zweryfikowane powiązanie AR można usunąć samodzielnie w zakresie własnej roli; Primary może też usunąć Secondary. Są to niewiążące zasady operacyjne ENISA, natomiast obowiązek i terminy wynikają z CRA.
Niezatwierdzona relacja nadal pozwala złożyć maksymalnie 20 zgłoszeń. ENISA zaleca inicjować rejestrację i walidację dopiero przy konkretnym zgłoszeniu; walidacja odbywa się równolegle i nie blokuje submission.
Krajowe guidance CDaC — przykład NBÚ / SK-CERT
5 października 2026 r. słowacki NBÚ / SK-CERT opublikował komunikat o metodycznych wytycznych dotyczących obowiązków raportowych CRA. Materiał przedstawia perspektywę krajowego organu i zespołu; nie jest nowym aktem UE ani guidance Komisji lub ENISA. Komunikat i jego pochodzenie sprawdziliśmy 7 października.
Przy korzystaniu z takich źródeł zapisuj kraj, organ, wersję dokumentu i datę sprawdzenia. Samo pojawienie się krajowych wytycznych nie zmienia terminów wynikających z CRA i nie oznacza, że można wybrać ten CDaC zamiast właściwego dla producenta. Szczegóły krajowe wymagają osobnego przeglądu w kontekście konkretnego zgłoszenia.
Reporting dotyczy także wcześniej udostępnionych produktów
Oficjalne podsumowanie Komisji wskazuje, że obowiązki raportowe obejmują wszystkie właściwe produkty z elementami cyfrowymi udostępnione na rynku UE, także te wprowadzone przed 11 grudnia 2027 r. Nie należy odkładać procesu reportingowego do pełnego stosowania CRA.
Jak przygotować organizację?
- jednoznacznie określ Primary AR, właściciela procesu i zastępstwa
- zapisuj autora Early Warning, osobę przejmującą 72h i autora Final Report wraz z timestampami
- połącz PSIRT, SOC, engineering, legal i kierownictwo
- zdefiniuj próg uzyskania wiedzy i ścieżkę eskalacji
- licz własne deadline'y 24h i 72h od awareness timestamp
- przygotuj dane produktowe potrzebne w 24h i 72h
- zapisuj status SRP, submission timestamp, SRP reference oraz evidence każdej wysyłki
CRA Reporting — najczęstsze pytania
Od kiedy obowiązuje CRA reporting?
Obowiązki raportowe z art. 14 CRA stosuje się od 11 września 2026 r.
Co trzeba zgłaszać w ciągu 24 godzin?
Early warning o aktywnie wykorzystywanej podatności albo poważnym incydencie wpływającym na bezpieczeństwo produktu należy przekazać bez zbędnej zwłoki, nie później niż w 24 godziny od uzyskania wiedzy.
Co trzeba zgłaszać w ciągu 72 godzin?
W terminie maksymalnie 72 godzin producent przekazuje główne zgłoszenie z dostępnymi informacjami o produkcie, charakterze podatności lub incydentu oraz podjętych albo dostępnych działaniach naprawczych i łagodzących.
Czy każde CVE trzeba zgłaszać do ENISA?
Nie. Samo CVE lub dopasowanie wersji komponentu nie oznacza aktywnego wykorzystania podatności. Obowiązkowy reporting dotyczy aktywnie wykorzystywanych podatności oraz poważnych incydentów spełniających przesłanki art. 14.
Gdzie składa się zgłoszenie CRA?
Producent składa zgłoszenie elektronicznie przez CRA Single Reporting Platform ustanowioną przez ENISA i wybiera właściwy CSIRT wyznaczony jako koordynator.
Czy reporting CRA dotyczy produktów wprowadzonych przed 11 grudnia 2027 r.?
Tak, jeżeli produkt z elementami cyfrowymi znajduje się w zakresie CRA. Oficjalne materiały Komisji i ENISA wskazują, że obowiązki raportowe od 11 września 2026 r. obejmują także właściwe produkty wprowadzone na rynek wcześniej.
Oficjalne źródła
Podstawa materiału została sprawdzona 20 września 2026.