Skanowanie podatności a testy penetracyjne: czym się różnią

19 sierpnia 2026

Najważniejsze w skrócie

Skaner pewnie znajduje znane podatności z bazy CVE i błędną konfigurację, a błędów logiki biznesowej nie znajdzie nigdy
W większości trafień podatność jest wywnioskowana z numeru wersji, a nie potwierdzona – stąd fałszywe alarmy
Ocena bazowa CVSS opisuje podatność, a nie ryzyko w konkretnym środowisku
Skan dowodzi, że port jest otwarty; test dowodzi, dokąd atakujący przez niego dojdzie
Ustawa o KSC wymienia testowanie systemu informacyjnego wprost w art. 8 ust. 1 pkt 2 lit. b

Skan kosztuje ułamek ceny testu penetracyjnego i kończy się gotową listą podatności. Pytanie, które pada w połowie rozmów handlowych, brzmi więc zupełnie rozsądnie: po co dopłacać za człowieka, skoro narzędzie już wszystko znalazło? Rzecz nie w tym, że skaner jest zły. Skaner robi swoje bardzo dobrze – po prostu odpowiada na inne pytanie niż to, które zadaje zarząd po incydencie.

Poniżej rozkładamy na części cztery usługi, które polscy dostawcy sprzedają pod myląco podobnymi nazwami, a potem pokazujemy, gdzie dokładnie kończą się możliwości narzędzia: co skaner znajduje pewnie, czego nie znajdzie strukturalnie, skąd biorą się fałszywe alarmy, jak czytać ocenę CVSS i jak zestawić skan z testem w jeden program.

Cztery usługi, jedna półka

W polskich ofertach krążą obok siebie audyt informatyczny, audyt bezpieczeństwa IT, test penetracyjny i skanowanie podatności. Nazwy się zazębiają, ceny różnią się kilkukrotnie, a kupujący porównuje pozycje, które mierzą zupełnie co innego.

Usługa	Odpowiada na pytanie	Jak powstaje wynik	Co dostajesz
Audyt informatyczny	Czy IT jest zarządzane tak, jak deklarujemy?	Wywiady, przegląd procedur, umów, licencji i dokumentacji	Ocena stanu organizacji IT i lista rozbieżności wobec przyjętych zasad
Audyt bezpieczeństwa IT	Czy zabezpieczenia odpowiadają wymaganiom normy albo przepisu?	Przegląd polityk, konfiguracji i dowodów, zwykle wobec normy ISO/IEC 27001 lub przepisów	Lista niezgodności wraz z rekomendacjami i planem naprawczym
Skanowanie podatności	Co jest nieaktualne albo źle skonfigurowane?	Narzędzie automatyczne, powtarzalne dowolnie często	Surowa lista trafień z numerami CVE i oceną CVSS
Test penetracyjny	Co da się wykorzystać i jak daleko zajdzie atakujący?	Praca ręczna pentestera, narzędzia tylko wspierają	Potwierdzone podatności z dowodem, opisem kroków i priorytetami

Te cztery pozycje się uzupełniają, a nie zastępują. Audyt patrzy na procesy i dokumenty, skan na wersje, test na skutki. Kto ma tylko audyt, ma opisany system zarządzania i nietknięte systemy. Kto ma tylko skan, ma długą listę bez priorytetów. Kto testuje raz do roku i nic pomiędzy, przegapi podatności opublikowane przez pozostałych jedenaście miesięcy.

Rozróżnienie ma też stronę handlową. W części cenników „audyt bezpieczeństwa” oznacza w praktyce skan z logo dostawcy na okładce. Trzy pytania rozstrzygają, co naprawdę kupujesz: jaki jest udział pracy manualnej, czy ktoś weryfikuje trafienia z narzędzia i czy w cenie jest retest po wdrożeniu poprawek. Jeśli oferta nie odpowiada na żadne z nich, opisuje skan. Jak wygląda pełny audyt bezpieczeństwa IT, opisaliśmy osobno.

Jak działa skaner podatności

Przebieg jest w każdym narzędziu – Nessus, OpenVAS, Nuclei i reszta – zasadniczo taki sam:

