CRA: zgłaszanie podatności, ENISA SRP, 24h/72h/14d

Unijny Akt o cyberodporności (rozporządzenie (UE) 2024/2847) czyni zgłaszanie podatności twardym, ograniczonym czasowo obowiązkiem prawnym dla każdego producenta produktu z elementami cyfrowymi. Od 11 września 2026 r. Artykuł 14 zobowiązuje do zgłaszania aktywnie wykorzystywanych podatności i poważnych incydentów przez platformę ENISA Single Reporting Platform (SRP) w rytmie 24h / 72h / 14d, a także do posiadania obowiązkowej polityki skoordynowanego ujawniania podatności (CVD) zgodnie z Załącznikiem I Część II. Ta strona stanowi kanoniczną referencję: czego wymaga prawo, kiedy startuje każdy zegar, co musi zawierać zgodna polityka CVD, jak VEX wspiera obowiązek "braku znanych podatności możliwych do wykorzystania" oraz jakie kary z Artykułu 64 grożą za brak zgłoszenia.

Czego CRA wymaga w zakresie zgłaszania podatności?

Artykuł 14 Aktu o cyberodporności stanowi operacyjne jądro reżimu obsługi incydentów w rozporządzeniu. Nakłada trzy obowiązki na każdego producenta produktu z elementami cyfrowymi wprowadzonego na rynek UE:

1. Zgłoszenie każdej aktywnie wykorzystywanej podatności w produkcie jednocześnie do CSIRT-koordynatora i do ENISA, w rytmie 24h / 72h / 14d (art. 14 ust. 1, 14 ust. 2).
2. Zgłoszenie każdego poważnego incydentu wpływającego na bezpieczeństwo produktu w rytmie 24h / 72h / 1 miesiąc (art. 14 ust. 3, 14 ust. 4).
3. Poinformowanie użytkowników dotkniętego produktu o podatności lub incydencie i wszelkich środkach naprawczych, bez zbędnej zwłoki (art. 14 ust. 8).

Artykuł 14 uzupełniają dwa inne obowiązki omówione na tej stronie: obowiązkowa polityka CVD z Załącznika I Część II oraz wymóg "braku znanych podatności możliwych do wykorzystania" z Załącznika I Część I, dlatego VEX ma znaczenie dla produktu zgodnego z CRA. Żaden z tych obowiązków nie ma progu wielkości. MŚP korzystają z wąskiej ulgi karnej dotyczącej 24-godzinnego zegara (patrz niżej), ale nie są zwolnione ze zgłaszania.

Platforma ENISA Single Reporting Platform (SRP)

SRP to jedyny kanał, przez który przechodzą wszystkie powiadomienia z Artykułu 14. Istnieje dlatego, że Artykuł 14 ust. 1 zobowiązuje producenta do jednoczesnego powiadomienia CSIRT-koordynatora i ENISA, a 27 osobnych zgłoszeń byłoby niewykonalne. Artykuł 16 ust. 1 powierza platformę ENISA: "bieżące działanie tej jednolitej platformy zgłaszania jest zarządzane i obsługiwane przez ENISA."

Jak to działa w praktyce:

• Producent składa zgłoszenie raz, przez elektroniczny punkt zgłoszeń CSIRT wyznaczonego jako koordynator na mocy Artykułu 14 ust. 7.
• Zgłoszenie trafia jednocześnie do CSIRT-koordynatora i do ENISA.
• CSIRT-koordynator następnie rozpowszechnia powiadomienie do CSIRTs w innych państwach członkowskich, w których produkt jest wprowadzony do obrotu (art. 16). Ten dalszy krok leży po stronie CSIRT, nie producenta.
• Artykuł 16 ust. 2 dopuszcza opóźnienie dalszego przekazywania przez CSIRT w wyjątkowych okolicznościach. Artykuł 16 ust. 6 dopuszcza opóźnienie podczas skoordynowanego ujawniania za zgodą producenta.

