ENISA wdraża pierwsze CNAs: co to oznacza dla Artykułu 14 CRA

Zegar 24 godzin przewidziany w Artykule 14 ust. 1 CRA startuje w chwili, gdy producent uzyska uzasadnione przekonanie o aktywnym wykorzystaniu podatności. Ten zegar zakłada sprawny łańcuch identyfikacji podatności. ENISA właśnie uczyniła ten łańcuch bardziej bezpośrednim.

6 maja 2026 r. ENISA ogłosiła, że cztery nowe organizacje dołączyły do Programu CVE jako Organy Numerujące CVE (CNA) pod ENISA Root. Siedem istniejących europejskich CNA przeniosło się z MITRE Root do ENISA Root. Dla każdego producenta przygotowującego się do zgodności z Artykułem 14 CRA to moment, w którym infrastruktura operacyjna staje się rzeczywistością.

To ogłoszenie ma większe znaczenie, niż mogłoby się wydawać. CRA nie istnieje w próżni. Rozporządzenie definiuje obowiązki prawne, lecz obowiązki te opierają się na infrastrukturze, która musi istnieć i działać przed 11 września 2026 r. ENISA, budując swoje CVE Root, tworzy część tej infrastruktury. Fakt, że dzieje się to teraz, przy tak bliskim terminie CRA, jest jednocześnie pozytywnym sygnałem i przypomnieniem, że UE wciąż składa maszynerię, podczas gdy zegar tyka.

Dlaczego identyfikatory CVE mają znaczenie dla zgłoszenia z Artykułu 14

Gdy Artykuł 14 CRA wymaga zgłoszenia aktywnie wykorzystywanej podatności, zgłoszenie musi precyzyjnie ją identyfikować. Identyfikatory CVE są globalnym standardem tej identyfikacji. Stosuje je Europejska Baza Danych o Podatnościach ENISA (EUVD). Będzie ich oczekiwać Jednolita Platforma Zgłaszania ENISA.

Uzyskanie przypisania identyfikatora CVE wymaga CNA. Jeśli żadne europejskie CNA nie obejmowało danej kategorii oprogramowania, producent kierował wniosek do MITRE. MITRE ma siedzibę w USA. Koordynacja działała, lecz wprowadzała opóźnienia. Przy zegarze 24-godzinnym opóźnienie stanowi ryzyko zgodności.

ENISA jako CVE Root zmienia tę ścieżkę. Europejskie CNA koordynują teraz przypisywanie CVE bezpośrednio z ENISA. Dla większości producentów jest to niewidoczne na co dzień. Producent nie musi być CNA. Badacz bezpieczeństwa, który znajdzie błąd w produkcie, czy CSIRT obsługujący ujawnienie podatności, działa teraz pod organem nadrzędnym, który geograficznie pokrywa się z agencją, do której producent składa zgłoszenia na podstawie Artykułu 14.

To właśnie ta infrastruktura jest podstawą okna 24-godzinnego.

Łańcuch zgłaszania na podstawie Artykułu 14 CRA

Artykuł 14 ust. 1 CRA nakłada na producentów obowiązek jednoczesnego zgłaszania do koordynującego CSIRT i do ENISA za pośrednictwem Jednolitej Platformy Zgłaszania ENISA. Producent składa jedno zgłoszenie. Obie strony je otrzymują.

SRP potrzebuje jednak identyfikatora CVE, żeby zakotwić zgłoszenie. Rola ENISA jako CVE Root oznacza, że krok identyfikacji i krok zgłaszania podlegają teraz tej samej agencji. Organ, który nazywa podatność, jest tym samym organem, do którego producent zgłasza incydent. Zamyka to lukę koordynacyjną, która istniała, gdy te dwie funkcje były realizowane przez osobne organizacje na różnych kontynentach.

Pełny cykl zgłaszania: 24 h, 72 h i 14 dni oraz zakres zgłoszenia do SRP opisuje przewodnik po zgłaszaniu z Artykułu 14.

Problem akceleracji przez AI

Hans de Vries, Chief Cybersecurity and Operations Officer w ENISA, był bezpośredni w kwestii tego, dlaczego ma to znaczenie właśnie teraz:

Narzędzia AI skracają czas między wykryciem błędu a jego wykorzystaniem. Okno między „badacz to odkrywa" a „zegar 24-godzinny z Artykułu 14 startuje" staje się coraz krótsze. Z tego wynikają dwie konsekwencje. Po pierwsze, wewnętrzny proces triage'u musi odpowiadać szybszemu harmonogramowi zagrożeń. Po drugie, krok przypisywania CVE w łańcuchu musi działać równie szybko. ENISA buduje tę zdolność teraz. Ustawa o cyberbezpieczeństwie 2 proponuje dodatkowe zasoby operacyjne ENISA przeznaczone konkretnie do tej funkcji.

Czego producent robić nie musi

Producent nie musi zostać CNA. Status Organu Numerującego CVE jest przeznaczony dla organizacji, które odkrywają i publikują rekordy podatności. Większość producentów CNA-mi nie jest, a CRA tego nie wymaga.

Załącznik I, Część II CRA wymaga natomiast skoordynowanej polityki ujawniania podatności (CVD). Ta polityka opisuje, jak organizacja przyjmuje, obsługuje i ujawnia podatności. W jej ramach producent współpracuje z CNA lub CSIRT-ami, które obsługują przypisywanie CVE. ENISA jako CVE Root oznacza, że ci partnerzy działają teraz w ramach bardziej bezpośredniej struktury organów UE. W Polsce naturalnym punktem kontaktu jest CERT Polska, działający w ramach NASK.

Przed 11 września 2026 r. przegląd polityki CVD powinien obejmować trzy pytania:

1. Czy polityka wskazuje ścieżkę zgłaszania? Polityka musi wskazywać SRP ENISA jako kanał składania zgłoszeń zgodnie z Artykułem 14.
2. Czy polityka określa sposób obsługi zgłoszeń przychodzących? Gdy badacz zgłasza podatność do producenta, polityka musi opisywać harmonogram odpowiedzi i proces wnioskowania o CVE.
3. Czy polityka wskazuje koordynujący CSIRT? Artykuł 14 ust. 7 CRA nakłada na producentów obowiązek wyznaczenia koordynującego CSIRT. To wyznaczenie powinno znaleźć się w polityce.

Punkt wyjścia do opracowania polityki CVD oferuje szablon polityki CVD.

Nasza ocena

Linia „wzmocnić, nie fragmentować" to właściwe podejście. Ryzyko związane z każdą infrastrukturą specyficzną dla UE polega na fragmentacji. Europejskie silo CVE, które rozchodziłoby się z MITRE, zaszkodzi wszystkim, w tym europejskim producentom próbującym funkcjonować w globalnych łańcuchach dostaw. Ogłoszenie jest jednoznaczne: ENISA współpracuje z CISA i MITRE jako część wspólnego zaangażowania w globalny program.

Ważniejszy przekaz dla producentów to kwestia harmonogramu. Infrastruktura jest składana w tym samym czasie, w którym producent ma już z niej korzystać. SRP jeszcze nie działa. Pod CVE Root działa 11 CNA z ponad 90 uprawnionych. Te elementy będą gotowe do września 2026 r., ale producent też musi być gotowy, a budowanie procesu wokół infrastruktury, która dopiero powstaje, jest trudniejsze niż budowanie go na stabilnym gruncie.