Priorytetyzacja podatności oparta na ryzyku: jak kontekst zasobu uzupełnia ocenę CVSS 

Rok 2025 był rekordowy pod względem liczby publikowanych podatności. Odnotowano ponad 48 tysięcy podatności, co w uśrednieniu daje 130 dziennie. (https://cve.icu/index.html) Trend ten nie wygasa, w pierwszej połowie 2026 roku opublikowano 36 tysięcy podatności, jest to blisko 50% więcej względem analogicznego okresu roku poprzedniego. Według prognozy FIRST do końca roku ma zostać ujawnione około 66 tysięcy nowych podatności. (https://www.first.org/newsroom/releases/20260615)  

Taki wzrost odbija się na zespołach bezpieczeństwa, które są odpowiedzialne za zarządzanie podatnościami. Pogłębia się nierównowaga między liczbą pozycji wymagających oceny a możliwościami ich naprawy. Jest to zauważalne nawet w instytucjach, które powstały w celu katalogowania zagrożeń takich jak amerykańskie NVD (National Vulnerability Database). Zgodnie z ich komunikatem z 15 kwietnia 2026 roku, zmieniają mechanizm priorytetyzacji. W pierwszej kolejności wzbogacają podatności z katalogu KEV (CISA’s Known ExploitedVulnerabilities- https://www.cisa.gov/known-exploited-vulnerabilities-catalog), dotyczące oprogramowania federalnego oraz krytycznego (zgodnych z definicją https://www.nist.gov/system/files/documents/2026/04/15/EO%2014028%20Critical%20FINAL.pdf). Pozostałe podatności będą trafiać do bazy NVD, jednak będą oznaczane niskim priorytetem, bez zaplanowanej natychmiastowej analizy i wzbogacenia ich opisu.  

Ta sytuacja jednoznacznie obrazuje, że tradycyjne podejście oparte na ocenie CVSS (Common Vulnerability Scoring System) jest niewystarczające w obecnie panujących warunkach. Przykład NVD potwierdza, że wymagane jest nowe podejście do zarządzania podatnościami, ponieważ obecnym wyzwaniem nie jest „jak załatać wszystkie luki”, lecz „co należy naprawić w pierwszej kolejności, aby najskuteczniej obniżyć ryzyko”. Takie rozwiązanie jest zaimplementowane w SecureVisio, poniżej pokazujemy, jak ta sama podatność może otrzymać różne priorytety w zależności od znaczenia zasobu, na którym występuje. 

Co mierzy CVSS, a czego nie mierzy? 

CVSS – Common Vulnerability Scoring System to międzynarodowy, otwarty standard oceny podatności w zabezpieczeniach systemów i oprogramowania. Określa, jak trudno wykorzystać daną lukę oraz jak poważne konsekwencje z tego przełamania wynikną. Standard CVSS można spotkać w różnych wersjach, np. v2.0 (legacy), v3.x, v4.0. Ta ostatnia jest najnowsza, funkcjonuje od 2023 roku. Bazy takie jak CVE, NVD czy też oprogramowania do skanowania i zarządzania podatnościami zazwyczaj działają na różnych wersjach równolegle, dlatego ta sama podatność często posiada dwie czy też trzy oceny odpowiadające poszczególnym wersjom standardu.  

Oceny te składają się z trzech grup metryk, które są takie same dla każdej wersji, jednak różnią się metrykami, które zawierają. Poniżej opis v3.1, ponieważ to ona jest najczęściej spotykana, v2 jest już przestarzała, a v4 jest dopiero wdrażana.  

CVSS v3.1 dzieli ocenę na trzy grupy metryk: 

• Base Metrics (metryki bazowe) – Statyczne cechy podatności, niezależne od czasu i środowiska. Są one obowiązkowe, ponieważ to one dają „surowy” wynik CVSS. 

• Temporal Metrics (metryki czasowe) – Zmieniają się w czasie życia podatności, odzwierciedlają aktualny stan wiedzy i reakcji na CVE. Są to metryki opcjonalne, mogące obniżyć Base Score. 

• Environmental Metrics (metryki środowiskowe) – Dostosowują ocenę do konkretnej organizacji/infrastruktury. Są to metryki opcjonalne, pozwalają nadpisać Base Score i dodać wagę biznesową. 

Można tutaj dostrzec próbę zaadresowania problemu związanego z ryzykiem wynikającym z charakterystyki konkretnego systemu. Jednak w obiegu funkcjonuje niemal wyłącznie Base Score, podatności publikowane w bazach takich jak NVD zawierają tę metrykę, a pozostałe zazwyczaj pozostają puste. Kolejna wersja standardu, czyli 4.0, poprawia samą precyzję oceny technicznej, jednak nie zmienia tego, że jest to miara dotkliwości, a nie ryzyka w konkretnym środowisku. Pełen opis poszczególnych wersji jest dostępny na stronie https://www.first.org/cvss/. 

Kluczowe jest to, że Base Score jest uniwersalny, czyli taki sam dla wszystkich organizacji i niezależny od tego, gdzie konkretna podatność występuje. Nie mówi nic o realnych konsekwencjach w prawdziwym środowisku. Opisuje skutki wyłącznie dla samego podatnego komponentu, z perspektywy technicznej, pomijając kontekst organizacji. Sam NVD zwraca na to uwagę, zaznaczając wprost, że „CVSS nie jest miarą ryzyka” (https://nvd.nist.gov/vuln-metrics/cvss).   

Utożsamianie tak rozumianej dotkliwości z ryzykiem prowadzi do błędnych decyzji. Ryzyko to wypadkowa dotkliwości, prawdopodobieństwa wykorzystania oraz wartości zasobu, który dana luka naraża, a bazowy CVSS opisuje wyłącznie pierwszy z tych elementów. Powoduje to konkretne ograniczenia. 

1. Metryki opisujące środowisko pozostają puste, chociaż standard je przewiduje, jednak ich ręczne uzupełnianie dla tysięcy pozycji jest zbyt pracochłonne, więc w niewielu przypadkach jest realizowane. W efekcie ocena traci jedyny element, który zapewniałby jej odwołanie do kontekstu organizacji. 

2. Przy aktualnej skali sama ocena słabo różnicuje podatności. W 2025 roku oceny krytyczne zostały przypisane do 8% opublikowanych podatności, a wysokie aż do 31% (https://nvd.nist.gov/general/visualizations/vulnerability-visualizations/cvss-severity-distribution-over-time). Przy 48 tysiącach luk daje to kilkanaście tysięcy podatności sklasyfikowanych jako pilne. Żaden zespół nie jest w stanie potraktować takiej liczby podatności jako priorytetowych, więc nie jest to przydatna informacja do ustalania kolejności działań. 

3. Ocena jest statyczna, nadawana jest raz i zwykle się nie zmienia, nawet jeśli dla danej podatności pojawia się nowy, publicznie i masowo dostępny exploit. Informacja o tym, czy luka jest realnie wykorzystywana, nie jest częścią Base Score. 

NIS2 i KSC a ocena podatności 

Uwzględnienie skutków dla konkretnej organizacji przy ocenie podatności nie jest wyłącznie dobrą praktyką. Dla wielu podmiotów jest to obowiązek prawny wynikający z dyrektywy NIS2 oraz znowelizowanej ustawy o krajowym systemie cyberbezpieczeństwa (KSC) wdrażającej NIS2 w Polsce. Przepisy nie narzucają konkretnej metody priorytetyzacji podatności ani nie zakazują CVSS, ale wymagają zarządzania ryzykiem i stosowania środków proporcjonalnych do zagrożenia. Kluczowa jest tu zasada proporcjonalności. Dobór środków ma odpowiadać stopniowi narażenia podmiotu, jego wielkości oraz prawdopodobieństwu i dotkliwości potencjalnych następstw, w tym skutkom gospodarczym i społecznym (https://www.trecom.pl/analiza-ryzyka-w-nis2-jak-osiagnac-zgodnosc-krok-po-kroku-przewodnik-2026/, https://www.trecom.pl/ustawa-o-ksc-w-2026-roku-jak-polskie-prawo-wdraza-nis-2/).  W tym świetle sortowanie podatności wyłącznie po technicznej dotkliwości CVSS, w oderwaniu od skutków dla organizacji, trudno uznać za wystarczające do wykazania podejścia opartego na ryzyku. Priorytetyzacja, która uwzględnia kontekst zasobu i konsekwencje, jest naturalnym sposobem, by tę proporcjonalność zrealizować i udokumentować. 

Warto dodać, że oczekiwanie regulatora pokrywa się z szerszym kierunkiem w branży, opisywanym jako risk-based vulnerability management (RBVM). Nie jest to podejście jednego producenta, lecz standard rynkowy o wspólnym mianowniku: dotkliwość techniczna to punkt wyjścia, a o kolejności napraw decydują prawdopodobieństwo wykorzystania i znaczenie zasobu dla organizacji. Poszczególne narzędzia realizują to na różne sposoby, a SecureVisio jest jedną z takich implementacji, w której cały kontekst powstaje wewnątrz jednej platformy. 

Kontekst zagrożenia a kontekst zasobu 

Realny priorytet podatności, który jest potrzebny do efektywnego zarządzania podatnościami oraz spełnienia wymagań regulatora, jest zależny od dwóch niezależnych pytań: 

• Pierwsze pochodzi ze świata zewnętrznego: jakie podatności istnieją i jak poważne są z natury, w oderwaniu od środowiska. Odpowiadają na nie bazy podatności z ocenami CVSS oraz skanery, które wykrywają luki w komponentach. To warstwa czysto techniczna. Nie rozstrzyga, co dana luka naraża w konkretnym środowisku. 

• Drugie dotyczy konkretnej organizacji: co się stanie, jeśli na tym konkretnym zasobie zostanie wykorzystana podatność, jakie procesy zostały tym dotknięte. To jest wiedza na pograniczu świata biznesu i technicznego. Wiedza o tym, jaki system operacyjny jest na zasobie, jak jest chroniony, jakie dane przetwarza, jakie procesy biznesowe obsługuje. Żadne zewnętrzne narzędzie ani żadna zewnętrzna organizacja nie jest w stanie dostarczyć tych danych, ponieważ są one specyficzne dla każdej organizacji. To właśnie one są kluczowe przy decydowaniu o rzeczywistej wadze podatności. 

Prosty przykład, który to ilustruje. Krytyczna podatność RCE, czyli możliwość zdalnego wykonania kodu o ocenie CVSS 9,8 na serwerze produkcyjnym w strefie DMZ, obsługującym kluczowy proces płatności i przetwarzania danych osobowych klientów. To potencjalny incydent o poważnych skutkach biznesowych oraz prawnych. Następnie ta sama luka na serwerze testowym, który znajduje się w odizolowanym fragmencie sieci, bez dostępu z zewnątrz oraz bez dostępu do Internetu, pracujący na danych testowych. W tym przypadku sytuacja nie jest już tak poważna, ryzyko jest ograniczone. Ocena CVSS dla obu przypadków jest taka sama, różnicę można zauważyć dopiero po dodaniu kontekstu tych zasobów. Dokładnie takie podejście jest realizowane w SecureVisio. 

CVSS i kontekst zasobu w praktyce 

Algorytm priorytetyzacji podatności, aby mógł odróżnić serwer testowy od systemu produkcyjnego, potrzebuje ustrukturyzowanej wiedzy o zasobach. Połączenie bazy zasobów CMDB z analizą wpływu na biznes BIA oraz analizą ryzyka jest w stanie dostarczyć takie informacje. Na takiej architekturze opiera się platforma SecureVisio, w której zarządzanie podatnościami jest zintegrowane z pozostałymi modułami, działającymi jako jedno narzędzie dostępne ze wspólnej konsoli. 

SecureVisio konsoliduje dane o zasobach dzięki dwukierunkowej integracji między modułami CMDB i zarządzania podatnościami. Każdy zasób może mieć informacje o właścicielu, poziomie krytyczności i powiązanych procesach biznesowych, które obsługuje, a system automatycznie dopasowuje informacje techniczne pochodzące ze skanu podatności do konkretnych zasobów. CMDB pełni tu funkcję mapy logicznej infrastruktury, pokazującej połączenia między zasobami. Kolejną warstwę dokłada BIA, która wskazuje konsekwencje, czyli to, co organizacja traci w razie naruszenia bezpieczeństwa danego zasobu. Moduł analizy ryzyka wykorzystuje te informacje i ocenia prawdopodobieństwo wystąpienia określonych ataków na konkretne zasoby oraz przedstawia ich skutki. 

W praktyce kontekst zasobu obejmuje atrybuty, które system zestawia z konkretnymi podatnościami. Są to m.in.: 

• lokalizacja i ekspozycja zasobu, np. obecność w strefie DMZ, 

• adresacja IP, 

• klasyfikacja zasobu, np. czy jest stacją roboczą, czy serwerem testowym lub produkcyjnym, czy jest to baza danych, 

• krytyczność zasobu, 

• powiązane procesy biznesowe, 

• autoryzowana komunikacja, np. informacja, że w ramach jednego z procesów biznesowych zasób jest wystawiony do Internetu. 

Na tę warstwę kontekstu jest nakładana ocena CVSS oraz dane z raportu podatności, co pozwala łączyć informacje techniczne z wiedzą organizacyjną. Dzięki spójności platformy zależność działa w dwie strony. Informacje o podatności wzbogacają dane w CMDB, a dane kontekstowe modyfikują priorytety w module zarządzania podatnościami. Analiza ryzyka działa w obie strony: jej wyniki wpływają na priorytety podatności, a dane o podatnościach wzbogacają samą analizę. Moduły SIEM, SOAR, UEBA również mogą brać udział w budowaniu kontekstu i jego wykorzystywaniu. 

Efektem takiego podejścia jest zamiana abstrakcyjnej oceny dotkliwości podatności na informację, która ma znaczenie operacyjne, np. dana podatność dotyczy systemu obsługującego rozliczenia z klientami, który jest pozbawiony dodatkowej warstwy ochronnej. Taki opis pozwala realnie ustalić kolejność prac naprawczych. 

Formuła priorytetyzacji w SecureVisio 

Mechanizm przeliczania kontekstu na priorytet w SecureVisio jest prosty: ocena dotkliwości zwracana przez raport ze skanera podatności jest mnożona przez priorytet wewnętrzny i modyfikowana za pomocą wbudowanych reguł priorytetyzacji podatności. Wynikiem jest ocena odzwierciedlająca rzeczywiste znaczenie danej podatności dla konkretnej organizacji. Można to zapisać jako wzór: 

dotkliwość ze skanera × priorytet wewnętrzny × wbudowane reguły priorytetyzacji = realny priorytet  

Każdy z tych trzech czynników odpowiada za inne elementy oceny i wnosi inny kontekst do całości. 

Dotkliwość ze skanera to dobrze opisany w tym artykule Base Score. System nie odrzuca tej oceny, ponieważ niesie ona istotną treść techniczną o samej podatności i stanowi punkt wyjścia do dalszych wyliczeń. 

Priorytet wewnętrzny dodaje kontekst zasobu i biznesu, pochodzi z CMDB, BIA i analizy ryzyka. Odpowiada na pytania, których skaner nie może zweryfikować: jaka jest krytyczność zasobu, jak krytyczne procesy biznesowe są na nim realizowane, od jakich systemów zależy. To właśnie te czynniki najmocniej pozwalają odróżnić pozornie identyczne podatności. 

Wbudowane reguły priorytetyzacji to warunki, które sprawdzają informacje o zasobie zebrane w różnych modułach systemu. Nie wszystkie działają w tę samą stronę: część reguł podnosi priorytet, część go obniża, zależnie od warunku zaszytego w danej regule. To na tym etapie do oceny wchodzi osiągalność zasobu i realna możliwość wykorzystania luki, czego sam Base Score nie widzi. Priorytet w górę podnoszą np.: wystawienie zasobu do Internetu lub umieszczenie w strefie DMZ, brak mechanizmu kompensującego (np. WAF przed usługą) czy powiązane z zasobem wskaźniki kompromitacji (IoC). W dół działają warunki przeciwne, np.: pełna izolacja zasobu, skuteczne zabezpieczenia kompensujące albo niska krytyczność przetwarzanych danych. Dzięki temu ta sama podatność dostaje różny priorytet nie tylko ze względu na wartość zasobu, ale też ze względu na to, jak realnie jest on osiągalny dla atakującego. 

Zestaw reguł nie jest zamknięty. SecureVisio pozwala tworzyć własne reguły priorytetyzacji oraz modyfikować te domyślne. Dzięki temu można odwzorować politykę zarządzania podatnościami i ryzykami danej organizacji. Silnik korelacyjny łączy te wszystkie czynniki w czasie rzeczywistym w jeden werdykt, zdejmując z analityków konieczność ręcznego przeglądania wielu parametrów dla każdej z setek czy nawet tysięcy podatności. W efekcie lista podatności jest porządkowana według ich znaczenia dla organizacji, a nie według dotkliwości technicznej w oderwaniu od środowiska. 

Przykład: ta sama podatność na dwóch zasobach 

Działanie formuły najlepiej zaprezentować na jednej podatności, która występuje na dwóch różnych zasobach. Wartości poniżej mają charakter ilustracyjny, ponieważ dokładna skala ocen zależy od konfiguracji organizacji, jednak mechanika pozostaje bez zmian. 

Podatność krytyczna CVE-2026-33824 (https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-33824) ocena 9,8 umożliwia zdalne wykonanie kodu na podatnej maszynie. Skaner podatności wykrył ją na dwóch serwerach. 

Serwer A: 

PRD-DB-01 to produkcyjna baza danych wystawiona na zewnątrz w DMZ, która pracuje na danych osobowych. Wszystkie te informacje są dostępne w SecureVisio, co widać na zrzucie ekranu poniżej. 

Rysunek 1. Kontekst zasobu PRD-DB-01 dostępny w SecureVisio 

Serwer B: 

TST-DB-01 to testowa baza danych, dostępna tylko w ramach sieci lokalnej, bez dostępu do Internetu, bez danych produkcyjnych i bez połączeń do systemów produkcyjnych. Wszystkie te informacje są dostępne w SecureVisio, co widać na zrzucie ekranu poniżej. 

Rysunek 2. Kontekst zasobu TST-DB-01 dostępny w SecureVisio 

Oba przypadki posiadają krytyczny Base Score, jednak priorytet uwzględniający kontekst organizacji rozróżnia te podatności znacząco. Jest to widoczne na poniższym zrzucie ekranu. Na serwerze produkcyjnym podatność jest oznaczona jako krytyczna (kolor czerwony), a na testowym tylko średnia (kolor żółty), dzięki czemu zespół zajmujący się podatnościami od razu po ich wykryciu wie, którą powinien zająć się w pierwszej kolejności. Gdyby pozostali przy standardowym podejściu opartym tylko na CVSS, to ta decyzja nie byłaby taka prosta. Przy skali liczonej w setkach czy tysiącach podatności ta różnica przekłada się bezpośrednio na skuteczność całego procesu. Podatność na serwerze testowym, z priorytetem średnim, trafi do środkowej części listy wszystkich podatności, dzięki czemu jej obsługa nie przesłoni luk bardziej krytycznych w kontekście organizacji. 

Rysunek 3. Priorytety podatności w SecureVisio 

Warunek skuteczności: jakość danych o zasobach 

Priorytetyzacja oparta na kontekście jest uzależniona od danych, które ją zasilają. Jeśli baza CMDB jest niekompletna lub nieaktualna, analiza ryzyka oraz wpływu na biznes nie została przeprowadzona, to wynik końcowy nie będzie znacząco różnił się od CVSS. Wartość tego podejścia rośnie wraz z jakością informacji o zasobach. 

Wdrożenie takiego modelu oceny podatności nie wymaga jednorazowej rewolucji. Polega ono na przeniesieniu decyzji z poziomu pojedynczej oceny technicznej na poziom całego procesu. W praktyce sprowadza się do kilku obszarów: 

• Inwentaryzacja i klasyfikacja zasobów. Zasobom należy przypisać właścicieli, poziom krytyczności oraz obsługiwane procesy biznesowe. Warto zacząć od tych najbardziej kluczowych dla organizacji. 

• Powiązanie inwentarza z wynikami skanów. Zapewnienie swobodnego przepływu informacji między raportami ze skanerów a bazą CMDB. Dwukierunkowa integracja CMDB z modułem zarządzania podatnościami sprawia, że każda luka jest od razu przypisana do zasobu wraz z jego kontekstem. 

• Dostosowanie reguł priorytetyzacji. Przełożenie wiedzy eksperckiej zespołu na powtarzalny mechanizm. Reguły domyślne stanowią dobry punkt startowy, ale to reguły odzwierciedlające specyfikę organizacji, dotyczące ekspozycji w DMZ, wymaganej obecności WAF czy klas danych, najlepiej oddają jej realne ryzyko.  

• Domknięcie procesu remediacji. Priorytet bez przypisanego właściciela i pomiaru czasu naprawy pozostaje jedynie oceną. Skierowanie najwyżej priorytetowych podatności do konkretnych osób i monitorowanie postępu sprawia, że lepsza priorytetyzacja przekłada się na realne obniżenie ryzyka. 

Im więcej z tych elementów działa w ramach jednej platformy, na wspólnym modelu zasobów, tym niższy jest koszt utrzymania całości i mniejsze ryzyko, że kontekst zdezaktualizuje się między osobnymi narzędziami. Architektura platformy SecureVisio umożliwia realizację wszystkich tych obszarów w jednym wspólnym punkcie. Dodatkowo sprzężenie tego z modułem SIEM/UEBA (które również wchodzą w skład SecureVisio) pozwala wprowadzić wiele automatyzacji. Kontekst CMDB może być budowany w oparciu o logi zbierane przez SIEM, dedykowane reguły korelacyjne potrafią wykryć takie rzeczy jak: rodzaj zasobu, uruchomione serwisy, pełnioną rolę, np. DNS, kontroler domeny, lokalizację użytkowników łączących się z usługami, zastosowane zabezpieczenia itp. Uproszczenie i przyspieszenie inwentaryzacji to nie jedyny plus, jaki wynika z tego podejścia. Budowa kontekstu opartego na realnych danych, czyli w tym przypadku na logach środowiskowych, znacząco zwiększa wiarygodność tych informacji. Przyjrzyjmy się takiej sytuacji. Pół roku temu na serwerze został wdrożony host firewall, ta informacja trafiła do inwentaryzacji i do dziś jest wykorzystywana przy ocenie ryzyk. Jednak miesiąc temu były prowadzone prace na tym zasobie i ten firewall blokował potrzebny ruch, więc został wyłączony. Po pracach nikt go nie uruchomił ponownie. Ocena podatności jest wykonywana na realnym, ale nieaktualnym kontekście, a w przypadku, gdy informacje o zabezpieczeniach czerpie się bezpośrednio z systemu (logi), SecureVisio wykryje, że host firewall nie jest już aktywny i nie będzie on już obniżał priorytetów wykrytych podatności. 

Podsumowanie 

CVSS pozostaje wartościową miarą dotkliwości technicznej, ale nie odpowiada na pytanie, które zadaje sobie zespół nad listą tysięcy luk: co naprawić najpierw. Base Score jest uniwersalny, identyczny dla produkcyjnej bazy w DMZ i dla maszyny testowej, więc nie różnicuje podatności według ich znaczenia dla organizacji. 

Robi to dopiero kontekst zasobu: wiedza o tym, co dana luka naraża, jaki proces obsługuje i jak jest chroniona. SecureVisio przelicza go na priorytet, mnożąc dotkliwość ze skanera przez priorytet wewnętrzny (z CMDB, BIA i analizy ryzyka) i korygując wbudowanymi regułami. Dzięki temu ta sama CVE-2026-33824 dostaje priorytet zależny od tego, gdzie występuje, a lista napraw odzwierciedla ryzyko biznesowe, a nie ranking techniczny. 

Całość działa na tyle, na ile aktualne są dane o zasobach. Dlatego warto zacząć od najważniejszych systemów i tam, gdzie to możliwe, budować kontekst z realnych danych (logi SIEM/UEBA), które utrzymują go w zgodzie ze stanem faktycznym.