Poniedziałkowy raport ze skanera ma 812 wykryć: 40 oznaczonych jako Critical, 130 jako High, reszta niżej. To scenariusz modelowy, a nie dane z konkretnego wdrożenia, ale skala tego rzędu jest zwyczajna już przy kilkudziesięciu hostach. Administrator otwiera listę posortowaną malejąco po ocenie CVSS i zaczyna od góry. Po tygodniu zamkniętych jest kilkanaście pozycji, backlog urósł o kolejne kilkadziesiąt, a podatność, od której w takim układzie zaczyna się realne ryzyko, potrafi mieć ocenę 7,2 i leżeć trzy ekrany niżej — na publicznie dostępnej bramie zdalnego dostępu, dla której od tygodnia istnieje gotowy kod ataku.

Problemem nie jest liczba wykryć. Problemem jest to, że lista posortowana po jednej liczbie odpowiada na pytanie, które ta liczba zadaje — jak poważna technicznie jest podatność sama w sobie — a nie na pytanie, które zadaje firma: co zrobić najpierw, żeby najszybciej obniżyć ryzyko przy dostępnych ludziach i oknach serwisowych.

Ten materiał opisuje proces, który na to pytanie odpowiada: od wykrycia zasobu, przez złożenie kilku niezależnych sygnałów, po zamknięcie wpisu dopiero na podstawie dowodu. Interpretację pojedynczego raportu ze skanera opisuje osobny tekst o tym, jak z raportu OpenVAS zrobić plan napraw; tutaj chodzi o warstwę wyżej — o powtarzalny proces, który działa między skanami.

Najważniejsze wnioski

  • Waga techniczna to nie ryzyko, a ryzyko to nie priorytet. CVSS opisuje właściwości samej podatności. Ryzyko powstaje dopiero po dołożeniu zasobu, ekspozycji i skutku biznesowego. Priorytet dokłada do ryzyka rzeczy, które z bezpieczeństwem nie mają nic wspólnego: koszt zmiany, okno serwisowe, dostępność ludzi i ryzyko samej naprawy.
  • Żaden pojedynczy wskaźnik nie jest kompletną oceną ryzyka. CVSS nie wie, gdzie stoi host. EPSS nie wie, jaki będzie skutek wykorzystania ani czy podatność w ogóle u Ciebie występuje. KEV mówi, że ktoś już atakował, ale nie mówi, czy dotyczy to Twojej konfiguracji. Kontekst zasobu nie mówi nic o samej podatności. Priorytet powstaje z ich zestawienia.
  • Brak sygnału nie jest dowodem bezpieczeństwa. Wśród 1674 wpisów katalogu CISA KEV — czyli podatności z potwierdzonym wykorzystaniem w atakach — 402 miały 22 sierpnia 2026 r. wartość EPSS poniżej 0,10, a spośród 1275 wpisów z oceną bazową CVSS v3 w NVD 137 mieści się w przedziale Low albo Medium. Polityka „naprawiamy tylko Critical i High” albo „tylko EPSS powyżej progu” pomija te przypadki.
  • Mitygacja i akceptacja ryzyka to nie remediacja. Reguła na zaporze i wpis w rejestrze wyjątków ograniczają ryzyko, ale podatny kod nadal działa. Status „naprawione” bez usunięcia przyczyny to strata informacji, a nie oszczędność czasu.
  • Zamknięcie wpisu należy się dowodowi, a nie deklaracji. Zainstalowanie pakietu nie jest dowodem, że usługa działa na nowym kodzie, a brak zgłoszeń nie jest dowodem, że naprawa nic nie popsuła. Dowodem jest ponowny skan, sprawdzona wersja komponentu i test funkcji, której podatność dotyczyła.

Dlaczego sortowanie po jednej liczbie nie jest programem napraw

Trzy pojęcia bywają używane zamiennie i to jest źródłem większości nieporozumień przy ustalaniu kolejności prac.

Waga techniczna (severity) opisuje, co atakujący może osiągnąć, jeżeli podatność wykorzysta — jaki jest wektor dostępu, ile uprawnień trzeba mieć wcześniej, co dzieje się z poufnością, integralnością i dostępnością komponentu. W warstwie bazowej są to właściwości samej podatności, niezależne od konkretnego wdrożenia: w CVSS 4.0 opisują je metryki Base, czyli CVSS-B. Wynik można następnie doprecyzować metrykami Threat, które odnoszą się do zmiennego w czasie stanu eksploatacji, oraz Environmental, które odnoszą się do konkretnego środowiska — sam CVSS-B tych dwóch warstw nie zawiera.

Ryzyko to iloczyn prawdopodobieństwa i skutku dla konkretnej organizacji. Ta sama podatność o identycznej wadze technicznej niesie inne ryzyko na bramie VPN obsługującej dwustu pracowników i inne na maszynie deweloperskiej w odizolowanym segmencie, wyłączanej na noc. Żaden globalny wskaźnik tej różnicy nie zna, bo nie zna Twojej sieci.

Priorytet to kolejność prac, a więc decyzja operacyjna. Wchodzi do niej ryzyko, ale też rzeczy, które z bezpieczeństwem nie mają wiele wspólnego: czy łatka wymaga restartu klastra, czy dostawca ma otwarty problem zgodności, czy zespół ma w tym tygodniu okno serwisowe, ile kosztuje wycofanie zmiany, gdyby poszła źle. Dwie podatności o identycznym ryzyku mogą mieć różny priorytet, jeżeli jedną naprawia się poleceniem, a druga wymaga migracji bazy.

Sortowanie po CVSS malejąco myli te trzy warstwy w jedną. Skutek jest podwójny: pilne rzeczy o średniej wadze technicznej wypadają poza pole widzenia, a zespół spędza tygodnie na wykryciach, które w danym środowisku nie prowadzą do niczego.

Skalę zawężenia widać na liczbach publicznych. Model EPSS z 22 sierpnia 2026 r. obejmował 363 588 rekordów CVE. Wartość 0,10 lub wyższą miało 17 305 z nich, czyli 4,76 procent; wartość 0,50 lub wyższą — 4320, czyli 1,19 procent. Katalog CISA KEV liczył w tym czasie 1674 pozycje, z czego 190 dodano od początku 2026 roku. Innymi słowy: podatności z potwierdzonym wykorzystaniem w atakach to niecałe pół procenta całego zbioru CVE. Program, który tej części nie potrafi wyłowić, nie jest programem zarządzania podatnościami, tylko obsługą kolejki.

(Liczby powyżej są obliczeniem własnym na podstawie dziennego pliku wyników EPSS oraz kanału JSON katalogu KEV pobranych 22 sierpnia 2026 r. Oba źródła zmieniają się codziennie — powtórzenie rachunku innego dnia da inne wartości.)

Cykl życia podatności i właściciel każdego etapu

Proces rozpada się na etapy, które w raporcie ze skanera zlewają się w jeden wiersz. Rozdzielenie ich ma praktyczny cel: każdy etap ma inne kryterium wyjścia i innego właściciela, więc zator w jednym miejscu widać od razu.

  1. Odkrycie zasobu. Zanim cokolwiek zostanie przeskanowane, musi być wiadomo, co istnieje. Właściciel: zespół utrzymania wspólnie z osobą odpowiedzialną za ewidencję.
  2. Identyfikacja podatności. Skaner, dane o wersjach z systemu zarządzania konfiguracją, biuletyny dostawców, komunikaty CSIRT, zgłoszenia zewnętrzne. Właściciel: bezpieczeństwo.
  3. Walidacja. Czy podatny komponent naprawdę jest na tym hoście, w tej wersji i w konfiguracji, której dotyczy opis. Właściciel: bezpieczeństwo z udziałem administratora systemu.
  4. Wzbogacenie kontekstem. Doklejenie do wykrycia wszystkiego, czego skaner nie wie: właściciela zasobu, ekspozycji, krytyczności, danych o eksploatacji. Właściciel: proces automatyczny, z ręczną korektą po stronie bezpieczeństwa.
  5. Priorytetyzacja. Przypisanie klasy pilności i terminu. Właściciel: bezpieczeństwo według reguł uzgodnionych wcześniej z biznesem, a nie ustalanych przy każdym wykryciu od nowa.
  6. Decyzja. Naprawiamy, ograniczamy ryzyko czy akceptujemy je świadomie. Właściciel: właściciel zasobu, przy podatnościach o wysokim ryzyku wspólnie z osobą decyzyjną po stronie biznesu.
  7. Remediacja albo mitygacja. Wykonanie zmiany. Właściciel: zespół utrzymania, w reżimie zarządzania zmianą.
  8. Weryfikacja. Dowód, że zmiana zadziałała i niczego nie zepsuła. Właściciel: ten, kto zgłosił, a nie ten, kto naprawiał.
  9. Zamknięcie. Status z uzasadnieniem i śladem audytowym.
  10. Obserwacja nawrotu. Wykrycie, które wraca po zamknięciu, jest sygnałem o procesie, nie o hoście.

Dwie uwagi z praktyki. Po pierwsze, etap ósmy prawie zawsze wypada, gdy weryfikuje ta sama osoba, która naprawiała — nie z braku uczciwości, tylko dlatego, że sprawdza się to, co się zmieniło, a nie to, czy podatność zniknęła. Po drugie, etapy 6 i 7 mieszczą się w istniejącym procesie zarządzania zmianą; budowanie osobnej ścieżki dla poprawek bezpieczeństwa kończy się dwoma rejestrami zmian, które nie zgadzają się ze sobą.

