ENISA o frontier AI: 5 konsekwencji CRA dla producentów

W styczniu 2026 r. curl zamknął swój program skoordynowanego ujawniania podatności (CVD). Raporty generowane przez AI zasypały opiekunów projektu, a zespół uznał, że koszt przyjmowania zgłoszeń przewyższa ich wartość. ENISA cytuje teraz to zamknięcie w oficjalnej publikacji. Oto część, która ma znaczenie dla producenta: producent objęty CRA nie może podjąć tej samej decyzji. Rozporządzenie w sprawie cyberodporności nakłada prawny obowiązek przyjmowania zgłoszeń podatności od 11 grudnia 2027 r. curl wybrał wyjście z gry. Producent takiej opcji nie ma.

To jedna z pięciu kolizji między nowym stanowiskiem ENISA a obowiązkami producenta wynikającymi z CRA. ENISA opublikowała swoje stanowisko w sprawie cyberbezpieczeństwa w erze frontier AI, czyli modeli AI najnowszej generacji w lipcu 2026 r. 16 stron dokumentu adresuje krajowe organy, unijnych decydentów, obrońców i dostawców usług. Żadna sekcja nie jest napisana z myślą o producentach produktów. Konsekwencje i tak trafiają na biurko producenta.

Co dokładnie opublikowała ENISA

Dokument to 16-stronicowe stanowisko, opracowane wspólnie z siecią CSIRT UE i EU-CyCLONe między majem a czerwcem 2026 r. Nota prawna dokumentu stwierdza, że nie tworzy on żadnego obowiązku regulacyjnego. Traktuj go jako sygnał kierunku, w którym zmierzają wytyczne operacyjne ENISA, i czytaj go równolegle z obowiązkami CRA, które już wiążą producenta.

Kluczowe twierdzenie da się zmierzyć. Okno między wykryciem podatności a jej wykorzystaniem skróciło się z lat, przez miesiące, do minut. Dane cytowane przez ENISA wskazują uzbrojenie w ciągu 15 minut od ujawnienia i medianę eksfiltracji na poziomie 72 minut od pierwszego dostępu. NCSC-NL dodaje, że autonomiczne agenty znoszą przewagę obrońcy wynikającą z prywatnego odkrycia: gdy agent AI znajdzie podatność, zbudowanie exploita staje się obliczeniem, nie projektem inżynierskim. Niektóre exploity istnieją, zanim powstanie poprawka, co dokument nazywa ujemnym czasem do wykorzystania (negative time-to-exploit).

ENISA jest szczera co do drugiej strony równania. Dokument stwierdza, że własne zdolności ENISA, razem ze zdolnościami producentów i krajowych CSIRT-ów, wymagają wzmocnienia lub przemyślenia, aby poradzić sobie z nadchodzącą falą wykrywanych podatności. Agencja odpowiedzialna za Jednolitą Platformę Zgłaszania informuje wprost, na piśmie, że wolumeny obciążą wszystkich.

Pięć sekcji poniżej bierze po jednym ustaleniu z dokumentu i pokazuje jego przełożenie na obowiązek CRA.

1. curl zamknął kanał zgłoszeń podatności. Producent nie może.

Na początku 2026 r. raporty o podatnościach generowane przez AI zaczęły przytłaczać część otwartoźródłowego kanału ujawniania podatności. Dokument nazywa szkody wprost: globalna platforma bug bounty wstrzymała nowe zgłoszenia w ramach Internet Bug Bounty po fali zgłoszeń o mieszanej jakości, wspomaganych przez AI, a curl zakończył swój program CVD w styczniu 2026 r., ponieważ opiekunowie projektu nie byli w stanie wchłonąć wolumenu i szumu. Problem to rozcieńczenie sygnału. Recenzenci-ludzie poświęcają czas na oddzielanie prawdziwych ustaleń od zgłoszeń powtarzalnych, powierzchownych lub niezweryfikowanych.

Projekt open source może zamknąć drzwi. Na gruncie CRA producent tego nie może. Rozporządzenie wymaga od producenta prowadzenia i egzekwowania polityki skoordynowanego ujawniania podatności oraz publikowania adresu kontaktowego do zgłaszania podatności w produkcie. Oba obowiązki obowiązują od 11 grudnia 2027 r. Niewygodna prawda brzmi tak: CRA napisano przy założeniu, że zgłoszenia są rzadkie i cenne. Dokument opisuje świat, w którym napływają setkami, pisane maszynowo i niezweryfikowane. Obowiązek zostaje. Założenie, na którym go oparto, zniknęło.

Polityka CVD potrzebuje więc klauzuli na erę AI. Powinny się w niej znaleźć trzy elementy:

• Wymogi walidacyjne: określ, co musi zawierać zgłoszenie, żeby trafić do triażu. Produkt i wersję, których dotyczy, kroki reprodukcji lub proof of concept oraz obserwowany skutek. Zgłoszenie bez tych elementów otrzymuje prośbę o uzupełnienie, nie miejsce w triażu.
• Deduplikacja przed triażem: narzędzia AI zgłaszają wielokrotnie tę samą słabość w różnych sformułowaniach. Grupuj napływające zgłoszenia względem znanych ustaleń w pierwszej kolejności i licz klastry, nie e-maile.
• Zobowiązania triażu według wagi: publikuj czasy odpowiedzi, które da się utrzymać przy dziesięciokrotnie większym wolumenie niż dziś. SLA potwierdzenia zgłoszenia łamane co tydzień to gorszy dowód niż skromniejsze zobowiązanie, którego producent dotrzymuje.

Jeszcze jeden niuans z dokumentu: ENISA zauważa, że ostatnie miesiące przyniosły realny wzrost jakości zgłoszeń od AI, więc zasada „żadnych zgłoszeń od AI” wyrzuca sygnał razem z szumem. Filtruj pod kątem kompletności i odtwarzalności, nie autorstwa. Publikowanie mechaniki przyjmowania zgłoszeń przez security.txt utrzymuje obowiązek punktu kontaktowego w formie możliwej do zweryfikowania.

2. AI zawyża znaczenie słów „znane” i „wykorzystywalne”

Dokument zawiera liczbę, która zmienia inżynierię wydań. Organizacja branżowa poinformowała ENISA, że przeszła z około 80 CVE w I kwartale 2025 r. do niemal 500 w I kwartale 2026 r., a następnie do mniej więcej 500 dziennie po zastosowaniu narzędzi frontier AI. ENISA nazywa to ekonomiczną dewaluacją odkrycia: znajdowanie luk staje się uprzemysłowione, więc wolumen zgłoszeń rośnie szybciej, niż ktokolwiek jest w stanie naprawiać.

CRA zakazuje wprowadzania na rynek produktu z podatnościami, które są znane i wykorzystywalne. Te dwa słowa niosą ten zakaz. AI mechanicznie rozszerza słowo znane: każde uruchomienie skanera na SBOM producenta ujawnia więcej ustaleń, kwartał po kwartale. Czego AI nie zmienia, to słowo wykorzystywalne, i właśnie tam żyje teraz dowód zgodności producenta. Praca nad oceną ważności, czyli oddzielaniem wewnętrznej wagi podatności od prawdopodobieństwa jej wykorzystania, przestaje być optymalizacją i staje się samą bramką wydania.

Argument o łączeniu działa w obie strony. ENISA ostrzega, że podatności niskiego ryzyka nie mogą już być odrzucane jako nieszkodliwe, ponieważ modele łączą je w działające exploity. Zasada „niskie CVSS, zignoruj” jako reguła triażu więc odchodzi. Ale surowa bramka CI oparta na liczbie CVE również umiera: przy 500 ustaleniach dziennie blokuje każde wydanie na zawsze. Co przetrwa, to udokumentowana wykorzystywalność dla każdego ustalenia. Dokument wskazuje dwa narzędzia: EPSS od FIRST dla prawdopodobieństwa wykorzystania oraz VEX do zapisywania, czy produkt w ogóle jest dotknięty.

3. Każda wydana poprawka mapuje lukę w starszych wersjach produktu

Sekcja dokumentu o wykorzystywaniu luk typu N-day stwierdza, że różnice między poprawkami (patch diffs) i zmiany binarne historycznie zasilały inżynierię wsteczną i rozwój exploitów, oraz że okno wykorzystania otwiera się jeszcze przed wdrożeniem poprawki. Modele frontier AI skracają tę inżynierię wsteczną z dni pracy specjalisty do pojedynczego obliczenia. Dokument zauważa też, że analiza wspomagana przez AI przyspiesza zrozumienie kodu systemów starszego typu (legacy).

Nałóż to teraz na własną linię produktową producenta. Producent wydaje poprawkę bezpieczeństwa dla wersji N. Różnica (diff) opisuje podatność precyzyjnie. Jeśli wersja N-1 dzieli dotknięty kod i znajduje się już poza okresem wsparcia, własna poprawka producenta staje się najlepszym dostępnym przewodnikiem po wykorzystaniu luki przeciwko jego własnej zainstalowanej bazie. Przy tempie ludzkim to było znane, ale powolne ryzyko. Przy tempie maszynowym dzieje się tego samego dnia.

To zmienia znaczenie dwóch decyzji wynikających z CRA:

• Okres wsparcia, co najmniej pięć lat w większości przypadków, określa, które wersje wciąż otrzymują poprawki. Wersje poza nim nie znikają z rynku. Pozostają osiągalne, a każda poprawka opublikowana dla wspieranych wersji uczy napastników również o nich. Rozproszenie wersji staje się teraz powierzchnią ataku, więc mniej, dłużej wspieranych wersji jest lepsze niż wiele krótkotrwałych. Zobacz okres wsparcia, by sprawdzić, jak ustala się jego długość.
• Informacja o końcu wsparcia, którą producent jest winien kupującym przed zakupem, staje się informacją operacyjną, nie formalnością na półce. Kupujący korzystający z produktu po ujawnionej dacie korzysta z produktu, który własny strumień poprawek producenta opisuje napastnikom. Powiedz to wprost w treści ujawnienia. Strona informacja o końcu wsparcia opisuje, gdzie data musi się pojawić.