Stan na maj 2026 r.: SRP ma zostać uruchomiona do 11 września 2026 r. zgodnie z stroną ENISA SRP. Wdrożenie zostało zlecone w przetargu ENISA/2025/OP/0001 (umowa 4-letnia) z terminem składania ofert w marcu 2025 r. Dostawcy nie ujawniono publicznie. Żaden adres URL do rejestracji nie został opublikowany. Oczekiwany jest okres testowy przed uruchomieniem; konkretne daty nie zostały ogłoszone. Akty wykonawcze na podstawie Artykułu 14, określające formaty i strukturę powiadomień, były nadal w toku w chwili redakcji.

Co producenci powinni zrobić teraz: zidentyfikować CSIRT-koordynatora na mocy Artykułu 14 ust. 7, opracować i wstępnie zatwierdzić szablony raportów dla zgłoszeń 24h, 72h i 14d oraz zdefiniować rotację dyżurów poza godzinami pracy. Szablonów i procesów nie można opracowywać, gdy zegar 24-godzinny już biegnie.

Terminy zgłaszania w szczegółach

Zarówno podatności, jak i poważne incydenty podlegają etapowemu modelowi zgłaszania. Zegary różnią się na etapie raportu końcowego.

Harmonogram zgłaszania z Artykułu 14

Etap	Podatność (art. 14 ust. 2)	Poważny incydent (art. 14 ust. 4)	Punkt startowy
Wczesne ostrzeżenie	24 godziny	24 godziny	Producent powziął wiedzę
Szczegółowe powiadomienie	72 godziny	72 godziny	Producent powziął wiedzę
Raport końcowy	14 dni od udostępnienia środka naprawczego lub łagodzącego	1 miesiąc od 72-godzinnego powiadomienia o incydencie	Inny punkt startowy dla każdej ścieżki
Informowanie użytkowników	Bez zbędnej zwłoki	Bez zbędnej zwłoki	Zgodnie z art. 14 ust. 8

Co zawiera każde zgłoszenie

Wczesne ostrzeżenie (24 godziny). Minimalne informacje do zaalarmowania organów: tożsamość producenta, dotknięty produkt i wersja, krótki opis, wstępna powaga, potwierdzenie lub podejrzenie wykorzystania oraz wskazanie zakresu wpływu. Wczesne ostrzeżenie to alert, nie analiza.

Szczegółowe powiadomienie (72 godziny). Na tym etapie obowiązują dwa odrębne wymogi. 72-godzinne powiadomienie o podatności na mocy Artykułu 14 ust. 2 lit. b dotyczy aktywnie wykorzystywanych podatności. 72-godzinne powiadomienie o incydencie na mocy Artykułu 14 ust. 4 lit. b dotyczy poważnych incydentów. W obu przypadkach zgłoszenie rozszerza wczesne ostrzeżenie o szczegóły techniczne, dotknięte wersje i konfiguracje, metodę wykorzystania (jeśli znana), bieżący status łagodzenia, harmonogram naprawy, znany zakres dotkniętych użytkowników oraz ewentualną koordynację z innymi stronami.

Raport końcowy. Dla podatności 14-dniowy zegar startuje "nie później niż 14 dni od udostępnienia środka naprawczego lub łagodzącego" (art. 14 ust. 2 lit. c), a nie od odkrycia ani od 72-godzinnego powiadomienia. Dla poważnych incydentów 1-miesięczny zegar jest zakotwiczony w 72-godzinnym powiadomieniu o incydencie na mocy Artykułu 14 ust. 4 lit. c. Raport końcowy obejmuje analizę przyczyn źródłowych, pełny opis techniczny, podjęte działania naprawcze, wdrożone środki zapobiegawcze oraz potwierdzoną ocenę wpływu.

