Testy penetracyjne w 2026 r.: zakres, metodyka, TLPT i jak odróżnić pentest od skanowania

Pentest, skan podatności, red team, purple team i TLPT

Pojęcia te opisują różne rodzaje badań.

Skanowanie podatności jest w dużej mierze zautomatyzowanym wykrywaniem znanych słabości i błędów konfiguracji. Jest powtarzalne i może działać często, ale nie zastępuje ręcznej analizy logiki, łączenia kilku słabości ani oceny skutku biznesowego.

Pentest ma zdefiniowany cel i zakres, na przykład aplikację internetową, infrastrukturę zewnętrzną, Active Directory, sieć wewnętrzną albo aplikację mobilną. Tester wykorzystuje narzędzia automatyczne, ale kluczowe decyzje dotyczące hipotezy ataku, walidacji, eksploatacji i dalszego ruchu są wykonywane ręcznie. OWASP WSTG określa test bezpieczeństwa aplikacji jako aktywną analizę słabości, wad technicznych i podatności, a wykryte problemy powinny być przedstawione właścicielowi wraz z oceną wpływu i propozycją ograniczenia ryzyka.^[8]

Red team bada szerszą zdolność organizacji do wykrywania i reagowania na przeciwnika. Może obejmować techniki wykraczające poza klasyczny pentest, na przykład socjotechnikę, działania w chmurze, wykorzystanie relacji zaufania albo dostęp fizyczny, ale wyłącznie wtedy, gdy zostały jawnie objęte autoryzacją. Zespół obronny może nie znać szczegółów ćwiczenia, ponieważ jednym z celów jest pomiar wykrywalności i reakcji.

Purple team nie jest po prostu "łagodniejszym red teamem". To model współpracy zespołu ofensywnego i obronnego, w którym techniki są wykonywane i od razu porównywane z telemetrią, regułami detekcji oraz reakcją. Aktualny TIBER-EU przewiduje replay i ćwiczenie purple teaming w fazie zamknięcia testu.^[5]

TLPT, czyli threat-led penetration testing, jest regulowanym testem opartym na rozpoznaniu zagrożeń dla konkretnej instytucji. W sektorze finansowym podstawą prawną jest DORA, a szczegółowe kryteria, fazy, wymagania wobec testerów, zakres raportowania i współpracę z organami określa rozporządzenie delegowane (UE) 2025/1190.^[3][4] W 2025 r. EBC zaktualizował TIBER-EU, aby dopasować go do DORA i tego rozporządzenia. Posługiwanie się wyłącznie wersją TIBER-EU z 2018 r. jest więc w 2026 r. nieaktualne.^[5]

Nie istnieje jedna uniwersalna kolejność "pentest co roku, red team co trzy lata" odpowiednia dla wszystkich organizacji. Częstotliwość i głębokość badań powinny wynikać z ryzyka, tempa zmian, krytyczności usług, wymagań prawnych i dojrzałości monitoringu. Red team nie ma dużej wartości, jeśli organizacja nie dysponuje telemetrią i procedurami, których skuteczność miałby sprawdzić.

Najpierw zakres i reguły zaangażowania

Profesjonalny test zaczyna się przed pierwszym pakietem wysłanym do badanego systemu. Strony powinny uzgodnić co najmniej:

• cel testu i decyzje, które ma wspierać;
• dokładny zakres techniczny, w tym domeny, adresy, aplikacje, segmenty, tenanty chmurowe i konta testowe;
• elementy wyłączone z testu;
• model dostępu: black box, gray box lub white box;
• działania dozwolone i zabronione, w szczególności phishing, trwałość, ruch boczny, eksfiltrację kontrolną, testy DoS i dostęp fizyczny;
• dopuszczalne godziny i limity obciążenia;
• kontakty awaryjne i warunki natychmiastowego przerwania testu;
• sposób postępowania z danymi, sekretami, tokenami, kopiami plików i dowodami;
• zasady usuwania artefaktów po teście;
• sposób zgłaszania znalezisk krytycznych jeszcze w trakcie badania;
• zakres retestu i kryteria zamknięcia ustaleń.

NIST SP 800-115 i CREST traktują planowanie oraz uzgodnienie badania jako część procesu testowego, a nie formalność administracyjną.^[6][7] W testach regulowanych poziom formalizacji jest jeszcze wyższy. Aktualny TIBER-EU wymaga między innymi określenia funkcji krytycznych lub ważnych, systemów i usług objętych testem oraz zatwierdzenia zakresu przez kierownictwo podmiotu.^[5]

Black box, gray box i white box