Wykrycie. Które hosty odpowiadają, które porty są otwarte, jakie usługi za nimi stoją.
Rozpoznanie usługi. Jakie oprogramowanie i w jakiej wersji obsługuje każdy port. Na tym kroku opiera się wszystko dalsze i to on najczęściej myli się jako pierwszy.
Porównanie. Rozpoznana wersja trafia do zestawienia z bazą opublikowanych podatności, oznaczonych numerami CVE.
Ocena. Każde trafienie dostaje poziom istotności, najczęściej ocenę bazową CVSS wprost z wpisu CVE.

Rozstrzyga trzeci krok. W większości trafień podatność jest wywnioskowana z numeru wersji, a nie potwierdzona. Skaner widzi „nginx 1.18.0”, znajduje pasujący wpis CVE i zgłasza trafienie. Tego, czy w Twojej konfiguracji podatna ścieżka jest w ogóle osiągalna, narzędzie już nie sprawdza.

Co skaner robi naprawdę dobrze

Mimo tego ograniczenia skaner jest w swoim obszarze bezkonkurencyjny, a obszar wcale nie jest wąski:

Ciągłość. Nowych wpisów CVE przybywa codziennie. System czysty w piątek może w poniedziałek mieć krytyczną podatność, choć nikt niczego w nim nie zmienił. Wyłapuje to tylko regularny skan.
Pokrycie. Setki hostów w kilka godzin. Ręcznie nikt tego nie przejdzie, a próba kończy się pominięciami.
Koszt jednostkowy. Skan jest tani i powtarzalny, więc można go uruchamiać co tydzień zamiast raz w roku.
Zarządzanie podatnościami. Porównanie z poprzednim przebiegiem pokazuje różnicę: co przybyło, co zniknęło, co wisi nienaprawione od kwartału. Bez tego nie da się prowadzić żadnego procesu naprawczego.
Wspólny język. Numer CVE i ocena CVSS pozwalają rozmawiać z dostawcą oprogramowania, z zespołem i z audytorem o tym samym obiekcie.

Skaner wyłapie pewnie przede wszystkim nieaktualne komponenty ze znanymi wpisami CVE, błędną konfigurację o wyraźnej sygnaturze (otwarte panele administracyjne, domyślne hasła, listowanie katalogów, włączony tryb debugowania), słabą konfigurację TLS i wygasłe certyfikaty, brakujące nagłówki bezpieczeństwa oraz odchylenia od stanu z poprzedniego skanu.

To praca, której człowiek robić nie powinien: jest jej dużo, jest jednostajna i ręcznie wychodzi z błędami. Dlatego nasza analiza podatności zaczyna się od skanów automatycznych. Tylko się na nich nie kończy.

Czego skaner nie znajdzie

Poniższe klasy błędów nie są dla narzędzia trudne. Są dla niego strukturalnie niedostępne, bo narzędzie nie wie, co w danej aplikacji ma być dozwolone:

Błędna autoryzacja. Użytkownik A widzi zamówienia użytkownika B. Dla skanera to poprawna odpowiedź z kodem 200. Nie ma pojęcia, do kogo powinien należeć rekord.
Błędy logiki biznesowej. Kod rabatowy do wielokrotnego użycia. Krok koszyka, który da się pominąć. Ujemna kwota księgowana jako uznanie na koncie klienta.
Łańcuchy błędów. Niegroźny wyciek informacji plus słaba procedura resetu hasła plus zapomniane konto testowe dają razem przejęcie konta administratora. Skaner zgłosi trzy drobiazgi o niskim priorytecie w trzech miejscach raportu i nie zobaczy związku między nimi.
Obejście uwierzytelniania wieloskładnikowego boczną drogą, na przykład przez API, które drugiego składnika nie wymaga.
Nadmiarowe dane w odpowiedzi. Endpoint zwraca więcej pól, niż pokazuje interfejs. Technicznie wszystko działa poprawnie, a w praktyce jest to wyciek danych osobowych.

Wszystkie te klasy opisuje metodyka OWASP, a żadnej z nich nie wykryje porównanie numerów wersji.

Fałszywe alarmy i skąd się biorą

Najczęstszy przypadek w praktyce to poprawki przenoszone wstecz (ang. backporting). Debian, Red Hat i inne dystrybucje wprowadzają poprawkę bezpieczeństwa do swojej wersji pakietu, nie podnosząc numeru wersji zgłaszanego przez aplikację. Dziura jest zamknięta, a skaner zgłasza ją mimo to, bo zna wyłącznie numer.

