Najtańszy pentest może okazać się najdroższy, jeżeli po kilku tygodniach dostajesz raport z automatu, którego nikt nie umie przełożyć na poprawki. Dobra firma pentestowa nie sprzedaje samego PDF-a. Sprzedaje decyzje: co jest naprawdę ryzykowne, co naprawić najpierw, jak to zweryfikować i jak nie powtórzyć błędu.
Rynek testów bezpieczeństwa jest nierówny. Pod tą samą nazwą „pentest” może kryć się manualny test aplikacji z analizą logiki biznesowej, ale też szybki skan automatem i eksport gotowego szablonu. Dla osoby kupującej usługę różnica bywa widoczna dopiero po odbiorze raportu — czyli za późno.
Pytanie 1: czy test będzie manualny?
Nie chodzi o to, żeby zakazać narzędzi. Dobry pentester korzysta z narzędzi, proxy, skanerów, fuzzingu, wordlist, analizy ruchu i automatyzacji. Problem pojawia się wtedy, gdy narzędzie zastępuje myślenie. Jeżeli wykonawca nie potrafi opisać, jak sprawdzi autoryzację, role, logikę biznesową i przepływy specyficzne dla Twojej aplikacji, istnieje ryzyko, że kupujesz skan.
Poproś o opis metodyki. Dobra odpowiedź powinna wspominać o pracy na kontach testowych, porównywaniu ról, analizie request/response, testach API, weryfikacji podatności i ręcznej ocenie wpływu.
Pytanie 2: jak wygląda przykładowy raport?
Próbka raportu mówi więcej niż folder marketingowy. Zobacz, czy podatność ma jasny opis wpływu, kroki reprodukcji, dowody, klasyfikację ryzyka, rekomendację i kryterium retestu. Jeżeli raport składa się głównie z ogólnych opisów z internetu, bez requestów, screenshotów i kontekstu biznesowego, będzie trudny do wdrożenia.
| Dobry raport | Słaby raport |
|---|---|
| pokazuje wpływ na dane, role i procesy | kopiuje opis kategorii podatności |
| zawiera PoC i kroki reprodukcji | zawiera ogólne zalecenie „zaktualizować” |
| rozdziela executive summary i szczegóły techniczne | jest niezrozumiały dla zarządu i developmentu |
| ma kryteria retestu | nie wiadomo, jak potwierdzić naprawę |
Pytanie 3: czy w cenie jest retest?
Retest zamyka pętlę. Bez retestu firma wie, że problem istniał, ale nie ma potwierdzenia, że został dobrze usunięty. Warto ustalić, ile rund retestu obejmuje oferta, w jakim czasie można go wykonać, co dzieje się przy częściowej poprawce i jak wygląda raport retestu.
Najlepsza praktyka to raport pierwotny, czas na poprawki i krótki raport retestu ze statusem każdej podatności: usunięta, częściowo usunięta, nieusunięta, niemożliwa do weryfikacji, zaakceptowana przez właściciela ryzyka.
Pytanie 4: czy wykonawca rozumie Twój typ systemu?
Inaczej testuje się prostą stronę marketingową, inaczej SaaS B2B, inaczej aplikację bankową, inaczej system medyczny, a inaczej API dla partnerów. Jeżeli masz role, tenanty, dokumenty, workflow, płatności, integracje lub aplikację mobilną, wykonawca musi zaplanować testy pod te mechanizmy.
Zapytaj, jakie konta testowe będą potrzebne. Jeżeli wykonawca nie pyta o role, przepływy, typy użytkowników i dane testowe, może nie planować testów logiki.
Pytanie 5: jak wyceniany jest zakres?
Wycena pentestu powinna wynikać z powierzchni testu, złożoności aplikacji, liczby ról, liczby endpointów, liczby środowisk, dostępności dokumentacji, wymaganego raportowania i retestu. Podejrzanie niska cena przy dużym systemie zwykle oznacza bardzo ograniczony czas albo automatyzację bez głębokiej analizy.
Nie zawsze drożej znaczy lepiej, ale zbyt tanio często oznacza, że ktoś nie spędzi czasu na zrozumieniu aplikacji. A właśnie zrozumienie aplikacji jest miejscem, gdzie znajdują się najciekawsze błędy.
Czerwone flagi przy wyborze dostawcy
- brak pytań o role użytkowników i logikę biznesową,
- obietnica pełnego testu dużej aplikacji w jeden dzień,
- brak przykładowego raportu lub raport bez PoC,
- brak retestu albo bardzo niejasne zasady retestu,
- raport tylko z narzędzia automatycznego,
- brak informacji o metodyce, ograniczeniach i odpowiedzialności,
- brak rozdzielenia raportu technicznego i zarządczego.
Jak przygotować się do rozmowy z firmą pentestową
Przed rozmową warto przygotować krótki opis systemu: co robi aplikacja, ilu ma użytkowników, jakie dane przetwarza, jakie role istnieją, czy jest API, czy jest aplikacja mobilna, czy są integracje, czy test ma być na produkcji czy stagingu, czy oczekiwany jest retest i czy potrzebny jest raport pod audyt.
Nie trzeba znać wszystkich szczegółów technicznych. Dobra firma pomoże doprecyzować zakres. Ważne, żeby nie ukrywać złożoności — jeśli system ma pięć ról, API i panel admina, to musi być uwzględnione w czasie testu.
Co powinna zawierać dobra oferta
Dobra oferta opisuje zakres, założenia, ograniczenia, metodykę, harmonogram, raportowanie, retest, wymagania po stronie klienta, zasady komunikacji i wyłączenia. Jeżeli oferta mówi tylko „pentest aplikacji — cena X”, trudno później rozstrzygnąć, co miało być testowane.
Warto też ustalić, czy test obejmuje API, aplikację mobilną, infrastrukturę, chmurę, social engineering, kod źródłowy, czy tylko interfejs webowy. Te elementy są często mylone, a mają duży wpływ na czas i wynik.
Jak rozpoznać ofertę, która ma sens
Dobra oferta pentestu nie powinna zaczynać się i kończyć na liczbie dni. Powinna wyjaśniać zakres, założenia, wymagane dostępy, metodykę, sposób raportowania, zasady retestu, ograniczenia i odpowiedzialność po obu stronach. Jeżeli oferta obiecuje „pełne bezpieczeństwo” albo opiera się wyłącznie na automatycznym skanie, warto zachować ostrożność.
Pytania, które warto zadać przed zakupem
- czy otrzymamy próbkę raportu z PoC i rekomendacjami,
- czy podatności będą ręcznie zweryfikowane,
- czy raport zawiera CVSS, wpływ biznesowy i kryteria retestu,
- czy w zakresie jest omówienie wyników z zespołem technicznym,
- czy retest jest uwzględniony albo jasno wyceniony,
- jak wykonawca podchodzi do danych testowych, kont, logów i bezpieczeństwa operacyjnego.
Najtańsza oferta może być dobra dla prostego skanu, ale nie dla systemu, który obsługuje klientów, dane osobowe, płatności, dokumenty, role administracyjne lub procesy krytyczne dla firmy.