Ten sam rozkład ról ma odzwierciedlenie w wymaganiach. NIST Cybersecurity Framework 2.0 rozdziela go na osobne oczekiwane wyniki: ID.RA-01 („podatności w zasobach są identyfikowane, walidowane i rejestrowane” — walidacja jest tam osobnym słowem), ID.RA-05, ID.RA-06 (odpowiedzi na ryzyko są wybierane, priorytetyzowane, planowane, śledzone i komunikowane), ID.RA-07 (zmiany i wyjątki są zarządzane, oceniane pod kątem wpływu na ryzyko, rejestrowane i śledzone) oraz PR.PS-02 (oprogramowanie jest utrzymywane, wymieniane i usuwane stosownie do ryzyka).

CVE jest identyfikatorem, a nie oceną

Rekord CVE pełni jedną funkcję: nadaje publicznie ujawnionej podatności wspólną nazwę, żeby dostawca, skaner, biuletyn i zgłoszenie mówiły o tej samej rzeczy. Program CVE opisuje swoją misję jako identyfikowanie, definiowanie i katalogowanie publicznie ujawnionych podatności. Identyfikatory nadają organizacje pełniące rolę CNA — w zakresie własnych produktów albo w zakresie przypisanym im przez program. ENISA jest taką organizacją od stycznia 2024 r. dla podatności wykrytych przez europejskie zespoły CSIRT oraz im zgłaszanych, jeżeli nie należą do zakresu innej organizacji CNA.

Z tego wynikają trzy konsekwencje, które w codziennej pracy mają znaczenie.

Rekord CVE nie zawiera oceny ryzyka. Oceny — CVSS, dane o eksploatacji, kategoria słabości — dokładają do rekordu inne podmioty. Ta sama podatność może mieć wektor CVSS od dostawcy, inny od NVD i trzeci od zespołu CERT, i wszystkie trzy bywają poprawne z punktu widzenia przyjętych założeń o zakresie.

Wpis nie znaczy, że jesteś podatny. Między „istnieje CVE dla tego pakietu” a „ten host jest podatny” stoją: zgodność wersji, sposób budowania pakietu w konkretnej dystrybucji, obecność podatnego modułu, konfiguracja włączająca podatną funkcję i osiągalność. Skaner opierający się wyłącznie na numerze wersji nie widzi żadnego z tych warunków — stąd tak wiele wykryć, które po walidacji zmieniają status na „nie dotyczy”. Odwrotny błąd też się zdarza: dystrybucje utrzymujące starsze gałęzie przenoszą poprawki bez zmiany numeru głównego, więc host załatany wygląda dla skanera jak podatny.

Brak CVE nie znaczy, że problemu nie ma. Błąd konfiguracji, domyślne hasło, wystawiony panel administracyjny i nieaktualne poświadczenie nie dostaną identyfikatora, a bywają szybszą drogą do środowiska niż jakikolwiek CVE. Skanowanie podatności i przegląd konfiguracji to dwie różne kontrole; opisuje to materiał o hardeningu usług publicznych.

CVSS 4.0: cztery grupy metryk i to, czego Base nie wie

CVSS w wersji 4.0 jest od listopada 2023 r. bieżącym wydaniem standardu FIRST. Składa się z czterech grup metryk i to rozróżnienie jest ważniejsze niż sama liczba.

Base opisuje właściwości podatności niezmienne w czasie i niezależne od środowiska: wektor ataku, złożoność, wymagania dotyczące ataku, potrzebne uprawnienia, udział użytkownika oraz wpływ na poufność, integralność i dostępność — osobno dla podatnego systemu i osobno dla systemów następczych. To jedyna grupa, którą podaje niemal każde źródło i jedyna, którą pokazuje większość skanerów.

Threat zawiera w wersji 4.0 jedną metrykę: dojrzałość eksploatacji (Exploit Maturity). Opisuje ona prawdopodobieństwo ataku na podstawie stanu technik ataku, dostępności kodu i obserwowanego wykorzystania. Przyjmuje wartości: niezdefiniowana, obserwowany atak, kod dowodowy, brak zgłoszeń.

Environmental pozwala przeliczyć ocenę pod kątem konkretnego środowiska: skorygować metryki bazowe zgodnie ze stanem faktycznym u siebie i nadać wagę poufności, integralności oraz dostępności dla danego systemu.

Supplemental to sześć metryk kontekstowych — bezpieczeństwo ludzi, możliwość automatyzacji ataku, zdolność odtworzenia systemu, gęstość wartości, nakład pracy na reakcję i pilność wskazana przez dostawcę. Specyfikacja jest tu jednoznaczna: żadna z nich nie wpływa na wynik liczbowy. Są przeznaczone do wykorzystania w polityce odbiorcy oceny.

Standard wprowadza też nazewnictwo, które warto stosować w rozmowie i w dokumentacji, bo od razu ujawnia, o czym mowa: CVSS-B to sama ocena bazowa, CVSS-BT to baza z metryką zagrożenia, CVSS-BE to baza ze środowiskiem, CVSS-BTE to komplet. Zdanie „ta podatność ma 9,8” bez tej informacji nie mówi, czy liczba w ogóle uwzględnia cokolwiek z Twojego środowiska. Zwykle nie uwzględnia — jest to CVSS-B.

Dwa nieporozumienia warto rozbroić od razu.

Nie każdy skaner korzysta ze wszystkich grup metryk. W praktyce większość narzędzi pokazuje ocenę bazową pobraną ze źródła zewnętrznego. Metryki środowiskowe wymagają wprowadzenia danych o systemie, a metryka zagrożenia — dowiązania źródła informacji o eksploatacji. Bez tego liczba widoczna w interfejsie jest oceną bazową, choć bywa nazywana po prostu „CVSS score”.

CVSS opisuje wagę techniczną, nie kompletny priorytet biznesowy. Sama specyfikacja zaleca, żeby organizacje uwzględniały czynniki spoza CVSS przy szeregowaniu zagrożeń dla własnej infrastruktury. Traktowanie oceny bazowej jako gotowej listy zadań jest użyciem narzędzia poza jego zakresem.

EPSS: prawdopodobieństwo wykorzystania, nie ocena skutku

EPSS jest modelem statystycznym utrzymywanym przez FIRST. Szacuje prawdopodobieństwo, że opublikowany rekord CVE będzie wykorzystywany w atakach w ciągu najbliższych 30 dni. Dokumentacja doprecyzowuje, co dokładnie jest mierzone: prawdopodobieństwo, że którykolwiek z partnerów danych i ich czujników wykryje, zarejestruje i udostępni dowód aktywności związanej z wykorzystaniem danej podatności.

To doprecyzowanie ma znaczenie praktyczne. EPSS mówi o obserwowalności ataku w globalnej telemetrii, a nie o tym, czy ktoś zaatakuje właśnie Ciebie.

Model korzysta z około 2850 cech w pięciu grupach: dostępność kodu ataku i narzędzi ofensywnych, wzmianki w źródłach związanych z bezpieczeństwem, właściwości samej podatności (w tym metryki CVSS), wiek rekordu i liczba odwołań oraz aktywność eksploatacyjna zbierana od blisko dwunastu partnerów — z telemetrii ochrony stacji końcowych, honeypotów, systemów wykrywania włamań i źródeł analizy zagrożeń. Wyniki publikowane są codziennie, zwykle w ciągu minuty lub dwóch po godzinie 13:30 czasu UTC, dla każdego ocenianego rekordu. Sam model jest przetrenowywany mniej więcej raz w roku; wersja obowiązująca 22 sierpnia 2026 r. nosi oznaczenie v2026.06.15 i tę wartość niesie pierwszy wiersz dziennego pliku wyników.

Wynik i percentyl to dwie różne wielkości

Wynik (score) jest miarą bezwzględną: 0,17 znaczy „szacowane siedemnaście procent szans na zaobserwowanie wykorzystania w oknie trzydziestu dni”. Percentyl jest miarą względną: mówi, jaki odsetek wszystkich ocenianych rekordów ma wynik niższy. Ta sama podatność może mieć wynik 0,05 i percentyl 0,93, bo rozkład wyników jest silnie skośny — zdecydowana większość rekordów ma wartości bliskie zeru.

W polityce wewnętrznej pomyłka między nimi ma poważny skutek. Reguła „reagujemy powyżej 0,9” obejmowała 22 sierpnia 2026 r. 786 rekordów, jeżeli odnosi się do wyniku, i 36 363 rekordy, jeżeli odnosi się do percentyla — ponad czterdziestokrotna różnica w wielkości kolejki. Zapisz w polityce, którą z tych dwóch wielkości masz na myśli.

Czego EPSS nie mierzy

Dokumentacja FIRST wylicza to wprost: EPSS nie mierzy, jak duże szkody spowodowałoby udane wykorzystanie, ani czy podatność w ogóle dotyczy Twojego środowiska. Nie uwzględnia kontekstu konkretnej instalacji, zabezpieczeń kompensujących ani żadnego czynnika właściwego dla danej organizacji.

Stąd wniosek, którego nie da się obejść: EPSS jest jednym wejściem do priorytetyzacji, a nie oceną ryzyka. Podatność o wyniku 0,004 na publicznie dostępnej bramie przechowującej dane osobowe może wymagać działania wcześniej niż podatność o wyniku 0,7 na hoście testowym bez danych.

