# Pentest, bug bounty, nebo sken zranitelností? Zvolit vhodný způsob prověření

> Pentest, sken zranitelností, nebo rovnou bug bounty? Co který způsob prověření najde, kde je slepý a v jakém pořadí dává smysl pro střední firmy.

Zdroj: https://phpsos.de/cs/blog/pentest-bugbounty-scan/  
Stav: 25.10.2026  
Poskytovatel: PHP SOS, Nouzová pomoc pro PHP a bezpečnost serverů. Okamžitá pomoc přes WhatsApp: https://wa.me/491736494914?text=Dobr%C3%BD%20den%2C%20PHP%20SOS%2C%20pot%C5%99ebujeme%20pomoc%20s%20na%C5%A1%C3%ADm%20PHP%20serverem.%20Firma%3A%20%E2%80%A6%20Web%3A%20%E2%80%A6

**Stručně:** Pentest, nebo sken zranitelností není otázka buď–anebo, ale otázka pořadí. Sken zranitelností automaticky najde známé zranitelnosti a chybné konfigurace, rychle a levně, ale s falešnými poplachy a slepými místy. Penetrační test cíleně prověřuje, čeho by útočník skutečně mohl dosáhnout. Program bug bounty otevírá prověřování externím badatelům a vyplatí se, až když jsou skeny a pentesty rutinou. Pro většinu malých a středních firem platí pořadí: pravidelně skenovat, nálezy odstraňovat, cíleně nechat testovat, zřídit místo pro hlášení zranitelností.

## Proč se otázka po PHP2Shell klade znovu

Kdo po PHP2Shell prověřuje svůj web online skenerem, může dostat matoucí výsledky. Jeden skener možná hlásí kritickou zranitelnost, ačkoli poskytovatel hostingu záplatu potvrdil. Jiný nehlásí nic, ačkoli server stále používá starou verzi PHP, protože údaj o verzi je skrytý.

