Raport z testów penetracyjnych to główny produkt, za który płacisz. To dokument, który ma pomóc naprawić podatności, uzasadnić inwestycje w bezpieczeństwo i spełnić wymagania compliance. Niestety, jakość raportów na rynku jest bardzo zróżnicowana.
Ten artykuł wyjaśnia, czego powinieneś oczekiwać od profesjonalnego raportu i jak ocenić, czy otrzymałeś wartościowy deliverable.
Struktura profesjonalnego raportu
1. Executive Summary
Dla kogo: Zarząd, CISO, menedżerowie nietechniczni
Co powinno zawierać:
- Ogólna ocena poziomu bezpieczeństwa (np. skala 1-5 lub risk rating)
- Najważniejsze findings w języku biznesowym
- Kluczowe ryzyka dla organizacji
- Priorytetowe rekomendacje
- Porównanie z poprzednimi testami (jeśli dotyczy)
Długość: 1-2 strony
Czego unikać:
- Żargonu technicznego
- Szczegółów exploitacji
- List wszystkich findings
Przykład dobrego executive summary:
“Testy penetracyjne aplikacji XYZ wykazały wysoki poziom ryzyka (4/5). Zidentyfikowano 3 podatności krytyczne umożliwiające nieautoryzowany dostęp do danych klientów. Najbardziej pilna jest podatność SQL Injection w module logowania, która pozwala na ekstrakcję całej bazy użytkowników. Rekomendujemy natychmiastowe wdrożenie łatek przed uruchomieniem produkcyjnym.”
2. Metodyka i zakres
Co powinno zawierać:
- Dokładny opis zakresu testów (co było testowane)
- Wyłączenia (co nie było testowane i dlaczego)
- Zastosowana metodyka (OWASP, PTES, NIST)
- Narzędzia użyte podczas testów
- Daty i godziny testowania
- Typ testów (black/grey/white box)
- Ograniczenia (np. brak dostępu do produkcji)
Dlaczego to ważne:
- Pozwala zrozumieć kontekst findings
- Umożliwia powtórzenie testów
- Chroni obie strony (dokumentacja zakresu)
3. Findings (podatności)
Każda podatność powinna zawierać:
a) Identyfikator i tytuł
- Unikalny numer (np. VULN-001)
- Opisowy tytuł (np. “SQL Injection w formularzu logowania”)
b) Severity/Risk Rating
- Standardowa skala (Critical, High, Medium, Low, Informational)
- Uzasadnienie ratingu (CVSS score lub własna metodyka)
- Kontekst biznesowy wpływający na ocenę
c) Opis podatności
- Co to za problem
- Gdzie występuje (URL, endpoint, funkcja)
- Warunki wystąpienia
d) Proof of Concept (PoC)
- Kroki do reprodukcji
- Dowody (screenshots, payloady, logi)
- Wystarczające szczegóły do walidacji przez klienta
e) Wpływ (Impact)
- Co atakujący może osiągnąć
- Wpływ na CIA (Confidentiality, Integrity, Availability)
- Konsekwencje biznesowe
f) Rekomendacje naprawcze
- Konkretne kroki do naprawy
- Alternatywne rozwiązania (jeśli główne niemożliwe)
- Odniesienia do dokumentacji/best practices
g) Referencje
- CWE ID
- OWASP category
- CVE (jeśli dotyczy)
- Linki do dokumentacji
4. Podsumowanie findings
Tabela zbiorcza zawierająca:
- Wszystkie findings z severity
- Status (nowy, znany, naprawiony)
- Priorytet naprawy
- Właściciel (jeśli znany)
Wizualizacje:
- Wykres rozkładu severity
- Trend w czasie (jeśli powtarzające się testy)
- Breakdown po kategorii (web, infrastructure, config)
5. Załączniki techniczne
Dla zespołu technicznego:
- Surowe dane ze skanerów
- Pełne logi z testów
- Screenshoty i dowody
- Lista przetestowanych hostów/endpoints
- Timeline aktywności testowej
📚 Przeczytaj kompletny przewodnik: Testy Penetracyjne: Testy penetracyjne - rodzaje, metodologie, przebieg
Sygnały jakości vs czerwone flagi
Cechy wysokiej jakości raportu
✅ Customizacja do środowiska – findings odnoszą się do Twojej specyfiki ✅ Kontekst biznesowy – ocena ryzyka uwzględnia Twój biznes ✅ Actionable recommendations – wiesz co dokładnie zrobić ✅ Proof of Concept – możesz zweryfikować findings samodzielnie ✅ Czytelna struktura – łatwo znaleźć potrzebne informacje ✅ Spójna terminologia – konsekwentne nazewnictwo i formatowanie ✅ Aktualne referencje – linki do obecnej dokumentacji
Czerwone flagi niskiej jakości
❌ Generic content – opisy skopiowane z internetu ❌ Brak PoC – “znaleźliśmy podatność” bez dowodu ❌ Inconsistent ratings – podobne problemy z różnym severity ❌ Tylko scanner output – zrzuty ekranu z narzędzi bez analizy ❌ Nierealne rekomendacje – “przepisz całą aplikację” ❌ Brak kontekstu – techniczne opisy bez wpływu biznesowego ❌ Błędy faktyczne – pomyłki w nazwach systemów, datach, wersjach
Jak ocenić raport przed akceptacją
Checklist odbiorowy
Formalny:
- Raport dostarczony w terminie
- Format zgodny z umową (PDF, Word, dostęp do platformy)
- Podpisany/autoryzowany przez wykonawcę
- NDA i warunki poufności spełnione
Merytoryczny:
- Executive summary zrozumiałe dla nietechnicznego czytelnika
- Zakres zgodny z SOW
- Wszystkie systemy w scope zostały przetestowane
- Findings mają PoC umożliwiające weryfikację
- Recommendations są konkretne i wykonalne
- Severity ratings są spójne i uzasadnione
Techniczny:
- Możliwość reprodukcji findings przez własny zespół
- Brak false positives (walidacja próbki)
- Odkrycia mają sens w kontekście środowiska
- Referencje są aktualne i poprawne
Co zrobić, gdy raport nie spełnia oczekiwań
Krok 1: Dokumentuj problemy
Przygotuj listę konkretnych zastrzeżeń:
- Brakujące elementy
- Błędy faktyczne
- Niejasności wymagające wyjaśnienia
- Niezgodności z SOW
Krok 2: Komunikacja z dostawcą
Profesjonalni dostawcy oczekują feedback i poprawek. Wyślij:
- Listę zastrzeżeń
- Prośbę o korektę/uzupełnienie
- Termin na poprawki
Krok 3: Eskalacja (jeśli potrzebna)
Jeśli dostawca odmawia poprawek:
- Odwołaj się do umowy (SLA, definicja deliverables)
- Eskaluj do management po stronie dostawcy
- Rozważ wstrzymanie płatności końcowej
Krok 4: Dokumentacja na przyszłość
Niezależnie od wyniku:
- Zapisz lessons learned
- Zaktualizuj kryteria wyboru dostawców
- Doprecyzuj wymagania w przyszłych SOW
Maksymalizacja wartości z raportu
Prezentacja wyników
Poproś o spotkanie walkthrough:
- Prezentacja dla zarządu (executive level)
- Sesja techniczna dla zespołu IT/Dev
- Q&A z pentesterami
Priorytetyzacja napraw
Stwórz plan remediation:
- Krytyczne: natychmiast (dni)
- Wysokie: w najbliższym sprincie (tygodnie)
- Średnie: w backlogu (miesiące)
- Niskie: przy okazji innych zmian
Retest
Zaplanuj walidację napraw:
- Ustal zakres retestu
- Określ termin po wdrożeniu poprawek
- Budżetuj retest (często dodatkowy koszt)
Archiwizacja i trending
- Przechowuj raporty bezpiecznie
- Porównuj wyniki między testami
- Śledź metryki: liczba findings, MTTR, recurring issues
Formaty raportów
Tradycyjny PDF
Zalety: Formalny, łatwy do archiwizacji, compliance-friendly Wady: Statyczny, trudny do śledzenia remediacji
Platforma online
Zalety: Real-time updates, integracja z ticketami, dashboardy Wady: Zależność od dostawcy, kwestie poufności
Hybrid
Najlepsze z obu światów:
- Formalny PDF jako oficjalny deliverable
- Dostęp do platformy dla bieżącego zarządzania
- Export do własnych systemów (SIEM, ticketing)
Podsumowanie
Profesjonalny raport z pentestów to:
- Executive Summary – dla zarządu, w języku biznesowym
- Szczegółowe findings – z PoC, impact i rekomendacjami
- Actionable insights – wiesz co i jak naprawić
- Dokumentacja – metodyka, zakres, ograniczenia
Nie akceptuj raportów, które:
- Są głównie outputem ze skanera
- Nie mają proof-of-concept
- Zawierają generic content niezwiązany z Twoim środowiskiem
- Nie dają konkretnych kroków naprawczych
Raport to główny deliverable – masz prawo oczekiwać jakości.
Otrzymałeś raport z pentestów i masz wątpliwości co do jego jakości? Skontaktuj się z nami – możemy pomóc w ocenie i interpretacji wyników.
Powiązane pojęcia
Poznaj kluczowe terminy związane z tym artykułem w naszym słowniku cyberbezpieczeństwa:
- Analiza podatności kodu źródłowego — Analiza podatności kodu źródłowego to proces systematycznego badania kodu…
- Backup — Backup (kopia zapasowa) to proces tworzenia duplikatu danych w celu ich…
- Cyberbezpieczeństwo — Cyberbezpieczeństwo to zbiór technik, procesów i praktyk ochrony systemów IT,…
- NIS2 — NIS2 (Network and Information Security Directive 2) to dyrektywa UE…
- Skaner podatności — Skaner podatności to narzędzie do automatycznej identyfikacji, analizy i…
Dowiedz się więcej
Zapoznaj się z powiązanymi artykułami w naszej bazie wiedzy:
- Korzyści z regularnych testów penetracyjnych dla średnich przedsiębiorstw
- Analiza kosztów i korzyści z przeprowadzania testów penetracyjnych
- Najczęstsze mity na temat testów penetracyjnych
- Narzędzia do testów penetracyjnych - Przegląd najważniejszych rozwiązań
- Prawo i regulacje dotyczące testów penetracyjnych - Najważniejsze regulacje prawne
Sprawdź nasze usługi
Potrzebujesz wsparcia w zakresie cyberbezpieczeństwa? Sprawdź:
- Testy penetracyjne - identyfikacja podatności w infrastrukturze
- Red Team - zaawansowane symulacje ataków
