Skanowanie podatności w 2026 r.: od CVSS 4.0 po EPSS, CISA KEV i zarządzanie ekspozycją

Skanowanie, pentest i audyt odpowiadają na inne pytania

Skanowanie podatności odpowiada przede wszystkim na pytanie: jakie znane problemy techniczne można wykryć w badanym zakresie przy użyciu określonych testów i danych. Daje szerokie, powtarzalne pokrycie i nadaje się do pracy cyklicznej, ale wynik wymaga walidacji.

Test penetracyjny odpowiada na inne pytanie: czy w uzgodnionym scenariuszu można rzeczywiście wykorzystać słabość, połączyć kilka problemów w ścieżkę ataku albo obejść zabezpieczenie. Pentest może ujawnić błędy logiki biznesowej lub kontroli dostępu, których typowy skaner infrastruktury nie wykryje. Z drugiej strony pentest jest badaniem punktowym w czasie i nie zastępuje ciągłego wykrywania nowych podatności. NIST SP 800-115 opisuje te techniki jako uzupełniające metody oceny bezpieczeństwa.^[1]

Audyt bezpieczeństwa IT ocenia natomiast stan wobec ustalonych kryteriów: prawa, normy, umowy, polityki albo przyjętej metodyki. Może sprawdzić, czy organizacja ma proces zarządzania podatnościami, jak ustala priorytety, czy przestrzega terminów, jak obsługuje wyjątki i czy potrafi wykazać wykonanie działań. Skan podatności może być jednym z dowodów w takim audycie, ale nie jest z nim tożsamy.

Z tego powodu nie należy przedstawiać skanowania, pentestu i audytu jako trzech wersji tej samej usługi. Równie błędne jest założenie, że każda organizacja podlegająca KSC, DORA lub RODO musi kupić wszystkie trzy w tym samym cyklu. Obowiązki wynikają z konkretnego reżimu prawnego, ryzyka i architektury. W niektórych przypadkach prawo wymaga wprost testowania lub skanowania, w innych wymaga rezultatu, który może być osiągnięty różnymi środkami.

Najpierw zakres i inwentaryzacja

Program zarządzania podatnościami zaczyna się przed pierwszym skanem. Trzeba wiedzieć, co podlega ocenie.

Do zakresu mogą należeć serwery, stacje robocze, urządzenia sieciowe, systemy dostępne z internetu, usługi chmurowe, urządzenia mobilne, kontenery, obrazy maszyn, aplikacje, systemy OT i urządzenia dostawców. Z punktu widzenia skuteczności ważniejsza od samej liczby znalezionych CVE bywa odpowiedź na pytanie, jaka część rzeczywistego środowiska w ogóle trafia do programu.

Brak zasobu w inwentaryzacji jest szczególnie niebezpieczny, ponieważ skaner może działać bezbłędnie i nadal nie zobaczyć systemu, którego nie ma w zakresie. Dotyczy to między innymi krótkotrwałych maszyn w chmurze, systemów testowych przekształconych w produkcyjne, urządzeń instalowanych przez podwykonawców albo zasobów uruchomionych poza standardowym procesem zmian.

Dlatego dojrzały program łączy informacje z inwentaryzacji aktywów, narzędzi chmurowych, systemów zarządzania urządzeniami, CMDB, EDR, monitoringu sieci i danych od właścicieli usług. Nie chodzi o stworzenie jednego idealnego rejestru, lecz o wykrywanie rozbieżności między źródłami.

Skanowanie z uwierzytelnieniem i bez uwierzytelnienia

Skanowanie bez uwierzytelnienia obserwuje system z perspektywy zdalnego klienta. Może wykrywać otwarte usługi, bannery, wersje, charakterystyczne odpowiedzi, błędy konfiguracji i podatności dostępne przez sieć. Jest przydatne do oceny powierzchni ataku, szczególnie od strony internetu, ale nie zawsze potrafi poprawnie ustalić stan poprawek lub konfigurację hosta.

Skanowanie z uwierzytelnieniem wykorzystuje konto techniczne albo inny mechanizm dostępu do badanego systemu. Dzięki temu może odczytać rzeczywiste wersje pakietów, stan aktualizacji i ustawienia, których nie widać z sieci. Zwykle poprawia jakość danych i ogranicza część fałszywych dopasowań, ale wprowadza nowe wymagania: bezpieczne przechowywanie poświadczeń, minimalne uprawnienia, rejestrowanie użycia konta i kontrolę zasięgu dostępu.

