AWS opisało, jak AI klasyfikuje CVE jądra EC2

Podczas konferencji Linux Plumbers Conference, która odbyła się wcześniej w październiku 2026 r., inżynierowie AWS opisali dwuetapowy proces wstępnej oceny CVE dla jądra Linux utrzymywanego na potrzeby infrastruktury Amazon EC2. Skrypt najpierw filtruje zgłoszenia, agent AI klasyfikuje pozostałe, a inżynierowie sprawdzają wyniki. Agent nie wdraża poprawek.

CVE (Common Vulnerabilities and Exposures) to system identyfikowania i opisywania podatności. Proces dotyczy jądra infrastruktury EC2, a nie systemu Amazon Linux ani jąder działających wewnątrz maszyn wirtualnych klientów.

Od filtra skryptowego do decyzji inżynierów

Pierwszy etap nie korzysta ze sztucznej inteligencji. Skrypt porównuje zakres wersji wymieniony w CVE oraz wskazane pliki źródłowe z wersją jądra i plikami wbudowanymi w obraz AWS. W swoim środowisku AWS odfiltrowywało w ten sposób około 70% CVE. Wynik zależy jednak w dużej mierze od konfiguracji i środowiska.

Pozostałe zgłoszenia trafiają do agenta AI. AWS przekazuje mu własne drzewo kodu jądra, konfiguracje, model zagrożeń i kryteria oceny dotkliwości. Agent wykonuje osobną klasyfikację dla każdego CVE i zwraca tabelę z jednym wierszem na zgłoszenie, zawierającą między innymi podsystem, typ podatności i wektor ataku.

Inżynierowie AWS opisali też ponad 32 000 opcji konfiguracji jądra. Wyłączenie niepotrzebnej funkcji może ograniczyć ilość kodu w obrazie i zwiększyć skuteczność filtra, ale wybranie niewłaściwej opcji może wywołać trudne do zauważenia błędy lub pogorszyć wydajność.

Klasyfikacja przyspiesza analizę, ale nie zastępuje przeglądu

Według prezentacji AWS agent potrzebował około 3,4 sekundy na wstępną analizę jednego CVE, podczas gdy ręczna analiza zajmowała minuty. To czas klasyfikacji, nie cała droga od zgłoszenia do poprawki: osobno pozostają przegląd inżynierów, naprawa, testy i wdrożenie. AWS wskazało, że przegląd człowieka był najwolniejszym etapem procesu.

Justinien Bouron, jeden z prezenterów z AWS, nieformalnie szacował, że problematyczne było 5–10% decyzji agenta. To szacunek, a nie wynik formalnego benchmarku.

Aktualizacja jądra wymaga pracy także poza jego kodem

Przy przejściu z wersji 5.10 na 6.12 AWS przypisało śledzone problemy aktualizacyjne do czterech obszarów:

AWS podało osobno, że 15% poprawek dotyczących kodu jądra przekazano do głównej gałęzi projektu (upstream). Udziały w tabeli opisują problemy śledzone podczas tej aktualizacji, a nie odsetek CVE ani czas napraw.

Przykłady z prezentacji pokazują, dlaczego kwalifikacja nowego jądra obejmuje cały stos. Zmiana sposobu przechowywania obszarów pamięci wirtualnej spowolniła operacje mmap() i munmap(). Zmiana harmonogramu procesora wpłynęła na czas operacji fork(), a zwiększenie domyślnego maksymalnego rozmiaru żądania w warstwie blokowej powodowało przekroczenia czasu operacji firmware’u, które AWS rozwiązywało przez dostrojenie sysctl.

AWS podało, że aktualizacja z 4.19 do 5.10 trwała 24 miesiące, z 5.10 do 6.12 zajęła 12 miesięcy, a z 6.12 do 6.18 sześć miesięcy. Za skrócenie kolejnych prac prezentacja wskazywała lepsze narzędzia, szersze testy i doświadczenie zespołu, nie samą różnicę wieku między wydaniami LTS. LTS oznacza wydanie z długoterminowym wsparciem.

Dane gałęzi LTS i możliwe reakcje na CVE

Zestawienie AWS z 16 września 2026 r. podawało liczbę niezałatanych CVE w poszczególnych gałęziach Linux LTS oraz medianę czasu od włączenia poprawki do głównej gałęzi do jej wydania w gałęzi LTS:

Liczby CVE dotyczą całych gałęzi, nie podatności stwierdzonych w jądrze używanym przez AWS w EC2. Podane mediany mierzą czas od połączenia poprawki z główną gałęzią Linux do jej wydania w gałęzi LTS, a nie czas wdrożenia przez AWS.

Po ocenie konkretnego CVE AWS rozważało cztery rodzaje reakcji: brak działania, gdy podatność nie dotyczy środowiska; oczekiwanie na kolejną poprawkę LTS, jeśli wpływ można zaakceptować; przeniesienie poprawki (cherry-pick), gdy potrzebna jest szybsza reakcja; albo zastosowanie obejścia, gdy aktualizacja jądra nie jest możliwa. Prezentacja wskazywała też, że przenoszenie poprawek na starsze, bardziej różniące się gałęzie bywa trudne, a brakująca poprawka wstępna może sprawić, że backport nie usunie podatności albo wprowadzi błędy.

Według relacji z 27 października AWS nie udostępniło opisanych narzędzi. Dylan Johnson mówił o chęci zbadania możliwości udostępnienia filtra, nie o ustalonym terminie jego publikacji.