Black box oznacza minimalną wiedzę przekazaną testerowi. Model dobrze pokazuje zewnętrzną powierzchnię ataku i jakość publicznej ekspozycji, ale część czasu jest zużywana na rozpoznanie informacji, które klient już posiada. Nie daje też automatycznie pełniejszego obrazu bezpieczeństwa.

Gray box dostarcza testerowi ograniczoną wiedzę i kontrolowane konta, na przykład użytkowników o kilku rolach. W aplikacjach biznesowych zwykle pozwala znacznie skuteczniej badać autoryzację, separację tenantów i logikę procesu. Jest często najlepszym kompromisem między realizmem a pokryciem.

White box może obejmować dokumentację architektury, konfigurację, kod źródłowy i konta o podwyższonych uprawnieniach. Jego celem nie jest odwzorowanie początkowego położenia napastnika, lecz maksymalizacja szansy wykrycia słabości w ograniczonym czasie. Dla aplikacji tworzonych na zamówienie albo przeglądu mechanizmów autoryzacji może być bardziej wartościowy niż czysty black box.

Nie ma podstaw do twierdzenia, że jeden model jest zawsze "bardziej realistyczny" albo "lepszy". Model ma odpowiadać pytaniu, które stawia organizacja. Test odporności na nieznanego przeciwnika i pogłębione badanie bezpieczeństwa aplikacji to dwa różne cele.

Metodyki i dokumenty odniesienia w 2026 r.

Nie istnieje jeden globalny standard, który wyczerpująco opisuje każdy rodzaj pentestu. W praktyce korzysta się z kilku dokumentów o różnym statusie.

NIST SP 800-115 z 2008 r. jest stary, ale nadal figuruje w katalogu NIST jako publikacja finalna i aktualna. Porządkuje planowanie testów technicznych, dobór technik, analizę wyników i działania naprawcze.^[6] Nie jest polskim przepisem prawa.

OWASP Web Security Testing Guide v4.2 pozostaje 29 sierpnia 2026 r. stabilnym wydaniem WSTG. OWASP prowadzi równolegle prace nad wersją 5.0, ale sekcja "latest" jest treścią rozwijaną i może się zmieniać. W umowie lub raporcie lepiej więc wskazać konkretną wersję, zamiast pisać ogólnie "zgodnie z najnowszym OWASP".^[8]

Dla aplikacji mobilnych istotna zmiana nastąpiła 4 lipca 2026 r., kiedy OWASP opublikował stabilne MASTG v2.0.0. MASTG należy stosować razem z MASVS, ponieważ jeden dokument opisuje techniki testowania, a drugi oczekiwane właściwości bezpieczeństwa.^[9]

MITRE ATT&CK nie jest metodyką pentestu. Jest bazą wiedzy o zachowaniach przeciwników, przydatną do opisywania technik, budowania scenariuszy red team i porównywania ich z detekcjami. Na 29 sierpnia 2026 r. bieżąca wersja to ATT&CK v19.2.^[10] Raportowanie każdego znaleziska jako techniki ATT&CK nie ma sensu, jeżeli problem nie opisuje zachowania przeciwnika.

PTES może nadal służyć jako społecznościowy model procesu, szczególnie w fazie pre-engagement, ale nie jest normą ani regulacją i od lat nie ma statusu aktualnego standardu formalnego. Nie powinien być przedstawiany jako źródło obowiązku prawnego.^[20]

CREST Defensible Penetration Test i przewodniki CREST są użyteczne przy zakupie usługi, ponieważ kładą nacisk na trzy elementy: dojrzałość organizacji świadczącej usługę, kompetencje konkretnych testerów i uzgodnioną specyfikację testu.^[7] Akredytacja może być wartościowym sygnałem jakości, ale sama nie dowodzi jakości konkretnego projektu.

Jak przebiega rzetelny test

Dobry test nie zaczyna się od uruchomienia pełnego zestawu skanerów. Najpierw tester buduje model badanego środowiska i hipotezy ataku.

Rozpoznanie ustala, co jest dostępne, jakie zależności istnieją i które elementy mogą prowadzić do celu testu. W aplikacji może to oznaczać mapowanie funkcji, ról, API i przepływów danych. W sieci wewnętrznej - relacji zaufania, usług uwierzytelniania, punktów administracyjnych i segmentacji.

Weryfikacja podatności oddziela sygnał narzędzia od rzeczywistej słabości. Znalezienie wersji oprogramowania nie wystarcza, jeżeli dystrybucja zaaplikowała poprawkę bez zmiany numeru wersji, usługa jest niedostępna dla badanego wektora albo podatny komponent nie jest używany.

