Testy penetracyjne - co to jest i czy ich potrzebujesz?
Testy penetracyjne (w skrócie pentesty) to umówione i kontrolowane próby włamania do aplikacji, sieci lub systemu. Robi je specjalista za pisemną zgodą właściciela, żeby znaleźć luki, zanim znajdzie je ktoś, kto chce ukraść dane. Na końcu dostajesz raport z listą błędów, oceną ryzyka i zaleceniami naprawy.
W Poldevs sami wykonujemy testy penetracyjne, więc piszę z perspektywy wykonawcy. Adresuję ten tekst do właścicieli firm i zarządów, którzy zamawiają lub utrzymują oprogramowanie i słyszą od klientów, audytorów albo prawnika: „macie to przetestowane pod kątem bezpieczeństwa?”.
Testy penetracyjne - co to jest?
Brytyjskie Narodowe Centrum Cyberbezpieczeństwa (NCSC) definiuje test penetracyjny jako metodę uzyskiwania pewności co do bezpieczeństwa systemu IT przez próbę przełamania jego zabezpieczeń narzędziami i technikami, jakich użyłby prawdziwy napastnik (NCSC, poradnik Penetration testing). Po polsku: doświadczony specjalista robi to, co zrobiłby włamywacz, ale w granicach Twojej zgody i w ustalonym czasie.
Jak to wygląda w praktyce?
Dla aplikacji z kontami klientów tester loguje się jako zwykły klient i sprawdza, czy zobaczy dane innego klienta, zmieni cudze zamówienie albo wyciągnie z API więcej, niż pokazuje ekran. Błędy kontroli dostępu i konfiguracji zabezpieczeń zajmują dwa pierwsze miejsca na liście OWASP Top 10:2025 (OWASP).
Jak długo wynik jest aktualny?
Pentest pokazuje stan z dnia testu. NCSC zaznacza, że test potwierdza jedynie brak znanych problemów w dniu sprawdzania, a przerwy między testami często trwają rok lub dłużej (NCSC). Dlatego rekomenduję test raz w roku oraz po większej zmianie, np. po dodaniu płatności, logowania lub integracji.
Dlaczego zarząd powinien się tym interesować?
Według raportu IBM Cost of a Data Breach 2026 średni koszt naruszenia danych wyniósł 4,99 mln USD, o 12% więcej niż rok wcześniej (IBM i Ponemon Institute, 2026). To średnia dla 602 organizacji na świecie, które doświadczyły naruszenia między marcem 2025 a lutym 2026 (IBM Newsroom, 2026). Koszt wycieku w małej polskiej firmie zależy od skali i rodzaju danych, a kwota IBM jest średnią dla organizacji objętych badaniem i pokazuje rząd wielkości po incydencie.
Pentest, skaner podatności i audyt - czym się różnią?
Skaner szuka znanych luk, audyt sprawdza zgodność z wymaganiami, a pentest sprawdza, czy i jak da się dotrzeć do danych. Żadne z tych podejść nie jest uniwersalnie „głębsze”: dobierasz je do pytania, na które potrzebujesz odpowiedzi.
Cel, zakres, wynik i ograniczenia:
- skaner podatności: wykrywa znane luki i błędy konfiguracji w wielu adresach naraz, a wynikiem jest lista z oceną ważności. Ograniczenie: fałszywe alarmy i brak rozumienia biznesu (skaner nie wie, że klient A nie powinien widzieć zamówień klienta B)
- audyt bezpieczeństwa: sprawdza zgodność organizacji z procedurami, normami lub umową z klientem, a wynikiem jest ocena zgodności z listą wymagań. Ograniczenie: nie rozstrzyga, czy konkretną lukę da się wykorzystać
- test penetracyjny: sprawdza w uzgodnionym zakresie (np. jedna aplikacja, jej role i API), czy i jak da się dotrzeć do danych, także łącząc kilka drobnych błędów. Wynik to opis luk, ocena ryzyka i zalecenia. Ograniczenie: stan z dnia testu i granice zakresu
NCSC opisuje pentest jako sprawdzian procesów oceny podatności i zarządzania nimi i zaznacza, że nie służy on jako główna metoda wyszukiwania podatności. Moim zdaniem do bieżącego wyszukiwania luk służą regularne skany. Pentest bez aktualizacji i skanów między testami kończy się ciągle tym samym raportem.
Porada 1:
Gdy ktoś proponuje Ci „pentest”, dopytaj, czy chodzi o skanowanie, audyt czy test ręczny. Ofertę na skan łatwo pomylić z ofertą na test, a różnica w cenie i w wartości raportu jest duża.
Czy każda firma potrzebuje testów penetracyjnych?
Nie każda. Rekomenduję test, gdy co najmniej jedno z poniższych jest prawdą.
Pentest ma sens, gdy:
- aplikacja przetwarza dane osobowe (zwłaszcza zdrowotne), płatności lub dane finansowe
- z aplikacji korzystają klienci z własnymi kontami i widzą swoje dane
- system łączy się z innymi systemami przez API (księgowość, magazyn, CRM, partnerzy)
- klient, audytor lub ubezpieczyciel wprost go wymaga
- wprowadzasz większą zmianę: nowe logowanie, płatności, moduł z danymi
RODO w art. 32 ust. 1 lit. d wymaga od administratora danych m.in. regularnego testowania, mierzenia i oceniania skuteczności środków technicznych i organizacyjnych (rozporządzenie (UE) 2016/679, EUR-Lex). Pentest jest jedną z form takiego sprawdzenia.
Dyrektywa NIS2 w art. 21 ust. 2 lit. f wymaga od podmiotów, których dotyczy, polityk i procedur oceny skuteczności środków zarządzania ryzykiem w cyberbezpieczeństwie, ale testów penetracyjnych wprost nie wymienia (dyrektywa (UE) 2022/2555, EUR-Lex). Pentest może być jednym ze sposobów takiej oceny.
Komu odradzam? Prostym stronom wizytówkowym bez logowania i bez formularzy z danymi wrażliwymi. Tu zwykle wystarcza aktualizowany system, mocne hasła, MFA i skaner podatności. O utrzymaniu oprogramowania piszę w tekście o kosztach utrzymania aplikacji mobilnej oraz na stronie usługi utrzymania aplikacji i systemu.
Jakie są rodzaje testów penetracyjnych i kiedy który wybrać?
Black box, grey box i white box
Podział zależy od tego, ile tester wie o systemie na starcie: w black box zna tylko adres, w grey box dostaje konta o różnych rolach, w white box także kod i dokumentację. Dla typowej aplikacji firmowej najczęściej rozsądny jest grey box, bo pozwala sprawdzić, czy jedno konto nie widzi cudzych danych. O logowaniu, rozdzielaniu danych użytkowników i skutkach pomyłki w tej dziedzinie piszę w artykule o funkcjach, których nie warto budować z AI bez wiedzy technicznej. White box warto rozważyć, gdy system przetwarza dane zdrowotne, finansowe lub płatności, a budżet pozwala na wgląd w kod. Na grafice poniżej grey box oznaczam ptaszkiem jako moją rekomendację dla typowej aplikacji firmowej.
Co jest testowane? Aplikacja, API, aplikacja mobilna, infrastruktura
Test aplikacji webowej sprawdza logowanie, uprawnienia i obsługę danych. Test API dotyczy interfejsów, którymi rozmawiają systemy i aplikacje mobilne. Test aplikacji mobilnej obejmuje także to, co zapisuje się w telefonie, a test infrastruktury serwery, sieć i konfigurację chmury. Zakres dobierasz według tego, gdzie leżą dane i jak groźna byłaby ich utrata. Panel administracyjny zwykle warto uwzględnić, bo jego przejęcie daje szeroki dostęp, choć decyzja zależy od izolacji panelu i jego uprawnień. Testy socjotechniczne (wyłudzanie haseł od pracowników) to osobna usługa z osobną zgodą.
Według jakiej metodyki pracuje tester?
Tester pracuje według ustalonej metodyki. Przykładem jest OWASP Web Security Testing Guide (WSTG), przewodnik po testowaniu bezpieczeństwa aplikacji i usług webowych, w którym każdy scenariusz ma cel, metodę i zalecenia naprawy (OWASP WSTG v4.2). Wydanie 4.2 dzieli testy na 12 grup, m.in. uwierzytelnianie, autoryzację, zarządzanie sesją, walidację danych wejściowych, logikę biznesową i API. Zapytaj wykonawcę, na jakiej metodyce opiera testy i jak raportuje wyniki.
Trzy luki, które tester sprawdza w aplikacji webowej:
- dostęp do cudzych danych (Insecure Direct Object References): aplikacja pobiera rekord po identyfikatorze podanym przez użytkownika i nie sprawdza, czy rekord należy do zalogowanej osoby. Wtedy zmiana numeru w adresie lub zapytaniu może pokazać cudze zamówienie
- SQL injection: napastnik wpisuje w pole formularza lub inne dane wejściowe fragment zapytania do bazy, a aplikacja go wykonuje
- XSS (Cross-Site Scripting): napastnik wstrzykuje do odpowiedzi strony kod wykonywany przez przeglądarkę użytkownika. Wersja odbita (reflected) działa przez spreparowany link, który ofiara otwiera
Definicje tych luk i sposoby ich sprawdzania opisuje WSTG: Insecure Direct Object References, SQL Injection i Reflected Cross Site Scripting. Pierwsza z nich to ten sam rodzaj błędu, który tester szuka w grey box, logując się na konta o różnych rolach.
Jak wygląda pentest krok po kroku?
Pentest ma pięć etapów: zakres i zgoda, środowisko i konta, testy, raport oraz naprawa z retestem. Poniżej każdy z nich z perspektywy zamawiającego: co robisz i o co pytasz wykonawcę.
1. Zakres i zgoda
Zacznij od wskazania, co jest najcenniejsze i co wyłączasz z testu. Według NCSC zakres ustalają wspólnie osoba odpowiedzialna za ryzyko, technicy znający system i przedstawiciel testerów. Zapytaj wykonawcę, co jest w zakresie, a co poza nim, i czy retest jest w cenie.
2. Środowisko i konta
Środowisko, konta o różnych rolach i dane testowe przygotowujesz Ty, a wykonawca powinien z góry powiedzieć, jakich kont i jakiej wiedzy o systemie potrzebuje na starcie. Poproś go o tę listę przed podpisaniem umowy.
3. Testy w uzgodnionym oknie
W trakcie testów potrzebujesz osoby technicznej, osiągalnej w krótkim czasie na wypadek problemu (zalecenie NCSC). Ustal z wykonawcą, jak poinformuje Was o krytycznej luce, nie czekając na raport końcowy.
4. Raport
Dobry raport opisuje każdą lukę, ocenia ryzyko i wskazuje sposób naprawy. Zanim podpiszesz umowę, poproś o próbkę raportu i o spotkanie omawiające wyniki.
5. Naprawa i retest
Każda luka dostaje osobę odpowiedzialną i termin. Przy wycenie dopytaj, ile retestów jest w cenie i w jakim terminie wykonawca je zrobi.
Co pokazują ostatnie wycieki danych? Medycyna, finanse, SaaS
Wejście napastnika bywa różne: skradzione hasła do kont bez MFA (Snowflake), tokeny integracji (Salesloft Drift), a w sprawach MyDr i Fakturowni komunikaty nie opisują przyczyny. Wybrałem incydenty z lat 2024-2026 opisane przez regulatorów lub firmy prowadzące śledztwo. Przy każdym oddzielam to, co potwierdzono, od tego, czego nie wiadomo.
Medycyna: MyDr i Medyc w Polsce (2026)
Co potwierdzono: 13 sierpnia 2026 r. UODO zapowiedział kontrolę spółki MyDr, której aplikacja przetwarza dane pacjentów dla placówek medycznych, po wycieku danych o stanie zdrowia. Urząd ma sprawdzić m.in., czy środki bezpieczeństwa były regularnie testowane (UODO, 13.08.2026). W komunikacie z 25 września UODO podaje, że wyciek z MyDr dotyczy 19 mln Polaków, i opisuje drugi incydent, w aplikacji Medyc spółki Qbusoft (UODO, 25.09.2026). Czego nie wiadomo: przyczyn obu incydentów komunikaty nie opisują, a liczba do 5 mln osób w sprawie Medyc pochodzi z mediów i nie jest potwierdzona przez urząd.
Dla zamawiającego ważny jest podział ról: MyDr jest podmiotem przetwarzającym, a placówki medyczne administratorami, którzy sami oceniają, czy zgłaszać naruszenie (UODO, 27.08.2026). Nawet gdy problem leży po stronie dostawcy, odpowiadasz przed pacjentami i regulatorem, więc zapytaj dostawcę, kiedy ostatnio testował bezpieczeństwo, i ustal to w umowie powierzenia danych.
Finanse: Fakturownia (wrzesień 2026)
Według komunikatu spółki nieuprawniona osoba miała dostęp do systemów Fakturowni od 27 września 2026 r. (ok. 3:20) do 28 września (ok. 17:45) i skopiowała dane z bazy na własne serwery. Incydent dotyczy każdego konta, a z ok. 2 250 kont pobrano wszystkie dane dostępne w systemie z lat 2022-2026, do daty innej dla każdego konta: m.in. dane firm i użytkowników (NIP, adresy, e-maile, telefony, hasła w postaci zahaszowanej), tokeny API i klucze integracji. Spółka podaje, że nie przechowuje danych logowania do banków ani kart płatniczych, a certyfikaty KSeF nie zostały pobrane (Fakturownia, komunikat, aktualizacja z 1.10.2026).
Czego nie wiadomo: komunikat nie opisuje, jak napastnik uzyskał dostęp. CERT Orange przywołuje wcześniejsze stanowisko spółki o wykorzystaniu luki w systemie i wskazuje możliwy atak SQL injection, ale aktualizacja spółki tego nie potwierdza, podobnie jak twierdzenia napastnika o 6 TB danych (CERT Orange, 29.09.2026). Z tej sprawy wynika dla Ciebie kilka rzeczy: wiedz, jakie dane trzymasz w takim systemie, miej listę integracji z tokenami API, które da się szybko unieważnić, i uważaj na wiadomości podszywające się pod kontrahentów, bo kto zna numery rachunków i kwoty faktur, łatwo je uwiarygodni.
SaaS: Snowflake (2024) i Salesloft Drift (2025)
Snowflake: w 2024 r. grupa oznaczona przez Mandiant (Google) jako UNC5537 wykradała dane z kont klientów platformy. Mandiant nie znalazł dowodów na włamanie do systemów samego Snowflake. Napastnicy logowali się hasłami skradzionymi wcześniej złośliwym oprogramowaniem. Konta nie miały MFA, część haseł była ważna latami, a dostęp nie był ograniczony listą dozwolonych adresów. Powiadomiono około 165 potencjalnie narażonych organizacji (Mandiant, 10.06.2024). Tę drogę zamykają MFA, wymiana starych haseł i ograniczenie dostępu do znanych adresów, i nie wymaga to pentestu.
Salesloft Drift: od 8 do 18 sierpnia 2025 r. napastnik użył skradzionych tokenów OAuth tej integracji, żeby eksportować dane z instancji Salesforce, a potem szukał w nich haseł i kluczy dostępu, m.in. do AWS i Snowflake. Według Google Threat Intelligence Group nie wynikało to z luki w samej platformie Salesforce (Google Threat Intelligence Group, 26.08.2025). Bramą była integracja z zewnętrznym narzędziem. Spisz więc integracje z dostępem do danych, ogranicz ich uprawnienia i wiedz, jak je szybko odłączyć. O ryzykach SaaS piszę w tekście co to jest SaaS i jakim firmom go odradzam.
Poniższa macierz zestawia cztery omówione sprawy: dla każdej pokazuje, czy źródła wskazują lukę w kodzie, w kontach czy w integracjach, albo że komunikaty tego nie opisują, oraz czy pentest mógłby tu pomóc, jeśli znalazłby się w jego zakresie.
Czy pentest uchroniłby przed tymi atakami?
Odpowiedź zależy od tego, którędy wchodził napastnik, i tu nie zgadzam się z firmami sprzedającymi pentest jako lekarstwo na wszystko. Snowflake i Drift zaczęły się od skradzionych haseł, kont bez MFA i uprawnień integracji, czyli poza kodem aplikacji klientów. Klasyczny test aplikacji zwykle tego nie obejmuje, ale do zakresu możesz dodać przegląd konfiguracji i dostępów. W MyDr i Fakturowni komunikaty nie opisują luki, więc nie ma podstaw do oceny, czy pentest by pomógł.
Luki w oprogramowaniu są natomiast realnym wejściem. Według Verizon Data Breach Investigations Report 2026 (incydenty od 1 listopada 2024 do 31 października 2025) wykorzystanie podatności było najczęstszym początkiem naruszeń (31%), przed skradzionymi danymi logowania (Verizon DBIR, 2026). Pentest może wychwycić to, czego skaner zwykle nie widzi: zbyt szerokie uprawnienia, błędy w logice biznesowej (klient A widzi zamówienia klienta B), niezabezpieczone punkty API czy źle obsłużone logowanie. Część takich błędów ma źródło w zaniedbaniach opisanych w tekście o długu technologicznym.
Porada 2:
Zanim zamówisz pentest, włącz MFA wszędzie, gdzie się da, zmień stare hasła i sprawdź, którzy dostawcy i integracje mają dostęp do Twoich danych. To kosztuje mniej niż test, a zamyka trzy luki, które według Mandiant umożliwiły ataki na klientów Snowflake (Mandiant, 2024).
Od czego zależy cena testów penetracyjnych?
Cena pentestu wynika zwykle z liczby dni pracy testera, a ta zależy od zakresu: im więcej ekranów, funkcji i ról użytkowników, tym wyższa wycena. Czynniki, które realnie zmieniają kwotę w ofercie:
Na cenę wpływa:
- zakres i złożoność logiki: liczba ekranów, funkcji, punktów API i ról użytkowników (każda rola to osobny zestaw uprawnień) oraz to, jak nietypowe są procesy biznesowe, które tester musi zrozumieć.
- rodzaj testu i obszar: w black box część czasu pochłania rozpoznanie systemu, w white box analiza kodu. Aplikacja webowa, mobilna, API i infrastruktura wymagają innych kompetencji, więc kilka obszarów to zwykle kilka osobnych prac.
- forma raportu: krótkie podsumowanie dla zarządu kosztuje mniej niż raport z dowodami i zaleceniami dla programistów.
- retest po naprawie: jedni wykonawcy wliczają go w cenę, inni wyceniają osobno albo ograniczają liczbę iteracji.
- środowisko, termin i poufność: jeśli to Ty przygotowujesz staging i konta testowe, wykonawca oszczędza czas. Krótki termin wymaga rezerwacji zespołu, a NDA dodaje formalności.
Najwięcej kosztuje niejasny zakres: wykonawca dolicza zapas na ryzyko albo zaczyna od najtańszego wariantu i w trakcie dopisuje prace.
Porada 3:
Poproś o wycenę z opisanym zakresem, obszarami i rolami oraz zapytaj, ile iteracji retestu jest w cenie. Dwie oferty różniące się o połowę zwykle różnią się zakresem, więc porównuj najpierw to, co każda obejmuje, jak przy porównywaniu wycen projektów IT.
Jak przeprowadzić pentest w kontrolowanym środowisku?
Środowisko i zakres dobiera się do celu testu i ryzyka. Domyślnie sensowny jest staging odwzorowujący produkcję, z danymi testowymi lub zanonimizowanymi. NCSC zwraca uwagę, że nie da się wykluczyć nieoczekiwanej reakcji systemu na testy (NCSC). Część problemów, np. konfiguracja, integracje i uprawnienia, ujawnia się tylko tam, gdzie naprawdę istnieje, więc czasem uzgadnia się też ograniczony test na produkcji.
Jak wygląda zgoda i zakres w praktyce?
Uzyskanie bez uprawnienia dostępu do całości lub części systemu informatycznego jest przestępstwem (art. 267 § 2 Kodeksu karnego, ISAP), więc zgoda musi być pisemna i podpisana przez osobę upoważnioną. Opisz w niej adresy, aplikacje, konta i wyłączenia (np. systemy dostawców, do których nie masz uprawnień), kontakt po Twojej stronie, zakazane techniki (np. przeciążanie systemu) i warunki zatrzymania testu. Jeśli dane stoją u dostawcy hostingu lub w chmurze, sprawdź jego regulamin. Do zgody dodaj umowę o poufności, o której piszę w tekście o umowie NDA.
Kiedy staging, a kiedy produkcja?
Staging ogranicza ryzyko awarii i tego, że tester zobaczy prawdziwe dane klientów. Jego wiarygodność zależy od podobieństwa do produkcji: różnice w konfiguracji, integracjach i uprawnieniach mogą ukryć część luk, a pusta baza ogranicza sprawdzanie dostępu do cudzych danych. Test na produkcji ma sens, gdy cel go wymaga: w ograniczonym zakresie, w ustalonym oknie, po wykonaniu kopii zapasowej z potwierdzonym odtworzeniem i z planem wycofania zmian. Więcej o pytaniach do dostawcy w artykule o zawodzącym dostawcy IT.
Checklista ustaleń przed startem:
- podpisana zgoda, zakres (adresy, aplikacje, role, wyłączenia) i zasady współpracy
- środowisko testowe odwzorowujące produkcję, z odwzorowanymi rolami i danymi testowymi lub zanonimizowanymi
- konta testowe dla każdej roli użytkownika
- okno czasowe uzgodnione z zespołem utrzymującym system i osoba techniczna dostępna w trakcie testu
- kopia zapasowa z potwierdzonym odtworzeniem i plan wycofania zmian (przy testach na produkcji)
- informacja lub zgoda dostawców, którzy hostują lub obsługują systemy w zakresie
- umowa o poufności i miejsce przechowywania raportu
Co zrobić po otrzymaniu raportu?
Raport to dopiero początek pracy. Według NCSC dobry raport zawiera opis każdej luki, ocenę ryzyka dla organizacji i sposób usunięcia. Po teście warto spotkać się z testerami, bo to dobra okazja do pytań.
Jak czytać priorytety?
W raportach spotkasz oceny wysokie, średnie, niskie i informacyjne; NCSC dopuszcza też ocenę CVSS jako dodatek. Wysoka ocena oznacza zwykle lukę pozwalającą na dostęp do danych lub przejęcie konta, więc naprawiasz ją najpierw. Testerzy nie znają jednak Twojego biznesu: NCSC ostrzega, że mogą ocenić lukę wyżej lub niżej niż Ty, a decyzje o naprawie zostają po Twojej stronie.
Kto naprawia i jak?
Raport przekaż zespołowi, który utrzymuje aplikację. Bez stałego opiekuna łatwo o scenariusz, w którym raport leży w szufladzie, bo nikt nie ma przypisanej naprawy. Dlatego poprawki warto włączyć w zakres utrzymania aplikacji i systemu albo w plan rozwoju oprogramowania, z ustalonym czasem reakcji.
Retest
Po naprawie zleć retest, czyli sprawdzenie, że luka zniknęła. Poproś, żeby raport końcowy wskazywał, które luki zamknięto, a które zostają jako ryzyko zaakceptowane przez zarząd.
Porada 4:
Zanim zamówisz test, ustal, kto i w jakim terminie naprawi znalezione luki. Pentest bez wykonawcy poprawek to drogi raport.
Jak wybrać wykonawcę testów penetracyjnych?
Wykonawcę oceniaj po tym, kto konkretnie będzie testował, jak wygląda jego raport i co dokładnie obejmuje oferta; certyfikaty są jednym z kryteriów. NCSC pisze wprost, że jakość testu jest ściśle związana z umiejętnościami testerów, a testy zewnętrzne powinni wykonywać wyłącznie wykwalifikowani, doświadczeni ludzie. Dla brytyjskich instytucji rządowych poleca firmy objęte programem CHECK (NCSC). W ofertach spotkasz też certyfikaty organizacji branżowych. Poniżej cztery najczęściej wymieniane i to, co według samych wystawców potwierdzają.
| Certyfikat (wystawca) | Co potwierdza według wystawcy | Format egzaminu | Źródło |
|---|---|---|---|
| OSCP / OSCP+ (OffSec) | wykrywanie podatności, wykorzystywanie systemów i podnoszenie uprawnień | praktyczny, nadzorowany, 24 godziny: 3 samodzielne maszyny i zestaw Active Directory. OSCP+ wygasa po 3 latach | OffSec |
| CEH (EC-Council) | wiedza o zagrożeniach, wektorach ataku, wykrywaniu i zapobieganiu atakom | egzamin wiedzy: 125 pytań wielokrotnego wyboru, 4 godziny. Osobny egzamin praktyczny (6 godzin) daje poziom CEH Master | EC-Council |
| GPEN (GIAC) | przeprowadzenie testu penetracyjnego skutecznymi technikami i metodykami | nadzorowany egzamin: 82 pytania, 3 godziny, próg zdania 73% (wersje od 12.07.2025) | GIAC |
| CREST (CPSA, CRT, CCT) | kompetencje testerów na poziomach Practitioner, Registered i Certified; CREST akredytuje też firmy i okresowo je ocenia | egzaminy poziomu Certified mają 2 części rezerwowane osobno | CREST |
Certyfikat potwierdza to, co sprawdza egzamin danego wystawcy, w dniu jego zdania. Formaty bardzo się różnią: OSCP to doba pracy na laboratoryjnych maszynach, a CEH i GPEN opierają się na pytaniach. To moja ocena, ale wynika z budowy egzaminów: żaden nie odbywa się na Twoim systemie, więc żaden nie mówi, czy tester zna technologię Twojej aplikacji i jak pisze raporty. OSCP, CEH i GPEN dotyczą konkretnej osoby, a CREST i CHECK obejmują także firmy i ich procesy. Jeśli klient lub audytor wymaga konkretnego certyfikatu, ustal to przed zapytaniem ofertowym, a od wykonawcy poproś o dane do sprawdzenia certyfikatu u wystawcy.
O co jeszcze pytać w ofercie:
- kto konkretnie będzie testował i jakie ma doświadczenie w technologii Twojej aplikacji
- próbka zanonimizowanego raportu (opis luki, ocena ryzyka, sposób naprawy)
- dokładny zakres na piśmie i informacja, czy retest jest w cenie
- poufność (NDA, miejsce i czas przechowywania raportu), kontakt awaryjny i spotkanie omawiające wyniki
NCSC zaleca zgłosić nietypowe elementy systemu już w zapytaniu ofertowym, żeby wykonawca dobrał odpowiednich testerów. Jeśli ta sama firma buduje system i go testuje, zapytaj o rozdzielenie ról: inni ludzie testują, inni pisali kod. Dotyczy to także Poldevs, więc zadaj nam te same pytania. Oferty porównasz tak jak w tekście o porównywaniu wycen projektów IT.
Typowe błędy zamawiających
Czego unikać:
- zamawianie „pentestu” bez opisanego zakresu, więc każda strona rozumie to inaczej
- środowisko dobrane bez celu: staging z pustą bazą, który ogranicza wiarygodność wyniku, albo test na produkcji bez kopii zapasowej i planu wycofania
- brak osoby, która naprawi znalezione luki, oraz zakończenie na raporcie bez retestu
- traktowanie raportu jak certyfikatu bezpieczeństwa na lata, choć przerwy między testami bywają roczne lub dłuższe
- pominięcie integracji i dostawców, choć w wyciekach z SaaS wejściem były hasła i integracje
Najczęściej zadawane pytania
Czy testy penetracyjne są legalne i czy trzeba mieć zgodę?
Testy penetracyjne są legalne wyłącznie za pisemną zgodą właściciela testowanego systemu i w uzgodnionym zakresie. Uzyskanie bez uprawnienia dostępu do całości lub części systemu informatycznego jest przestępstwem z art. 267 § 2 Kodeksu karnego, zagrożonym grzywną, karą ograniczenia wolności albo pozbawienia wolności do lat 2. Jeśli dane hostuje dostawca chmury lub hostingu, sprawdź też jego regulamin.
Czym różni się test penetracyjny od skanowania podatności?
Skaner podatności automatycznie wyszukuje znane luki i podaje ich listę, a test penetracyjny wykonuje człowiek, który sprawdza, czy luki da się wykorzystać i czy kilka drobnych błędów razem daje dostęp do danych. Skaner nadaje się do regularnych kontroli, pentest do sprawdzenia konkretnej aplikacji w uzgodnionym zakresie. Zwykle stosuje się oba.
Czy testy penetracyjne można robić na produkcji?
Tak, ale środowisko dobiera się do celu testu i ryzyka. Domyślnie test robi się na stagingu odwzorowującym produkcję, z danymi testowymi lub zanonimizowanymi. Test na produkcji jest możliwy w uzgodnionym zakresie i oknie czasowym, po wykonaniu sprawdzonej kopii zapasowej i z planem wycofania zmian. Bez takiego przygotowania grozi awarią i ujawnieniem prawdziwych danych osobowych osobom trzecim.
Jak wybrać wykonawcę testów penetracyjnych?
Wybierz wykonawcę, który wskaże, kto konkretnie będzie testował, pokaże zanonimizowaną próbkę raportu, poda zakres na piśmie z retestem i zobowiąże się do poufności. Certyfikaty testerów, takie jak OSCP, GPEN, CEH czy CREST, potwierdzają wiedzę sprawdzoną na egzaminie. Doświadczenie w technologii Twojej aplikacji sprawdzisz w referencjach i próbce raportu.
Źródła
IBM i Ponemon Institute, Cost of a Data Breach Report 2026: ibm.com/reports/data-breach; IBM Newsroom (metodologia: 602 organizacje, marzec 2025 - luty 2026): mea.newsroom.ibm.com
Verizon, 2026 Data Breach Investigations Report: verizon.com/business/resources/reports/dbir
Mandiant (Google Cloud), UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion, 10.06.2024: cloud.google.com; Google Threat Intelligence Group, Data Theft from Salesforce Instances via Salesloft Drift, 26.08.2025: cloud.google.com
UODO, Prezes UODO skontroluje spółkę MyDr, 13.08.2026: uodo.gov.pl; Pytania związane z incydentem MyDr, 27.08.2026: uodo.gov.pl; Po nowym wycieku danych medycznych PUODO zapowiada kontrolę, 25.09.2026: uodo.gov.pl
Fakturownia, Incydent - oficjalny komunikat, aktualizacja nr 1 z 1.10.2026: fakturownia.pl; CERT Orange, Włamanie do Fakturowni, 29.09.2026: cert.orange.pl
NCSC (Wielka Brytania), Penetration testing (poradnik, strona bez daty publikacji, dostęp: listopad 2026): ncsc.gov.uk; OWASP, Top 10:2025: top10.owasp.org/2025; OWASP, Web Security Testing Guide v4.2 (dostęp: listopad 2026): wstg.owasp.org/v4.2
Certyfikaty (dostęp: listopad 2026): OffSec, PEN-200 / OSCP: offsec.com; EC-Council, CEH: eccouncil.org; GIAC, GPEN: giac.org; CREST, certyfikaty i akredytacja: crest-approved.org/certifications, crest-approved.org/accreditation
Ustawa z dnia 6 czerwca 1997 r. Kodeks karny (Dz.U. 1997 nr 88 poz. 553), art. 267 § 2, ISAP: isap.sejm.gov.pl; Rozporządzenie (UE) 2016/679 (RODO), art. 32 ust. 1 lit. d, EUR-Lex: eur-lex.europa.eu; Dyrektywa (UE) 2022/2555 (NIS2), art. 21 ust. 2 lit. f, EUR-Lex: eur-lex.europa.eu