1. Producent powziął wiedzę. Zegar 24-godzinny startuje w chwili powzięcia uzasadnionego przekonania o aktywnym wykorzystaniu.
2. + 24 godziny. Wczesne ostrzeżenie złożone przez ENISA SRP (art. 14 ust. 2 lit. a).
3. + 72 godziny. Szczegółowe powiadomienie złożone ze szczegółami technicznymi, dotkniętymi wersjami i statusem łagodzenia (art. 14 ust. 2 lit. b).
4. Udostępnienie środka naprawczego lub łagodzącego. Tu startuje 14-dniowy zegar raportu końcowego, a nie w chwili odkrycia.
5. + 14 dni. Raport końcowy złożony: analiza przyczyn, pełny opis techniczny, działania naprawcze, potwierdzony wpływ (art. 14 ust. 2 lit. c).

Co wyzwala obowiązek zgłaszania?

Artykuł 14 obejmuje dwie kategorie wyzwalaczy.

1. Aktywnie wykorzystywane podatności

Podatność w produkcie, która:

• jest znana producentowi (odkryta wewnętrznie lub zgłoszona zewnętrznie),
• została wykorzystana przez złośliwego aktora, oraz
• dotyczy lub może dotyczyć użytkowników produktu.

CRA definiuje aktywnie wykorzystywaną podatność jako taką, w której "złośliwy aktor wykorzystuje lukę." To nie jest to samo co publiczne ujawnienie, opublikowany proof-of-concept ani demonstracja możliwości wykorzystania przez badacza. Wyzwalaczem jest rzeczywiste złośliwe użycie.

2. Poważne incydenty

Incydenty bezpieczeństwa, które wpływają na bezpieczeństwo produktu, naruszają środowisko deweloperskie w sposób wpływający na bezpieczeństwo produktu, powodują rozległe zakłócenia usług dla użytkowników lub skutkują rozległym naruszeniem.

Scenariusze zgłaszalne i niezgłaszalne

Scenariusz	Zgłosić?	Uzasadnienie
Badacz zgłasza podatność prywatnie	Nie	Brak dowodów na wykorzystanie; obsłuż przez CVD
PoC opublikowany na GitHub	Nie	Publikacja to nie jest wykorzystanie
Klient zgłasza aktywność zgodną z podatnością	Tak	Spełniony próg uzasadnionego przekonania
Podatność wykryta jako aktywnie wykorzystywana	Tak	Aktywne złośliwe użycie
Komponent w SBOM ma aktywnie wykorzystywany CVE	Oceń	Zgłaszalne tylko jeśli wykorzystanie dotyczy tego produktu (tu znaczenie ma VEX)
Produkt jest celem konkretnych grup zagrożeń	Tak	Bezpośredni dowód na wykorzystanie
Ogólne złośliwe oprogramowanie używa klasy podatności, którą posiada produkt	Oceń	Tylko jeśli konkretna implementacja jest dotknięta

Standard "uzasadnionego przekonania"

Dowód forensyczny na wykorzystanie nie jest wymagany. Standard z Artykułu 14 to uzasadnione przekonanie na podstawie dostępnych dowodów: nietypowe wzorce dostępu zgodne ze znanymi technikami exploitów, raporty klientów o naruszeniu, wywiad o zagrożeniach wskazujący na cel w postaci produktu lub wykrycie kodu exploitu zaprojektowanego dla produktu. W przypadku niepewności należy złożyć zgłoszenie. Przedwczesne wczesne ostrzeżenie, które okaże się nieuzasadnione, jest znacznie lepsze niż przegapiony termin dla rzeczywistego wykorzystania, a 72-godzinne powiadomienie może zaktualizować ocenę.

Skoordynowane ujawnianie podatności (CVD): powiązanie z artykułem 14

Załącznik I Część II punkt 5 CRA zobowiązuje producenta do „wprowadzenia i egzekwowania polityki w zakresie koordynowanego ujawniania podatności". Polityka CVD jest mechanizmem operacyjnym, który zamienia zgłoszenia zewnętrznych badaczy w ustrukturyzowany triaż, a w chwili wykrycia aktywnego wykorzystania uruchamia równolegle zegar zgłaszania z artykułu 14. Obowiązek dotyczy każdego produktu z elementami cyfrowymi i nie przewiduje progu dla MŚP ani dla wielkości podmiotu. Minimum dostawcze to publiczny URL polityki oraz plik security.txt pod /.well-known/security.txt (RFC 9116), aby zgłoszenia były wykrywalne dla badaczy, których rozporządzenie ma kierować do tego kanału.

