Pentester to specjalista, który za pisemną zgodą i w ściśle ustalonym zakresie próbuje włamać się do systemów klienta, żeby znaleźć luki, zanim znajdzie je ktoś działający bez zgody. Jego produktem nie jest samo włamanie, tylko raport: co realnie da się osiągnąć w danym środowisku i jak to naprawić. Ten tekst opisuje zawód z dwóch stron: dla osoby, która chce nim zostać, i dla firmy, która zastanawia się, po czym poznać dobrego wykonawcę.

Metodyka i przebieg pojedynczego testu to osobny temat, opisany w tekście o tym, czym jest test penetracyjny. Tutaj skupiamy się na ludziach: co robią na co dzień, skąd się biorą, ile na rynku pracy kosztuje ich czas i jak zweryfikować ich kompetencje przed zleceniem projektu.

Krótka odpowiedź

  • Pentester spędza więcej czasu na rekonesansie, analizie architektury i pisaniu raportu niż na samej eksploatacji podatności.
  • Do zawodu wchodzi się przez fundamenty (sieci, Linux, web, skryptowanie), praktykę w laboratoriach i umiejętność raportowania, a nie przez znajomość narzędzi.
  • Certyfikaty potwierdzają, że ktoś umiał coś zrobić w warunkach egzaminu. Nie potwierdzają doświadczenia w konkretnej technologii klienta ani jakości raportowania.
  • Widełki wynagrodzeń w Polsce rozjeżdżają się między źródłami, bo różne raporty mierzą różne grupy stanowisk. Aktualnych przedziałów szukaj w raportach płacowych wskazanych w sekcji Źródła, nie w pojedynczej liczbie z internetu.
  • Firma zamawiająca test powinna weryfikować cztery rzeczy: kto konkretnie wykona pracę, jaką ma metodykę, jak wygląda jego przykładowy raport i czy w zakresie jest retest.

Czym pentester zajmuje się na co dzień?

Codzienna praca pentestera to metodyczny proces: ustalenie zakresu i reguł gry, rekonesans, testy techniczne, próba eksploatacji, a na końcu raport i omówienie wyników z zespołem klienta. Efektowne przełamanie zabezpieczeń to tylko jeden z etapów i rzadko najdłuższy.

Zaczyna się od scopingu i Rules of Engagement. Spisujemy w nich, co wolno testować, czego nie wolno ruszać i w jakich godzinach. Ustalamy też, kto po stronie klienta odbiera telefon, jeśli coś pójdzie nie tak. To nie formalność: bez tego dokumentu test łamie prawo, a operacyjnie niesie ryzyko.

Potem idzie rozpoznanie: co w ogóle istnieje w zakresie, jakie usługi widać z zewnątrz, jakie wersje, gdzie przebiegają granice zaufania między komponentami. Rozpoznanie potrafi być żmudne, ale to od niego zależy, czy test trafi w rzeczywiste ryzyko, czy w listę oczywistości ze skanera.

Testy właściwe to mieszanka automatów i pracy ręcznej. Skanery i skrypty pozwalają szybko pokryć powtarzalne sprawdzenia w dużym środowisku. Reszta, zwłaszcza błędy logiki biznesowej i problemy z autoryzacją, wymaga pracy ręcznej. Automat rzadko wykryje, że użytkownik jednego konta może podmienić identyfikator w żądaniu i zobaczyć dane innego klienta.

Najbardziej niedoceniany etap to raportowanie. Wynik testu nie trafia do innego pentestera, tylko do zespołu IT, dostawcy oprogramowania i nierzadko do zarządu. Trzeba więc opisać, co zawiera podatność, jak to odtworzyć, co realnie może się stać i jak to naprawić bez rozwalenia systemu.

Obszary, w których pentesterzy pracują na co dzień:

  • aplikacje webowe i API: autoryzacja, sesje, logika biznesowa, klasy podatności z OWASP Top 10,
  • sieci i infrastruktura: segmentacja, VPN, usługi brzegowe, konfiguracja urządzeń,
  • Active Directory i środowiska firmowe: uprawnienia, eskalacja, ruch boczny,
  • chmura (AWS, Azure, GCP), kontenery i pipeline’y CI/CD,
  • aplikacje mobilne (Android, iOS), czasem urządzenia IoT.

