Raport Azul „Luka w zabezpieczeniach AI 2026” pokazuje, że przedsiębiorstwa nie nadążają z łataniem systemów za zagrożeniami związanymi z AI

Raport Azul „Luka w zabezpieczeniach AI 2026” wskazuje na rozbieżność między szybkością, z jaką liderzy ds. bezpieczeństwa spodziewają się działań atakujących wykorzystujących AI, a czasem potrzebnym ich organizacjom na wdrożenie poprawek. W ankiecie przeprowadzonej wśród 300 amerykańskich liderów ds. bezpieczeństwa 69% stwierdziło, że atakujący mogą stworzyć działający exploit w ciągu trzech dni, a 44% przyznało, że ich organizacje potrzebują co najmniej czterech dni, by załatać krytyczną podatność w całym środowisku produkcyjnym.

Najbardziej uderzającym wnioskiem z raportu jest doświadczenie respondentów związane z tymi opóźnieniami: 85% zgłosiło incydent, podejrzenie incydentu lub sytuację bliską incydentowi, które przypisali opóźnieniom w instalowaniu poprawek. Liczba ta odzwierciedla zgłoszone doświadczenia, a nie niezależnie zweryfikowany odsetek naruszeń — nie dowodzi też, że zdarzenia te spowodowała AI.

Badanie, zlecone przez Azul i przeprowadzone przez Censuswide, koncentruje się na organizacjach szeroko wykorzystujących Javę. Jego szerszy przekaz dotyczy działań operacyjnych: wykrycie podatności to dopiero początek. Poprawka musi przejść testy, dotrzeć do systemów, których dotyczy problem, i usunąć zagrożenie w całym środowisku, którego zespoły mogą nie widzieć w pełni.

Dwa zegary, które nie chodzą równo

W ankiecie osobno zbadano oczekiwania liderów dotyczące możliwości atakujących oraz zdolność ich organizacji do wdrażania poprawek:

• 69% uważa, że atakujący wykorzystujący AI mogą stworzyć exploit w ciągu najwyżej trzech dni; 22% twierdzi, że zajmie im to mniej niż 24 godziny.
• 56% deklaruje, że może wdrożyć krytyczną poprawkę w całym środowisku produkcyjnym w ciągu trzech dni: 13% w mniej niż 24 godziny, a 43% w ciągu jednego do trzech dni.
• 44% potrzebuje więcej czasu: 32% od czterech do sześciu dni, a 12% jeszcze dłużej.

Są to rozkłady odpowiedzi ankietowych, a nie pomiary wyścigu atakujących z konkretnymi organizacjami w przypadku tych samych podatności. Różnica uzasadnia obawy o gotowość, ale nie należy jej interpretować jako dokładnego, trzydniowego okna narażenia dla każdego przedsiębiorstwa.

Ta sama nierównowaga jest widoczna przy progu jednego dnia: 22% spodziewa się, że atakujący będą działać tak szybko, w porównaniu z 13% respondentów, którzy twierdzą, że ich organizacja zdoła w tym czasie wdrożyć poprawkę. Tymczasem 59% przyznaje, że narzędzia do ataków oparte na AI zwiększają narażenie, ale nie zmieniło swojego podejścia do bezpieczeństwa.

Testowanie w znacznym stopniu wydłuża opóźnienia

Testowanie aktualizacji środowiska uruchomieniowego Java wydłuża cykl instalowania poprawek o co najmniej cztery dni w 58% ankietowanych organizacji. W tej grupie 36% zgłasza opóźnienie wynoszące od czterech do sześciu dni, a 22% — tydzień lub dłużej. Kolejne 33% podaje od jednego do trzech dni, a 9% — mniej niż 24 godziny. Żaden respondent nie stwierdził, że pominięto testowanie.

Zmiany w środowisku uruchomieniowym mogą wpływać na wiele aplikacji, dlatego testowanie ma praktyczne uzasadnienie: aktualizacja zabezpieczeń, która zakłóci działanie krytycznej usługi, stwarza kolejny problem operacyjny. Raport wskazuje, że do tego obciążenia przyczynia się zakres aktualizacji, ponieważ pełne kwartalne wydania OpenJDK mogą obejmować zmiany niezwiązane z bezpieczeństwem, obok poprawek podatności.

Azul osobno przeanalizowało 26 kwartalnych aktualizacji OpenJDK z okresu ponad sześciu lat i uznało, że sześć z nich spowodowało poważną regresję. Wartość 23% to ocena wydań dokonana przez dostawcę, a nie szacunkowa częstotliwość awarii aplikacji pojedynczego klienta.

Wśród najczęściej zgłaszanych przeszkód utrudniających szybsze instalowanie poprawek 44% respondentów wymienia rozbudowane testowanie, 40% — złożoność lub wiek systemów, których dotyczy problem, a 36% — ograniczoną widoczność znanych podatności. Opóźnienia dostawców w udostępnianiu poprawek wskazało 25%. Wyniki pokazują, że znaczna część wyzwań związanych z usuwaniem podatności wynika z wewnętrznych procesów wdrożeniowych przedsiębiorstw.

Zgłoszenia incydentów i braki w inwentaryzacji wymagają odrębnej interpretacji