Treść samej polityki CVD, w tym wymagane elementy, konwencje okna ujawnienia, klauzulę bezpiecznej przystani i szablony komunikacji z badaczami, omawia przewodnik CRA: koordynowane ujawnianie podatności. Umiejscowienie CVD wśród pozostałych obowiązków Załącznika I Część II (SBOM, środki naprawcze, bezpieczne aktualizacje, dostarczanie bez opłat) opisuje obsługa podatności według CRA. Niniejsza strona skupia się na kadencji zgłaszania z artykułu 14, która uruchamia się, gdy triaż potwierdzi aktywne wykorzystywanie.

VEX: komunikowanie zastosowania podatności

Załącznik I Część I wymaga, by produkty CRA były dostarczane bez znanych podatności możliwych do wykorzystania i z domyślnie bezpieczną konfiguracją. Skanowanie SBOM produkuje długie listy CVE dla komponentów, z których większość w rzeczywistości nie jest możliwa do wykorzystania w konkretnym produkcie. VEX (Vulnerability Exploitability eXchange) to mechanizm, który przekształca te surowe wyniki skanowania w dającą się obronić pozycję "nie dotyczy / dotyczy / naprawiono / w trakcie badania" dla każdego CVE, czego oczekuje rozporządzenie, rozwijane normy zharmonizowane i zamówienia publiczne w Niemczech na podstawie BSI TR-03183 Część 3.

Czym jest VEX

VEX to ustrukturyzowane, czytelne maszynowo oświadczenie o tym, czy podatność w komponencie rzeczywiście dotyczy konkretnego produktu. Odpowiada na pytanie: "CVE-XXXX istnieje w naszym SBOM. Czy dotyczy naszego produktu, dlaczego lub dlaczego nie, i co użytkownik powinien zrobić?" Cztery podstawowe stany to:

Stan	Znaczenie
not_affected	Podatność istnieje w komponencie, ale nie dotyczy tego produktu (niedostępna ścieżka kodu, funkcja nie jest wywoływana, konfiguracja łagodzi itp.). Oczekiwane jest uzasadnienie.
affected	Podatność dotyczy tego produktu. Oczekiwane są działanie i zalecenie.
fixed	Podatność była obecna i została usunięta w tej wersji.
under_investigation	Status jeszcze nieokreślony; trwa ocena.

Powiązanie z CRA

VEX nie jest wymieniony z nazwy w tekście CRA, ale stanowi operacyjne narzędzie stojące za trzema klauzulami rozporządzenia:

• Załącznik I Część I, brak znanych podatności możliwych do wykorzystania. Oświadczenie VEX not_affected z udokumentowanym uzasadnieniem to dowód, że dany CVE został oceniony i uznany za niedotyczący produktu. Bez niego każdy CVE w SBOM jest domniemaną odpowiedzialnością.
• Załącznik I Część II, obsługa podatności. VEX to ścieżka audytu pokazująca, jak każdy CVE przeszedł ze stanu under_investigation do not_affected, affected lub fixed w czasie.
• Artykuł 14, wyzwalacze zgłaszania. Podatność oznaczona jako affected i znana jako aktywnie wykorzystywana to dokładnie wyzwalacz uruchamiający 24-godzinny zegar. Podatność oznaczona jako not_affected z rzetelnym uzasadnieniem nim nie jest.

Formaty VEX

W praktyce znaczenie mają dwa formaty. CycloneDX VEX jest osadzony bezpośrednio w SBOM CycloneDX w sekcji vulnerabilities[].analysis. CSAF VEX to osobny dokument w formacie CSAF 2.0 (format wymagany przez BSI TR-03183 Część 3 dla komunikatów bezpieczeństwa, domyślnie publikowany i przetwarzany przez niemieckie CERT). Oba są czytelne maszynowo i spełniają tę samą rolę operacyjną.