Progi są polityką lokalną

FIRST nie wskazuje uniwersalnego progu i mówi to wprost: wartość 0,10 bywa cytowana w branży, ale nie ma statusu zalecenia EPSS. Jeżeli ustalasz próg, ustal go jako własną politykę, zapisz uzasadnienie i sprawdź jego skutek na swoich danych — czyli policz, ile wykryć w Twoim środowisku wpada powyżej i poniżej. Próg dobrany „z artykułu” bywa albo pusty, albo obejmuje pół backlogu.

Poniżej przykład takiego zapisu, świadomie oznaczony jako przykład: „wynik EPSS 0,20 lub wyższy na zasobie osiągalnym z Internetu podnosi klasę pilności o jeden stopień; wynik poniżej 0,01 na zasobie wewnętrznym pozwala obniżyć ją o jeden stopień, o ile podatność nie jest w katalogu KEV”. Reguła tego typu ma zawsze dwie części — podnoszącą i obniżającą — bo tylko wtedy realnie zmniejsza kolejkę.

CISA KEV: potwierdzona eksploatacja jako sygnał najmocniejszy

Katalog znanych wykorzystywanych podatności (Known Exploited Vulnerabilities) prowadzony przez CISA zbiera podatności, dla których istnieją wiarygodne dowody wykorzystania w atakach. Wpis wymaga spełnienia trzech warunków jednocześnie: podatność ma nadany identyfikator CVE, istnieją wiarygodne dowody jej aktywnego wykorzystywania oraz istnieje jasne działanie naprawcze, na przykład aktualizacja od dostawcy.

Ten trzeci warunek bywa pomijany, a wyjaśnia część różnicy między skalą obserwowanych ataków a zawartością katalogu. CISA wymaga jasnego działania naprawczego albo mitygacji i nie zawęża go do klasycznej łatki: może nim być aktualizacja zgodnie z instrukcją producenta, obejście stosowane do czasu wydania poprawki, a przy produkcie po zakończeniu wsparcia albo takim, którego nie da się zaktualizować — usunięcie go ze środowiska. Podatność, dla której takiego działania nie da się wskazać, do katalogu nie trafia. W drugą stronę zależność nie działa: samo istnienie obejścia o wpisie nie przesądza, bo wszystkie trzy warunki muszą być spełnione jednocześnie.

CISA formułuje swoje zalecenie precyzyjnie: organizacje powinny wykorzystywać katalog jako wejście do własnego procesu priorytetyzacji, a nie jako całą listę zadań. To sformułowanie warto zapamiętać, bo różni się od tego, co często pisze się w materiałach handlowych.

Obowiązek dotyczy określonego kręgu podmiotów

Terminy naprawy wynikające z katalogu są wiążące dla amerykańskich federalnych agencji władzy wykonawczej — i to jest cały zakres tego obowiązku. Polska firma nie podlega mu w żadnym stopniu. CISA sama to rozdziela: podmioty spoza tego kręgu, w tym samorządy i sektor prywatny, katalogiem nie są związane, ale mogą istotnie wzmocnić swoją odporność, priorytetyzując wymienione w nim podatności.

Warto przy tym odnotować zmianę z 2026 roku, bo starsze opracowania jej nie uwzględniają. Dyrektywa BOD 22-01 z listopada 2021 r., która ustanowiła katalog, została uchylona. Zastąpiła ją wydana 10 czerwca 2026 r. dyrektywa BOD 26-04 „Prioritizing Security Updates Based on Risk”, która przejęła kryteria wpisu do katalogu bez zmian, uchyliła również BOD 19-02 i połączyła terminy naprawy w jeden model decyzyjny.

Model BOD 26-04 jest wart uwagi także poza Stanami Zjednoczonymi

Nie dlatego, że obowiązuje — bo nie obowiązuje — tylko dlatego, że pokazuje, jak wygląda tabela terminów zbudowana bez CVSS. Pilność wynika tam z czterech zmiennych: czy zasób jest publicznie osiągalny, czy podatność jest w katalogu KEV, czy atakujący może zautomatyzować wszystkie kroki wykorzystania oraz jaki jest wpływ techniczny — w rozumieniu SSVC Partial albo Total. Partial to ograniczona kontrola nad zachowaniem podatnego oprogramowania albo ekspozycja informacji o tym zachowaniu, a Total oznacza całkowitą kontrolę nad tym zachowaniem albo całkowite ujawnienie informacji z systemu, w którym podatność się znajduje. Podatność polegająca na ujawnieniu danych może więc mieć wpływ techniczny Total, nawet jeśli nie pozwala uruchomić kodu. Dane potrzebne do odpowiedzi na te cztery pytania pochodzą z trzech rodzajów źródeł. Status w katalogu KEV sprawdza się w samym katalogu CISA. Możliwość automatyzacji i wpływ techniczny publikuje program Vulnrichment, w którym CISA ocenia nowe i niedawne rekordy CVE, dokładając do nich punkty decyzyjne SSVC — te dane są dostępne publicznie i maszynowo, ale nie warto zakładać pełnego pokrycia całego historycznego zbioru CVE, a brak wzbogacenia dla konkretnego rekordu oznacza brak danych, nie odpowiedź przeczącą. Czwarta zmienna, publiczna osiągalność, jest cechą konkretnego zasobu i musi pochodzić z ewidencji albo z obserwacji własnego środowiska.

Poniżej pięć z szesnastu wierszy tej tabeli, dobranych tak, żeby pokazać kontrast. Pełny zestaw jest w treści dyrektywy.

Tabelę można przewijać w poziomie.

Wybrane wiersze tabeli terminów naprawy z dyrektywy BOD 26-04. Kolumna „Zasób publiczny” odpowiada na pytanie o osiągalność z sieci publicznych, a terminy podano w dniach kalendarzowych. Wiążą one wyłącznie amerykańskie federalne agencje władzy wykonawczej; dla innych organizacji jest to przykład konstrukcji reguły, a nie wymaganie.
Zasób publiczny W KEV Automatyzacja Wpływ techniczny Termin naprawy
Tak Tak Tak Total 3 dni oraz wstępna analiza śledcza zasobu
Tak Tak Nie Partial 14 dni
Tak Nie Nie Partial 60 dni
Nie Tak Tak Total 3 dni oraz wstępna analiza śledcza zasobu
Nie Nie Nie Partial Naprawa przy kolejnej większej aktualizacji

Trzy rzeczy z tej tabeli przenoszą się na dowolne środowisko. Po pierwsze, ocena CVSS nie występuje w niej ani razu; jednym z czterech punktów decyzyjnych jest zamiast tego Technical Impact z kategoriami Partial i Total. Po drugie, w pokazanych wyżej wierszach podatność z katalogu KEV na zasobie wewnętrznym dostaje termin krótszy niż podatność spoza katalogu na zasobie publicznym — sama ekspozycja nie rozstrzyga więc o kolejności. Nie jest to jednak uniwersalna hierarchia „KEV zawsze ważniejsze od ekspozycji”: w pełnej macierzy termin wynika z kombinacji wszystkich czterech zmiennych i publiczny zasób spoza katalogu, przy podatności dającej się zautomatyzować i wpływie technicznym Total, dostaje trzy dni. Po trzecie, terminy są dynamiczne — dyrektywa podaje jako przykład, że odcięcie systemu od Internetu zmienia wartość punktu Publicly Exposed z „tak” na „nie” i wydłuża termin dalszych działań, a dopisanie podatności do katalogu go skraca. Zmiana ekspozycji nie przestawia jednak każdego wiersza macierzy: przy podatności z katalogu KEV, której nie da się zautomatyzować, i wpływie technicznym Partial termin wynosi 14 dni niezależnie od tego, czy zasób jest publicznie osiągalny. To i tak dobra własność dla polityki wewnętrznej: mitygacja powinna wpływać na ponowną ocenę priorytetu, a nie automatycznie zamykać wpis.

Model stoi na metodyce SSVC opracowanej przez SEI Carnegie Mellon wspólnie z CISA. Wariant SSVC opisany w przewodniku CISA prowadzi do jednej z czterech decyzji — Track, Track z gwiazdką, Attend albo Act — na podstawie pięciu punktów decyzyjnych: statusu eksploatacji, wpływu technicznego, możliwości automatyzacji, rozpowszechnienia produktu w misji organizacji i wpływu na dobro publiczne. Jest to gotowy szkielet dla firmy, która nie chce budować własnego modelu od zera.

Brak wpisu w KEV nie jest dowodem bezpieczeństwa

Katalog obejmuje przypadki, w których CISA ma dowody spełnienia wszystkich warunków wpisu. Brak CVE w katalogu nie dowodzi więc, że nikt tej podatności nie wykorzystuje — mówi tylko tyle, że według publicznie stosowanych przez CISA kryteriów wpisu nie ma. Powodem bywa brak wystarczających dowodów aktywnego wykorzystania albo brak jasnego działania naprawczego, którego katalog wymaga. Traktowanie go jako pełnej listy „tego, co jest atakowane” jest nadinterpretacją.

Widać to też w danych. Spośród 1674 wpisów katalogu z 21 sierpnia 2026 r. 402 miały wartość EPSS poniżej 0,10, a 48 poniżej 0,01 — czyli model statystyczny nie wskazywał ich jako prawdopodobnych celów, mimo potwierdzonego wykorzystania. W drugą stronę działa to tak samo: wysoki EPSS bez wpisu w katalogu nie jest dowodem, że atak trwa. To są dwa niezależne sygnały i właśnie dlatego warto mieć oba.