Do tego dochodzi warstwa etyczna, która w tym zawodzie nie jest ozdobnikiem. Pentester regularnie dostaje dostęp do danych, których nie powinien oglądać. Zdarza się znaleźć błąd dający wgląd w prywatne pliki użytkowników. Jedyna poprawna reakcja: natychmiast zgłoś to klientowi, opisz zakres ekspozycji i przerwij drążenie w tym kierunku.

Jak zostać pentesterem? Ścieżka wejścia i realne umiejętności

Najskuteczniejsza droga do zawodu prowadzi przez fundamenty techniczne, praktykę w laboratoriach, umiejętność raportowania i dopiero na końcu certyfikaty. Odwrotna kolejność, czyli certyfikat najpierw, kończy się tym, że kandydat zna narzędzia, ale nie potrafi wyjaśnić, dlaczego atak zadziałał.

Fundamenty, bez których reszta nie ma sensu

Potrzebujesz rozumienia, jak IT działa pod spodem, a nie tego, co kliknąć. Składają się na to cztery bloki. Sieci: TCP/IP, DNS, HTTP i HTTPS, NAT, firewalle, podstawy Wiresharka. Linux: uprawnienia, procesy, systemd, bash. Web: backend kontra frontend, cookies, sesje, JWT, CORS, podstawy baz danych. Windows z Active Directory: Kerberos, model uprawnień, PowerShell. Ostatni blok możesz odłożyć na później, ale się opłaca, bo Active Directory występuje w wielu środowiskach firmowych w Polsce. Do tego programowanie na poziomie użytkowym. Bez swobodnego czytania kodu i pisania skryptów w Pythonie i Bashu pentester zawsze będzie o krok za kimś, kto logikę aplikacji rozumie.

Myślenie ofensywne, czyli miejsce, w którym odpada najwięcej osób

Pentester musi myśleć niepoprawnie. Tam, gdzie system mówi „tego się nie da”, pada pytanie „a co jeśli”. Co jeśli token nigdy nie wygaśnie. Co jeśli API ufa danym przysłanym z frontu. Rdzeniem tej pracy jest łączenie kilku drobnych błędów, z których żaden osobno nie wygląda groźnie, w jeden realny scenariusz ataku. Uczy się tego przez powtarzalny proces, nie przez tutoriale: rekonesans, enumeracja, eksploatacja, eskalacja uprawnień, ruch boczny, dowody i raport. Kto zna proces, poradzi sobie w nieznanej technologii; kto zna tylko listę komend, utknie przy pierwszym nietypowym środowisku.

Narzędzia są ważne, ale wtórne

Burp Suite, Nmap, Metasploit, sqlmap, narzędzia do fuzzingu, frameworki pod Active Directory, chmurę i mobile: to wszystko trzeba znać. Różnica między juniorem a osobą doświadczoną nie polega jednak na liczbie znanych narzędzi. Doświadczony tester dobiera narzędzie do celu, rozpoznaje fałszywe trafienia w obie strony i wychodzi poza automat tam, gdzie automat nie sięga.

Praktyka, raportowanie i pierwsze zlecenia

Laboratoria robią robotę, o ile cel jest właściwy. Zamiast „zrobić 50 maszyn” lepiej postawić sobie trzy warunki: umiem wyjaśnić, czemu exploit zadziałał, umiem powtórzyć atak bez instrukcji i umiem opisać każdą znalezioną dziurę w krótkim raporcie. Platformy, które faktycznie uczą, to Hack The Box, TryHackMe, PortSwigger Web Security Academy i OverTheWire.