Nie ma jednej reguły mówiącej, że pierwszy tryb służy tylko do skanowania internetu, a drugi tylko do sieci wewnętrznej. Dobór zależy od celu. Dla systemu dostępnego publicznie warto wiedzieć zarówno, co widzi niezaufany klient z zewnątrz, jak i czy system od strony lokalnej ma rzeczywiście zainstalowane właściwe poprawki.

Skanowanie nie powinno być testem destrukcyjnym. Aktywne testy mogą jednak wpływać na stare urządzenia, systemy czasu rzeczywistego, urządzenia OT, drukarki, sprzęt medyczny albo niestabilne usługi. Przed uruchomieniem skanu trzeba ustalić reguły prowadzenia badania, okna czasowe, mechanizm przerwania testu i kontakt do właściciela systemu. NIST SP 800-115 wyraźnie traktuje autoryzację i rules of engagement jako element przygotowania testów technicznych.^[1]

Walidacja: wynik skanera nie jest jeszcze ustaleniem

Najbardziej kosztownym błędem programu jest przekazywanie surowej listy wyników bez walidacji.

Skaner może błędnie przypisać podatność na podstawie wersji widocznej z sieci. Może nie uwzględnić backportowanej poprawki dostawcy systemu operacyjnego. Może rozpoznać bibliotekę, która znajduje się na dysku, ale nie jest używana w podatnym kontekście. Może też nie wykryć problemu, jeżeli usługa jest filtrowana albo identyfikacja wersji jest niemożliwa.

Walidacja nie zawsze oznacza ręczne sprawdzenie każdej pozycji. Oznacza natomiast istnienie sposobu rozstrzygania przypadków niepewnych, uwzględniania advisory producenta, lokalnego stanu pakietu, konfiguracji, ekspozycji oraz dowodów ze skanowania uwierzytelnionego.

Raport powinien rozróżniać co najmniej: potwierdzone podatności, prawdopodobne obserwacje wymagające weryfikacji, pozycje nieaplikowalne oraz wyniki, których nie dało się rozstrzygnąć. Dzięki temu właściciel systemu wie, na czym oparto wniosek i co powinien zrobić dalej.

CVSS 4.0: dotkliwość, nie gotowy wynik ryzyka

FIRST opublikował CVSS 4.0 1 listopada 2023 r. Czerwcowa prezentacja z 2023 r. była wcześniejszym pokazem nowej wersji, a nie datą jej oficjalnej publikacji.^[2]

CVSS 4.0 zachowuje skalę 0-10, ale zmienia model. Usunięto metrykę Scope z wersji 3.1 i rozdzielono skutki dla systemu podatnego od skutków dla kolejnego systemu. Dodano nową bazową metrykę Attack Requirements, a interakcję użytkownika opisano bardziej szczegółowo. FIRST wyodrębnia także grupy Base, Threat, Environmental i Supplemental.^[2]

Grupa Threat zawiera między innymi Exploit Maturity, czyli informację o dojrzałości dostępnych sposobów wykorzystania podatności. Grupa Environmental pozwala konsumentowi oceny uwzględnić znaczenie poufności, integralności i dostępności w jego własnym środowisku oraz modyfikować wybrane metryki bazowe. Grupa Supplemental zawiera dodatkowe informacje, takie jak Safety, Automatable, Recovery, Vulnerability Response Effort i Provider Urgency. Metryki uzupełniające nie zmieniają samego wyniku CVSS.^[2]

Najważniejsze zastrzeżenie FIRST jest jednoznaczne: CVSS Base Score mierzy dotkliwość, a nie ryzyko. Sam wynik bazowy nie uwzględnia tego, czy dany system istnieje w naszej organizacji, czy jest wystawiony do internetu, czy zawiera dane krytyczne, czy ma zabezpieczenia kompensujące i czy istnieją oznaki aktywnego wykorzystania.^[2]

Nie należy więc tworzyć polityki w rodzaju "wszystko z CVSS >= 7 łatamy w 30 dni" bez dalszego kontekstu. Taki próg może być elementem wewnętrznej polityki, ale nie jest uniwersalną granicą ryzyka.