Kontekst europejski: EUVD, NIS2 i rozporządzenie 2024/2690

Europejska baza podatności (European Vulnerability Database, EUVD) prowadzona przez ENISA działa na podstawie art. 12 dyrektywy NIS2. Zbiera informacje z kilku źródeł naraz — od zespołów CSIRT, od dostawców, z bazy CVE i z otwartych źródeł — i udostępnia trzy widoki: podatności krytyczne, podatności wykorzystywane oraz podatności koordynowane przez europejskie zespoły CSIRT. Rekord ma własny identyfikator w formacie EUVD-rok-numer, ale niesie też odsyłacze do identyfikatorów z innych systemów: numeru CVE, identyfikatora doradczego z ekosystemu pakietów, wektora CVSS i bieżącej wartości EPSS. Dostęp jest możliwy przez interfejs webowy i przez API.

Warto opisać to precyzyjnie, bo bywa przedstawiane skrótowo. EUVD nie zastępuje programu CVE i nie jest równoległym schematem numeracji, którym trzeba by zastąpić identyfikatory CVE w narzędziach. Jest warstwą agregacji i wzbogacenia dla europejskiego odbiorcy, z rolą uzupełniającą wobec CVE — i z tego powodu jest przede wszystkim dodatkowym kanałem monitorowania informacji o podatnościach, a nie zamiennikiem istniejących.

Od 11 września 2026 r. znaczenie tego kanału rośnie z innego powodu. Rozporządzenie o cyberodporności (CRA) nakłada wtedy na producentów obowiązek zgłaszania aktywnie wykorzystywanych podatności i poważnych incydentów przez wspólną platformę zgłoszeniową prowadzoną przez ENISA. Dla odbiorcy oprogramowania oznacza to zmianę praktyczną: część informacji, które dziś trafiają wyłącznie do biuletynów dostawców, zacznie płynąć jednym, przewidywalnym korytem. Dla polskiego producenta oprogramowania oznacza to nowy obowiązek — CERT Polska opisał go szczegółowo.

Co z tego jest wymaganiem prawnym

Warto oddzielić dobrą praktykę od obowiązku, bo te dwie rzeczy bywają w ofertach zlepiane.

Dla kategorii podmiotów wymienionych w art. 1 rozporządzenia wykonawczego Komisji (UE) 2024/2690 — między innymi dostawców usług DNS, usług chmurowych, ośrodków przetwarzania danych, usług zarządzanych i usług zaufania — obowiązują wprost dwa punkty załącznika. Punkt 6.6 dotyczy zarządzania poprawkami bezpieczeństwa i wymaga, żeby poprawki były wdrażane w rozsądnym czasie od udostępnienia, testowane przed wdrożeniem na produkcji, pochodziły z zaufanych źródeł i były sprawdzane pod kątem integralności, a gdy poprawka nie jest dostępna albo nie zostaje zastosowana — żeby wdrożono środki dodatkowe i zaakceptowano ryzyko szczątkowe. Punkt 6.6.2 dopuszcza rezygnację z poprawki, gdy jej wady przeważają nad korzyścią dla bezpieczeństwa, ale nakazuje należycie udokumentować i uzasadnić taką decyzję.

Punkt 6.10 dotyczy obsługi i ujawniania podatności. Wymaga monitorowania informacji o podatnościach właściwymi kanałami (wymienia komunikaty CSIRT, organów właściwych oraz dostawców), wykonywania skanów w zaplanowanych odstępach wraz z zachowaniem dowodów wyników, zajmowania się bez zbędnej zwłoki podatnościami uznanymi za krytyczne dla działalności oraz spójności obsługi podatności z procesami zarządzania zmianą, poprawkami, ryzykiem i incydentami. Punkt 6.10.3 dokłada rzecz, o którą najczęściej rozbija się audyt: gdy potencjalny wpływ podatności to uzasadnia, trzeba stworzyć i wdrożyć plan jej ograniczenia, a w pozostałych przypadkach udokumentować i uzasadnić, dlaczego naprawa nie jest wymagana.

Wytyczne techniczne ENISA do tego rozporządzenia idą krok dalej i podpowiadają, jak to robić: zalecają przyjęcie ram oceny wagi podatności opartych na modelach takich jak CVSS czy EPSS, uzupełnionych o metryki środowiskowe i metryki zagrożenia, oraz przegląd planów ograniczenia ryzyka i uzasadnień odstąpienia od naprawy przez organ odpowiedzialny za nadzór nad ryzykiem. Wśród przykładów dowodu wymieniają zapisy z terminami i osobami odpowiedzialnymi za każdą naprawę wraz z weryfikacją poprawek oraz zapis każdej podatności, którą pozostawiono bez naprawy, razem z uzasadnieniem.

Dla podmiotów objętych polską ustawą o krajowym systemie cyberbezpieczeństwa obraz jest inny i szerszy, niż da się zmieścić w jednym akapicie — opisuje go osobny materiał o przygotowaniu infrastruktury IT do NIS2 i KSC, łącznie z rozróżnieniem obowiązków podmiotu kluczowego i podmiotu ważnego oraz z terminami wdrożenia. Tutaj wystarczy jedno przełożenie praktyczne: rejestr wyjątków z terminem i właścicielem oraz dowód ponownego sprawdzenia po naprawie to elementy, o które pyta się przy audycie niezależnie od reżimu.

Bez inwentaryzacji zostaje zarządzanie listą CVE

Wykrycie bez kontekstu jest nazwą pakietu i numerem hosta. Priorytet powstaje dopiero, gdy do tej pary da się dołożyć odpowiedzi na pytania, których skaner nie zadaje.

  • Kto jest właścicielem zasobu. Nie zespół — konkretna osoba, która może zdecydować o oknie serwisowym. Wykrycie bez właściciela trafia do kolejki „ktoś powinien”.
  • Jakie to środowisko. Produkcja, przedprodukcja, test, środowisko deweloperskie. Ta sama podatność ma różny priorytet w każdym z nich, ale uwaga: host testowy z kopią danych produkcyjnych jest produkcją z punktu widzenia ryzyka.
  • Czy zasób jest osiągalny z Internetu. To pytanie ma zaskakująco często odpowiedź inną, niż wynika z dokumentacji. Zewnętrzną perspektywę opisuje materiał o zarządzaniu zewnętrzną powierzchnią ataku.
  • Jak krytyczna jest usługa. Co się dzieje z firmą, gdy ta usługa stoi przez godzinę, przez dzień, przez tydzień.
  • Jakie dane przetwarza. Kategoria danych zmienia skutek incydentu i bywa jedynym argumentem, który przemawia poza działem IT.
  • Od czego zależy i co zależy od niej. Restart bazy o czternastej to nie jest zdarzenie lokalne.
  • Czy da się ją zatrzymać i w jakim oknie. Zasób, którego nie wolno wyłączyć, wymaga innego planu naprawy, a nie odłożenia sprawy.
  • W jakiej fazie cyklu życia jest komponent. System zaplanowany do wymiany za dwa miesiące i system, który zostanie na pięć lat, zasługują na inne decyzje.
  • Kiedy kończy się wsparcie producenta. Data zakończenia wsparcia jest atrybutem zasobu, a nie odkryciem, którego dokonuje się w chwili, gdy poprawka nie przychodzi.

Powód, dla którego program bez inwentaryzacji zamienia się w zarządzanie listą CVE, jest mechaniczny, a nie retoryczny. Bez ewidencji nie da się wykonać trzech operacji: nie da się policzyć pokrycia skanowania (nie wiadomo, ile zasobów w ogóle istnieje, więc „przeskanowano 340 hostów” jest liczbą bez mianownika), nie da się przypisać wykrycia do osoby, która ma prawo podjąć decyzję, i nie da się odróżnić podatności krytycznej dla firmy od podatności krytycznej dla skanera. Zostaje sortowanie po jedynej dostępnej liczbie — czyli punkt wyjścia tego artykułu. Jak zbudować taką ewidencję i utrzymać ją w stanie użytecznym, opisuje materiał o CMDB i dokumentacji infrastruktury IT.

Ewidencja zasobów ma jednak swoją granicę rozdzielczości: kończy się na hoście i usłudze, a nie schodzi do bibliotek wewnątrz aplikacji. Gdy podatność dotyczy komponentu użytego przez aplikację, a nie pakietu systemowego, potrzebna jest warstwa niżej — wykaz składników oprogramowania. Opisuje ją materiał o SBOM i bezpieczeństwie łańcucha dostaw oprogramowania.

Jak złożyć sygnały w jeden priorytet

Poniższa tabela zestawia sygnały, których używa się w priorytetyzacji, wraz z tym, na co każdy z nich odpowiada i czego nie rozstrzyga. Kolumna ostatnia jest najważniejsza: to ona wyjaśnia, dlaczego żaden pojedynczy wiersz nie wystarcza.

Tabelę można przewijać w poziomie.

