Penetrační test vs. skenování zranitelností: kdy co zvolit

Skenování zranitelností a penetrační test se v marketingu často zaměňují, ale řeší jiné otázky. Sken odpoví, jestli vaše systémy obsahují známé zranitelnosti z veřejných databází. Pentest navíc ukáže, jestli a jak by je reálný útočník dokázal zřetězit a co by tím získal. Která z disciplín (nebo obě) je vhodná pro vaši situaci a jak se na ně připravit, je rozhodnutí, které zpravidla potkává firmu jednou za 1–2 roky.

Co dělá skenování zranitelností?

Sken zranitelností (vulnerability scan) je primárně automatizovaná kontrola systémů, aplikací a síťových zařízení proti databázím známých zranitelností (CVE ↗, CWE, vendorové bulletiny). Nástroj typu Nessus, Qualys nebo OpenVAS prochází otevřené porty, identifikuje běžící služby a jejich verze a porovnává je s daty o tom, co je v dané verzi známé jako zranitelné. Výstupem je seznam nálezů se skóre CVSS ↗ a doporučenou opravou (typicky upgrade nebo konfigurační změna).

Sken najde to, co je veřejně známé. Nenajde logickou chybu v aplikaci, špatně nastavené oprávnění v cloudu, ani zranitelnost v in-house kódu, kterou ještě nikdo nepublikoval. Také neukáže, co by útočník s nálezem skutečně dokázal udělat: jestli z nízko-závažné chyby v jednom systému postaví privilege escalation v dalším.

Co dělá penetrační test?

Penetrační test je řízená simulace reálného útoku, kterou provádí specialista (etický hacker, penetrační tester). Na rozdíl od skenu není primárně automatizovaný. Tester kombinuje nástroje s manuální analýzou: hledá zranitelnosti v aplikační logice, snaží se obejít autorizaci a zřetězit dílčí nálezy do scénáře plné kompromitace. Pro webové aplikace se vychází z OWASP Top 10 ↗ a OWASP WSTG, pro mobilní aplikace z OWASP MASVS ↗, pro infrastrukturu z metodik jako NIST SP 800-115 ↗ nebo PTES.

Pentest má tři běžné varianty podle toho, kolik informací tester předem dostane:

• Black box: tester nezná interní strukturu, simuluje externího útočníka
• Gray box: dostane přístup standardního uživatele a snaží se eskalovat
• White box: má kompletní informace včetně zdrojového kódu a konfigurace

Volba se řídí scénářem, který chcete ověřit. Pro veřejnou aplikaci dává smysl začít gray boxem, protože většina útoků v praxi vychází z kompromitovaného uživatelského účtu, ne z anonymního průlomu na perimetru.

Co pentest najde, ale skener nikdy neuvidí

Pentest typicky odhaluje nálezy, na které skener z principu nedosáhne. Logickou chybu, kdy aplikace generuje sekvenční čísla objednávek a přepsáním ID v URL získáte cizí dokumenty. Insecure Direct Object Reference (IDOR), kdy přihlášený uživatel A změní user_id v API požadavku a získá data uživatele B. Server-Side Request Forgery (SSRF), kdy aplikace načítá obrázky z uživatelem zadané URL a útočník ji nasměruje na interní endpoint cloudových metadat. Tyto nálezy mívají vysoký business impact, ale skener je nezachytí, protože nejde o známou zranitelnost konkrétního produktu, ale o specifickou chybu vašeho kódu.

Hlavní rozdíly v kostce

Kdy zvolit co?

Žádná z metodik samotná nepokrývá kompletní obrázek. Volba se řídí tím, na co potřebujete odpovědět.

Kdy stačí samotné skenování

Skenování samotné dává smysl tam, kde provozujete převážně standardizovanou infrastrukturu bez vlastního kódu, potřebujete průběžnou patch hygienu napříč velkým počtem strojů, nebo regulátor explicitně vyžaduje pravidelné posouzení zranitelností a aplikační vrstva je bez významnějších úprav. Typicky firmy, které kupují hotová řešení a samy nevyvíjejí.

Kdy potřebujete pentest

Pentest má smysl objednat zejména v těchto situacích:

• Vyvíjíte vlastní aplikaci nebo nasazujete významnou změnu
• Aplikace zpracovává osobní nebo finanční data (GDPR, PCI DSS)
• Před významným launchem (nová e-commerce, B2B portál, veřejné API)
• Po incidentu, abyste ověřili, že obnovené prostředí už není zranitelné

V praxi: kombinace obou

Skenování běží kontinuálně a chytá známé regrese i opožděné patche. Pentest provádíte na klíčových aplikacích minimálně jednou ročně a při zásadních změnách. NIS2 ↗ i ISO 27001 takový režim implicitně předpokládají: hovoří o pravidelném posouzení zranitelností i o testování účinnosti bezpečnostních opatření, což sken bez následného pentestu sám neprokáže.

Co očekávat od reportu?

Sken vyprodukuje seznam nálezů s CVSS skórem, postiženým assetem a doporučenou opravou, typicky v PDF nebo strojově čitelném formátu pro import do ticketovacího systému. False positives je třeba ošetřit ručně, protože skener nezná kontext: nález na interním systému dostupném jen z VPN má jiný dopad než na veřejném perimetru.

Pentest report by měl obsahovat čtyři vrstvy:

• Executive summary pro vedení (zpravidla 1 stránka, bez technického žargonu)
• Detailní popis každého nálezu se severity, CVSS a důkazem (screenshot, PoC)
• Prioritizovaná doporučení s jasným indikátorem, co opravit dřív
• Retestovou klauzuli: po opravě tester ověří, že nález je skutečně uzavřený

Skenování odpoví na otázku „co je rozbitého?“. Pentest odpoví na otázku „kdyby útočník chtěl, dostane se?“

Pokud teprve začínáte, doporučujeme jednorázový penetrační test klíčové aplikace jako součást gap analýzy, ze které vznikne roadmapa. V druhém kroku zaveďte pravidelné skenování zranitelností jako součást operativní hygieny. Pro firmy s vlastním vývojem dává smysl pentest 1× ročně doplněný o automatický scan po každém významném deployi do produkce. Komplet bezpečnostního programu, do kterého obě disciplíny patří, vedeme jako cyber security governance přímo u zákazníka. Souvislost se širší regulací jsme rozebrali v článku o povinnostech NIS2.