Do tego dochodzą:

Kod nieosiągalny. Podatna funkcja jest w bibliotece, ale aplikacja nigdy jej nie wywołuje.
Środki kompensujące. Firewall aplikacyjny, segmentacja sieci albo uwierzytelnianie przed usługą sprawiają, że droga ataku w praktyce nie działa.
Błędne rozpoznanie. Reverse proxy albo celowo podmieniony baner prowadzą narzędzie do zupełnie nietrafionego dopasowania.

Dlatego etap, który zamienia wydruk z narzędzia w analizę, wygląda zawsze tak samo: każde poważne trafienie sprawdzamy ręcznie, resztę oznaczamy jako szum i piszemy, dlaczego. Lista bez tego kroku potrafi zająć zespół na tygodnie sprawami bez znaczenia, a przy okazji nauczyć go, że raporty można ignorować – a to kosztuje więcej niż same tygodnie.

Jak czytać ocenę CVSS

Ocenę CVSS czyta się odruchowo jako poziom ryzyka. Nie jest nim. Opisuje samą podatność w standardowych założeniach, bez wiedzy o środowisku, w którym ta podatność występuje.

Ocena bazowa 9,8 znaczy tyle: podatność da się wykorzystać przez sieć, bez danych uwierzytelniających, z pełnym wpływem na poufność, integralność i dostępność – jeżeli system jest tak dostępny, jak zakłada ocena. Cztery pytania przekładają liczbę na Twoje realne priorytety:

Pytanie	Podnosi priorytet	Obniża priorytet
Jak dostępny jest system?	wystawiony do internetu	sieć wewnętrzna, VPN, odcięty segment
Czy istnieje publiczny exploit?	działający kod dostępny, wykorzystywany w atakach	opisana wyłącznie teoria
Co jest na tym systemie?	dane klientów, dane płatnicze, poświadczenia	dane testowe bez danych osobowych
Co stoi przed nim?	usługa wystawiona bezpośrednio	firewall aplikacyjny, uwierzytelnianie, segmentacja

W praktyce podatność z oceną 6,5 w portalu klienta jest niemal zawsze pilniejsza niż 9,8 na zamkniętym systemie testowym. Ustawienie tej kolejności to właśnie priorytetyzacja podatności i to ona układa kolejkę naprawczą na najbliższy kwartał.

Otwarty port a realne wejście

Skan kończy się stwierdzeniem faktu: port jest otwarty, usługa ma nieaktualną wersję, ocena 8,1, obok numer CVE. Test penetracyjny zaczyna się dokładnie w tym miejscu i pyta, co za tym portem stoi.

W praktyce taki łańcuch wygląda tak: zapomniany panel administracyjny wystawiony do internetu, w nim konto z hasłem z dokumentacji wdrożeniowej, z panelu odczyt konfiguracji z poświadczeniami konta serwisowego, tym kontem dostęp do udziału sieciowego z kopiami zapasowymi, a w kopiach skróty haseł kont uprzywilejowanych. Cztery drobiazgi w łańcuchu, na końcu przejęcie domeny.

Skaner zgłosiłby tu trzy trafienia o średnim priorytecie, rozrzucone po trzech sekcjach raportu, i żadne z nich nie brzmiałoby pilnie. Pentester zgłasza jedno znalezisko: przejęcie domeny, z opisem kroków, dowodem i wskazaniem, które ogniwo zerwać najtaniej. Cała różnica mieści się w jednym zdaniu: skan dowodzi, że port jest otwarty, a test dowodzi, dokąd atakujący przez niego dojdzie.

Stąd też bierze się różnica w cenie. Skan jest tańszy, bo odpowiada na prostsze pytanie i robi to maszyna. Co dokładnie wpływa na wycenę samego testu, rozłożyliśmy w tekście o tym, ile kosztuje test penetracyjny. Definicje i przebieg prac opisuje z kolei artykuł o tym, co to jest test penetracyjny.

Skanowanie, testy i ustawa o KSC