Eksploatacja powinna być proporcjonalna do celu. Czasem wystarczy minimalny dowód, że kontrola jest omijalna. W innym projekcie celem jest pokazanie pełnego łańcucha: od wejścia, przez eskalację uprawnień, po dostęp do uzgodnionego zasobu. Im większy potencjalny wpływ, tym bardziej szczegółowe powinny być limity i warunki przerwania testu.

Poeksploatacja nie może zmieniać pentestu w niekontrolowany incydent. Trwałość, pozyskiwanie kolejnych kont, ruch boczny, kontrolowana eksfiltracja i C2 są dopuszczalne tylko wtedy, gdy zakres je przewiduje. Każdy artefakt powinien być możliwy do zidentyfikowania i usunięcia.

Cleanup jest częścią testu. Tester powinien usunąć utworzone konta, pliki, zadania, klucze, reguły, tunele, tokeny i inne artefakty, a klient powinien mieć możliwość zweryfikowania tego stanu. Brak procedury czyszczenia jest szczególnie niebezpieczny w red teamie i TLPT.

Retest powinien sprawdzać nie tylko, czy pierwotny exploit przestał działać, lecz również czy poprawka nie utworzyła nowej ścieżki i czy została wdrożona we wszystkich objętych elementach. Samo oznaczenie zadania w systemie zgłoszeń jako "zamknięte" nie jest dowodem naprawy.

Raport: dowód zamiast listy alarmów

Raport z pentestu powinien umożliwiać odtworzenie najważniejszych ustaleń przez kompetentnego odbiorcę. Nie oznacza to publikowania sekretów w szeroko dystrybuowanym dokumencie. Dowody techniczne mogą znaleźć się w chronionym załączniku.

Dobre ustalenie zawiera:

• kryterium lub oczekiwaną właściwość bezpieczeństwa;
• stan faktyczny i warunki, w których został zaobserwowany;
• dowód;
• opis drogi wykorzystania;
• wpływ techniczny i biznesowy;
• ograniczenia wnioskowania;
• zalecenie naprawcze;
• sposób retestu.

CVSS może pomóc opisać techniczną dotkliwość podatności, ale nie powinien zastępować oceny kontekstu organizacji. W pentestach szczególnie ważne są łańcuchy ataku: kilka pozornie umiarkowanych słabości może razem prowadzić do skutku krytycznego.

Raport dla kierownictwa powinien odpowiadać na inne pytania niż załącznik techniczny. Powinien wskazać, jakie cele atakującego były osiągalne, które warstwy zabezpieczeń zawiodły, jakie decyzje są potrzebne i gdzie występują zależności między ustaleniami. Nie powinien obiecywać, że brak znalezionej ścieżki oznacza brak możliwej ścieżki.

Pentest a SOC i wykrywanie

Test ofensywny ma dodatkową wartość, gdy można zestawić jego oś czasu z logami SOC. Wtedy organizacja otrzymuje odpowiedź nie tylko na pytanie "czy dało się wejść", ale również "kiedy powinniśmy to zauważyć".

ATT&CK v19.2 może pomóc opisać wykonane zachowania i porównać je z istniejącymi detekcjami.^[10] Taka mapa nie powinna jednak zamieniać się w procent "pokrycia ATT&CK" oderwany od jakości telemetrii. Reguła przypisana do techniki, która nie ma wymaganych danych albo nigdy nie została przetestowana, nie daje realnej zdolności wykrycia.

Po red teamie szczególnie wartościowe jest wspólne odtworzenie ścieżki przez zespół ofensywny i obronny. Aktualny TIBER-EU formalizuje replay i purple teaming właśnie po to, by połączyć działania red teamu z reakcją blue teamu oraz planem naprawczym.^[5]

W 4crypto test penetracyjny traktujemy jako osobną metodę badania, uzupełniającą ciągłe skanowanie podatności, monitoring SOC, hardening i audyt bezpieczeństwa. Łączenie tych prac ma sens tylko wtedy, gdy zachowane są odrębne cele, dowody i odpowiedzialność za wnioski.

OT i ICS: aktywny test może być samym zagrożeniem

Środowiska OT wymagają innego poziomu ostrożności niż typowa sieć biurowa. NIST SP 800-82 Rev. 3 wskazuje, że testy penetracyjne w OT należy prowadzić tak, aby nie pogorszyć działania funkcji technologicznych; jako przykłady zabezpieczeń podaje testowanie na środowisku replikowanym, zwirtualizowanym lub symulowanym oraz prowadzenie testów w zaplanowanych oknach wyłączenia.^[11]