Pięćdziesiąt pięć procent respondentów zgłasza potwierdzony incydent przypisywany opóźnieniom w instalowaniu poprawek, a 53% — sytuację bliską incydentowi. Respondenci mogli wybrać kilka odpowiedzi, dlatego wartości te częściowo się pokrywają i nie należy ich sumować. Szerszy wynik 85%, podany w nagłówku, obejmuje również podejrzenia incydentów.

Badanie nie dowodzi, że wszystkie te zdarzenia dotyczyły podatności w Javie. Uczestnicy pracują w organizacjach intensywnie wykorzystujących Javę, ale badanie obejmuje zarówno pytania o instalowanie poprawek w oprogramowaniu ogólnie, jak i pytania dotyczące konkretnie środowisk uruchomieniowych Java.

Drugim wyzwaniem jest inwentaryzacja. Tylko 19% respondentów twierdzi, że co najmniej 90% wykorzystywanych w środowisku produkcyjnym środowisk uruchomieniowych Java ma najnowszy poziom poprawek bezpieczeństwa. Oznacza to, że 81% nie osiąga tego progu; nie znaczy to, że 81% nie ma żadnych aktualnych środowisk. Około jedna piąta respondentów podaje, że aktualne jest najwyżej 50% ich środowisk.

Osobno 51% respondentów przyznaje, że ma jedynie częściową lub ograniczoną widoczność krytycznych środowisk uruchomieniowych Java, w tym instancji wbudowanych, starszych i niezarządzanych. Wykrycie podatnego środowiska uruchomieniowego w aplikacji pakietowej lub kontenerze może być trudniejsze niż zidentyfikowanie instalacji zarządzanej centralnie. Poprawka nie usunie zagrożenia w systemie, do którego nie dociera proces wdrożeniowy.

Co technologia Azul wnosi do dyskusji

Oferta Azul w zakresie aktualizacji zabezpieczeń ogranicza wybrane wydania do poprawek bezpieczeństwa opartych na wcześniej ustabilizowanej bazie OpenJDK. Firma udostępnia aktualizacje kwartalne, ukierunkowane aktualizacje comiesięczne oraz aktualizacje poza regularnym harmonogramem, dążąc do ograniczenia ilości niezwiązanych z nimi zmian, które przedsiębiorstwa muszą ocenić przed wdrożeniem pilnej poprawki.

To węższa interwencja techniczna niż wyeliminowanie potrzeby kontroli zmian. Ograniczenie zmian w kodzie może zmniejszyć zakres walidacji, ale nadal istotne są testy specyficzne dla aplikacji, odpowiedzialność za wdrożenie i przygotowanie do wycofania zmian. Azul jest sponsorem raportu i sprzedaje produkty ukierunkowane na problemy, które raport mierzy.

Jej narzędzia do inwentaryzacji środowisk Java i wykrywania podatności odpowiadają na inną potrzebę w tym procesie: identyfikację środowisk uruchomieniowych, wersji i stopnia narażenia, tak aby można było powiązać nowe ujawnienie podatności z dotkniętymi nią systemami. Raport nie przedstawia kontrolowanego porównania, które pokazywałoby, w jakim stopniu badane organizacje poprawiłyby swoje wyniki, wdrażając te produkty.

„Nasze badania pokazują, że liderzy ds. bezpieczeństwa rozumieją zagrożenie: problemem nie jest już brak świadomości, lecz realizacja działań” — powiedział Scott Sellers, współzałożyciel i dyrektor generalny Azul.

Przekładanie planów aktualizacji na mierzalny proces

W nadchodzącym roku 32% respondentów wskazuje szybsze i częstsze instalowanie poprawek jako główną strategię ograniczania narażenia, a 26% stawia na lepszą inwentaryzację oprogramowania i środowisk uruchomieniowych. Kolejne 17% priorytetowo traktuje wykrywanie zagrożeń i reagowanie na nie zamiast szybszego instalowania poprawek.

Badanie wskazuje na potrzebę śledzenia całej drogi od ujawnienia podatności do jej usunięcia: które systemy są nią dotknięte, kto za nie odpowiada, jakie testy są wymagane i czy poprawka rzeczywiście trafiła do środowiska produkcyjnego. Termin jest przydatny tylko wtedy, gdy zespoły mogą potwierdzić zakończenie prac we wszystkich odpowiednich systemach.

Wyniki dotyczące USA pochodzą z badań terenowych przeprowadzonych w dniach 3–7 sierpnia 2026 r. wśród liderów ds. bezpieczeństwa z organizacji zatrudniających co najmniej 1000 pracowników i w znacznym stopniu wykorzystujących Javę/JVM w środowisku produkcyjnym. Są to odpowiedzi deklaratywne zebrane od określonej populacji, a nie wyniki spisu przedsiębiorstw ani bezpośredniego pomiaru rozwoju exploitów.

W pełnym Raporcie o luce w zabezpieczeniach związanych z AI z 2026 r. szczegółowo opisano wyniki i metodologię. Najważniejszy wniosek jest taki, że należy jednocześnie przyspieszyć instalowanie poprawek i zwiększyć widoczność środowisk uruchomieniowych: szybka poprawka ma ograniczoną wartość, jeśli organizacja nie potrafi zidentyfikować wszystkich wdrożeń, których dotyczy, ani potwierdzić, że aktualizacja do nich dotarła.