Od 3 kwietnia 2026 r. część organizacji ma w tej sprawie termin ustawowy, a nie wyłącznie zdrowy rozsądek. Ustawa z 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa (Dz.U. 2026 poz. 252) to polskie wdrożenie dyrektywy NIS2. Dzieli objęte nią organizacje na podmioty kluczowe (załącznik nr 1) i podmioty ważne (załącznik nr 2), a kalendarz jest rozpisany: wpis do wykazu do 3 października 2026 r., obowiązki z rozdziału 3 wraz z podłączeniem do systemu S46 do 3 kwietnia 2027 r., pierwszy audyt i pierwsze kary pieniężne od 3 kwietnia 2028 r.

Ustawa nie mówi ani o skanowaniu, ani o teście penetracyjnym. Mówi o testowaniu. Art. 8 ust. 1 pkt 2 lit. b wymaga, żeby system zarządzania bezpieczeństwem informacji obejmował bezpieczeństwo w procesie nabywania, rozwoju, utrzymania i eksploatacji systemu informacyjnego, „w tym testowanie systemu informacyjnego”. Bieżący skan jest dowodem na to, że proces działa. Dowodem na skuteczność zabezpieczeń jest dopiero test, bo tylko on pokazuje skutek, a nie samą listę.

Co dostarczamy do audytu z art. 15

Art. 15 ust. 1 nakłada na podmiot kluczowy obowiązek przeprowadzenia audytu bezpieczeństwa systemu informacyjnego na własny koszt, co najmniej raz na trzy lata. Audyt prowadzi akredytowana jednostka oceniająca zgodność, sektorowy zespół CSIRT albo co najmniej dwóch audytorów z certyfikatami z listy Ministra Cyfryzacji – CISA, CISM, CRISC, CISSP, CIA, audytor wiodący ISO/IEC 27001 lub ISO 22301, ISA/IEC 62443 Cybersecurity Expert.

Audytor nie włamuje się do systemu – sprawdza, czy organizacja testuje swoje systemy, czy robi to regularnie i czy wyciąga z wyników wnioski. Pyta więc o dowody, a te dowody wytwarzamy my: przeprowadzone testy, potwierdzone podatności z opisem kroków, ocenę ryzyka, listę działań naprawczych i pisemne potwierdzenie z retestu, że poprawki działają. Tego właśnie dotyczy wymóg testowania systemu informacyjnego z art. 8 ust. 1 pkt 2 lit. b, a nasz zespół ma certyfikaty klasy OSCP i robi te testy ręcznie, a nie jednym przebiegiem skanera.

Sektor publiczny ma obowiązek starszy i częstszy: § 19 ust. 2 pkt 14 rozporządzenia w sprawie Krajowych Ram Interoperacyjności (Dz.U. 2024 poz. 773) nakazuje jednostkom realizującym zadania publiczne coroczny audyt bezpieczeństwa informacji. Osobna podstawa to art. 32 ust. 1 lit. d RODO – Prezes UODO nakładał kary, wskazując w uzasadnieniu brak regularnego testowania skuteczności zabezpieczeń, tak jak w decyzji dotyczącej Morele.net (DKN.5130.2484.2019). Szerzej piszemy o tym na stronie testów penetracyjnych zgodnych z NIS2 i ustawą o KSC.

Ten materiał ma charakter informacyjny i nie jest poradą prawną. Zakres obowiązków zależy od sektora, wielkości organizacji i roli w łańcuchu dostaw – w razie wątpliwości warto zweryfikować go z radcą prawnym.

Jak to poskładać w jeden program

Układ, który sprawdza się w średniej wielkości organizacji, ma cztery elementy:

Skanuj na bieżąco. Zasoby wystawione do internetu raz w tygodniu, sieć wewnętrzną raz w miesiącu, a poza tym po każdej istotnej zmianie.
Weryfikuj raz na kwartał. Człowiek przechodzi poważne trafienia, odsiewa fałszywe alarmy i układa listę według realnego priorytetu. To jest właściwa analiza podatności, a nie sam wydruk z narzędzia.
Testuj raz w roku i po dużych zmianach. Test penetracyjny pokrywa klasy błędów, których nie znajdzie żadne narzędzie, i wytwarza dowód, którego szuka audytor.
Sprawdzaj poprawki. Bez retestu masz udokumentowany problem, a nie udokumentowane rozwiązanie.