Sygnały priorytetyzacji podatności i zakres każdego z nich. Zestawienie opisuje, na jakie pytanie odpowiada dany sygnał; ocena ryzyka powstaje dopiero z ich złożenia.
Sygnał Na jakie pytanie odpowiada Skąd pochodzi Czego nie rozstrzyga
Rekord CVE Czy podatność ma wspólny identyfikator i publiczny opis Program CVE i organizacje CNA Czy podatność występuje u Ciebie i jakie niesie ryzyko
CVSS 4.0 — ocena bazowa Jak poważna technicznie jest podatność w oderwaniu od środowiska Wektor od CNA, od dostawcy albo z bazy krajowej Ekspozycji zasobu, krytyczności usługi, faktu eksploatacji
CVSS 4.0 — grupa środowiskowa Jak zmienia się waga po uwzględnieniu Twojego systemu Twoje dane, wprowadzone ręcznie albo z ewidencji Prawdopodobieństwa ataku i kosztu naprawy
EPSS Jakie jest prawdopodobieństwo zaobserwowania wykorzystania w ciągu 30 dni FIRST — plik dzienny i API Skutku wykorzystania i obecności podatności w Twoim środowisku
Katalog CISA KEV Czy istnieją wiarygodne dowody wykorzystania w atakach CISA — katalog w formacie CSV i JSON Czy dotyczy to Twojej konfiguracji; brak wpisu nie dowodzi braku ataków
Osiągalność podatnej funkcji Czy podatny kod jest wykonywany i dostępny dla atakującego Konfiguracja usługi, analiza wywołań, test Wagi technicznej i prawdopodobieństwa ataku
Kontekst zasobu Co ta podatność znaczy dla tej firmy Ewidencja zasobów, dane o ekspozycji, właściciel usługi Niczego o samej podatności — opisuje wyłącznie jej otoczenie
Koszt i ryzyko naprawy Ile kosztuje zmiana i co może pójść źle Zespół utrzymania, historia zmian, informacje od dostawcy Wielkości ryzyka wynikającego z pozostawienia podatności

Reguła składania jest prosta w zapisie i trudna w dyscyplinie: sygnał o eksploatacji podnosi pilność, kontekst zasobu ją moduluje, koszt naprawy wpływa na sposób i termin, ale nie na ocenę ryzyka. Ostatni człon jest tym, który najczęściej wypada. Trudna naprawa nie zmniejsza ryzyka — zmienia tylko to, że w międzyczasie trzeba zastosować coś innego.

Trzy przypadki modelowe

Poniższe przypadki są skonstruowane po to, żeby pokazać kontrast. Nie są opisem konkretnych zdarzeń i nie stanowią reguły przenośnej na dowolne środowisko — w innym układzie zasobów i zabezpieczeń ta sama analiza może dać inny wynik.

Przypadek A. Ocena bazowa CVSS 9,8. Host testowy w segmencie wewnętrznym, bez danych produkcyjnych, wyłączany poza godzinami pracy. Podatny moduł jest zainstalowany, ale funkcja, której dotyczy podatność, jest wyłączona w konfiguracji. Brak wpisu w katalogu KEV, EPSS poniżej 0,01. Wynik: pilność niska, termin wynikający ze zwykłego cyklu utrzymania. Uzasadnienie: waga techniczna jest wysoka, ale prawdopodobieństwo i skutek dla firmy — niskie, a podatna funkcja nie jest osiągalna. Uwaga: status „funkcja wyłączona” trzeba udokumentować i monitorować, bo pierwsza zmiana konfiguracji, która ją włączy, unieważnia całą tę analizę.

Przypadek B. Ocena bazowa CVSS 7,2. Brama zdalnego dostępu wystawiona do Internetu, przez którą loguje się cała firma. Podatność jest w katalogu KEV, więc eksploatacja jest potwierdzona. Zasób ma najwyższą klasę krytyczności. Wynik: najwyższa pilność, zmiana awaryjna, a jeżeli poprawki nie da się wdrożyć od razu — natychmiastowe ograniczenie dostępu do bramy do znanych adresów i wzmożona obserwacja logów uwierzytelnienia. Uzasadnienie: niższa liczba niż w przypadku A, a ryzyko nieporównanie wyższe, bo trzy czynniki nakładają się na siebie — ekspozycja, potwierdzony atak i krytyczność.

Przypadek C. Ocena bazowa CVSS 5,3, podatność klasy „ujawnienie informacji”. Komponent na wewnętrznym serwerze aplikacyjnym. Brak wpisu w KEV, EPSS około 0,03. Sama w sobie wygląda na pozycję do zwykłej kolejki. Ale podatność ujawnia nazwy kont usługowych, a w tym samym środowisku otwarta jest inna pozycja — podniesienie uprawnień wymagające znajomości nazwy konta. Wynik: pilność podniesiona, bo dwa wykrycia razem tworzą ścieżkę, której żadne z nich nie tworzy osobno. To jest powód, dla którego sortowanie po wadze technicznej gubi łańcuchy ataku: ocenia pozycje pojedynczo.

Klasy pilności i terminy naprawy

Cztery pojęcia bywają używane wymiennie, a znaczą co innego. Waga techniczna przychodzi z zewnątrz. Priorytet to Twoja decyzja o kolejności. Termin naprawy to zobowiązanie wewnętrzne przypisane do klasy priorytetu. Termin regulacyjny to zobowiązanie wynikające z przepisu i dotyczy zwykle zgłoszenia incydentu, a nie naprawy podatności. Zmiana awaryjna to tryb wykonania, który omija normalną kolejkę zatwierdzeń — i który musi mieć własną, opisaną procedurę, bo inaczej „awaryjnie” zaczyna znaczyć „bez dokumentacji”.

Poniższy model klas jest przykładem do zaadaptowania, a nie wymaganiem. Konkretne liczby godzin i dni powinny wynikać z możliwości Twojego zespołu i z apetytu na ryzyko uzgodnionego z biznesem — model, którego nikt nie dotrzymuje, jest gorszy od jego braku, bo wytwarza fałszywy obraz w raportach.

Tabelę można przewijać w poziomie.

Przykładowy model klas pilności i terminów naprawy. Termin dotyczy remediacji albo skutecznej mitygacji, a ostatnia kolumna wskazuje, kto zatwierdza odstępstwo od niego. Wartości są punktem wyjścia do własnej polityki, a nie zaleceniem NIS2, CISA ani NIST; żadna z tych instytucji takich liczb nie narzuca podmiotom prywatnym w Polsce.
Klasa Reguła wejścia Termin Tryb zmiany Odstępstwo
P0 Podatność w katalogu KEV albo potwierdzone wykorzystanie w środowisku, zasób osiągalny z Internetu 24 do 72 godzin Zmiana awaryjna, poza kolejką Osoba odpowiedzialna za bezpieczeństwo wraz z właścicielem usługi
P1 Podatność w katalogu KEV na zasobie wewnętrznym albo wysoka waga techniczna z wysokim EPSS na zasobie osiągalnym 7 dni Przyspieszona zmiana standardowa Osoba odpowiedzialna za bezpieczeństwo
P2 Zasób produkcyjny, brak sygnału eksploatacji, podatna funkcja osiągalna wewnętrznie 30 dni Najbliższe okno serwisowe Właściciel zasobu
P3 Zasób nieprodukcyjny albo podatna funkcja nieosiągalna w tej konfiguracji 90 dni albo najbliższa większa aktualizacja Zwykły cykl utrzymania Właściciel zasobu

Trzy zasady, bez których taki model rozjeżdża się po kilku miesiącach. Po pierwsze, klasa wynika z reguły, a nie z uznania — reguła musi dać się zapisać tak, żeby dwie osoby doszły do tej samej klasy. Po drugie, termin biegnie od momentu, w którym wykrycie zostało zwalidowane, a nie od chwili, gdy ktoś się nim zajął. Po trzecie, klasa może się zmienić w obie strony: dopisanie podatności do katalogu KEV podnosi ją, a skuteczna mitygacja obniża. Wpis, którego klasa nigdy się nie zmienia, zwykle znaczy, że nikt na niego nie patrzy.

Stronę wykonawczą — okna serwisowe, kolejność hostów, rollback i walidację po zmianie — opisuje osobny materiał o aktualizacjach serwerów Linux w produkcji. Terminy z tabeli powyżej mają sens tylko wtedy, gdy ta strona jest poukładana; inaczej P0 oznacza tylko tyle, że ktoś będzie improwizował szybciej.

Gdy poprawki nie da się wdrożyć