EPSS: prognoza wykorzystania, nie druga skala dotkliwości

Exploit Prediction Scoring System (EPSS) jest rozwijanym przez społeczność FIRST modelem danych, który szacuje prawdopodobieństwo, że dla opublikowanej CVE zostanie zaobserwowana aktywność exploitacyjna w ciągu kolejnych 30 dni. Wynik mieści się w przedziale od 0 do 1 i jest aktualizowany codziennie.^[3] Podstawy wcześniejszej generacji modelu opisano także w recenzowanej publikacji zespołu Jacobs i współautorów.^[4]

EPSS nie mówi, jak poważny będzie skutek udanego ataku. Nie zna też naszego środowiska. Wynik 0,10 oznacza oszacowanie około 10-procentowego prawdopodobieństwa zaobserwowania wykorzystania w horyzoncie 30 dni w modelu EPSS, a nie "10 procent ryzyka organizacji".^[3]

Nie istnieje oficjalny próg FIRST, powyżej którego każda podatność powinna zostać uznana za krytyczną. Organizacja może zdefiniować progi na potrzeby swojego procesu, ale powinna je kalibrować do przepustowości zespołu, rodzaju zasobów i akceptowanego poziomu ryzyka. FIRST publikuje również percentyle, które pomagają ocenić względną pozycję podatności w całej populacji.^[3]

CISA KEV: dowód aktywnego wykorzystania

Katalog Known Exploited Vulnerabilities prowadzony przez CISA zawiera podatności spełniające kryteria potwierdzonego wykorzystania w rzeczywistych atakach. CISA sama określa go jako źródło, które organizacje powinny wykorzystywać jako wejście do priorytetyzacji zarządzania podatnościami.^[5]

Dla amerykańskich cywilnych agencji federalnych terminy napraw wynikają z Binding Operational Directive 22-01 i terminów przypisanych poszczególnym wpisom. Ten obowiązek nie przenosi się automatycznie na polskie przedsiębiorstwa ani jednostki publiczne. W Polsce KEV jest przede wszystkim mocnym sygnałem threat intelligence: pokazuje, że pytanie "czy ktoś to wykorzystuje?" ma już odpowiedź twierdzącą.

KEV nie jest listą wszystkich podatności wykorzystywanych na świecie. Wpis zależy od spełnienia kryteriów CISA i dostępnych dowodów. Dlatego brak CVE w KEV nie oznacza, że podatność jest bezpieczna albo nie jest używana w żadnej kampanii. Dobrze prowadzony program uzupełnia KEV o advisory producentów, komunikaty CSIRT/CERT, ENISA, dane z własnego SOC oraz inne wiarygodne źródła informacji o zagrożeniach.^[5][7][19]

Jak łączyć CVSS, EPSS, KEV i kontekst zasobu

Najskuteczniejsza priorytetyzacja nie sprowadza tych sygnałów do jednej arbitralnej liczby. Lepiej zachować informację o tym, co każdy z nich opisuje.

• CVSS odpowiada na pytanie o techniczną dotkliwość podatności.
• EPSS odpowiada na pytanie o prognozowane prawdopodobieństwo zaobserwowania wykorzystania w najbliższych 30 dniach.
• KEV odpowiada na pytanie, czy istnieją potwierdzone dowody wykorzystania w realnych atakach.
• Kontekst organizacji odpowiada na pytanie, czy podatny zasób jest ważny, osiągalny, narażony i jakie będą skutki kompromitacji.

Do tego trzeba dodać informacje operacyjne: dostępność poprawki, trudność jej wdrożenia, możliwość zastosowania zabezpieczenia kompensującego, zależności biznesowe i wymagania prawne.

Przykładowo podatność o umiarkowanym CVSS może wymagać natychmiastowej uwagi, jeżeli znajduje się w KEV, dotyczy urządzenia brzegowego dostępnego z internetu i umożliwia wejście do sieci. Z kolei podatność o wysokim CVSS w wyłączonym komponencie laboratorium bez połączenia z produkcją może zostać obsłużona inną ścieżką. Takie decyzje powinny być udokumentowane i powtarzalne.