Rada NCSC Irlandii zawarta w dokumencie jest bezpośrednia: przeglądaj inwentaryzację zasobów, priorytetyzuj dyscyplinę łatania i oceniaj narażenie na komponenty pozbawione wsparcia. Dla producenta lustrzanym obowiązkiem jest niedopuszczenie, by luka między „załataną gałęzią” a „porzuconą gałęzią” cicho się powiększała.

4. Poprawki napisane przez AI nadal trafiają na rynek pod oznakowaniem CE producenta

ENISA oczekuje, że naprawa przyjmie te same narzędzia co odkrywanie. Wynikiem jest opisane w dokumencie wąskie gardło weryfikacji: zespoły techniczne stają przed wyzwaniem skali w audytowaniu i walidacji poprawek generowanych przez AI, tak by nie wprowadzały nowych podatności do kodu. Dokument opisuje też presję po drugiej stronie: „lukę autorytetu” (Authority Gap), w której ludzkie komitety zmian nie zdążą autoryzować interwencji w czasie dostępnym na przeciwdziałanie autonomicznym exploitom.

CRA nie ma zdania na temat tego, kto lub co pisze kod producenta. Ma za to jasne zdanie na temat tego, kto za niego odpowiada. Rozporządzenie wymaga skutecznego i regularnego testowania bezpieczeństwa produktu, a deklaracja zgodności podpisywana w ramach oceny zgodności obejmuje każdą poprawkę dystrybuowaną w okresie wsparcia. Poprawka wygenerowana przez AI, która otwiera nową lukę, to niezgodność producenta, w tempie maszynowym.

Praktyczna konsekwencja: potok poprawek producenta potrzebuje dowodów z testów, które nadążają za wolumenem poprawek. Ludzka recenzja każdej linii kodu napisanej przez AI nie skaluje się do 500 ustaleń dziennie. Udokumentowane, zautomatyzowane testy bezpieczeństwa na ścieżce poprawek się skalują i produkują artefakty potrzebne do dokumentacji technicznej. Producent wdrażający naprawę wspomaganą przez AI powinien zapisywać, które poprawki powstały maszynowo i jaką walidację każda z nich przeszła. Gdy organ nadzoru zapyta, jak producent utrzymał uczciwość obowiązku testowania przy takim tempie, odpowiedzią jest log, nie deklaracja polityki.

5. Zgłoszenia podatności producenta stają się publiczną historią bezpieczeństwa

Ostatnia konsekwencja jest najcichszą w dokumencie. ENISA pisze, że skorelowane dane EUVD mogą identyfikować gorące punkty łańcucha dostaw, słabości systemowe i trendy w podatnościach przyspieszane przez odkrywanie wspomagane AI. Jedno zdanie dalej dodaje: zgłoszenia związane z CRA mogą pomóc zweryfikować deklaracje producentów o wzmocnieniu zabezpieczeń względem rzeczywistej wykorzystywalności i wzorców incydentów.

Producent powinien czytać to z własnej perspektywy. Od 11 września 2026 r. producent zgłasza aktywnie wykorzystywane podatności i poważne incydenty w ciągu 24 godzin za pośrednictwem Jednolitej Platformy Zgłaszania, następnie składa uzupełnienie w ciągu 72 godzin, a na końcu raport końcowy w ciągu 14 dni od wdrożenia poprawki. Każde zgłoszenie trafia do infrastruktury, którą ENISA planuje korelować. Z czasem ta korelacja staje się historią bezpieczeństwa każdego dostawcy: jak często był wykorzystywany, jak szybko naprawiał, jak jego rejestr wypada na tle jego własnych deklaracji.

Z tego wynikają dwa zachowania:

• Formułuj deklaracje o bezpieczeństwie produktu, które da się obronić własną historią zgłoszeń. „Wzmocniony” i „bezpieczny z założenia” na karcie danych produktu w końcu znajdą się obok wiersza producenta w EUVD. Marketing, który wyprzedza dane, staje się tematem rozmowy z organem nadzoru rynku.
• Traktuj jakość zgłoszeń jako reputację, nie papierkową robotę. Precyzyjne powiadomienie w ciągu 72 godzin z realnymi środkami naprawczymi czyta się inaczej niż minimalne zgłoszenie, a deklarowanym celem ENISA jest zamknięcie luki między ujawnieniem a skoordynowaną odpowiedzią przy użyciu tych danych. Sam łańcuch zgłaszania ruszył etapami w tym roku: ENISA przyjęła swoje pierwsze Organy Numerujące CVE w maju 2026 r.

Streszczenie wykonawcze dokumentu mówi, że SRP musi być używana, gdy tylko zacznie działać, do radzenia sobie z wyzwaniami nowych zjawisk. ENISA zobowiązała się do tego na piśmie. Zgłoszenia producenta są danymi wejściowymi tego procesu.

Niniejszy artykuł ma charakter wyłącznie informacyjny i nie stanowi porady prawnej. W celu uzyskania szczegółowych wskazówek dotyczących zgodności należy skonsultować się z wykwalifikowanym doradcą prawnym.