To nie jest sytuacja wyjątkowa, tylko normalny element procesu. Poprawka może nie istnieć, może wymagać wersji systemu, której aplikacja nie obsługuje, może kolidować z integracją albo wymagać przestoju, na który nie ma zgody. Wtedy do wyboru jest kilka działań i warto je znać jako zestaw, a nie sięgać po pierwsze z brzegu.

  • Ograniczenie ekspozycji. Zdjęcie usługi z publicznego adresu, ograniczenie dostępu do znanych adresów źródłowych, wymuszenie tunelu. Najszybsze i najskuteczniejsze działanie, jeżeli usługa nie musi być publiczna.
  • Wyłączenie podatnej funkcji. Moduł, rozszerzenie, obsługa formatu, końcówka API. Wymaga sprawdzenia, kto z niej korzysta — i zapisania tego, bo za pół roku nikt nie będzie pamiętał, dlaczego jest wyłączona.
  • Reguła na zaporze, WAF lub liście kontroli dostępu. Sygnatura blokująca konkretny wzorzec żądania jest środkiem doraźnym i bywa obchodzona; reguła ograniczająca dostęp do usługi jest znacznie trwalsza.
  • Segmentacja. Ograniczenie zasięgu udanego ataku, nawet gdy sam atak jest możliwy. Podejście opisuje materiał o segmentacji sieci i strefach.
  • Zmiana konfiguracji. Odebranie uprawnienia, zmiana użytkownika procesu, wyłączenie metody uwierzytelnienia — czasem usuwa warunek konieczny do wykorzystania podatności.
  • Obejście wskazane przez dostawcę. Warto stosować dokładnie w wersji opisanej w biuletynie i odnotować numer biuletynu, żeby po wydaniu poprawki dało się to obejście wycofać.
  • Dodatkowa obserwacja. Reguła wykrywania nastawiona na konkretną próbę wykorzystania, z alarmem trafiającym do kogoś, kto wie, co z nim zrobić. Nie usuwa podatności i zwykle nie zmniejsza prawdopodobieństwa próby jej wykorzystania, ale skracając czas do wykrycia i reakcji może ograniczyć skutki incydentu.
  • Izolacja albo wyłączenie zasobu. Rozwiązanie skuteczne i częściej wykonalne, niż się wydaje — zwłaszcza dla usług, które działają wyłącznie dlatego, że nikt ich nie wyłączył.
  • Plan wycofania systemu. Gdy problem jest strukturalny, jedyną trwałą odpowiedzią jest wymiana, a wszystko powyżej jest pomostem do niej.
  • Formalna akceptacja ryzyka. Ostatnia opcja, nie pierwsza. Wymaga uzasadnienia, właściciela decyzji, terminu ważności i daty przeglądu.

Trzy statusy, których nie wolno mylić

Remediacja usuwa przyczynę. Podatny kod przestaje być obecny albo przestaje być podatny. Po remediacji ponowny skan nie zgłasza wykrycia.

Mitygacja ogranicza ryzyko przy zachowanej przyczynie. Podatny kod nadal działa, tylko trudniej go dosięgnąć albo skutek jego wykorzystania jest mniejszy. Ponowny skan zwykle nadal zgłasza wykrycie — i to jest poprawne zachowanie, a nie fałszywy alarm do wyciszenia.

Akceptacja ryzyka nie zmienia niczego technicznie. Jest decyzją, że w danym okresie firma świadomie żyje z tym ryzykiem.

Praktyczna konsekwencja jest jedna i twarda: wykrycia zmitygowanego nie oznacza się jako naprawionego. Nie chodzi o formalizm. Chodzi o to, że sześć miesięcy później ktoś przeniesie usługę za inny reverse proxy albo uprości reguły zapory, kontrola kompensacyjna zniknie, a wpis w rejestrze będzie mówił „naprawione”. Status „zmitygowane” z opisem zastosowanej kontroli i datą przeglądu jest jedyną rzeczą, która pozwala to wychwycić.

Systemy po zakończeniu wsparcia to osobna kategoria

Brak poprawki dla systemu, który wyszedł ze wsparcia producenta, wygląda jak zwykły wyjątek w zarządzaniu poprawkami, ale nim nie jest — i traktowanie go tak samo jest jednym z częstszych błędów strukturalnych.

Różnica jest jakościowa. Zwykły wyjątek dotyczy jednej podatności i kończy się, gdy poprawka zostanie wydana albo wdrożona. Wyjątek dla systemu po zakończeniu wsparcia dotyczy wszystkich przyszłych podatności tego systemu i nie kończy się nigdy, dopóki system istnieje. Zamiast malejącej listy problemów masz rosnącą, o nieznanym z góry rozmiarze.

Możliwe odpowiedzi, w kolejności trwałości:

  • Wymiana albo migracja na wspieraną wersję. Jedyne rozwiązanie, które zamyka temat. Wymaga budżetu i planu, więc decyzja musi zapaść, zanim wsparcie się skończy, a nie po pierwszym niemożliwym do załatania wykryciu.
  • Rozszerzone wsparcie producenta. Tam, gdzie jest dostępne — z jasnym zapisem, co obejmuje i do kiedy.
  • Izolacja. Osobny segment, ruch wyłącznie do wskazanych systemów, dostęp administracyjny przez punkt pośredni, brak połączeń wychodzących poza niezbędne.
  • Kontrole kompensacyjne wokół systemu. Filtrowanie na wejściu, ograniczenie uprawnień konta usługowego, monitorowanie zachowania procesu.
  • Plan wycofania z datą. Nawet odległą — sama data zmienia rozmowę z „kiedyś to wymienimy” na „mamy termin”.

O trwałym wyjątku warto wiedzieć jedno: on nie znika, tylko przestaje być widoczny. Rejestr wyjątków bez daty przeglądu po dwóch latach zawiera pozycje, których nikt nie pamięta, a stan faktyczny środowiska dawno się zmienił. Data przeglądu jest jedynym mechanizmem, który wymusza powrót do tematu — i dlatego jest polem obowiązkowym, a nie opcjonalnym.

Statusy wykrycia i dowód, którego wymagają

Każde wykrycie kończy się jakimś statusem. Wartość rejestru zależy od tego, czy status jest podparty dowodem, czy tylko czyjąś oceną.

Tabelę można przewijać w poziomie.

Statusy zamknięcia wykrycia i wymagany dowód. Ostatnia kolumna odpowiada na pytanie, czy podatność przestała istnieć w środowisku — a nie na pytanie, czy zgłoszenie zostało zamknięte.
Status Co znaczy Wymagany dowód Czy podatność zniknęła
Naprawione Przyczyna usunięta poprawką, nową wersją albo zmianą usuwającą podatny kod Wersja komponentu po zmianie, ponowny skan bez wykrycia, wpis w rejestrze zmian Tak
Zmitygowane Ryzyko ograniczone, podatny komponent nadal obecny i działający Opis kontroli kompensacyjnej, dowód jej działania, termin powrotu do tematu Nie
Ryzyko zaakceptowane Świadoma decyzja o nienaprawianiu w danym okresie Uzasadnienie, właściciel decyzji, termin ważności, data przeglądu, zatwierdzenie na właściwym szczeblu Nie
Nie dotyczy Komponent jest, ale konfiguracja albo sposób budowania wyklucza podatność Wskazanie warunku z opisu podatności lub biuletynu dostawcy i dowód, że nie jest spełniony Warunkowo — do najbliższej zmiany konfiguracji
Fałszywe wykrycie Skaner pomylił się co do komponentu, wersji albo mapowania Dowód rzeczywistej wersji, zgłoszenie do dostawcy skanera, reguła wyciszenia z terminem ważności Nigdy nie było
Ponowne wykrycie Podatność wróciła po zamknięciu wpisu Data ponownego wykrycia, ustalona przyczyna nawrotu, poprawka w procesie, a nie tylko na hoście Nie

Dwa statusy zasługują na osobny komentarz, bo są najczęściej nadużywane.

„Nie dotyczy” jest poprawnym i potrzebnym statusem, ale ma warunek. Jeżeli podatność nie dotyczy hosta, ponieważ dana funkcja jest wyłączona, to zapis musi wskazywać, która to funkcja i gdzie sprawdzono jej stan. Bez tego status jest niesprawdzalny, a pierwsza zmiana konfiguracji cicho go unieważnia. Dobrą praktyką jest powiązanie takiego wpisu z kontrolą konfiguracji, która wykryje zmianę.

„Fałszywe wykrycie” wymaga dowodu rzeczywistego stanu, a nie przekonania. Reguła wyciszająca powinna mieć termin ważności i być powiązana z konkretnym zasobem oraz konkretnym identyfikatorem — wyciszenie „tego CVE wszędzie na zawsze” po roku obejmuje hosty, których w chwili decyzji nie było.

Weryfikacja: zamknięcie na dowód

Zainstalowanie pakietu nie jest końcem naprawy. Kończy ją potwierdzenie, że podatność zniknęła i że usługa nadal działa. NIST SP 800-40 Rev. 4 definiuje zarządzanie poprawkami w skali przedsiębiorstwa jako proces identyfikowania, priorytetyzowania, pozyskiwania, instalowania i weryfikowania instalacji poprawek — weryfikacja jest tam częścią definicji, a nie dodatkiem.

Minimalny zestaw kontroli po zmianie:

  1. Ponowny skan zasobu. Nie całej sieci — dokładnie tego zasobu, dokładnie po zmianie. Skan z nocnego harmonogramu sprzed dwóch dni nie jest dowodem.
  2. Sprawdzenie wersji komponentu na miejscu. Menedżer pakietów, wersja zwracana przez usługę, suma kontrolna pliku. Zdarza się, że pakiet się zaktualizował, a proces nadal działa na starym kodzie w pamięci.
  3. Potwierdzenie restartu tego, co restartu wymagało. Aktualizacja biblioteki bez przeładowania procesów, które ją mapują, zostawia podatny kod w działaniu — a skaner sprawdzający wersję pakietu tego nie zobaczy.
  4. Test funkcji, której podatność dotyczyła. Jeżeli podatność była w obsłudze przesyłania plików, przetestuj przesyłanie plików.
  5. Test podstawowej ścieżki biznesowej. Logowanie, zapis, odczyt, integracja z systemem zewnętrznym.
  6. Przegląd logów w oknie obserwacji. Nowe błędy, zmiana profilu ruchu, restarty w pętli. Bez centralnego zbierania logów ta kontrola sprowadza się do zgadywania — porządkuje to materiał o centralizacji i retencji logów.
  7. Porównanie wskaźników z poziomem sprzed zmiany. Czasy odpowiedzi, odsetek błędów, obciążenie.
  8. Zamknięcie wpisu z odwołaniem do dowodu. Numer zmiany, identyfikator skanu, wynik testu.

