Penetrační test (pentest) sám o sobě nemá žádnou hodnotu – tu mu dává závěrečný report. Je to jediný hmatatelný výstup celého projektu a zároveň dokument, podle kterého se budete řídit při opravách, auditech i obhajobě investic do bezpečnosti před vedením. V tomto článku si projdeme, co všechno by měl kvalitní report penetračního testu obsahovat, ať už testujeme webovou aplikaci, nebo síťovou infrastrukturu.
Proč je report tak důležitý
Report penetračního testu plní hned několik rolí najednou. Pro management je důkazem o stavu zabezpečení a podkladem pro rozhodování o investicích. Pro vývojáře a administrátory je technickým návodem, co a jak opravit. Pro auditory a regulátory je dokladem souladu s normami jako ISO/IEC 27001, PCI DSS, NIS2 nebo zákonem o kybernetické bezpečnosti. A pro obchodní oddělení je často nutnou podmínkou ve výběrových řízeních u korporátních zákazníků.
Špatně napsaný report dokáže zničit i sebelepší test. Pokud nálezy nejsou srozumitelné, prioritizované a akčně popsané, skončí v šuplíku – a zranitelnosti zůstanou neopravené.
Struktura kvalitního reportu z penetračního testu
Mezinárodně uznávané metodiky (OWASP, PTES, NIST SP 800-115) i česká doporučení NÚKIBu se v základní struktuře shodují. Kvalitní report z penetračního testu obvykle obsahuje následující části.
1. Manažerské shrnutí (Executive Summary)
Manažerské shrnutí je nejčtenější část celého dokumentu a často jediná, kterou si přečte vedení firmy. Píše se netechnickým jazykem a vejde se zpravidla na jednu až dvě strany. Najdete v něm:
- cíl a rozsah testování stručně a srozumitelně,
- celkové hodnocení úrovně zabezpečení,
- počet nálezů rozdělený podle závažnosti,
- nejzávažnější rizika a jejich možný dopad na byznys,
- doporučené prioritní kroky a další postup.
Důležité je, aby manažer po přečtení této části věděl, jak na tom firma reálně je a kam směřovat zdroje – bez nutnosti rozumět HTTP hlavičkám nebo CVE identifikátorům.
2. Rozsah a cíle testování (Scope)
Tato kapitola přesně definuje, co bylo a co nebylo součástí testu. U penetračního testu webové aplikace zde najdete URL testovaného prostředí, role uživatelů, testované funkcionality, API endpointy a případně rozhraní třetích stran. U penetračního testu infrastruktury jsou uvedeny IP rozsahy, jednotlivé systémy, segmenty sítě nebo cloudové prostředí.
Vždy by zde mělo být explicitně uvedeno také to, co bylo z testování vyloučeno (např. produkční databáze, DDoS testy, sociální inženýrství) a jaká byla časová okna testu. Tato část chrání obě strany – objednatele i poskytovatele – a je klíčová pro audit.
3. Použitá metodika a přístup
Report by měl jasně popsat, podle jaké metodiky se testovalo. Mezi nejpoužívanější patří:
- OWASP Testing Guide a OWASP ASVS – standard pro testování webových aplikací,
- OWASP Top 10 a OWASP API Security Top 10 – nejčastější třídy zranitelností,
- PTES (Penetration Testing Execution Standard) – obecný rámec pro průběh pentestu,
- NIST SP 800-115 – doporučení pro technické testování bezpečnosti,
- MITRE ATT&CK – mapování technik útočníka.
Najdete zde také typ testu (black-box, grey-box, white-box), použité nástroje (např. Burp Suite, Nmap, Nessus, Metasploit, vlastní skripty) a poměr automatizovaného a manuálního testování. Manuální testování je u kvalitního pentestu vždy v převaze – automatické skenery samy o sobě nestačí.
4. Souhrn nálezů a statistiky
Před detailním technickým popisem bývá zařazen přehledový souhrn všech nálezů, typicky formou tabulky a grafu. Pro každý nález je uveden identifikátor, název, závažnost a stav. Tato kapitola umožňuje na první pohled vidět, kolik kritických, vysokých, středních a nízkých rizik bylo nalezeno a kde se kumulují.
5. Detailní popis jednotlivých zranitelností
Jádro celého reportu. Pro každý nález by mělo být uvedeno:
- Unikátní ID a název zranitelnosti,
- Závažnost vyjádřená kombinací slovního hodnocení (Kritická / Vysoká / Střední / Nízká / Informační) a CVSS skóre (verze 3.1 nebo 4.0) včetně vektoru,
- Kategorie zranitelnosti (např. OWASP Top 10, CWE identifikátor),
- Popis problému a jeho technické příčiny,
- Postižený komponent – konkrétní URL, parametr, IP adresa, služba, port,
- Kroky k reprodukci (Proof of Concept) – přesný návod, jak zranitelnost ověřit, včetně HTTP požadavků, screenshotů nebo ukázek odpovědí,
- Dopad na byznys – co konkrétně může útočník zneužitím získat (přístup k datům, převzetí účtu, eskalace oprávnění, narušení dostupnosti),
- Doporučená náprava – konkrétní, technologicky specifický návod, ne obecná fráze typu „ošetřete vstupy“.
Dobrý pentester nepíše jen „SQL Injection v parametru id“, ale doplní i ukázku payloadu, dotčený řádek kódu (pokud je znám), odkaz na bezpečné API daného frameworku a odhad pracnosti opravy.
6. Hodnocení rizika a prioritizace
Samotné CVSS skóre nestačí. Kvalitní report doplňuje technickou závažnost o byznysový kontext – jaká data jsou ohrožena, jak snadno je zranitelnost zneužitelná, zda je systém vystaven veřejně, nebo jen interně, a jaké jsou kompenzační kontroly. Z toho vychází finální prioritizace oprav, která dává smysl pro vaši konkrétní organizaci.
7. Doporučení a roadmapa
Vedle nápravy jednotlivých nálezů by report měl obsahovat i strategická doporučení: co změnit v procesech vývoje (např. zavedení SAST/DAST, bezpečnostní školení vývojářů), v architektuře (segmentace sítě, MFA, principy Zero Trust), v monitoringu a v reakci na incidenty. Často je součástí i návrh roadmapy, která říká, co řešit ihned, co v horizontu týdnů a co dlouhodobě.
8. Přílohy a technické artefakty
Do příloh patří výpisy z nástrojů, raw data ze skenů, kompletní seznam testovaných URL nebo IP adres, použité slovníky, případně skripty. V této části bývá také changelog dokumentu, distribuční seznam a kontakty na testery.
Specifika reportu pro webové aplikace vs. infrastrukturu
Přestože základní struktura je stejná, v detailech se report z penetračního testu webové aplikace a penetračního testu infrastruktury výrazně liší.
U webových aplikací a API se report soustředí na zranitelnosti typu Broken Access Control, Injection, SSRF, IDOR, chyby v autentizaci a správě session, business logic flaws nebo nesprávnou konfiguraci bezpečnostních hlaviček. Mapuje se obvykle na OWASP Top 10 a OWASP ASVS a u každého nálezu je důležitá ukázka HTTP požadavku a odpovědi.
U infrastrukturních testů (interních i externích) se report zaměřuje na zastaralé verze služeb, nezáplatované systémy, slabé konfigurace (TLS, SMB, RDP, SSH), chybějící segmentaci sítě, výchozí přihlašovací údaje, expozici manažerských rozhraní a možnosti laterálního pohybu nebo eskalace oprávnění v doméně. Mapuje se mimo jiné na MITRE ATT&CK a často obsahuje i schéma sítě s vyznačenými útočnými cestami.
CVSS – jak číst skóre závažnosti
CVSS (Common Vulnerability Scoring System) je standardizovaný způsob, jak vyjádřit závažnost zranitelnosti číslem od 0 do 10. Hrubé dělení vypadá takto:
- 9,0–10,0 Kritická – okamžité riziko, zpravidla vyžaduje opravu v řádu hodin až dnů,
- 7,0–8,9 Vysoká – závažné riziko, opravit v řádu dnů,
- 4,0–6,9 Střední – řešit plánovaně v rámci nejbližšího release,
- 0,1–3,9 Nízká – řešit při nejbližší příležitosti.
Vždy je vhodné mít vedle čísla i vektor (např. CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N), který říká, jak byla zranitelnost ohodnocena. Skóre by mělo být upraveno o environmentální metriky podle vašeho prostředí – jinak hrozí přeceňování i podceňování rizik.
Retest – nezbytná součást celého procesu
Kvalitní dodavatel po dokončení oprav nabízí retest nálezů, někdy také zvaný verifikační test. Jeho cílem je ověřit, že opravy skutečně fungují a že při jejich nasazení nevznikly nové zranitelnosti. Výstupem retestu je aktualizovaná verze reportu, kde má každý původní nález nový stav: opraveno / částečně opraveno / neopraveno / akceptováno jako riziko. Bez retestu nemáte jistotu, že váš systém je opravdu v lepším stavu než před testem.
Na co si dát při výběru dodavatele pozor
Před objednáním penetračního testu si vždy vyžádejte vzorový (anonymizovaný) report. Z něj poznáte úroveň dodavatele lépe než z jakékoliv prezentace. Sledujte zejména:
- zda je manažerské shrnutí skutečně srozumitelné neIT člověku,
- zda každý nález obsahuje konkrétní Proof of Concept a konkrétní doporučení,
- zda je report psaný česky (nebo v jazyce, který očekáváte) a bez generických frází,
- zda obsahuje mapování na uznávané standardy (OWASP, CWE, MITRE ATT&CK),
- zda je součástí nabídky i retest a prezentace výsledků.
Pozor také na reporty, které jsou v podstatě jen exportem z automatického skeneru. Skutečný pentest vždy obsahuje významný podíl manuální práce a nálezy, které žádný skener neumí najít – typicky chyby v business logice, autorizaci nebo řetězení zranitelností.
Závěr
Report penetračního testu není formalita, ale praktický nástroj pro zvyšování bezpečnosti. Měl by mluvit jak k vedení firmy, tak k vývojářům a administrátorům, být přesný, prioritizovaný a hlavně akční. Pokud testujete webové aplikace nebo infrastrukturu, vyžadujte report, který odpovídá výše popsané struktuře – ušetříte si tím čas, peníze a často i nervy během dalšího auditu.
Potřebujete penetrační test webové aplikace nebo infrastruktury a chcete vidět, jak vypadá náš vzorový report? Ozvěte se nám – rádi probereme váš konkrétní případ a navrhneme rozsah testování přesně na míru.