Terminy napraw powinny wynikać z polityki organizacji i analizy ryzyka. NIST SP 800-40 Rev. 4 opisuje zarządzanie poprawkami jako proces identyfikowania, priorytetyzowania, pozyskiwania, instalowania i weryfikowania poprawek, ale nie ustanawia uniwersalnych SLA typu "KEV 14 dni" albo "CVSS 9.0 w 30 dni" dla wszystkich organizacji.^[12]

Co pokazują dane z 2025-2026 r.

Verizon DBIR 2026 wskazał wykorzystanie podatności jako początkowy wektor w 31% badanych naruszeń i po raz pierwszy w historii raportu jako częstszy punkt wejścia niż nadużycie poświadczeń.^[6] Nie oznacza to, że 31% wszystkich cyberataków na świecie zaczyna się od podatności. DBIR opisuje własny zbiór danych i własną metodę klasyfikacji.

ENISA Threat Landscape 2025, analizujący 4875 incydentów od 1 lipca 2024 r. do 30 czerwca 2025 r., wskazał wykorzystywanie podatności jako 21,3% rozpoznanych początkowych wektorów wejścia, po phishingu.^[7] To inna populacja niż DBIR, dlatego tych procentów nie należy bezpośrednio porównywać.

Oba źródła wspierają jednak wniosek operacyjny: podatności techniczne pozostają istotnym sposobem uzyskiwania początkowego dostępu. Szczególnej uwagi wymagają systemy brzegowe i inne zasoby osiągalne z internetu, dla których okno między publikacją luki a próbami wykorzystania może być krótkie.

Najczęstsze błędy programu zarządzania podatnościami

1. Skanowanie tylko przed audytem. Roczny raport może potwierdzać, że badanie wykonano w określonym dniu, ale nie opisuje podatności opublikowanych później ani zmian konfiguracji wprowadzonych po skanie. Częstotliwość powinna wynikać z ryzyka, dynamiki środowiska i obowiązujących wymagań. Dla niektórych systemów uzasadniony jest krótki cykl, dla innych ostrożniejsze badania w uzgodnionych oknach.
2. Brak właściciela. Lista CVE nie jest planem naprawczym. Każda pozycja wymagająca działania powinna mieć właściciela, priorytet, termin, status i dowód zamknięcia.
3. Brak obsługi wyjątków. Nie każdą poprawkę można wdrożyć natychmiast. Może brakować aktualizacji producenta, okna serwisowego lub zgodności z aplikacją. Wyjątek powinien mieć uzasadnienie, właściciela ryzyka, zabezpieczenia kompensujące, termin ponownej oceny i plan docelowego rozwiązania.
4. Ograniczenie zakresu do serwerów. Podatności występują także w stacjach roboczych, urządzeniach sieciowych, drukarkach, kamerach, hiperwizorach, systemach chmurowych, kontenerach i urządzeniach OT.
5. Utożsamianie liczby znalezisk z poziomem bezpieczeństwa. Wzrost liczby ustaleń po poprawieniu pokrycia skanowaniem może oznaczać, że program działa lepiej, a nie gorzej. Dlatego mierniki powinny obejmować również pokrycie aktywów, czas walidacji, czas usuwania pozycji priorytetowych, liczbę zaległych wyjątków i odsetek powtarzających się problemów.
6. Automatyczna naprawa bez kontroli wpływu. Patch może usunąć podatność i jednocześnie zatrzymać krytyczną usługę. Dojrzały proces łączy zarządzanie podatnościami z zarządzaniem zmianą, testami, kopiami zapasowymi i planem wycofania zmiany.

OT i systemy trudne do aktualizacji

W środowiskach OT aktywne skanowanie wymaga szczególnej ostrożności. Stary sterownik, urządzenie czasu rzeczywistego albo nietypowy protokół może reagować na ruch testowy inaczej niż typowy serwer IT. Dlatego przed skanem trzeba uzgodnić dopuszczalne techniki z właścicielem procesu i producentem urządzenia, a w niektórych segmentach większą rolę może pełnić pasywna obserwacja ruchu i inwentaryzacja.