Důvod spočívá ve způsobu práce. Mnoho skenerů odvozuje zranitelnost ze zobrazené verze. Distribuce ale nasazují backporty, aniž by se změnilo číslo verze; podle zpráv například Ubuntu 24.04 po aktualizaci dál ukazuje 8.3.6. Proč tomu tak je, vysvětluje [Proč php -v po aktualizaci ukazuje stejné číslo](https://phpsos.de/cs/blog/php-v-zeigt-alte-nummer/). Spolehlivý doklad poskytuje changelog balíčku, viz [Jak správně ověřit verzi PHP a stav záplat](https://phpsos.de/cs/php2shell/php-version-pruefen/).

To není argument proti skenerům, ale argument pro to, znát jejich hranice a kombinovat je s jinými postupy.

## Pentest, nebo sken zranitelností: tři postupy ve srovnání

| Kritérium | Sken zranitelností | Penetrační test | Bug bounty |
|---|---|---|---|
| Kdo prověřuje? | Automatizovaný nástroj | Pověření odborníci | Externí badatelé, často přes platformu |
| Co se najde? | Známé zranitelnosti, zastaralé verze, chybné konfigurace | Zneužitelné zranitelnosti, logické chyby, řetězení | Co badatelé najdou a nahlásí, často neobvyklé věci |
| Hloubka | Široká, ale povrchní | Hluboká v dohodnutém rozsahu | Různá, závisí na účastnících |
| Falešné poplachy | Časté | Vzácné, nálezy se dokládají | Mnoho hlášení, která je nutné posoudit |
| Plánovatelnost | Vysoká, libovolně opakovatelný | Vysoká, pevné období a rozsah | Nízká, hlášení přicházejí průběžně |
| Předpoklady ve firmě | Někdo, kdo výsledky vyhodnotí | Dohodnutý rozsah, testovací prostředí nebo servisní okno | Zralý proces posuzování, odstraňování a odměňování |
| Typické nasazení | Průběžně, např. měsíčně nebo po změnách | Před spuštěním, po větších změnách, pravidelně | Doplňkově u zralých, exponovaných aplikací |

Žádný z postupů nenahrazuje ostatní. Sken ukáže mnoho za krátkou dobu, pentest ukáže, na čem skutečně záleží, a bug bounty najde, na co nikdo nemyslel.

U skenerů se vyplatí i druhý pohled na druh skenu. Sken zvenčí vidí jen to, co vidí každý návštěvník, a verze musí často odhadovat z odpovědí serveru. Autentizovaný sken, při němž nástroj s vlastními přihlašovacími údaji načte nainstalované balíčky na serveru, dává výrazně spolehlivější výsledky, zejména u skutečného stavu balíčku PHP. Předpokládá ale, že k tomu zřídíte omezený přístup a dobře ho ochráníte. Pro závislosti vlastních aplikací v PHP existují zase vlastní kontrolní nástroje, například `composer audit` pro balíčky z Composeru.

## Rozumné pořadí pro malé a střední firmy

1. **Inventář a sken:** Nejdřív vědět, jaké weby a servery existují, pak pravidelně skenovat. Nálezy nepřebírat bez ověření, ale vyhodnocovat.
2. **Odstranit základy:** Odstranit zastaralý software, chybějící aktualizace a zjevné chybné konfigurace. Zadat pentest na nezáplatované systémy je plýtvání rozpočtem.
3. **Cílený penetrační test:** Pro nejdůležitější aplikace, například e-shop, zákaznický portál nebo rozhraní, s jasně dohodnutým rozsahem a následným testem.
4. **Kontrola kódu u vlastních vývojů:** Kdo provozuje vlastní aplikace v PHP, doplní test o prohlídku zdrojového kódu. Jak to probíhá, popisuje [Bezpečnostní code review pro projekty v PHP](https://phpsos.de/cs/blog/sicherheits-code-review-php/).
5. **Místo pro hlášení zranitelností:** Směrnice, jak mohou externí osoby hlásit zranitelnosti, a soubor security.txt podle RFC 9116 na `/.well-known/security.txt` s kontaktem a datem platnosti.
6. **Bug bounty, až základy stojí:** Teprve když se hlášení spolehlivě posuzují a zranitelnosti rychle odstraňují.

Aby z toho vznikl trvalý postup, vyplatí se pohled na [Řízení zranitelností pro střední firmy](https://phpsos.de/cs/blog/schwachstellenmanagement-mittelstand/).

## Co žádný z postupů neumí

Žádný způsob prověření nedokazuje, že je systém bezpečný. Ukazuje jen to, co se v určitém okamžiku určitými metodami našlo. Čistá zpráva z pentestu z jara nevypovídá nic o zranitelnosti jako PHP2Shell, která vyjde najevo v říjnu.

Stejně tak sken ani pentest nezodpoví otázku, zda už byl server kompromitován. K tomu je třeba hledání stop na samotném systému: procesy, soubory, cronjoby, účty, spojení. To je samostatný úkol s vlastními metodami.

> **Důležité:**
> Nechte prověřovat jen systémy, k nimž jste oprávněni, a u hostovaných systémů si předem ujasněte pravidla poskytovatele. Penetrační test vyžaduje písemné pověření s rozsahem, obdobím a kontaktními osobami.

## Kdy externí test nepotřebujete

Pro jednoduchý firemní web bez formulářů s citlivými daty, u poskytovatele hostingu, který spolehlivě instaluje aktualizace, často stačí pravidelný sken s kritickým vyhodnocením výsledků. Penetrační test by byl zde většinou nepřiměřený. Důležitější jsou aktuální software, silné přístupy a zálohy.

Externí test se vyplatí u e-shopů, portálů, vlastních vývojů, rozhraní na interní systémy a všude tam, kde zákazníci nebo normy vyžadují nezávislý doklad.

## Jak konkrétně pomáhá PHP SOS?

- Zřizujeme pravidelné skeny a vyhodnocujeme výsledky, včetně falešných poplachů způsobených backporty.
- Pomáháme odstranit základy dřív, než peníze poputují do pentestu.
- Společně se specializovanými partnery provádíme [bezpečnostní audity a penetrační testy](https://phpsos.de/cs/leistungen/sicherheitsaudit-penetrationstest/) s dohodnutým rozsahem a následným testem.
- Podporujeme zřízení místa pro hlášení zranitelností a souboru security.txt.

## Závěr

Sken, pentest a bug bounty jsou stupně, ne konkurenti. Kdo začne pravidelnými skeny, odstraní základy a pak nechá cíleně testovat, dostane za svůj rozpočet nejvíc bezpečnosti. Bug bounty je vrchol pro organizace, jejichž povinná jízda už sedí.


## Časté dotazy

**Jaký je rozdíl mezi pentestem a skenem zranitelností?**  
Sken zranitelností automaticky ověřuje, zda jsou rozpoznatelné známé zranitelnosti nebo chybné konfigurace. Penetrační test jde dál: Odborníci se v dohodnutém rámci snaží zranitelnosti skutečně zneužít a zřetězit a posuzují následky.

**Zjistí skener, zda je můj server proti PHP2Shell záplatován?**  
Jen omezeně. Mnoho skenerů čte zobrazenou verzi PHP. Pokud distribuce nasadí backport, číslo často zůstává stejné a skener hlásí zranitelnost, která je dávno uzavřena. Naopak se může zobrazit nové číslo, zatímco staré procesy ještě běží.

**Je program bug bounty něco pro malé firmy?**  
Většinou ještě ne. Bug bounty předpokládá, že se hlášení rychle posuzují a zranitelnosti rychle opravují. Dobrým začátkem je jednoduchá směrnice pro hlášení zranitelností se souborem security.txt.

**Smím svůj web prověřit skenerem sám?**  
Vlastní systémy zpravidla ano, pokud k tomu jste oprávněni. Pokud web leží u poskytovatele hostingu, předem si ujasněte, zda jsou skeny povoleny nebo se musí ohlásit. Cizí systémy prověřujte jen s písemným svolením provozovatele.

**Jak často by se měl pentest konat?**  
Pevné pravidlo neexistuje. Obvyklý je test před spuštěním nové aplikace, po větších změnách a v pravidelných odstupech, které určuje vaše riziko a případně požadavky zákazníků nebo norem.

## Zdroje

- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [security.txt (RFC 9116)](https://securitytxt.org/)
- [BSI](https://www.bsi.bund.de/)