Nie wynika z tego uniwersalna zasada "w produkcji tylko pasywnie". Czasem aktywny test produkcyjny jest możliwy, ale wymaga znajomości procesu technologicznego, udziału operatora, ograniczenia technik i świadomej decyzji o ryzyku. Testowanie PLC, RTU czy urządzeń bezpieczeństwa funkcjonalnego bez wiedzy o procesie może stworzyć większe zagrożenie niż podatność, której szuka tester.

Rodzina IEC 62443 jest ważnym odniesieniem dla bezpieczeństwa systemów automatyki i sterowania, ale należy wskazywać konkretną część i wydanie, jeżeli ma być formalnym kryterium. Ogólne powołanie się na "IEC 62443" nie tworzy jednej metodyki pentestu.

Testowanie AI i LLM

Testy systemów wykorzystujących modele językowe rozszerzają klasyczny zakres bezpieczeństwa aplikacji o problemy wynikające z samego modelu i jego integracji. Do typowych klas testów należą bezpośrednie i pośrednie prompt injection, wyciek danych z kontekstu, nadużycie narzędzi udostępnionych agentowi, błędy separacji tenantów, omijanie polityk oraz wykorzystanie nieufnych treści do sterowania działaniem modelu.

Nie należy jednak twierdzić, że od 2 sierpnia 2026 r. wszystkie systemy wysokiego ryzyka muszą już spełniać art. 15 AI Act w pierwotnie planowanym terminie. Rozporządzenie (UE) 2026/1744 przesunęło stosowanie wymagań z sekcji 1-3 rozdziału III dla systemów wysokiego ryzyka: dla systemów z art. 6 ust. 2 i załącznika III na 2 grudnia 2027 r., a dla systemów z art. 6 ust. 1 i załącznika I na 2 sierpnia 2028 r.^[14][15]

Inaczej wygląda sytuacja modeli ogólnego przeznaczenia o ryzyku systemowym. Art. 55 AI Act nakłada na ich dostawców między innymi obowiązek ewaluacji modelu z użyciem odpowiednich protokołów i narzędzi, w tym prowadzenia i dokumentowania testów przeciwstawnych w celu identyfikowania i ograniczania ryzyka systemowego.^[14] Zakres podmiotowy tego przepisu jest jednak węższy niż potoczne hasło "AI Act wymaga pentestów AI".

Wymagania prawne w Polsce i UE

KSC i NIS2. NIS2 wymaga od podmiotów objętych dyrektywą stosowania proporcjonalnych środków zarządzania ryzykiem oraz polityk i procedur oceny ich skuteczności.^[2] W Polsce konkretne obowiązki wynikają przede wszystkim z obowiązującej ustawy o krajowym systemie cyberbezpieczeństwa. Po nowelizacji z 2026 r. art. 8 wymaga od podmiotów kluczowych i ważnych między innymi bezpieczeństwa w procesie nabywania, rozwoju, utrzymania i eksploatacji systemu, w tym testowania systemu informacyjnego, a także polityk i procedur oceny skuteczności środków.^[1] Ustawa nie ustanawia jednak uniwersalnego obowiązku corocznego pentestu każdej organizacji.

RODO. Art. 32 ust. 1 lit. d wymaga, stosownie do ryzyka, procesu regularnego testowania, mierzenia i oceniania skuteczności środków technicznych i organizacyjnych.^[12] Przepis nie mówi, że jedyną formą takiego testowania jest pentest, ani nie ustanawia jednej częstotliwości dla wszystkich administratorów.

DORA. Art. 24 wymaga programu testowania operacyjnej odporności cyfrowej odpowiedniego do ryzyka. TLPT jest jego zaawansowaną częścią. Zgodnie z art. 26 DORA wskazane podmioty finansowe, z wyłączeniami przewidzianymi w rozporządzeniu, przeprowadzają TLPT co najmniej raz na trzy lata, przy czym właściwy organ może dostosować częstotliwość do profilu ryzyka i okoliczności operacyjnych.^[3] Kryteria wyboru podmiotów i szczegóły procesu określa rozporządzenie delegowane (UE) 2025/1190.^[4] Nie każdy bank, ubezpieczyciel ani inny podmiot objęty DORA automatycznie wykonuje TLPT tylko dlatego, że podlega DORA.

PCI DSS. Dla podmiotów, do których ma zastosowanie PCI DSS, aktualnym wydaniem jest v4.0.1. Wymaganie 11.4 obejmuje regularne wewnętrzne i zewnętrzne testy penetracyjne, a 11.4.2 i 11.4.3 wymagają ich co najmniej raz na 12 miesięcy oraz po istotnej zmianie infrastruktury lub aplikacji.^[13] PCI DSS jest standardem branżowym, nie powszechnie obowiązującym polskim aktem prawnym.

