Między 1 sierpnia a 11 września 2026 CISA dopisała do katalogu znanych wykorzystywanych podatności 53 pozycje. Dla 35 z nich termin usunięcia wynosił trzy dni. Dla pozostałych osiemnastu — czternaście. Nie ma tam ani jednego wpisu z terminem liczonym w miesiącach.
To nie jest zaostrzenie dotychczasowej praktyki. To inna doktryna, zapisana w dyrektywie BOD 26-04, która uchyla i zastępuje dwa wcześniejsze dokumenty: BOD 22-01 z 2021 roku, który powołał do życia katalog KEV, oraz BOD 19-02 regulujący usuwanie podatności w systemach dostępnych z internetu.
Co się zmieniło w podejściu
Poprzedni model opierał się w praktyce na punktacji CVSS i jednolitych terminach. BOD 26-04 wprowadza priorytetyzację opartą na czterech pytaniach o konkretny system w konkretnym środowisku:
- Ekspozycja zasobu — czy podatny system jest publicznie dostępny?
- Status KEV — czy podatność figuruje w katalogu znanych wykorzystywanych podatności?
- Automatyzacja ataku — czy atakujący może zautomatyzować wszystkie kroki potrzebne do wykorzystania podatności?
- Wpływ techniczny — czy po udanym ataku przejmuje częściową, czy pełną kontrolę nad systemem?
Różnica jest zasadnicza. CVSS opisuje podatność w oderwaniu od kontekstu. Te cztery zmienne opisują ryzyko — czyli podatność osadzoną w Twojej architekturze. Ta sama luka na serwerze wystawionym do internetu i na maszynie w odizolowanym segmencie to dwie różne sprawy, choć numer CVE mają identyczny.
Uzasadnienie CISA zawiera zdanie, które warto zacytować dosłownie: wykorzystanie sztucznej inteligencji przez atakujących „może dodatkowo zawęzić czas, jaki obrońcy mają na reakcję między wydaniem łatki a możliwym wykorzystaniem podatności”. To oficjalne przyznanie, że okno między publikacją poprawki a pojawieniem się działającego exploita skurczyło się na tyle, by wymagać przepisania zasad.
Koniec z odhaczaniem łatki
Najpoważniejsza zmiana kryje się w szczególe. Przy najwyższym priorytecie dyrektywa nie kończy się na wymogu usunięcia podatności w ciągu trzech dni. Nakłada dodatkowo obowiązek przeprowadzenia audytu systemu.
Założenie leżące u podstaw tego wymogu jest brutalnie szczere: przy tej klasie podatności zainstalowanie poprawki nie przywraca stanu bezpieczeństwa, bo atakujący najprawdopodobniej już tam był. Łatka zamyka drzwi. Nie usuwa nikogo, kto wszedł, zanim je zamknięto.
W większości organizacji, także w Polsce, proces wygląda inaczej: skaner wykrywa podatność, zespół instaluje aktualizację, ticket zostaje zamknięty, raport pokazuje zgodność. Nikt nie sprawdza, co działo się na tym systemie przez trzy tygodnie między publikacją exploita a wdrożeniem poprawki. BOD 26-04 mówi wprost, że to niewystarczające.
Osiem podatności, które nie są nowe
W analizowanym okresie do katalogu trafiło osiem podatności z lat wcześniejszych niż 2026. Ta lista mówi o stanie bezpieczeństwa więcej niż niejeden raport branżowy:
- CVE-2015-3246 — Red Hat Libuser
- CVE-2015-5287 — Red Hat Automatic Bug Reporting Tool
- CVE-2019-1068 — Microsoft SQL Server
- CVE-2021-23758 — Ajax.NET Professional
- CVE-2022-0995 — jądro Linux
- CVE-2023-49105 — ownCloud
Podatności z 2015 roku zostały dopisane do katalogu aktywnie wykorzystywanych luk w sierpniu 2026! Jedenaście lat po ujawnieniu. Poprawki istnieją od dekady.
Wniosek: atakujący nie potrzebują luk zero-day, dopóki działają te sprzed jedenastu lat. Cała branżowa rozmowa o zaawansowanych technikach i grupach APT rozbija się o systemy, na których od dekady nie założono łatki — bo „to działa, nie ruszamy” albo „ten serwer jest za stary na aktualizację”.
Co z tego wynika dla polskiej organizacji?
BOD 26-04 jest wiążąca dla amerykańskich federalnych agencji cywilnych. Nie obowiązuje w Polsce i nie ma tu mocy prawnej. Ale stanowi najbardziej aktualny publicznie dostępny zapis tego, jak instytucja dysponująca danymi o realnych atakach ocenia dziś tempo zagrożeń — i to czyni ją użytecznym punktem odniesienia niezależnie od jurysdykcji.
Trzy rzeczy warte przeniesienia na nasze własne podwórko.
Po pierwsze — przestań priorytetyzować wyłącznie po CVSS. Podatność o punktacji 7.5 na systemie wystawionym do internetu, z publicznie dostępnym exploitem, jest pilniejsza niż dziewiątka na maszynie w odseparowanym segmencie! Cztery zmienne z dyrektywy dają się wdrożyć bez żadnego nowego narzędzia — wystarczy zadać je przy każdym zgłoszeniu.
Po drugie — katalog KEV jest darmowy i maszynowo czytelny. Publikowany jako plik JSON, aktualizowany na bieżąco, bez rejestracji i bez opłat. Zestawienie go z własnym rejestrem zasobów to zadanie na jedno popołudnie, a odpowiada na najważniejsze pytanie: czy mam u siebie coś, o czym wiadomo, że jest właśnie wykorzystywane w atakach.
Po trzecie — miej przygotowaną ścieżkę awaryjną na trzy dni. Nie chodzi o łatanie wszystkiego w 72 godziny, bo to niewykonalne i niepotrzebne. Chodzi o to, by istniała procedura, którą można uruchomić dla wąskiej klasy przypadków: system wystawiony publicznie, obecny w KEV, atak automatyzowalny, pełne przejęcie kontroli. Jeśli jedyną dostępną opcją jest comiesięczne okno serwisowe, ta procedura nie istnieje.
Liczba, którą warto zapamiętać
Trzydzieści pięć z pięćdziesięciu trzech. Dwie trzecie podatności dopisanych do katalogu w ciągu sześciu tygodni zostało zakwalifikowanych jako wymagające reakcji w ciągu trzech dni.
Jeśli Twój proces zarządzania podatnościami nie jest w stanie obsłużyć takiego tempa dla systemów o najwyższym ryzyku, to nie jest kwestia niedoboru narzędzi ani ludzi. To kwestia procesu zaprojektowanego pod tempo zagrożeń sprzed pięciu lat, który nigdy nie został zrewidowany.Źródła