Dwie uwagi z praktyki. Weryfikację powinien wykonać ktoś inny niż osoba wykonująca zmianę — nie z nieufności, tylko dlatego, że osoba naprawiająca sprawdza to, co zmieniła, a nie to, co miało zniknąć. I odwrotna strona tego samego: zamknięcie wpisu bez dowodu jest gorsze od pozostawienia go otwartym, bo usuwa problem z pola widzenia, nie usuwając go ze środowiska.

Backlog i metryki, które coś znaczą

Miara, która rośnie razem z liczbą skanowanych zasobów, nie mierzy bezpieczeństwa, tylko zasięg skanowania. Dobra metryka odpowiada na pytanie decyzyjne: czy w tym miesiącu jest lepiej niż w poprzednim i gdzie dokładnie jest wąskie gardło.

  • Liczba otwartych podatności z katalogu KEV. Jedna liczba, którą warto mieć zawsze pod ręką. W dobrze prowadzonym środowisku jest mała i wraca do zera.
  • Podatności z katalogu KEV po terminie. Podzbiór powyżej, ale mówiący o procesie, a nie o stanie.
  • Podatności na zasobach osiągalnych z Internetu. Osobno, bo ten zbiór ma inny profil ryzyka niż reszta.
  • Wiek najstarszej otwartej pozycji w każdej klasie pilności. Mówi więcej niż średnia, bo pojedynczej zaległości nie da się w nim schować.
  • Mediana czasu do naprawy w klasie pilności. Mediana, nie średnia — rozkład jest skośny, a jedna zaległa pozycja przesuwa średnią o tygodnie. Wartość liczy się osobno dla każdej klasy; wspólna wartość dla wszystkich klas nie znaczy nic, bo miesza terminy trzydniowe z dziewięćdziesięciodniowymi.
  • Pokrycie skanowaniem. Odsetek zasobów z ewidencji objętych skanowaniem w ostatnim cyklu. Bez ewidencji ta metryka nie istnieje.
  • Pokrycie ewidencji. Odsetek zasobów znanych ewidencji wśród wszystkich wykrytych innymi drogami — skanem sieci, przeglądem zewnętrznej powierzchni ataku, danymi z rejestratora domen.
  • Liczba i wiek aktywnych wyjątków. Rosnący wiek jest sygnałem, że rejestr wyjątków zamienia się w archiwum.
  • Odsetek ponownych wykryć. Ile zamkniętych pozycji wróciło w ciągu kwartału. Wysoka wartość wskazuje na problem w procesie: brak weryfikacji, odtwarzanie hostów ze starego obrazu, konfiguracja nadpisywana przez automatyzację.
  • Udział zasobów po zakończeniu wsparcia. Metryka, która nie zmienia się w wyniku pracy operacyjnej, tylko w wyniku decyzji inwestycyjnych — i dlatego jest jedyną sensowną liczbą do rozmowy o budżecie.

Czego nie warto raportować jako miary bezpieczeństwa: całkowitej liczby wykryć (rośnie z zasięgiem skanowania i z liczbą reguł w skanerze), liczby zamkniętych zgłoszeń bez podziału na status (miesza naprawy z wyciszeniami) i średniej oceny CVSS w backlogu (nie odpowiada na żadne pytanie decyzyjne).

Automatyzacja: co maszyna, a co człowiek

Automatyzacja w tym procesie ma jasno wyznaczoną granicę: maszyna dobrze zbiera, łączy i przenosi dane, a źle rozstrzyga wątpliwości.

Warto zautomatyzować:

  • pobieranie wyników skanów i normalizację ich do jednego formatu,
  • codzienne dociąganie wartości EPSS i stanu katalogu KEV — oba źródła są publiczne i dostępne maszynowo,
  • dowiązanie wykrycia do zasobu w ewidencji i przeniesienie właściciela, środowiska oraz krytyczności,
  • wyliczenie proponowanej klasy pilności według zapisanych reguł,
  • założenie zgłoszenia we właściwej kolejce z kompletem kontekstu,
  • ponowny skan zaplanowany automatycznie po zamknięciu zmiany,
  • przypomnienia o zbliżającej się dacie przeglądu wyjątku,
  • raport odchyleń: pozycje po terminie, wyjątki bez daty przeglądu, zasoby bez właściciela.

Decyzji nie warto oddawać maszynie w czterech miejscach. Walidacja wątpliwego wykrycia wymaga zajrzenia w konfigurację. Podniesienie albo obniżenie klasy wbrew regule jest z definicji przypadkiem, którego reguła nie objęła — i powinno zostawiać ślad z uzasadnieniem. Akceptacja ryzyka jest decyzją biznesową, więc podpisuje ją człowiek, który ponosi jej konsekwencje. Automatyczne wdrożenie poprawki na produkcji bywa właściwe dla stacji roboczych i dla warstwy bezstanowej, ale dla systemów, których restart oznacza przerwę w usłudze, wymaga tego samego reżimu co każda inna zmiana.

Jedna pułapka warta wskazania: automatyczne zamykanie zgłoszenia w chwili, gdy skaner przestaje zgłaszać wykrycie. Wygląda na oszczędność, a w praktyce zamyka pozycje z powodów, które nie mają nic wspólnego z naprawą — host był wyłączony w czasie skanu, zmienił adres, wypadł z zakresu albo skaner nie uwierzytelnił się poprawnie. Zamknięcie powinno wymagać skanu, który tego zasobu faktycznie dosięgnął.

Najczęstsze błędy

  • Sortowanie wyłącznie po ocenie CVSS. Punkt wyjścia tego artykułu i najtrwalszy nawyk — bo lista posortowana po jednej liczbie wygląda na obiektywną.
  • Praca „od Critical w dół” bez kontekstu. Kolejność wygodna do raportowania, oderwana od tego, gdzie stoją zasoby.
  • Pomijanie pozycji Medium i Low. Wśród wpisów katalogu KEV z oceną bazową CVSS v3 sto trzydzieści siedem mieści się w tych przedziałach. Polityka ignorująca je pomija podatności z potwierdzonym wykorzystaniem.
  • Skanowanie bez aktualnej ewidencji. Skanuje się to, co znane; przejmowane jest to, o czym nikt nie pamiętał.
  • Wykrycie bez właściciela. Pozycja bez przypisanej osoby nie ma terminu — ma tylko datę utworzenia.
  • Zamykanie po instalacji pakietu. Bez restartu procesu, bez ponownego skanu i bez sprawdzenia wersji, na której faktycznie działa usługa.
  • Wyjątki bez daty przeglądu. Po dwóch latach rejestr wyjątków opisuje środowisko, którego już nie ma.
  • Mitygacja opisana jako naprawa. Ceną tego skrótu jest utracona informacja, a widać ją dopiero przy pierwszej zmianie architektury.
  • Traktowanie zakończenia wsparcia jak zwykłego wyjątku. Wyjątek, który dotyczy wszystkich przyszłych podatności systemu, jest decyzją inwestycyjną, a nie operacyjną.
  • Brak ponownego skanu. Zamknięcie oparte na deklaracji wykonawcy zmiany.
  • Brak osobnej kontroli zasobów publicznych. Zbiór, który zmienia się najszybciej i niesie największe ryzyko, bywa objęty tym samym cyklem co reszta.
  • Proces poprawek bezpieczeństwa obok zarządzania zmianą. Dwa rejestry zmian, które nie zgadzają się ze sobą, i zmiany bez śladu.
  • Używanie EPSS jako kompletnej oceny ryzyka. Model odpowiada na jedno pytanie i sam o tym mówi w dokumentacji.
  • Przenoszenie cudzych progów bez sprawdzenia ich skutku u siebie. Próg jest polityką, więc wymaga policzenia, ile wykryć obejmuje w konkretnym środowisku.

Najczęstsze pytania

Czy podatność z oceną CVSS 10,0 trzeba naprawić jako pierwszą?

Nie automatycznie. Ocena bazowa 10,0 znaczy, że podatność jest technicznie bardzo poważna — zwykle zdalna, bez uwierzytelnienia i z pełnym wpływem na system. To mocny argument, ale nie odpowiedź na pytanie o kolejność. Jeżeli podatny komponent stoi w segmencie odciętym od sieci, podatna funkcja jest wyłączona, a jednocześnie na publicznej bramie zdalnego dostępu leży podatność z oceną 7,x i z potwierdzoną eksploatacją, to naprawa zaczyna się od bramy. Ocena 10,0 jest jednak sygnałem, którego nie wolno przegapić: jeśli taka podatność dotyczy zasobu osiągalnego, praktycznie zawsze wchodzi do najwyższej klasy pilności.

Czym różni się CVSS od EPSS?

Odpowiadają na różne pytania. CVSS opisuje, co się stanie, gdy podatność zostanie wykorzystana — wektor ataku, wymagane warunki, wpływ na poufność, integralność i dostępność. EPSS szacuje, czy ktoś ją wykorzysta — dokładniej: jakie jest prawdopodobieństwo zaobserwowania wykorzystania w ciągu najbliższych trzydziestu dni. CVSS jest w większości statyczny, EPSS zmienia się codziennie. Żaden z nich nie wie, czy podatność występuje w Twoim środowisku ani ile kosztowałby incydent. Używa się ich razem, a nie zamiennie.

