Co jsou bug bounty programy a proč je firmy spouštějí
Bug bounty program je organizovaný rámec, ve kterém společnost legálně a řízeně vyzývá nezávislé výzkumníky (ethical hackery) k hledání bezpečnostních nedostatků a za kvalifikovaná hlášení vyplácí odměny. Cílem je zkrátit čas do odhalení, snížit náklady na incidenty a systematicky zvyšovat úroveň zabezpečení – doplňkově k interním testům, penetračním testům a bezpečnostním auditům. Tento článek vysvětluje principy fungování, rozsah, pravidla, právní a etické aspekty, rozhodování o odměnách, triáž, metriky i osvědčené postupy – bez technických exploitů.
Bug bounty vs. VDP: kde je hranice
- VDP (Vulnerability Disclosure Policy): otevřený kanál „nahlas chybu“ bez slibu odměny. Cílem je mít bezpečný a legální způsob hlášení zranitelností (security.txt, kontaktní formulář, PGP klíč).
- Bug bounty: rozšířené VDP s finančními odměnami, explicitním rozsahem, pravidly testování a SLA triáže. Očekává se aktivní, motivované testování vymezených cílů.
- Kdy začít: firmy často spouštějí VDP jako minimum a po vyzrání procesů (triáž, opravy, rozpočet) přecházejí na private bounty (pozvánky) a později public bounty.
Modely programů: private, public a managed
- Private: pouze pozvaní výzkumníci; nižší šum, kontrolovaný tok reportů, vhodné na start.
- Public: otevřené pro všechny; vyšší diverzita nálezů i reportů, vyžaduje zralou triáž a automatizaci.
- Managed (přes platformu): externí partner (např. triážní tým platformy) pomáhá filtrovat duplikáty, ověřovat dopad a udržovat kvalitu komunikace.
Rozsah (scope): co je „v sázce“ a co ne
Dobře definovaný rozsah je základem úspěchu. Měl by být konkrétní a stabilní, s možností průběžné aktualizace:
- In-scope: domény/eTLD+1, mobilní aplikace (platformy a verze), API, cloudová prostředí, hardware či IoT komponenty, pokud jsou připraveny na testování.
- Out-of-scope: služby třetích stran mimo kontrolu, sociální engineering, fyzické útoky, DoS/stres testy, credential stuffing na reálných účtech, manipulativní nákupy s reálnými škodami, přístup k osobním údajům mimo explicitní rámec.
- Citlivé zóny: produkční data a PII – preferován je sandbox nebo „Safe Data Program“ (syntetické účty). Pokud není k dispozici, pravidla musí přísně definovat limity interakce s daty.
Pravidla bezpečného testování (do no harm)
- Minimální dopad: zákaz nástrojů a technik způsobujících výpadky či degradaci služby; zákaz automatizovaného agresivního skenování produkce.
- Žádné prohlížení reálných PII: pokud narazíte na citlivé údaje, je přípustný pouze důkaz existence bez čtení obsahu (např. částečně redigovaný výstřižek) a okamžité přerušení testu.
- Žádné sdílení nebo zveřejnění mimo kanál programu; respektování embarga až do potvrzené opravy a schválené koordinované publikace.
Safe harbor: právní ochrana pro výzkumníky
Kvalitní program obsahuje klauzuli „safe harbor“, která deklaruje, že organizace nebude podnikat právní kroky proti výzkumníkovi, který:
- konal v dobré víře a dodržoval pravidla programu,
- překročil pouze minimálně nutné hranice k důkazu zranitelnosti,
- nepracoval s daty nad rámec demonstrování, nic neměnil ani neexfiltroval,
- bezodkladně hlásil a nezveřejnil bez koordinace.
Safe harbor má často geografické a legislativní specifika; firma by jej měla konzultovat s právníkem a jasně komunikovat v politice.
Životní cyklus reportu: od hlášení po odměnu
- Podání: výzkumník odešle report přes platformu/portál. Povinná pole: cíl, popis problému, dopad, krok-za-krokem reprodukce, důkazy (redigované).
- Triáž: tým ověří reprodukovatelnost, vliv, rozsah a duplicitnost. Výsledkem je kategorizace a předběžná závažnost.
- Potvrzení: report se označí jako triaged/confirmed nebo se zamítne (out-of-scope, informační, nedohledatelné, duplikát).
- Remediace: vlastník systému (product/engineer) obdrží ticket s detaily, doporučením a SLA podle závažnosti.
- Ověření opravy: retest; pokud je oprava účinná, report se uzavře (resolved/fixed).
- Odměna: výpočet podle zásad (viz níže), odeslání platby; případně „hall of fame“ zápis.
- Koordinovaná publikace (volitelná): po opravě může být publikován technický blog nebo poradné oznámení.
Závažnost a priorita: jak se rozhoduje bez emocí
- CVSS (standardizované skórování dopadu a pravděpodobnosti) a interní P1–P5 priority. Příklady:
- P1/Kritická: vzdálený neautentizovaný přístup k citlivým údajům nebo převzetí účtu v produkci.
- P2/Vysoká: eskalace oprávnění po přihlášení, obcházení silných bezpečnostních kontrol.
- P3/Střední: omezené úniky metadat, business logic issue s částečným dopadem.
- P4/Nízká: informační nálezy bez přímého dopadu, malé chyby konfigurace.
- Kritéria dopadu: rozsah (kolik uživatelů/dat), jednoduchost zneužití, přítomnost mitigací, viditelnost a reálnost scénáře.
Odměňování: transparentní zásady a tabulky
Program by měl předem zveřejnit bounty table a pravidla eskalace odměn:
- Rozpětí odměn dle priority (např. P1: 3 000–10 000 €, P2: 1 000–3 000 €, P3: 200–1 000 €, P4: do 200 € nebo „kudos“).
- Multiplikátory za řetězení více oblastí nebo cross-tenant dopad; de-multiplikátory při okrajových podmínkách a obtížně replikovatelných situacích.
- Duplikáty: odměna patří prvnímu kvalifikovanému reportu; pozdější reporty jsou „duplicate“ bez bounty, ale mohou dostat thanks.
- Platby a daně: metody (SEPA, platforma, krypto dle politiky), KYC/daňové náležitosti a termíny vyplácení.
Kvalitativní laťka reportu: co očekává triáž
- Reprodukce: jasné, minimální kroky, žádné „magické“ proměnné; uvedení testovacího účtu a prostředí.
- Dopad: popis, co konkrétně může útočník udělat a v jakém rozsahu (nejen „je to špatné“).
- Důkazy: redigované screenshoty, logy a identifikátory transakcí; žádné zbytečné exfiltrace či čtení reálných PII.
- Minimalismus: jen tolik interakcí se systémem, aby se potvrdila existence problému; žádné škody.
Komunikace s výzkumníkem: etika a profesionalita
- Průběžné aktualizace: potvrzení přijetí, stav triáže, odhadovaný čas na opravu/ověření; vyhnout se tichu.
- Jazyk: věcný, bez defenzivity; uznání přínosu i při zamítnutí, pokud report posunuje porozumění riziku.
- Zpětná vazba: u „informational“ reportů vysvětlit, co chybělo a jak zvýšit šanci na kvalifikaci příště.
Organizační připravenost: co mít hotové před startem
- Proces oprav (kdo má vlastnit fix, jaké SLA, jak se deployuje záplata).
- Ownership map cílů v scope (product owners, SRE, security champions).
- Bezpečné testovací účty, seedovaná data bez PII a logování přístupů výzkumníků.
- Incident playbook pro případ, že test odhalí kritickou chybu v produkci.
- Rozpočet a schválení odměn (finance, právní, DPO), spolu s daňovou a účetní evidencí.
Právní a regulační aspekty
- Smluvní podmínky programu (T&C): definice povoleného testování, safe harbor, práva k reportům, pravidla publikace.
- Ochrana osobních údajů: minimalizace práce s PII; pokud k ní dojde, výzkumník je poučen, jak okamžitě zastavit a nahlásit.
- Exportní a sektorové regulace: některé země/odvětví mohou mít omezení pro odměny nebo výzkumníky z určitých jurisdikcí.
Měření úspěchu: KPI a metriky zralosti
- MTTT/MTTR: čas do triáže a čas do opravy.
- Podíl kritických nálezů z externího programu oproti interním detekcím.
- Duplicity a šum: procento zamítnutých reportů; trend po úpravě rozsahu a pravidel.
- Úspora proti incidentům: odhad nákladů ušetřených díky odhaleným chybám před jejich zneužitím.
- Retence výzkumníků: kolik kvalitních reportérů se vrací a jaká je jejich spokojenost s komunikací a odměňováním.
Nejčastější chyby firem a jak se jim vyhnout
- Nejasný scope: vede k frustrujícím zamítnutím a ztrátě důvěry. Řešení: precizní seznam cílů, verzování a changelog.
- Ticho po reportu: výzkumníci migrují jinam. Řešení: SLA na odpověď (např. 72 h), automatizované potvrzení.
- Nekonzistentní odměny: pocit nespravedlnosti. Řešení: tabulky odměn a interní review board.
- Závislost jen na bounty: program není náhradou bezpečného SDLC, code review a testů; je doplňkem.
Nejčastější chyby výzkumníků a profesionální standardy
- Agresivní testování (DoS, bruteforce) bez povolení – vede k blokacím. Držte se pravidla minimálního dopadu.
- Nedostatečné reporty bez jasné reprodukce – snižují šanci na kvalifikaci.
- Předčasné zveřejnění – škodí uživatelům i reputaci, může vést k diskvalifikaci.
Programová ekonomie: náklady, přínosy a plánování rozpočtu
- Fixní náklady: interní triážní tým, tooling, čas inženýrů na opravy.
- Proměnné náklady: odměny a poplatky platformám.
- ROI: porovnání s náklady na tradiční testy a s rizikem incidentů; pravidelné vyhodnocování a úprava bounty tabulek.
Koordinovaná zveřejněnost (CVD) a publikace
- Embargo a termíny: typicky 60–120 dní dle složitosti opravy a koordinace s třetími stranami.
- Obsah: zaměřit se na poučení a změny procesů; vyhnout se detailním exploit krokům, pokud to není nezbytné pro pochopení rizika.
Checklist pro spuštění bug bounty programu
- Máme VDP a funkční kanál pro hlášení?
- Je definován scope (in/out), kontakty, safe harbor a pravidla testování?
- Existuje triážní proces, SLA a vlastníci oprav?
- Máme bounty tabulku, rozpočet a mechanismus plateb?
- Jsou připraveny testovací účty, syntetická data a logging?
- Interní review board pro spory o závažnost a odměny?
Checklist pro výzkumníky před podáním reportu
- Je cíl v scope a dodržuji pravidla (žádný DoS, žádné PII)?
- Mám reprodukční kroky a minimální důkaz dopadu?
- Jsou důkazy redigované a neobsahují citlivá data?
- Komunikuji výhradně přes oficiální kanál a respektuji embargo?
FAQ: stručné odpovědi
- Potřebuji speciální licenci