Brak możliwości natychmiastowej aktualizacji nie oznacza braku działania. Organizacja może ograniczyć ekspozycję przez segmentację, filtrowanie ruchu, ograniczenie zdalnego dostępu, dodatkowy monitoring, kontrolę aplikacji albo czasowe wyłączenie funkcji. Są to zabezpieczenia kompensujące, które trzeba powiązać z konkretnym ryzykiem i planem docelowego usunięcia przyczyny.

Skanowanie aplikacji webowych

Skanowanie infrastruktury i dynamiczne testy aplikacji webowych to pokrewne, ale różne obszary. Narzędzia DAST wysyłają do aplikacji żądania i obserwują jej reakcje. Mogą wykrywać część klas błędów, ale nie zastępują przeglądu logiki biznesowej, testów autoryzacji ani analizy kodu.

OWASP Top 10 2025 jest dokumentem świadomościowym opisującym istotne kategorie ryzyka aplikacyjnego, a nie metodyką skanowania. OWASP ASVS 5.0.0 jest z kolei katalogiem wymagań weryfikacyjnych i może służyć jako znacznie precyzyjniejsze kryterium testów aplikacji.^[17]

Dlatego raport "brak wyników ze skanera DAST" nie powinien być przedstawiany jako dowód zgodności całej aplikacji z OWASP Top 10 albo ASVS.

Podstawy prawne w Polsce i UE

KSC. Po nowelizacji obowiązującej od 3 kwietnia 2026 r. art. 8 KSC nakłada na podmioty kluczowe i ważne obowiązki obejmujące systematyczne zarządzanie ryzykiem, zbieranie informacji o cyberzagrożeniach i podatnościach, regularne aktualizowanie oprogramowania z uwzględnieniem krytyczności aktualizacji oraz niezwłoczne działania po dostrzeżeniu podatności.^[8] Ustawa nie mówi, że każdy taki podmiot ma kupić konkretny skaner.

Dla części dostawców wskazanych w art. 8b KSC znaczenie ma bezpośrednio rozporządzenie wykonawcze Komisji (UE) 2024/2690. W punkcie 6.10 wymaga ono pozyskiwania informacji o podatnościach, oceny ekspozycji i zarządzania nimi, a "w stosownych przypadkach" również wykonywania skanów podatności w zaplanowanych odstępach i dokumentowania wyników. Ten sam akt wymaga polityki testów bezpieczeństwa oraz powiązania zarządzania podatnościami z patch management, change management, risk management i incident management.^[10]

NIS2. Art. 21 dyrektywy wskazuje wśród środków zarządzania ryzykiem między innymi bezpieczeństwo nabywania, rozwoju i utrzymania systemów, w tym vulnerability handling and disclosure, oraz ocenę skuteczności środków.^[9] Dla polskiej organizacji kwalifikację i konkretne obowiązki należy jednak ustalać przede wszystkim według KSC i właściwych aktów UE stosowanych bezpośrednio.

KRI. Rozporządzenie z 21 maja 2024 r., obowiązujące na 29 sierpnia 2026 r., wymaga od podmiotów realizujących zadania publiczne aktualnej inwentaryzacji sprzętu i oprogramowania, aktualizacji oprogramowania, redukcji ryzyk wynikających z opublikowanych podatności technicznych oraz niezwłocznego działania po dostrzeżeniu nieujawnionych podatności.^[14] Rozporządzenie nie określa jednej częstotliwości skanowania. ELI wskazuje jego utratę mocy 23 lutego 2027 r.; w sierpniu 2026 r. projekt nowego KRI RD313 pozostaje projektem, więc nie należy stosować go tak, jak obowiązującego prawa.^[14]

DORA. Rozporządzenie (UE) 2022/2554 wymaga od podmiotów finansowych ciągłego identyfikowania źródeł ryzyka ICT oraz oceny cyberzagrożeń i podatności istotnych dla ich funkcji i zasobów.^[11] Rozporządzenie delegowane Komisji (UE) 2024/1774 idzie dalej: wymaga procedur zarządzania podatnościami oraz wykonywania zautomatyzowanego skanowania i ocen zasobów ICT, przy czym częstotliwość i zakres mają odpowiadać klasyfikacji i profilowi ryzyka zasobu.^[13] Nie jest to więc uniwersalny nakaz jednego harmonogramu dla wszystkich systemów.