ISO/IEC 27001. Norma może stanowić kryterium systemu zarządzania bezpieczeństwem informacji i punkt odniesienia dla programu oceny skuteczności zabezpieczeń, ale sama certyfikacja nie oznacza, że przeprowadzono konkretny pentest określonej aplikacji. Na 29 sierpnia 2026 r. aktualne pozostaje wydanie ISO/IEC 27001:2022 wraz z Amd 1:2024.^[16]

Jak wybierać wykonawcę

Nie ma jednego certyfikatu, którego posiadanie automatycznie gwarantuje dobry pentest. Przy wyborze wykonawcy warto sprawdzić:

• doświadczenie konkretnych testerów w technologii objętej badaniem;
• przykładową strukturę raportu i sposób dokumentowania dowodów;
• proces recenzji jakości;
• procedury obsługi sekretów i danych klienta;
• ubezpieczenie i odpowiedzialność kontraktową, jeśli są istotne dla projektu;
• sposób reagowania na znalezisko krytyczne w trakcie prac;
• sposób rozwiązywania konfliktów interesów;
• warunki retestu i usuwania danych po projekcie.

Niezależność należy oceniać w kontekście celu. Nie istnieje uniwersalny zakaz, zgodnie z którym dostawca IT nigdy nie może wykonać testu. Jeżeli celem jest niezależna ocena jego własnego projektu, oczywisty konflikt interesów przemawia za innym wykonawcą. W TLPT wymagania wobec zewnętrznych i wewnętrznych testerów wynikają dodatkowo z DORA oraz rozporządzenia 2025/1190.^[3][4]

Najczęstsze błędy przy zakupie testu

1. Kupowanie skanowania pod nazwą pentestu. Raport wygenerowany z narzędzia może być użyteczny w programie vulnerability management, ale nie dowodzi ręcznej walidacji, analizy logiki, łączenia słabości ani sprawdzenia skutku.
2. Zbyt szeroka obietnica przy zbyt małym budżecie. "Pentest całej infrastruktury" bez liczby aplikacji, segmentów, hostów, ról, interfejsów i ograniczeń jest hasłem, nie zakresem.
3. Sztuczne oczekiwanie określonej liczby znalezisk. Zero podatności krytycznych nie dowodzi ani wysokiego bezpieczeństwa, ani słabego testera. Znaczenie ma pokrycie zakresu, jakość dowodów, testowane hipotezy, ograniczenia i odtwarzalność badania.
4. Brak retestu. Raport opisuje stan w czasie testu. Jeżeli poprawki nie zostały zweryfikowane, organizacja wie jedynie, że zadeklarowano ich wdrożenie.
5. Brak powiązania z detekcją. Jeżeli organizacja ma SOC lub SIEM, znane działania testera są wyjątkowo dobrym materiałem do sprawdzenia, czy telemetria i reguły rzeczywiście działają.

Co pokazują dane o rzeczywistych naruszeniach

Verizon DBIR 2026 podaje, że w jego zbiorze danych wykorzystanie podatności odpowiadało za 31% znanych początkowych wektorów naruszenia, a nadużycie poświadczeń za 13%.^[19] To nie jest dowód, że każdy pentest powinien koncentrować się przede wszystkim na publicznych CVE. Jest natomiast mocnym argumentem za tym, aby nie ograniczać programu testów do phishingu ani do samej konfiguracji tożsamości.

ENISA Threat Landscape 2025 i raport CERT Polska za 2025 r. pokazują z kolei, że krajobraz zagrożeń jest zależny od sektora, regionu i rodzaju usług.^[17][18] W testach opartych na zagrożeniach te źródła są punktem wyjścia do scenariuszy, a nie gotową listą ataków do wykonania bez analizy kontekstu.

Wniosek

Dobry pentest nie jest konkursem na liczbę CVE ani pokazem narzędzi. Jego wartość wynika z dobrze postawionego pytania, prawidłowo ograniczonego zakresu, kompetencji testera, jakości ręcznej walidacji, odtwarzalnych dowodów i zdolności organizacji do wykorzystania wyniku.

Najbardziej dojrzały program nie pyta wyłącznie "czy przeprowadziliśmy pentest w tym roku". Pyta, które scenariusze zostały rzeczywiście sprawdzone, czego test nie objął, które warstwy obrony zadziałały, które nie zadziałały i czy po retestach można wykazać, że najważniejsze ścieżki zostały zamknięte.