Nawyk pisania mini-raportu po każdym ćwiczeniu buduje portfolio szybciej niż kolejne narzędzie w CV. Minimum, które warto pokazać rekruterowi: dwa lub trzy zanonimizowane raporty, repozytorium ze skryptami i write-upami oraz krótki opis, jakie klasy podatności znajdujesz i jak je opisujesz. Do pierwszego komercyjnego doświadczenia prowadzą trzy drogi: bug bounty jako nauka, staż lub stanowisko juniorskie w firmie audytowej oraz przejście z roli administratora IT albo analityka SOC. Tą ostatnią idzie wiele osób i ma to sens, bo osoba, która utrzymywała systemy, wie, jak się je psuje.

Certyfikaty pentestera: co potwierdzają, a czego nie

Certyfikat praktyczny potwierdza, że kandydat w warunkach egzaminu potrafił samodzielnie przejść ścieżkę ataku i ją opisać. Nie potwierdza doświadczenia w technologii klienta, umiejętności pracy w zakresie produkcyjnym ani jakości raportu handlowego. To rozróżnienie liczy się i dla kandydata, i dla firmy, która czyta CV zespołu wykonawcy.

Podział, który w praktyce funkcjonuje na rynku:

  • Na start: eJPT jako egzamin praktyczny wprowadzający oraz CEH, certyfikat teoretyczny, którego wymaga część działów HR i część postępowań zakupowych.
  • Dla profesjonalistów: OSCP (Offensive Security Certified Professional), 24-godzinny egzamin praktyczny, uznawany za złoty standard weryfikacji realnych umiejętności ofensywnych.
  • Zaawansowane: OSWE dla aplikacji webowych i analizy kodu oraz PNPT dla realistycznych scenariuszy sieciowych.

Czego certyfikat nie mówi: czy ktoś testował kiedykolwiek środowisko podobne do Twojego. Ani czy potrafi pracować na systemie produkcyjnym bez wywracania go. Ani czy jego raport da się przekazać dostawcy oprogramowania bez tłumaczenia każdego akapitu. Rozsądna kolejność jest więc taka: certyfikat to dowód, że ktoś już umie, a nie klucz do pracy ani jedyne kryterium wyboru wykonawcy.

W kursach komercyjnych obowiązuje ta sama zasada. Rynek szkoleń jest szeroki, od krótkich kursów online po programy z egzaminem i dostępem do laboratoriów, a zakres, długość i forma zajęć bywają bardzo różne. Przed zakupem sprawdź dwie rzeczy: czy kurs kończy się egzaminem praktycznym i czy daje dostęp do środowiska do samodzielnych ćwiczeń po zajęciach.

Ile zarabia pentester w Polsce?

Doświadczony pentester zarabia w Polsce orientacyjnie 26 000–38 000 zł netto miesięcznie na kontrakcie B2B albo 22 000–30 000 zł brutto na umowie o pracę. Takie widełki dla stanowiska Penetration Tester na poziomie senior podaje zestawienie wynagrodzeń w cyberbezpieczeństwie agencji rekrutacyjnej NTIATIVE (2026). Dla młodszych poziomów osobnych danych o pentesterach nie znaleźliśmy, dlatego poniżej podajemy szerszą kategorię Security z ogłoszeń o pracę.

Poziom B2B, zł netto (+VAT) Umowa o pracę, zł brutto
Junior 9 140–14 180 8 000–10 000
Mid 20 160–24 255 14 000–17 000
Senior 25 200–30 240 20 000–28 000

Kategoria Security, mediany dolnych i górnych widełek z ogłoszeń opublikowanych od 1 stycznia do 31 grudnia 2025 r. Źródło: No Fluff Jobs, „Rynek pracy IT w Polsce 2025/2026”, s. 32. Kategoria obejmuje wszystkie stanowiska bezpieczeństwa, nie tylko pentesterów.

Ankiety wśród pracowników pokazują kwoty niższe niż ogłoszenia, bo mierzą faktycznie wypłacane pensje, a nie widełki oferowane w rekrutacji. W badaniu Bulldogjob 2025 mediana dla stanowiska Senior Cybersecurity Specialist na umowie o pracę wyniosła 23 700 zł brutto.

