Test penetracyjny (pentest) - co to jest i jak przebiega

Test penetracyjny - co to jest

Test penetracyjny, w skrócie pentest, odpowiada na pytanie: co konkretnie może zrobić atakujący w Twoim systemie? Tester działa jak napastnik - szuka podatności i bezpiecznie je wykorzystuje - ale w uzgodnionym zakresie, w ustalonych oknach czasowych i bez szkody dla systemu. Od ataku odróżniają go pisemna zgoda właściciela systemu i zasady testu spisane przed startem.

Wynikiem testu jest raport: lista potwierdzonych podatności z dowodami technicznymi, oceną powagi (zwykle w skali CVSS), opisem wpływu na biznes i rekomendacją naprawy każdej z nich.

Jak przebiega test penetracyjny

Ramy procesu opisują m.in. PTES i NIST SP 800-115. W praktyce test składa się z sześciu kroków:

1. Zakres i zasady - lista celów, podejście, konta testowe, okna czasowe, kontakt awaryjny i pisemna zgoda.
2. Rekonesans - rozpoznanie technologii, punktów wejścia i powierzchni ataku.
3. Wyszukiwanie podatności - ręczne testy wspierane narzędziami, według przyjętej metodyki.
4. Potwierdzenie i ocena - każdą podatność tester potwierdza bezpiecznym dowodem (Proof of Concept), sprawdza, czy da się ją połączyć z innymi w łańcuch ataku, i ocenia jej wpływ.
5. Raport i omówienie - część techniczna dla zespołu, który naprawia, i podsumowanie dla zarządu.
6. Retest - po naprawach tester sprawdza każdą podatność ponownie. Bez retestu raport opisuje stan sprzed poprawek.

Rodzaje testów penetracyjnych

Rodzaj testu wynika z tego, co jest celem, i każdy wymaga innej metodyki. Tak wygląda zakres testów w ofercie Innovix:

• aplikacje webowe - portale klientów, systemy transakcyjne, panele administracyjne (OWASP WSTG v4.2, OWASP Top 10:2025),
• API - REST, GraphQL, gRPC i webhooki (OWASP API Security Top 10 2023),
• aplikacje mobilne - iOS i Android razem z backendem, z którym się komunikują (OWASP MASVS 2.1),
• infrastruktura - perymetr widoczny z internetu oraz sieć wewnętrzna z Active Directory (NIST SP 800-115),
• chmura - konfiguracja i uprawnienia w AWS, Microsoft Azure i Google Cloud,
• kod źródłowy - test white box połączony z audytem kodu.

Zakres każdego z nich opisujemy osobno: testy penetracyjne aplikacji webowych, testy bezpieczeństwa API, testy aplikacji mobilnych, testy infrastruktury i sieci, testy bezpieczeństwa chmury i audyt kodu źródłowego.

Black box, grey box i white box

Podejście określa, ile tester wie o systemie na starcie:

• Black box - bez wiedzy i bez kont, z pozycji zewnętrznego atakującego. Pokazuje, co widać z internetu, ale zwykle nie sięga funkcji dostępnych po zalogowaniu.
• Grey box - z kontami użytkowników o różnych rolach i podstawową dokumentacją. Sprawdza autoryzację, dostęp do cudzych danych (np. IDOR) i logikę biznesową.
• White box - z pełną wiedzą: dokumentacją, architekturą i kodem źródłowym. Najdokładniej wskazuje przyczyny podatności.

W praktyce podejścia się łączy, np. black box z zewnątrz i grey box z kontami testowymi w jednym projekcie. Zestawienie podejść znajdziesz na stronie testów penetracyjnych.

Test penetracyjny a skan podatności i audyt

Skan podatności to automatyczne porównanie systemu z bazą znanych błędów: szybkie i powtarzalne, ale z fałszywymi alarmami i bez testów logiki biznesowej. Test penetracyjny prowadzi człowiek, który weryfikuje każde ustalenie i sprawdza, co da się z nim zrobić. Audyt zgodności bada z kolei, czy organizacja spełnia wymagania normy lub przepisu. Te narzędzia się uzupełniają, ale nie zastępują.

Testy penetracyjne w przepisach

Testowanie zabezpieczeń wymagają m.in. ustawa o krajowym systemie cyberbezpieczeństwa i DORA:

• Ustawa o KSC (NIS2) - system zarządzania bezpieczeństwem informacji podmiotów kluczowych i ważnych obejmuje m.in. bezpieczeństwo przy nabywaniu, rozwoju, utrzymaniu i eksploatacji systemu, w tym testowanie systemu informacyjnego (art. 8 ust. 1 pkt 2 lit. b). Pentest jest dobrym dowodem takiego testowania, ale nie zastępuje audytu bezpieczeństwa z art. 15 ustawy.
• DORA - podmioty inne niż mikroprzedsiębiorstwa ustanawiają oparty na ryzyku program testowania operacyjnej odporności cyfrowej (art. 24 ust. 1-3). Wśród przykładowych testów takiego programu art. 25 ust. 1 DORA wymienia wprost testy penetracyjne. Co najmniej raz w roku testuje się wszystkie systemy i aplikacje ICT wspierające krytyczne lub istotne funkcje (art. 24 ust. 6).

Wybrane podmioty finansowe przeprowadzają ponadto zaawansowane testy TLPT, nie rzadziej niż co trzy lata - zobacz testy TLPT w DORA. Stan prawny na 6 października 2026 r.

Typowe pomyłki

• "Pentest to automatyczny skan." Bez ręcznej weryfikacji i testów uprawnień skan nie jest testem penetracyjnym.
• "Brak ustaleń oznacza bezpieczny system." Test sprawdza określony zakres w określonym czasie. Nowe wydanie albo zmiana konfiguracji mogą wprowadzić nowe podatności, dlatego testy powtarza się po zmianach i cyklicznie.
• "Wystarczy test z zewnątrz." W systemach z kontami użytkowników najpoważniejsze błędy - dostęp do cudzych danych, eskalacja uprawnień - widać dopiero po zalogowaniu.

Powiązane pojęcia

• CVE - publiczny identyfikator znanej podatności, do którego odwołują się raporty i skanery.
• OWASP Top 10 - lista najważniejszych kategorii ryzyk aplikacji webowych.
• OWASP ASVS - katalog wymagań bezpieczeństwa aplikacji, przydatny przy odbiorze i testach.

Jak przygotować zapytanie i wybrać wykonawcę, opisujemy w artykule jak porównać oferty na testy penetracyjne. Pełny opis usługi, metodyki i raportu znajdziesz na stronie testów penetracyjnych.