Co oznacza obecność podatności w katalogu CISA KEV?

Że CISA ma wiarygodne dowody jej aktywnego wykorzystywania w atakach, że podatność ma nadany identyfikator CVE i że istnieje jasne działanie naprawcze. To najmocniejszy publiczny sygnał, jakim dysponuje osoba ustalająca kolejność napraw, bo nie mówi o prawdopodobieństwie, tylko o zdarzeniu, które już nastąpiło. CISA zaleca traktowanie katalogu jako wejścia do własnego procesu priorytetyzacji.

Czy brak CVE w katalogu KEV oznacza, że nikt tego nie wykorzystuje?

Nie. Katalog rejestruje przypadki, w których CISA ma dowody spełnienia wszystkich warunków wpisu. Poza nim zostają więc podatności, dla których takich dowodów nie ma, oraz te, dla których nie wskazano jeszcze jasnego działania naprawczego — a to jeden z warunków. Brak wpisu jest brakiem sygnału, nie sygnałem negatywnym.

Jaka wartość EPSS jest wysoka?

FIRST nie podaje uniwersalnego progu i wprost zaznacza, że popularna wartość 0,10 nie ma statusu zalecenia. Pomocny jest raczej rozkład: 22 sierpnia 2026 r. wynik 0,10 lub wyższy miało 4,76 procent ocenianych rekordów, a 0,50 lub wyższy — 1,19 procent. Wynik 0,20 stawia więc podatność w wąskiej grupie, ale nie mówi nic o skutku ani o tym, czy podatność u Ciebie występuje.

Czy można ustalić własny próg EPSS?

Można i zwykle warto — pod trzema warunkami. Próg musi być zapisany jako polityka wewnętrzna z uzasadnieniem, a nie prezentowany jako zalecenie FIRST. Musi jasno wskazywać, czy dotyczy wyniku, czy percentyla. I musi zostać policzony na własnych danych: ile wykryć w Twoim środowisku obejmuje i ile pomija. Dobrą praktyką jest reguła dwustronna — próg wysoki podnosi klasę pilności, próg niski pozwala ją obniżyć, ale nigdy dla podatności z katalogu KEV.

Jak często wykonywać skanowanie podatności?

Odpowiedź zależy od klasy zasobu, a nie od jednej częstotliwości dla całego środowiska. Rozsądny punkt wyjścia: zasoby osiągalne z Internetu — co najmniej raz w tygodniu, a dodatkowo po każdej zmianie w warstwie ekspozycji; zasoby produkcyjne wewnętrzne — co najmniej raz w miesiącu; pozostałe — kwartalnie. Do tego dwa skany zdarzeniowe: po każdej istotnej zmianie w środowisku oraz po dopisaniu do katalogu KEV podatności dotyczącej używanego oprogramowania. Rozporządzenie 2024/2690 dla objętych nim podmiotów formułuje to ogólniej: skany w zaplanowanych odstępach, z zachowaniem dowodów wyników.

Co zrobić, gdy poprawka grozi awarią usługi?

Rozdzielić dwie rzeczy: ryzyko wynikające z podatności i ryzyko wynikające ze zmiany. Trudna naprawa nie zmniejsza pierwszego. Kolejność działań: ograniczyć ekspozycję natychmiast, żeby zyskać czas; przetestować poprawkę w środowisku odzwierciedlającym produkcję; przygotować i sprawdzić procedurę wycofania; wdrożyć w oknie serwisowym, falami, z określonym kryterium cofnięcia. Jeżeli poprawka pozostaje niemożliwa do wdrożenia, wpis zmienia status na „zmitygowane” z opisem kontroli kompensacyjnej i terminem powrotu — a nie na „naprawione”.

Czy mitygacja oznacza, że podatność jest zamknięta?

Nie. Mitygacja ogranicza ryzyko, ale podatny kod nadal działa i nadal będzie zgłaszany przez skaner. Wpis pozostaje otwarty ze statusem „zmitygowane”, z opisem zastosowanej kontroli, jej właścicielem i datą przeglądu. Zamknięcie należy się dopiero remediacji albo wycofaniu zasobu. Rozporządzenie 2024/2690 idzie w tym samym kierunku: gdy poprawka nie jest stosowana, wymaga środków dodatkowych i formalnej akceptacji ryzyka szczątkowego, a nie uznania sprawy za załatwioną.

Jak traktować systemy po zakończeniu wsparcia producenta?

Jako decyzję inwestycyjną, nie jako pozycję w kolejce napraw. Brak poprawki nie jest tu pojedynczym zdarzeniem, tylko stanem trwałym obejmującym wszystkie przyszłe podatności tego systemu. Minimum operacyjne to izolacja, ograniczenie dostępu, monitorowanie i formalna akceptacja ryzyka z datą przeglądu. Rozwiązaniem docelowym jest wymiana albo migracja i warto mieć dla niej termin, nawet odległy.

Czy OpenVAS wystarczy do zarządzania podatnościami?

Do wykrywania — dla wielu środowisk tak, zwłaszcza przy skanowaniu z uwierzytelnieniem, które daje znacznie dokładniejszy obraz niż skan zdalny. Do zarządzania — nie, i nie dlatego, że to akurat OpenVAS. Sam wynik skanu nie zna właściciela biznesowego usługi, jej rzeczywistej krytyczności, akceptowalnego przestoju ani kosztu zmiany, dopóki dane te nie zostaną dostarczone z ewidencji zasobów, bazy konfiguracji albo procesu organizacyjnego. Rozbudowane platformy zarządzania podatnościami potrafią taki kontekst przechowywać, prowadzić rejestr wyjątków z terminami, odróżniać mitygację od naprawy i wiązać wykrycia z obiegiem zgłoszeń — ale same informacje nadal muszą pochodzić z organizacji, a nie ze skanu. Skaner jest jednym wejściem do procesu; resztę stanowi ewidencja, reguły priorytetyzacji i dyscyplina zamykania na dowód. Jak przełożyć pojedynczy raport na listę prac, opisuje osobny materiał o planie napraw po skanie OpenVAS.

Jak powiązać zarządzanie podatnościami z NIS2 i KSC?

Trzema rzeczami, o które pyta się przy weryfikacji: udokumentowanym procesem obsługi podatności spójnym z zarządzaniem zmianą i ryzykiem, dowodami wykonania (wyniki skanów, zapisy napraw z terminami i osobami odpowiedzialnymi, wyniki ponownych sprawdzeń) oraz rejestrem decyzji o nienaprawianiu wraz z uzasadnieniem. Dla podmiotów objętych rozporządzeniem 2024/2690 są to wprost punkty 6.6 i 6.10 jego załącznika. Zakres obowiązków wynikających z polskiej ustawy o krajowym systemie cyberbezpieczeństwa i terminy ich wdrożenia opisuje osobny materiał o przygotowaniu infrastruktury do NIS2 i KSC.

Co zrobić, gdy podatność jest już wykorzystywana w naszym środowisku?

To nie jest wtedy zagadnienie zarządzania podatnościami, tylko obsługa incydentu — i kolejność działań jest inna: zabezpieczenie śladów przed zmianą czegokolwiek, ograniczenie zasięgu, dopiero potem naprawa. Pierwsze kroki opisuje materiał o pierwszych sześćdziesięciu minutach incydentu na Linuksie. Warto zwrócić uwagę, że nawet dyrektywa BOD 26-04 łączy najkrótszy termin naprawy z wymaganiem wstępnej analizy śledczej zasobu: przy podatności o pełnym wpływie technicznym i potwierdzonej eksploatacji sama łatka nie odpowiada na pytanie, czy system nie został już przejęty.

Źródła

Odnośniki sprawdzone 22 sierpnia 2026 r. Dane liczbowe pochodzą z tego samego dnia; oba źródła zmieniają się codziennie, więc przy powtórzeniu rachunku wartości będą inne.

Standardy oceny podatności

Eksploatacja i priorytetyzacja

Kontekst europejski i wymagania

Ramy zarządzania i utrzymanie

Podsumowanie

Zarządzanie podatnościami nie zaczyna się od skanera. Zaczyna się od listy zasobów z właścicielem, środowiskiem i ekspozycją, bo bez niej wynik skanu jest zbiorem nazw pakietów, których nie da się do niczego przypisać. Potem potrzebne są dwie rzeczy: reguła, która z kilku niezależnych sygnałów robi jedną klasę pilności, i dyscyplina zamykania wpisu dopiero wtedy, gdy istnieje dowód.

Jeżeli miałbym wskazać trzy zmiany dające najszybszy efekt w środowisku, które dziś sortuje po ocenie CVSS: codzienne dociąganie stanu katalogu KEV i wartości EPSS do wyników skanów, wydzielenie zasobów osiągalnych z Internetu jako osobnego zbioru z krótszym cyklem oraz rozdzielenie statusów „naprawione” i „zmitygowane” w rejestrze. Żadna z nich nie wymaga nowego narzędzia. Wszystkie trzy zmieniają to, na co patrzy zespół w poniedziałek rano.

Jeżeli chcesz przełożyć ten model na konkretne środowisko, najbliżej temu materiałowi do bezpieczeństwa środowiska IT — uporządkowania ekspozycji, procesu obsługi podatności i dowodów działania kontroli. Stronę wykonawczą, czyli aktualizacje i okna serwisowe, obejmuje administracja serwerami Linux, a obserwację skutków zmian i wykrywanie nawrotów — monitoring infrastruktury IT.