Zestawiając te dane, pamiętaj, że raporty mierzą różne populacje stanowisk i różne formy zatrudnienia. Kategoria „pentester” rozciąga się w nich od osoby uruchamiającej skanery po eksperta prowadzącego złożone projekty. Do tego część zestawień dotyczy umowy o pracę, a część kontraktów B2B, których stawek nie da się porównywać wprost. Dlatego sensowniej patrzeć na przedział z co najmniej dwóch źródeł i na datę publikacji raportu niż na jedną liczbę wyjętą z kontekstu.

Na miejsce w tym przedziale wpływa kilka czynników, które warto znać niezależnie od tego, czy szukasz pracy, czy wyceniasz koszt zespołu.

  • Portfolio realnych testów wraz z raportami. Liczba i rodzaj zrealizowanych projektów mówi więcej niż lista narzędzi w CV.
  • Certyfikaty praktyczne. Egzaminy wymagające samodzielnego przejścia ścieżki ataku i jej opisania (OSCP, OSWE) rynek wycenia wyżej niż certyfikaty teoretyczne.
  • Zakres technologiczny w jednej osobie. Połączenie kompetencji webowych, chmurowych i Active Directory jest rzadsze niż każda z nich osobno, a przy szerszych projektach ogranicza liczbę potrzebnych specjalistów.
  • Model pracy. Konsulting płaci zwykle więcej, ale wiąże się z większą presją i rotacją projektów, a wewnętrzny zespół bezpieczeństwa daje stabilność kosztem różnorodności zadań.
  • Forma zatrudnienia. Kontrakt B2B i umowa o pracę mają inną strukturę kosztów po obu stronach, więc kwot z obu modeli nie porównasz bez przeliczenia.
  • Umiejętność raportowania. Firma audytowa wyraźnie wyżej ceni osobę, której raport da się przekazać dostawcy oprogramowania bez tłumaczenia każdego akapitu. Te same kompetencje techniczne bez tej umiejętności znaczą mniej.

Jedna uwaga dla firm czytających raporty płacowe: wynagrodzenie specjalisty to nie to samo co koszt projektu. Budżet testu zależy od zakresu, liczby aplikacji i środowisk, wymaganej głębokości oraz tego, czy w cenie jest retest i wsparcie przy usuwaniu podatności.

Jak ocenić kompetencje pentestera lub zespołu przed zleceniem projektu?

Kompetencje wykonawcy ocenia się po czterech rzeczach: kto konkretnie wykona pracę, jaką stosuje metodykę, jak wygląda jego przykładowy raport i czy w zakresie umowy jest retest. Certyfikaty i logo na stronie są tylko punktem wyjścia, bo test wykonuje konkretna osoba, a nie firma jako całość.

O co zapytać przed podpisaniem umowy

  • Kto realnie wykona test. Poproś o imienny skład zespołu, jego doświadczenie i certyfikaty. Częsty problem: ofertę prezentuje ekspert, a projekt realizuje ktoś inny. Zapisz skład zespołu w umowie albo przynajmniej wymóg akceptacji zmian.
  • Doświadczenie w Twojej technologii. Zapytaj wprost, ile projektów zespół zrobił w tym samym stosie: ten framework, ten dostawca chmury, ten typ integracji, ta branża.
  • Metodyka i standard. Wykonawca powinien umieć nazwać metodykę, według której pracuje, i pokazać, co to zmienia. Na przykład: jakie klasy podatności obejmuje, a jakie świadomie zostawia poza zakresem.
  • Podział na testy ręczne i automatyczne. Zapytaj, jaka część prac to praca ręczna. Jeśli odpowiedź brzmi „używamy profesjonalnych skanerów”, kupujesz skan podatności, nie test penetracyjny.
  • Przykładowy raport. Sanityzowany raport z wcześniejszego projektu mówi o wykonawcy więcej niż cała prezentacja handlowa. Dobry dostawca ma go przygotowanego.
  • Procedura przy znalezisku krytycznym. Ustal, że wykonawca zgłasza podatność o wysokim ryzyku natychmiast, a nie dopiero w raporcie końcowym.
  • Formalności. Umowa powierzenia danych, NDA, zasady przechowywania dowodów i termin ich usunięcia po projekcie.