Skan i test nie konkurują o ten sam budżet, bo pilnują różnych rzeczy: skan pilnuje, żeby nic nie gniło po cichu między testami, a test pilnuje, żeby lista z narzędzia nie była całą wiedzą o własnych systemach. Firma, która robi jedno i odpuszcza drugie, płaci za połowę odpowiedzi.

Skanowanie podatności – najczęstsze pytania

Czym różni się test penetracyjny od skanowania podatności?

Skanowanie odpowiada na pytanie, co jest nieaktualne albo źle skonfigurowane. Test penetracyjny odpowiada na pytanie, co z tego da się wykorzystać i jak daleko zajdzie atakujący. Skan to wynik działania narzędzia: podatność jest w nim najczęściej wywnioskowana z numeru wersji, a nie potwierdzona. Test to w dużej części praca ręczna, w której pentester weryfikuje trafienia, łączy pojedyncze błędy w łańcuch i dokłada błędy logiki biznesowej, których żaden skaner nie opisze. W skrócie: skan dowodzi, że port jest otwarty, test dowodzi, dokąd atakujący przez niego dojdzie.

Czym jest skanowanie podatności?

Skanowanie podatności to automatyczne porównanie systemów z bazą znanych błędów bezpieczeństwa. Narzędzie wykrywa działające usługi i ich wersje, zestawia je z opublikowanymi wpisami CVE i zwraca listę trafień z oceną CVSS. Trwa godziny, a nie dni, można je powtarzać dowolnie często i jest podstawą bieżącego zarządzania podatnościami. Testu penetracyjnego jednak nie zastępuje.

Czy po teście system jest już bezpieczny?

Nie. Raport opisuje stan konkretnego zakresu w konkretnym tygodniu. Nowe wpisy CVE pojawiają się codziennie, kod się zmienia, dochodzą kolejne integracje, więc system czysty w piątek potrafi mieć krytyczną podatność w poniedziałek, choć nikt niczego w nim nie ruszył. Bezpieczeństwo daje dopiero cykl: bieżące skanowanie, naprawa, retest poprawek i kolejny test po każdej istotnej zmianie. Dostawca, który po teście obiecuje bezpieczny system, obiecuje coś, czego nie da się zagwarantować.

Jak często wykonywać skanowanie podatności?

Dla zasobów wystawionych do internetu rozsądny takt to raz w tygodniu, dla sieci wewnętrznej raz w miesiącu, a poza tym zawsze po istotnej zmianie: wdrożeniu, migracji, przebudowie uwierzytelniania. Powodem nie jest to, że systemy zmieniają się aż tak szybko, tylko to, że codziennie publikowane są nowe podatności w komponentach, które już masz u siebie.

Czy CVSS 9,8 zawsze oznacza ryzyko krytyczne?

Nie. Ocena bazowa CVSS opisuje samą podatność w standardowych założeniach, a nie środowisko, w którym ta podatność występuje. Ta sama dziura z oceną 9,8 na serwerze wystawionym do internetu bywa faktycznie krytyczna, a na odciętym systemie testowym bez danych praktycznie nieistotna. O realnym priorytecie decydują dostępność systemu, istniejące środki kompensujące, wrażliwość danych i to, czy publicznie krąży działający exploit.

Czy skanowanie podatności wystarczy do zgodności z ustawą o KSC?

Do bieżącego zarządzania podatnościami skan jest podstawą, ale ustawa mówi o czymś szerszym. Art. 8 ust. 1 pkt 2 lit. b nowelizacji ustawy o krajowym systemie cyberbezpieczeństwa wymaga, żeby system zarządzania bezpieczeństwem informacji obejmował bezpieczeństwo w procesie nabywania, rozwoju, utrzymania i eksploatacji systemu informacyjnego, w tym testowanie systemu informacyjnego. Osobnym obowiązkiem jest audyt z art. 15 ust. 1, który podmiot kluczowy zleca na własny koszt co najmniej raz na trzy lata akredytowanej jednostce oceniającej zgodność, sektorowemu zespołowi CSIRT albo co najmniej dwóm audytorom z listy Ministra Cyfryzacji. Do tego audytu dostarczamy dowody z testów: potwierdzone podatności z opisem kroków, ocenę ryzyka, listę działań naprawczych i pisemne potwierdzenie z retestu. Ten materiał nie jest poradą prawną.

Menu