Minimalna asercja VEX w formacie CycloneDX:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "version": 1,
  "vulnerabilities": [
    {
      "id": "CVE-2027-XXXXX",
      "source": { "name": "NVD" },
      "analysis": {
        "state": "not_affected",
        "justification": "code_not_reachable",
        "detail": "The vulnerable function is not called in our implementation."
      },
      "affects": [{ "ref": "pkg:generic/openssl@3.0.12" }]
    }
  ]
}

Specyfikacja CycloneDX 1.5 definiuje sześć stanów analizy (in_triage, exploitable, not_affected, false_positive, resolved, resolved_with_pedigree), bardziej szczegółowy słownik niż cztery stany OpenVEX (not_affected, affected, fixed, under_investigation), na które jest mapowany. BSI TR-03183 Część 3 oczekuje oświadczeń VEX obok SBOM dla produktów zgodnych z CRA. Pełny obraz SBOM i BSI TR-03183 znajdziesz w przewodniku klastra SBOM.

Wyłączenia dla MŚP i zmniejszone obowiązki

Artykuł 64 ust. 10 przewiduje wąską ulgę karną dla najmniejszych producentów. Nie zwalnia nikogo ze zgłaszania.

Mikroprzedsiębiorstwa i małe przedsiębiorstwa (zdefiniowane jako poniżej 50 pracowników i roczny obrót lub suma bilansowa do 10 mln EUR; mikroprzedsiębiorstwa: poniżej 10 pracowników, 2 mln EUR) są zwolnione z kar za przekroczenie 24-godzinnych terminów wczesnego ostrzeżenia z art. 14 ust. 2 lit. a i art. 14 ust. 4 lit. a. Ulga obejmuje wyłącznie kary za timing na etapie 24-godzinnym.

Nadal wymagane, bez ulgi dla MŚP:

• 72-godzinne szczegółowe powiadomienie (art. 14 ust. 2 lit. b i 14 ust. 4 lit. b).
• 14-dniowy raport końcowy dla podatności i 1-miesięczny raport końcowy dla poważnych incydentów.
• Polityka CVD z Załącznika I Część II.
• Wszystkie inne obowiązki CRA, w tym wymóg "braku znanych podatności możliwych do wykorzystania" z Załącznika I Część I.

Średnie przedsiębiorstwa (do 250 pracowników) nie korzystają z ulgi dla MŚP w ogóle. Wyłączenie to wąska ulga karna, nie zmniejszony reżim zgłaszania.

Typowe błędy

• Czekanie na pewność forensyczną przed uruchomieniem zegara. Artykuł 14 stosuje standard uzasadnionego przekonania. Czekanie na dowód oznacza przekroczenie terminu.
• Mylenie CVD ze zgłaszaniem z Artykułu 14. Zgłoszenie badacza to dane wejściowe do CVD; zgłaszanie z Artykułu 14 jest uruchamiane, gdy istnieje dowód aktywnego wykorzystania. Polityka CVD musi zawierać wyraźną bramkę dla tego przejścia.
• Pojedynczy punkt awarii eskalacji. Jedna osoba uprawniona do zgłaszania, nieosiągalna w piątkowy wieczór. Zegar 24-godzinny nie zatrzymuje się.
• Pierwszy kontakt z CSIRT-koordynatorem podczas incydentu. Nawiąż tę relację i ustal routing teraz, gdy żaden zegar nie biegnie.
• Brak opublikowanej polityki CVD. Obowiązek z Załącznika I Część II nie jest spełniony przez dokument wewnętrzny.
• Brak oświadczeń VEX. Każdy CVE w SBOM jest domniemany jako możliwy do wykorzystania, dopóki nie stwierdzisz inaczej. Załącznik I Część I jest znacznie trudniejszy do obrony bez VEX.
• Traktowanie uruchomienia SRP jako przyszłego problemu. Szablony, rotacja dyżurów i relacje z CSIRT muszą być gotowe przed wrześniem 2026 r., a nie budowane po tym terminie.