Zanim wyślesz zapytanie do kilku dostawców, ujednolić opis zakresu. Inaczej ofert nie porównasz. Praktyczne wskazówki, co powinno się w takim dokumencie znaleźć, zebraliśmy w tekście o tym, jak napisać zapytanie ofertowe na testy penetracyjne.

Jak wygląda dobry raport

Raport jest jedynym trwałym produktem projektu i to po nim najlepiej ocenia się wykonawcę. Poniższa tabela pokazuje różnicę między dokumentem, który tylko wypełnia obowiązek, a takim, na podstawie którego zespół IT może pracować.

Element Raport słabej jakości Raport użyteczny
Podsumowanie dla zarządu Ogólniki i wykresy bez wniosków Krótki opis realnego wpływu na biznes i lista priorytetów
Opis podatności Skopiowany opis z bazy podatności Opis w kontekście konkretnej aplikacji i jej danych
Dowody Zrzut ekranu ze skanera Kroki reprodukcji, żądania, dowód wpływu
Ocena ryzyka Sama ocena liczbowa ze skanera Ocena skorygowana o realny kontekst i ekspozycję systemu
Rekomendacje „Zaktualizuj komponent” Konkretna zmiana, wariant obejściowy i wskazanie skutków ubocznych
Fałszywe trafienia Zostawione w raporcie Zweryfikowane i odrzucone przed wydaniem dokumentu

Jeśli w raporcie każda podatność ma identyczną strukturę opisu i brakuje w niej odniesienia do Twojego środowiska, prawdopodobnie patrzysz na wyeksportowany wynik skanera z dopisanym nagłówkiem.

Retest, czyli dlaczego bez niego projekt jest niedokończony

Retest to ponowna weryfikacja tych samych podatności po wdrożeniu poprawek przez zespół klienta. Bez niego nie masz potwierdzenia, że luka faktycznie zniknęła, a nie została tylko częściowo zasłonięta albo naprawiona w jednym z kilku miejsc, w których występowała.

Ustal trzy rzeczy przed startem. Czy retest mieści się w zakresie oferty, czy stanowi dopłatę. Ile czasu od raportu masz na zgłoszenie poprawek do weryfikacji. Czy po retestcie dostajesz zaktualizowany dokument. Ostatni punkt liczy się formalnie, bo audytor lub kontrahent chce zobaczyć potwierdzenie usunięcia ustaleń, a nie samą listę znalezisk.

Dlaczego doświadczenie w konkretnej technologii ma znaczenie

Metodykę przenosisz między projektami, ale podatności zależą od stosu technologicznego. Osoba, która przez lata testowała aplikacje webowe, wejdzie w środowisko chmurowe z sensowną intuicją. Nie będzie jednak znała typowych błędów konfiguracji uprawnień u danego dostawcy ani wzorców nadużyć w usługach zarządzanych. Test aplikacji finansowej z rozbudowaną logiką transakcyjną, test Active Directory i test API obsługującego integracje partnerskie wymagają trzech różnych zestawów doświadczeń. Dlatego pytanie „ile projektów w tej technologii zrobiliście w ostatnim roku” jest bardziej diagnostyczne niż pytanie o liczbę certyfikatów w zespole.

Warto też dopasować rodzaj usługi do celu. Klasyczne testy penetracyjne odpowiadają na pytanie, jakie podatności są w danym zakresie i jak je naprawić. Jeśli celem jest sprawdzenie, czy organizacja wykryje i powstrzyma atak, właściwszym formatem jest red teaming, który testuje ludzi, procesy i monitoring, a nie tylko technologię. Gdy pytanie brzmi szerzej, czyli czy konfiguracja, procesy i dokumentacja odpowiadają przyjętym wymaganiom, punktem wyjścia jest audyt bezpieczeństwa IT, a testy obejmują wtedy systemy wskazane jako najważniejsze.