RODO. Art. 32 ust. 1 lit. d wymaga, odpowiednio do ryzyka, procesu regularnego testowania, mierzenia i oceniania skuteczności środków technicznych i organizacyjnych.^[15] Nie ustanawia wprost obowiązku "skanu podatności co X dni". Skanowanie może natomiast być jednym z dowodów, że organizacja rzeczywiście ocenia skuteczność zabezpieczeń.

PCI DSS. W środowiskach objętych standardem kartowym aktualnym wydaniem jest PCI DSS v4.0.1. Requirement 11 przewiduje okresowe skany podatności, a zewnętrzne skany w określonym zakresie mają być wykonywane przez Approved Scanning Vendor. PCI SSC wyjaśnia, że wymagane skany kwartalne oznaczają co najmniej raz na trzy miesiące.^[16] To wymaganie branżowego standardu, nie ogólny obowiązek każdej organizacji.

Cyber Resilience Act i SBOM

Rozporządzenie (UE) 2024/2847, czyli Cyber Resilience Act (CRA), zmienia odpowiedzialność po stronie producentów produktów z elementami cyfrowymi. Główne obowiązki stosuje się od 11 grudnia 2027 r., natomiast obowiązki raportowe z art. 14 zaczną być stosowane 11 września 2026 r.^[18]

CRA wymaga między innymi procesu obsługi podatności, a dokumentacja techniczna ma obejmować software bill of materials (SBOM). Załącznik I nakłada na producentów obowiązki identyfikowania i dokumentowania podatności i komponentów oraz tworzenia SBOM w powszechnie używanym formacie maszynowym obejmującym co najmniej zależności najwyższego poziomu.^[18]

Dla użytkownika SBOM nie jest skanerem i nie mówi automatycznie, czy produkt jest podatny. Daje natomiast szybszą odpowiedź na pytanie, czy określony komponent występuje w produkcie. To skraca czas analizy po ujawnieniu podatności w szeroko używanej bibliotece.

Od skanowania do zarządzania ekspozycją

Dojrzały program coraz rzadziej zaczyna się od listy CVE, a częściej od pytania: które ścieżki prowadzą do istotnego zasobu i które słabości rzeczywiście zwiększają prawdopodobieństwo kompromitacji.

Skan podatności pozostaje ważnym czujnikiem, ale warto łączyć go z danymi o powierzchni ataku, tożsamościach, konfiguracji chmury, bezpieczeństwie aplikacji, aktywności napastników i rzeczywistych zależnościach usług. Nie oznacza to konieczności kupowania produktu z etykietą "exposure management". Chodzi o połączenie danych w proces, który pozwala podejmować lepsze decyzje.

W praktyce usługa skanowania podatności może być powiązana z audytem bezpieczeństwa IT, hardeningiem, testami penetracyjnymi i SOC 24/7. Każdy z tych elementów odpowiada jednak na inne pytanie. W 4crypto wyniki techniczne są traktowane jako wejście do procesu zarządzania ryzykiem, a nie jako samodzielny "certyfikat bezpieczeństwa".

Jak mierzyć program

Liczba wykrytych podatności jest potrzebna operacyjnie, ale jest słabym miernikiem dojrzałości. Bardziej użyteczne są między innymi:

• pokrycie: jaki odsetek znanych aktywów i krytycznych usług jest objęty właściwym rodzajem oceny;
• świeżość danych: jak szybko nowy zasób trafia do programu;
• walidacja: jak długo trwa potwierdzenie albo odrzucenie ustalenia wysokiego priorytetu;
• naprawa: jaki jest czas od potwierdzenia do skutecznego usunięcia lub ograniczenia ryzyka;
• zaległości: ile pozycji przekroczyło przyjęty termin i z jakiej przyczyny;
• wyjątki: ile zaakceptowanych odstępstw nie ma aktualnej ponownej oceny;
• nawroty: ile problemów pojawia się ponownie z tej samej przyczyny;
• weryfikacja: jaki odsetek napraw został ponownie sprawdzony.

Metryki powinny być zdefiniowane tak, aby wiadomo było, kiedy zaczyna i kończy się pomiar. "Średni czas naprawy" liczony od publikacji CVE będzie inną wartością niż ten sam wskaźnik liczony od wykrycia luki w naszej organizacji.