Zanim zamówisz cokolwiek, zrób u siebie jedno krótkie ćwiczenie. Wypisz systemy, których awaria lub wyciek danych zatrzymałby działanie firmy albo wymagałby zgłoszenia do regulatora. Sprawdź potem, których z nich nikt nie testował w ostatnim roku. Uzupełnij tę listę o wersje, integracje i osoby odpowiedzialne. Taka lista posłuży jednocześnie za podstawę zakresu testu i za najlepszy filtr na wykonawców, bo dobry dostawca zada do niej pytania, zanim wyśle ofertę.

Gotowy opis zakresu, w tym samym układzie dla wszystkich zapytanych dostawców, przygotujesz w konfiguratorze zakresu. To także najszybszy sposób, żeby zobaczyć, które parametry środowiska najsilniej wpływają na pracochłonność, a więc i na budżet projektu.

Najczęstsze pytania

Ile zarabia pentester w Polsce?

Doświadczony pentester (senior) zarabia orientacyjnie 26 000–38 000 zł netto na kontrakcie B2B albo 22 000–30 000 zł brutto na umowie o pracę (NTIATIVE, 2026). Dla całej kategorii Security mediany widełek z ogłoszeń za 2025 r. wynoszą od 9 140–14 180 zł B2B dla juniora do 25 200–30 240 zł B2B dla seniora (No Fluff Jobs, „Rynek pracy IT w Polsce 2025/2026”).

Czy pentester to to samo co haker?

Nie. Pentester działa legalnie, na podstawie pisemnej zgody właściciela systemu i w ustalonym zakresie. Osoba atakująca bez zgody nie ma żadnych ograniczeń zakresu ani czasu, co jest jednym z powodów, dla których test penetracyjny nigdy nie odwzoruje realnego ataku w stu procentach.

Czy trzeba umieć programować, żeby zostać pentesterem?

Nie trzeba być zawodowym programistą, ale umiejętność czytania kodu i pisania skryptów, najczęściej w Pythonie i Bashu, jest niezbędna. Służy do automatyzacji powtarzalnych zadań i do zrozumienia logiki testowanej aplikacji, a to właśnie w logice biznesowej znajdują się błędy, których nie wykryje żaden skaner.

Czy praca pentestera jest stresująca?

Bywa. Składają się na to presja czasu w projektach o sztywnym harmonogramie, odpowiedzialność za dostęp do wrażliwych danych i konieczność ciągłego douczania się. Rekompensatą jest zwykle widoczny efekt pracy i różnorodność środowisk.

Po czym poznać, że dostawca sprzedaje skan podatności zamiast testu penetracyjnego?

Po trzech sygnałach: brak imiennego składu zespołu, brak sanityzowanego raportu przykładowego oraz bardzo krótki czas realizacji przy dużym zakresie. Dodatkowym sygnałem jest raport, w którym opisy podatności nie odnoszą się do Twojego środowiska i nie zawierają kroków reprodukcji.

Czy jedna osoba wystarczy do przetestowania całego środowiska firmy?

Zwykle nie, jeśli środowisko obejmuje kilka różnych technologii. Aplikacje webowe, infrastruktura, chmura i Active Directory wymagają innych doświadczeń, więc przy szerszym zakresie sensowniejszy jest zespół z podziałem ról niż jeden specjalista rozciągnięty na wszystko. Przy wąskim, jednorodnym zakresie pojedynczy doświadczony tester jest w porządku.

Źródła

Cyberbezpieczeństwo dla firm - Pentestica

Redakcja Pentestica to zespół pentesterów i konsultantów bezpieczeństwa, którzy na co dzień wykonują testy penetracyjne, testy TLPT wymagane przez DORA, red teaming i audyty bezpieczeństwa IT, a także prowadzą wdrożenia zgodności z NIS2, DORA i MiCA. Teksty na tym blogu piszemy z tej praktyki, a nie z opracowań. Każde twierdzenie o przepisie, terminie albo karze opieramy na źródle pierwotnym: dzienniku ustaw, tekście dyrektywy, komunikacie organu nadzoru. Jeśli czegoś nie da się potwierdzić, piszemy o tym wprost, zamiast powtarzać liczbę krążącą po branżowych portalach.

Bezpłatna wycena Napisz